Some time ago, Paul Koning contacted me about the issue that RSTS did not correctly detect the CPU type when the cpu was configured as a J-11 type – 11/84 or 11/94. He had already identified a problem in the cpu sources: the MFPT instruction would set the CPU code in the primary register set, instead of the currently active register set according to the PSW.
I built the core for the MFPT instruction a long time ago, at the point where I was working with a copy of the ZKDJ test to verify that the regular instructions were working correctly. I added the MFPT mainly because I liked the idea of sticking as close as possible to the original ZKDJ source – at the time, I did not anticipate the system becoming as complete as it is now. Why I chose to write the CPU type value in the primary register set I don’t really remember – it seems illogical now.
Anyway. The fix did solve the CPU type detection problem, but immediately revealed another: the startup code in RSTS went into a halt. Paul quickly found the reason; RSTS would overwrite it’s memory sizing code while trying to find out how much memory was available. The cause of this was that the J-11 models have 2044Mw of memory, and do not implement the unibus remap of the top 128K back into low memory – as 11/44 and 11/70 do.
After I fixed that issue, yet another appeared: the startup would proceed further, but would now issue the message:
This DCJ11 cannot be used in conjunction with an FPJ11 accelerator. Contact Field Service for FCO kit EQ-01440-01 to correct the problem. INIT will continue, but timesharing cannot be started. RSTS V10.1-L RSTS (DB0) INIT V10.1-0L
Which I could easily suppress by setting the 8th bit of the control register at 17 777 750 to zero – stating no FPJ-11 floating point accelerator is present. Since the J-11 always includes the floating point instruction set in it’s microcode, functionally there is no difference in whether or not the FPJ-11 is present – it should only speed up the floating point instructions. But then, the message shows that there is a difference…
Diving deeper into the issue, Paul was able to find that the test that produced the message failed on a test involving the ASHC instruction. Sure enough, in the manual for the 11/84 EK-1184E-TM-001_Dec87.pdf – to be found on Bitsavers – page B-17 lists two model differences for the ASH and ASHC instructions, which I had already implemented a long time ago – but incorrectly applied to all models. As a test, I disabled this specific behaviour – and the result was that RSTS booted up, and recognized a FPJ-11 without complaining.
Apparently, the FPJ-11 then played some role in fixing the wrong implementation of ASHC and probably ASH in the J-11. Maybe the accelerator actually executed these instructions? or maybe it’s presence implied different microcode, or a different path in the microcode?
I’m not sure there is a way to find out – none of the documentation I’ve found so far includes this level of detail on the original hardware. Whatever the case, the RSTS CPU recognition bug is now fixed. Thanks Paul!
Besides fixing these bugs, I also made the bit setting in 17 777 750 a configurable item – including the corresponding behaviour of the ASHC and ASH instructions. The parameter is called have_fpa, and it’s default setting is 0 meaning no FPJ-11. I don’t think there is any use for having this, other than looking at the differences in the hardware listing in the RSTS startup…
have_fpa => 0
HA HARDWR suboption? LI Name Address Vector Comments TT0: 177560 060 RB0: 176700 254 Units: 0(RP06) XE0: 174510 120 DELUA Address: 00-04-A3-1A-70-E1 KW11L 177546 100 (Write-only) SR 177570 DR 177570 Hertz = 60. Other: FPU, 22-Bit, Data space, J11-E CPU HARDWR suboption?
have_fpa => 1
HA HARDWR suboption? LI Name Address Vector Comments TT0: 177560 060 RB0: 176700 254 Units: 0(RP06) XE0: 174510 120 DELUA Address: 00-04-A3-1A-70-E1 KW11L 177546 100 (Write-only) SR 177570 DR 177570 Hertz = 60. Other: FPU with FPA, 22-Bit, Data space, J11-E CPU HARDWR suboption?
As usual, I’ll post the updated sources to the download page some time later this weekend.