PDP-11 disk image question

[Bill Gunshannon]

On 2/18/19 7:39 PM, Paul Koning wrote:
> 
> 
>> 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.

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