[Simh] Questions regarding future simulator development

Wed Apr 10 22:37:15 EDT 2013

On Wednesday, April 10, 2013 at 5:13 PM, Christian Gauger-Cosgrove wrote:
> Hello Mark,
> 
> On 10 April 2013 13:37, Mark Pizzolato - Info Comm <Mark at infocomm.com>
> wrote:
> > Anything is possible.  Someone could extend a particular simulator instance
> to implement a something (a GUI perhaps) which provided a way for a user
> to express the desire to perform one of these actions and to gather the
> needed details relating to the desired action.
> >
> > Hooks exist in the codebase to allow a particular simulator to provide what
> can be reasonably described as arbitrary extensions the basic simh
> framework.  These extensions can include both simulator specific commands
> and/or arbitrarily anything else.
> >
> That is understandable, though my question would have been better
> phrased as "would the rewrite of the code to separate the simulator
> command processor from the simulator CPU into different threads be
> something that requires a massive rewrite of the codebase?"

It might not actually require a separate thread.  The current simh code does many things by mere polling of sockets.  A separate thread might make this more efficient, but it probably wouldn't be required.  

> > Once again, anything is possible, but this would be a significant amount of
> work.   If there was some formal documentation available which described
> the RS03 and RS04 disks, then adding them to the pdp11_rq.c code would
> probably not be too hard.  Looking in the 'usual places' on bitsavers.org
> doesn't provide any information on these disk devices though.
> >
> Well it would be to the pdp11_rp.c code, but either way, they're just another
> form of MASSBUS disk, and in my quick browse through the pdp11_rp.c
> code, it looks likes like the various drives under its purview are only defined
> as their geometries. So to add the RS03 and RS04, all that would be needed
> to be added -- in my quick glance at the code, would only require entering
> the proper geometry for the devices.

They are just another form of MASSBUS disk, BUT do they share register functionality with the existing RP/RM disks?  A RS03 and RS04 document would describe these details.  The geometry is certainly necessary, but it is not complete.  As far as I know, the RS03/RS04 were never supported on VMS. So I don't have access to driver source listings to 1) analyze what the host software is expecting and 2) to actually test things out.

> > Meanwhile, there already exists support for many disks within the current
> simh codebase.  There is existing support for 4 RQDX controllers each of
> which can support 4 drives.  The RL controller can support up to 4 drives.  The
> RP can support up to 8 drives.  The HK (RK611) can support up to 8 drives.
> >
> Speaking of the RK611, I noticed a problem, whereby an RK07 errors out in
> RSTS/E (10.1-L) with "device not ready" or something similar, while it works
> just fine with an RK06... weird.

There have been fixes to the RK611 implementation.  Please try the code at https://github.com/simh/simh/archive/master.zip If you still see a problem, we can work out a way to reproduce and fix the issue.

> There is only one set of drives that isn't implemented in SIMH at present, is
> the pre-MASSBUS RP drives (on the actual RP11 controller, so RP01, RP02 and
> RP03). But I don't think much if any still extant software even supports the
> RP0[1:3].

Given that, I'm not too worried.  Once again, If you can come up with detailed device documentation we can look at what it will take to add this functionality into simh.  Maybe someone has visibility into a PDP11 OS device driver source for these devices and can confirm at least that the driver is shared between either the RP disks or the RM disks.  If so, then maybe all we're talking about is adding a different drive type.  If, the register set/driver is different, then we'll need more detail....

> > Simulated systems can easily be configured which could have never exist in
> the real hardware space due to issues like 1) cost, 2) concurrency of
> technology, 3) power/bus loading constraints, etc.  Yes, you can't currently
> configure a system which could have arbitrarily been designed with real
> hardware, but you can also configure many system configurations which
> exceed many of the assumptions which existed when working with real
> hardware.
> >
> Of course it is possible to "misconfigure" a system, But I know in my own
> case, I try to keep any system configurations limited to what was actually
> possible (with the occasional waiver, e.g. having the RP drive series plus its
> associated RH controller on a QBUS system with the justification of
> "somewhere there is a third party board that let's you put a CDC 9766 on a
> QBUS box".

These choices existed, but when the 3rd party Qbus controller business really blossomed in the mid 80's the MSCP devices were already well established and using such a controller let you use the natural size of whatever SMD disk you connected to them.

> Plus the simulated system has allowed the debugging of software with
> proper configuration issues. (The example of choice being the "XVM/DOS
> doesn't play nice with an RF15 with 8 platters, only a maximum of 7.")

I think those cases were more likely on the Unibus systems.

- Mark