PDP-11 disk image question

[Paul Koning]

> On Feb 18, 2019, at 5:24 PM, Bill Gunshannon via cctalk <cctalk at classiccmp.org> 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.

>> 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.

>> 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.

>> ...
>> 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?

>> 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.

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.

> 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.

	paul