[Simh] porting RL01 images to RL02

[Johnny Billquist]

On 2017-02-05 21:31, Mark Pizzolato wrote:
> A concept related to this discussion is simh's auto sizing of disks.  In the PDP11 and
> VAX simulators the RQ and RP disks use the sim_disk library to perform I/O to disk
> Images and/or physical disk devices.
>
> A relatively new feature that this code performs is that it make an attempt to peek
> into the image file being attached and determine the size of the file system that
> is in the container file.  Currently there is support for detecting the size of ODS2/5
> file systems and Ultrix partition tables.
>
> Peeking into the disk structure of these disks is necessary to properly auto size them.
> This is necessary since if disk images were created using a simh 3.x simulator, there
> was no auto sizing available AND a 3.x disk container only got to be full sized if some
> operation in the operating system actually wrote to the end of the disk.  RP disk
> images often got to be full sized when they were initially created when the BAD 144
> data was written to the last track when simh created the disk. RQ disk images didn't
> have this.  The simh 4.x code writes to the last simulated sector whenever a disk is
> created, so auto sizing merely based on size works for that case, but VMS and other
> OS disk images certainly exist that were created with a 3.x simulator.  Auto sizing is
> the default behavior when RQ and RP disks are attached, so a consistent way to
> determine (and verify) a disk's size must look into the disk's contents.

Ouch. Thanks for that bit of information, Mark. A bit ugly, but I can 
see that there is no easy solution to the problem.

> So, I'd like to expand the set of file system types that the auto sizing logic can perform
> to include RSTS disks and whatever might be commonly used with RSX and RT11.
>
> If anyone wants to take a direct crack at this, I'll be glad to include the results, and
> also add the validation logic to the other disk types that these systems supported
> (RK, RL, etc...).
>
> Alternatively, If someone has precise information about the file system data
> structures and how to walk them to determine the a disk's size, I'll take that.

I can certainly give all the information you need for ODS-1, which is 
what RSX use. The structures are pretty similar to ODS-2, so if you 
already have that, it should be very simple to add the ODS-1 stuff.
Unfortunately, this will only cover RSX systems. For RT-11 (as well as 
RSTS/E and others), you'll have to get someone else to help. I suspect 
Paul should know RSTS/E, if he just have the time.

Anyway, the gist in ODS-1 is that the size of the device is contained in 
a file called BITMAP.SYS (FID 2,2,0). In there, there is a 32-bit value 
saying what the size of the disk is in logical blocks.

The trick is finding BITMAP.SYS, given only the home block, which is the 
only known block at the start. The home block (which also happens to be 
a part of INDEXF.SYS (FID 1,1,0)) holds a pointer to where the file 
header bitmap area is (which is also a part of INDEXF.SYS) and the size 
of the file header bitmap. Continguous with this is the first 16 file 
headers, and each file header is one block. So, with this information, 
you can find the file header for BITMAP.SYS, and from there you get the 
size.

Now, I know this is way too fuzzy to actually implement from, but if you 
recognize this from ODS-2, then I can just give you the small details 
needed to adopt for ODS-1, and you should be set.

	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