[Simh] Recent bug fixes

[Mark Pizzolato - Info Comm]

On Sunday, October 13, 2013 at 2:21 PM, R.Voorhorst wrote:
> Bob Supnik <bob at ...> writes:
> > Message: 5
> > Date: Fri, 06 Sep 2013 17:40:19 +0200
> > From: Johnny Billquist<bqt at ...>
> > To:simh at ...
> > Subject: Re: [Simh] Various PDP11 fixes and enhancements
> > On 2013-09-06 17:13, Bob Supnik wrote:
> > > 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk.
> > > Only tested with RT11, as M+ and RSTS/E support requires a unique
> > > SYSGENs. Feel free to hack on it.
> >
> > Is this something specific to a third massbus, or just a case of the
> > RS03/RS04 devices as such? I mean, on M+ you can have all type of
> > devices on the same massbus.
> >
> > >>> The Massbus implementation links an RH to a single device type.
> > >>> This is an artifact of the simulator, not of real life.
> > >>> Three RH adapters allows for 8 RP/RM units, 8 TU units, and 8 RS units.
> > [...]
> > /Bob Supnik
> >
> Initially testing this on RSX11MP and RstsE required some toying with Sysgen.
> I did so with Rsx11MPlus 4.6-BL87 (only, not with M itself but there will
> be little differences with respect to RH behaviour) and RstsE V10.1-L.
> 
> We have the following case:
> The Massbus device variants on both OS's are:
> 
> 1. RP's (except RP07 > DB:),
> 2. RM's (and RP07 > DR:),
> 3. RS'es (RS03/04 > DS:) and
> 4. TU's (TU10-77 > MM:).
> 
> Both OS's support 4 RHX maximum as does the hardware.
> 
> At the moment Simh supports only 3 RH's of the maximum of 4, but
> moreover ties the different devicetype groups to one RH controller 
> per group in a fixed sequential order: RP/RM on RHA, TU on RHB and 
> RS on RHC.
>
> Simh also combines the devicetypes RP (DB:)and RM (DR:) into one group of
> maximally 8 drives tied to (one) RH(A) only, thereby limiting the maximum
> amount of 16 disks.
> 
> In supporting this Simh configuration, RSX11MPlus is the most flexible and
> forgiving as it's Sygen supports 2 modes:
> 
> 1. Mixed Massbus mode where every devicetype can be tied to any port on
> any Massbus controller, and
> 2. Traditional mode with all device types on separate RH controllers.
> 
> RSX11MP shows it's great configurational flexibility bedcause in both modes
> every RH  controller can be tied to any required Csr/Vector address combination
> 
> 
> 
> RstsE 10.1 is much more choosy and supports only the traditional
> configuration of every of the total 4 devicetypes on one specific
> controller, however every type is even tied to a specific RHX with a fixed
> certain Csr and Vector address; while Rsts does allow for changing the Csr
> afterwards, that is not the case for the vector address.
> 
> RstsE expects the following types on the following RH's on Csr/Vectors:
> 
> 1. DB drives (RP04-06) are expected on         RH#? (RB:) with Csr=176700
> Vector=254
> 2. DR drives (RMxx, RP07) are expected on  RH#? (RR:)with Csr=176300
> Vector=150
> 3. DS drives (RS03/04) are expected on          RH#? (RS:) with Csr=172040
> Vector=204
> 4. TU drives (TU15-77) are expected on          RH#? (TU:) with Csr=172440
> Vector=224
> 
> The current Simh implementation is hampering a Rsts configuration in  two
> ways:
> 
> 1. Standard only RP's drives (DB:) can be specified because of it's ties
> with the Simh RHA.
> 2. There is no controller for RM (DR:) drives so the maximum $ of 16 drives
> is limited to 8.
> 
> Point 1 can be alleviated by forcing in Simh the RHA controller to the
> Csr/Vector as expected for RM drives; then however the RP drives
> disappear;
>
> Conclusion is as follows:
> 
> 1. The traditional mode on Rsx and Rsts is not completely supported.
> 2. Mixed mode in RSX is not supported unless restricted to a RP/RM
> combination on RHA only.
> 3. Having RP drives also doubling up as RM drives in traditional mode
> confuses things in the OS as RP drives remain DB' s.
> 
> Solution to support the full traditional modes while retaining the tying
> mechanism of RH' s to device groups:
> 
> 1. Split the RP multifunction group and expand to an 8 RP (DB) and an 8 RM
> (DR) group.
> 2. Introduce a 4th RH tied to the RM group.
> 
> Solution to support complete Rsx11 mixed mode:
> 
> 1. Split the RP multifunction group and expand to an 8 RP (DB) and an 8 RM
> (DR) group.
> 2. Introduce an attach function in the RH controller in the same way that
> Rsx handles mixed mode: ATT RHXi YYj with X=one of (A, B, C, D), YY=one of
> (RP, RM, RS, TU) and i,j=one of (1..9). Attachment can then be spefied to a
> group (the original setup: ATT RHA RP)
> 
> 
> 
>  or per unit: ATT RHA3 TU5.
> 
> In all this your mileage may vary according to the amount of work to
> realise things.
> 
> 
> 
> Supporting the full traditional mode with an extra RH and
> 
> splitting/expanding the RP/RM might deliver the optimum in a cost effective
> way.
> 
> On RstsE 10.1-L fooling RHA with a different Csr/vector pair looked as
> 
> follows:
> 
> RSTS V10.1-L RSTS   (DU0) INIT V10.1-0L
> 
> 13.10.12 23:25
> 
> Start timesharing? <Yes> NO
> Option: <Start> HA
> 
>   HARDWR suboption? LI
> 
>   Name  Address Vector  Comments
>   TT0:   177560   060
>   RS0:   172040   204   Units: 0(RS04) 1(RS04) 2(RS04) 3(RS04)
>                                4(RS04) 5(RS04) 6(RS04) 7(RS04)
>   RL0:   174400   160   Units: 0(RL01) 1(RL01) 2(RL01) 3(RL01)
>   RR0:   176300   150   Units: 0(RM03) 1(RM03) 2(RM03) 3(RM03)
>                                4(RM03) 5(RM03) 6(RM03) 7(RM03)
>   RU0:   172150  P310   RQDX3   Units: 0(RA90) 1(RD54) 2(RD54) 3(RX50)
>   MU0:   174500  P314   TK50    Units: 0(TK50) 1(TK50) 2(TK50) 3(TK50)
>   TU0:   172440   224   Units: 0(TE16 @TM03 #0) 1(TE16 @TM03 #0)
>                                2(TE16 @TM03 #0) 3(TE16 @TM03 #0)
>                                4(TE16 @TM03 #0) 5(TE16 @TM03 #0)
>                                6(TE16 @TM03 #0) 7(TE16 @TM03 #0)
>   PR0:   177550   070
>   PP0:   177554   074
>   LP0:   177514   200
>   RX0:   177170   264   Units: 0(RX01) 1(RX01)
>   CR0:   177160   230
>   DZ0:   160100   300   Sub-lines: 8
>   KW11L  177546   100
>   Hertz = 50.
>   Other: FPU, CIS, 22-Bit, Data space, J11-E CPU
> 
>   HARDWR suboption?

The massbus relationships are indeed hard coded.  This was done a long time ago and many other details depend on the resulting hard coded subtleties.  The work involved to allow arbitrary connection of massbus devices to arbitrary massbuses would be very significant for very little gain.  From what I read above, the only real gain would seem to be providing more available disk devices to the RSTS OS.  I suspect that RSTS already has access to the 16 RQ disks which can each be arbitrarily sized, so there really should be no reasonable limit to available disks for a RSRS system.

Theoretically, what you suggest could be done.  It would be a large effort.  You are free to explore the details needed to implement it yourself, but you'll probably find the work involved along with the resulting gain is indeed not worth the effort.

> In the mean time, as a funny side effect with the new RHC/RS03,04’s
> suddenly popping up, the venerable VAX 11/780 and 8600/50 were suddenly
> found trying to recognize the even more arcane RS03/04 drives on RHC and,
> while autogenning in the startup phase, trying desperately to find a non-
> existing RSDRIVER for every drive configured and massively complaining
> about it. Needless to say these efforts were in vain J but it kept one
> pondering what was going on at that instant ...

How/where did you observe this?  The RHC was definitely NOT added to the VAX7x0_mba implementation and the RS device was also NOT added to the VAX780 configuration.  Any problems you are seeing in this domain would be bugs.  Please open an issue on github describing the details of what you are seeing and how they can be recreated.

- Mark