18 Feb
2019
18 Feb
'19
4:39 p.m.
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:
Yes, but you said 4 partitions on a 2 GB disk, which is rather different from the actual
RA81 size.
...
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. 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. 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. ...
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. :-) 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!) 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