[Simh] Disk sizing

[Johnny Billquist]

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: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol