[Simh] Questions regarding future simulator development

Thu Apr 11 11:47:48 EDT 2013

> This communication may not represent my employer's views,
> if any, on the matters discussed.
> 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).
RP stood for "rotating pack", which meant removable disk pack. Until the 
RP07, which was a Massbus disk with a sealed HDA.  It probably should 
have been named RSxx - though the RS was "Rotating swap" (fast and 
small), and the RP07 was mass storage, at about 2 1/2 x an RP06.

RP0[1:3] are not Massbus disks; they use the ISS/Memorex interface that 
looks like an IBM channel.  In fact, IIRC, the drives were designed as 
3rd-party drives for 360s.  Controllers: RP11-C, RP10-C+DF10-C.

Emulating the PDP-11 implementation in simh is reasonable.  The PDP-10 
is not.

Docs:
PDP-11
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/handbooks/PDP11_PeripheralsHbk_1973.pdf 
(P4.294...)

http://bitsavers.trailing-edge.com/pdf/dec/unibus/DEC-11-HRPCA-C-D_RP11-C_Maint_Aug74.pdf 
(3.6-4)

PDP-10
http://bitsavers.trailing-edge.com/pdf/dec/pdp10/periph/DEC-10-HRPC-D_RP10-C_Disk_Pack_Synchronizer_Maint_Oct73.pdf 
(Mostly Chapter 3)
+
http://bitsavers.trailing-edge.com/pdf/dec/pdp10/periph/A-MN-DF10-C_MAN1_DF10-C_Data_Channel_Maintenance_Manual_Oct74.pdf 
(Mostly chapter 4)

Note, however, that the PDP-10 controller/channel would be difficult to 
fit into simh - it uses the memory/IO bus/IO instruction architecture of 
the KA/KI/KL processor, and the OS knows this.  So you'd have to 
implement one of the other processors...which means for the other 
disks/tapes, also implement the RH10/RH20; for comms the DC10 or 680 or 
DL10 (and it's PDP11) or (for the KL10: DN20 and/or the KLNIA KLIPA).  
Although not impossible, it would be a considerable source of entertainment.

Enjoy.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 10-Apr-13 22:37, Mark Pizzolato - Info Comm wrote:
> 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
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130411/1f900e0f/attachment-0002.bin>