[Simh] Recent bug fixes

Sun Oct 13 17:20:43 EDT 2013

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

> Message-ID:<5229F763.8090807 at ...>

> Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> 

> 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.

> 

> > 3. PDP11 CPU - MMR1 no longer tracks changes to the PC. The issue that

> > it should not track changes in floating point instructions is still 

open.

> 

> I wasn't aware of any discussions. Could you, or someone sum it up? Is

> it a question of whether MMR1 should reflect changes to the general

> registers if a FP instruction is aborted? If so, I'm pretty sure they

> should be. I think I have read it somewhere in some documentation, and

> could try and locate it, if that really is the question.

> 

> Also, MMR1 might reflect changes to the PC as well, as far as I can read

> documentation... But it's "complicated".

> 

> 	Johnny

> 

> >>> Looking at the J-11 microcode:

> >>> MMR1 does not track FP changes. This is because in early systems, like

> >>> the 11/45, it didn't have enough bits to record an 8 byte register 

change.

> >>> The J-11 goes through great pains to undo register changes before it

> >>> springs a trap or memory management abort.

> >>> Likewise, the J-11 never tracks PC changes in MMR1. The instruction

> >>> stream is read through a special microinstruction, because the 

hardware

> >>> always prefetches the next instruction word. Even modes 47 and 57, 

which

> >>> make no sense, don't update MMR1.

> 

> /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?

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 ...

Best regards,

R. Voorhorst