On 2017-02-06 19:38, Mark Pizzolato wrote:
On Sunday, February 5, 2017 at 4:41 PM, Johnny Billquist wrote:
On 2017-02-06 01:11, Johnny Billquist wrote:
On 2017-02-06 00:40, Mark Pizzolato wrote:
Now that Johnny pointed me to the ODS1 spec, I'm adding the
appropriate file
system structure definitions right now. I have enough to solve this
case.
Mark, I found a slightly revised ODS-1 spec that gives an alternative
interpretation of the SCB block in BITMAP.SYS on ODS-1 for large disks.
DEC did a revision.
Putting that up as well, as http://mim.update.uu.se/ods1-1
Once you provided the earlier document, I looked to see if it was available
on Bitsavers since having it amongst all the other archived documents
would seem to make sense. What I found was this newer document
which I actually worked from.
Ah. Excellent! I found the newer version in a Multitasker issue (the SIG
Newsletter at DECUS for RSX), so it was published for anyone to read. I
suspect Al Kossov got a copy from someone a long time ago already.
And the size limit mentioned is not correct. I seem to remember there
is also a file level 403, and the limit of ODS-1 with 3+1 retrieval
pointers are in fact 8G. I don't think that file level changes
anything on how you find the disk size, though.
I'll try to find if I have any documentation for really large ODS-1 volumes. But
for now, I can report this:
They seem to still use 402 of H.VLEV
In the SCB of BITMAP.SYS, all four initial bytes (number of storage bitmap
blocks) are 0. And then comes disk size. And then the number of blocks for the
bitmaps comes after the disk size instead.
I can provide example dumps of the SCB if you need any.
Rather than that, please just give the latest github code a spin to see if the
ODS1 volumes you have at your fingertips are correctly recognized when they
are attached to a RP or RQ device.
What can I expect to see? I mean, my images are already the correct size
anyway, so the sizing should not result in any difference than today...
I'll try it when I get a little time. Maybe this weekend. I guess it's
time I updated my version of simh anyway. :-)
Bringing this functionality to other disk types is a project for another day and
might not provide much value since most, if not all, of them had their last
track written with BAD144 data.
Well, in the case of ODS, the code should work fine on any kind of disk,
so there is really no reason to limit it to some controllers.
That said, all RP disks should have BAD144 data written anyway. Standard
procedure in RSX is that before you create a file system, you should let
the bad block scanner go over the disk, and create the BAD144 data,
which the file system initialization code tries to read, in order to
remove bad blocks from the usable filesystem.
An interesting effect is that now all of the ODS1 and ODS2 disk images which
were originally created on other device types (RK, RL, etc.) can be attached
to an RQ controller and be properly sized.
Yup. But it will cause them to be accessed with a "strange" controller,
so don't try and boot them. :-)
I looked at the RT11 specs and that's a project I won't be undertaking.
I would suspect that just running through the directory list in RT-11
should give you the size of the disk, since I think all space on the
disk is always accounted for in the directory list.
But I am not going to try and work on that one either.
Meanwhile, we could use support for detecting RSTS disk sizes...
Paul...? :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
