[Simh] Dec-10 Day announcement from Living Computers: Museum + Labs

Paul Koning paulkoning at comcast.net
Mon Dec 11 11:44:50 EST 2017



> On Dec 11, 2017, at 11:37 AM, Johnny Billquist <bqt at softjar.se> wrote:
> 
> Paul. The RM06 has its own massbus id. The device can also emulate existing dec disks, which means no changes needed. But when identified as an RM06 it becomes a bit more interesting as this device does not have a fixed size. Similar to mscp in that way. It has fixed numbers for sectors/track and tracks/cylinder but the number of cylinders depends on the actual disk. So the os must figure disk size out at runtime.
> 
> I know rsx does it, as I have the sources. I would expect that Mentec also added this for RSTS/E but I have not actually checked that.

I don't know that Mentec did anything to RSTS other than change the logo on the cover of the manuals. 

RSTS handles non-MSCP disks by determining the drive type, then looking up the geometry in a table.  So for Massbus, there's a table that lists Massbus ID values and the corresponding sector/track/cylinder counts.  There isn't any support for a given ID having varying size.

It certainly would be possible to write code that pokes at a disk to see how big it is, but RSTS doesn't do that.  Well, except for the very unofficial PRO support I added, which is buried in the V10 code of INIT but not otherwise exposed.  That distinguishes some PRO disk models by doing I/O to check the size, and/or to see how many heads there are.  But for non-Pro PDP11s, RSTS doesn't do it that way.

Unlike RT or RSX, RSTS was never intended to be customized by users, so there is no support for user-written drivers or any easy way to handle peripherals not supplied by DEC.   It's certainly possible to do the work if you have the sources, but neither the process of writing drivers not the way to build an OS are documented.

	paul



More information about the Simh mailing list