On 2/18/19 7:39 PM, Paul Koning wrote: > > >> On Feb 18, 2019, at 5:24 PM, Bill Gunshannon via cctalk >> <[email protected]> wrote: >> >> On 2/18/19 4:35 PM, Paul Koning wrote: >>> >>> ... >>> For the case of RSTS, small or large is not a consideration. What matters, >>> as I mentioned, is that RSTS has a file system layout that is dependent on >>> the device size. So (unlike some other file systems like FAT32) is isn't >>> always valid to do an image copy from one device to a larger device. >> >> My reference to small vs. large had to do with moving images from >> SIMH virtual disks to real physical disks. I have done it with >> small disks which means the physical format of the virtual disk >> in SIMH does, in fact, match the format of a\real equivalents. >> At least for smaller disks. I am fairly certain I have heard of >> people doing it with RQ disks as well. This was my first foray >> into trying to do it with something the size of an RA disk. >> >> Theoretically, the SIMH emulated RA81 and the CMD emulated real >> disk RA81 should be the same size because they are both supposed >> to be RA81's. > > Yes, but you said 4 partitions on a 2 GB disk, which is rather different from > the actual RA81 size.
According to the manual the first three will be RA81 and the last partition whatever is left over. So the part I was using is supposed to be the same as a real RA81. > >>> If the input and output devices are the same size, and error free, image >>> copy is always valid. MSCP devices are error free; >> >> All of this sounds good on paper, but so far I have had no luck >> actually accomplishing it. I have tried copying with different block >> sizes, copying from different media used to move the image. The results >> are always the same. > > You could read back the copy and compare it with the original. But I can > tell you that a properly executed image copy WILL work. I suppose one > question is whether dd is actually such a program. When I said I have seen others claim to do it, they usually claim to have done it with dd. I do know that VTServer worked for RL02 and RX/RY disks because I have done it myself. But the idea of doing this with a 400MB disk at 9600 baud seems rather futile. :-) > >>> some older devices are also normally error free (like RK05 or RP03). >>> >>> It would be interesting if you can post the exact sizes in blocks of the >>> SIMH image, and the real disk you copied it to. That would help confirm my >>> guess that it's a size issue. >> >> If it's a size issue then one of them is doing it wrong because the >> size of an RA81 constant. > > If you change the transfer address in the boot block by +2, you'll be dropped > into ODT immediately after INIT is loaded by the boot loader. You can then > proceed from the break and ODT will be called again if a fatal error occurs > (such as the "init not found" message). > > You can then look at the disk size table. Use PATCH on your SIMH copy of the > system to find the address of DU$SZL and DU$SZM, those are the tables of low > and high 16 bits of the device size for each DU unit (indexed by unit > number). The number there will tell you what INIT heard from the controller. > Interesting. Not sure I am ready to go that far into it at this point. Still just looking for some way to move the data. I am thinking more and more that an RD31 or RD33 might be a good stepping stone. >>> ... >>> The steps for bare metal restore go roughly like this: >>> >>> 1. Boot a kit >> >> And there is the problem. If I had a kitI would just do a clean >> install on the 11/93. :-) > > What kit device do you need? Well, all I really have are CQD module which does MSCP and TMSCP over SCSI. I have other controllers that might be coaxed into doing RX50 or RX33 but I haven't used one of them in ages, either. And, as I said earlier TU58 in emulation. On a PC right now but I have all the parts to build a hardware emulator. > >>> 2. Use the DSKINT option to initialize the output disk >>> 3. Use the COPY option to copy the minimal files to the output disk, which >>> is then booted. >>> 4. Start that minimal system on the output disk. >>> 5. Use RESTORE to copy everything from your backup. >>> >>> I don't remember if there is a documented procedure for creating a minimal >>> kit. For disk based ones, it's pretty simple: >>> >>> a. Initialize the kit device as read-only. >>> b. Mount it, overriding the read-only setting. >>> c. Copy the minimal files. >>> d. Hook INIT.SYS. >>> e. To test it, boot the kit; it should boot correctly and act as a kit (by >>> offering to copy to the output device rather than by going to the usual >>> INIT prompt). >>> >>> You can do this for any RSTS disk that's big enough, and for which INIT >>> still has a boot loader. For example, even in V10.1 you can boot an RK05, >>> so you can make an RK05 kit. >>> >>> If the device isn't big enough for all the minimal files, it gets a bit >>> tricky but it still can be done; the Micro-RSTS RX50 based kit is an >>> example. I don't have the details at my fingertips but I can dig them out >>> if needed. >> >> Well, this sounds like the most interesting and possible way. >> If it cold be done on RX50's it should be doable on other >> media. Maybe RX33 or maybe even TU58. (Emulated, of course!) > > TU58, no -- that's not a file structured device on RSTS. RX33 is an RX50 in > a different physical package if I remember -- 800 block MSCP device. That > works fine, subject to the necessary tricks to get the files on the floppies > and do the switching. No, RX50 was a strange DEC format. RX33 is a 1.2M floppy. > > Checking... The way it's done is that INIT.SYS has to be on the first > floppy, of course, which is what you boot. Then the other needed files can > be spread over other floppies as needed to fit (whole files per floppy). All > but the last floppy contain a name.EOV file where "name" is the pack label of > the next floppy to use. The content of the file is printed on the console as > a prompt; it's a null terminated string. That's going to be fun to try whether I find another solution or not. > >> I haven't given up yet but it is turniong out to be a lot more >> of a challenge than I expected. I wonder what the chances are >> I could get something like an RD31 or RD33 to work and use it as >> an intermediate for the big disk setup? Good thing it's only >> a hobby cause I certainly can't see anyone paying me to do this >> kind of stuff. >> >> bill > > You mean build an initial system on a small disk, and then load the rest onto > a big disk some other way? Sure, that should work fine. I was thinking build a minimal system on a smaller disk and and then use it and backup to move the RA81 system to real hardware and then use that for playing with. bill
