Mark and John,
Summarizing...The disks in the RL01 directory are 5MB, which is the RL01
disk size I believed, but if they are RL02, why would I not use "RL02" in
the simh commands?
For example the code Mark wrote with John's changes, should it not be
rlo2,
not rl01?
sim> sho cpu
CPU 11/40, idle enabled, autoconfiguration enabled
64KB
sim> sh rl
RL RL11, address=17774400-17774411, vector=160, 4 units
RL0 2621KW, attached to rsxm32.rl01, on line
write enabled, RL01
RL1 2621KW, attached to excprv.rl01, on line
write enabled, RL01
RL2 2621KW, attached to mcrsrc.rl01, on lineBRU (Backup and restore
write enabled, RL01
RL3 2621KW, attached to rlutil.rl01, on line
write enabled, RL01
sim> b rl
The v3.2 version I have from bitsavers has the baseline disk a few
bytes larger than
an RL01 so simH autosized it (incorrectly) to an RL02. Hopefully
Mark?s new sizing
code should avoid this in the future. To copy an RL01 RSX disk to
an RL02 you can use
BRU (Backup and Restore Utility). Get the magtape image
BB-L974F-BC_RSX11M_4.5_BRU64K.tap from bitsavers. Attach your
RL01 image to
rl0 and create a new RL02 image attached to rl1. Boot the magtape:
first device is dl0:
second device is dl1:
At the ?>? prompt type ?run bru?
At the ?BRU>? prompt type ?/init dl0: dl1:? and it will perform
the copy. If you copied the
baseline system, you should be able to boot the newly created RL02.
John.
So essentially what you're saying is that simH by luck converted the disk
to RL02 because it was converted to disk format incorrectly, and that at
some point the disk image ballooned to 10MB from 5MB? Above you see the
output of
simh> sh rl
...after the re-sizing of the disk, would this config fail to be able to
load the disks because they were resized? At some point these RL01's were
changed to RL02s? Or can you with simH simply load an RL02 disk even
though you set the rl = RL01? See what I mean?
Bill