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.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).
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-11http://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-10http://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 <[email protected]> wrote:Anything is possible. Someone could extend a particular simulator instanceto 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 whatcan 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 ofwork. 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 currentsimh 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 inthe 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 [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
