Adding RQDX1

[Rhialto]

This is a continuation of #215, which was "closed as fixed" by @vaxorcist, but not actually fixed in this repo, and I couldn't reopen the issue myself.

To really fix the issue in open-simh, I added a RQDX1 flavor to our RQ device family. As discussed, I also made that version the default in microvax1.

The model ID for RQDX1 I obtained from the list in appendix C of http://www.bitsavers.org/pdf/dec/dsa/mscp/Mass_Storage_Control_Protocol_Ver_2.4.0_Jun92.txt . While having that list, I checked it against our implementation and I noticed some discrepancies. I added some comments in the code, with the goal to discuss them, and resolve that before committing the final version. Here is a copy:

// AFAIK the UNIBUS KLESI and QBUS KLESI used the same controller type ...
#define KLESI_CTYPE     1               // RC25 controller (UNIBUS and QBUS both)
#define KLESI_UQPM      1               // Mass_Storage_Control_Protocol_Ver_2.4.0_Jun92.txt Appendix C:
#define KLESI_MODEL     1               // 1 | HSC50; 3 | RC25 integrated controller

I suppose we should change to 3 here since the model value we have now is for HSC50.

#define UDA50_CTYPE     3               // UNIBUS SDI (RAxx) controller
#define UDA50_UQPM      6               // really type of UDA50A; UDA50 is 2
#define UDA50_MODEL     6

The model value we are using is really for UDA50A, not UDA50. I changed the name in one location in the text as a place holder. Maybe we should change it everywhere. Or maybe the difference is too small to bother.

#define KDA50_CTYPE     6               // QBUS SDI (RAxx) controller
#define KDA50_UQPM      13              // KDA50-Q
#define KDA50_MODEL     13

Here the given name is just slightly different. Probably doesn't matter.

#define KRU50_CTYPE     8               // UNIBUS RRD40/50 CDROM controller
#define KRU50_UQPM      26              // unassigned in appendix C
#define KRU50_MODEL     26

This one doesn't occur in the list at all.

As we have seen in practice, these model numbers don't matter in the vast majority of cases, so we could decide to do nothing about the discrepant cases. Or add a few more models so that we have both versions. Or we just add a pseudo register to access the model number, so that you can set any arbitrary value.

I also deleted a few #defines that were already no longer in use. They related to the selection of the default model, and while previously they did the same as the code that actually did that, they no longer match. So they'd better go.

With these changes, the scenario from #271 also works now: microvax1 uvms.ini 2, using the uvms.ini from comment #271 (comment) , and other files from #271 and #215.

Link to merge request: #278 .

[pkoning2]

I looked at the RSTS initialization code -- which uses the controller ID numbers to report what type of controller you have -- and Appendix C of that spec. Those seem to match.
As for the pdp11_rq.c code you quoted, I'm not sure what to make of "CTYPE", but the MODEL number of UDA50A matches. But what is the meaning of the comments on the KLESI lines? Yes, RC25 is model 3, but what does that have to do with the define for KLESI_MODEL = 1 ?
The lack of KRU50 entry in the MSCP spec is puzzling, given that the 1991 option/module list (from Bitsavers) shows it.

[Rhialto]

The *_CTYPE numbers are just an internal sequence number, which corresponds to the position of a controller's model data in the static struct ctlrtyp ctlr_tab[] . Since I added the new entry in the middle (RQDX1 just before -3, which is the nice location for it), I bumped the numbers.

Regarding KLESI/RC25, in the text Set KLESI (RC25) Controller Type" the two are essentially equated. The KLESI_MODEL of 1 doesn't match the table, which has 1 for HSC50, and 3 for RC25 integrated controller. It's a bit confusing, so if some other model number is appropriate...

[pkoning2]

Yes, KLESI_MODEL should be 3, that way the OS will see it as an RC25. Checked with RSTS.

[Rhialto]

I notice in the CMAKE builds that it creates package names starting with simh-4.0.0. I thought we were at version 4.1...

[pkoning2]

Yes, maybe @bscottm can look into this.

[vaxorcist]

First: I'm very sorry for premature closing #215 as it was fixed in another repo only.
I appreciate it very much that it got fixed here as well.

On the matter of controller model IDs:
There were two versions of the UDA50:

• The "early" one made of the modules M7485 and M7486, and
• the "late" one made of the modules M7161 and M7162.

I think that the two UDA50 controller IDs reflect the two versions.
As it is unsure whether any software insists on only one of the two, I'd suggest to add both model IDs, maybe defaulting to "UDA50" (only a guess).

Furthermore I think it would be very helpful to add the "pseudo register to access the [controller] model number" feature that @Rhialto proposed.
If any new problems occur, one could easily check if another controller ID fixes it.

Many thanks for all the effort and brain you put into simh!

Regards
Ulli

[Rhialto]

As a result of the above I made the first amendment in the merge request. I removed the comment from the number change at KLESI_MODEL, that seems to be set.

Regarding the UDA50(A), I wonder if there is supposed to be any significant difference between them, enough to warrant separate entries. I was more wondering if all mentions of the name to the user should be adapted, or if mentioning in one place that an UDA50 is actually an UDA50A is enough, or something along those lines. Especially if that model number register comes in, that could well be enough.

I made a few experiments to add such a register and it is more involved than just adding an entry to a table, so I will leave that to a separate merge requiest.

I also noticed I forgot to list another change which was prompted by the list:

#define RUX50_CTYPE     2               // UNIBUS RX50-only controller
#define RUX50_UQPM      10		// this should be 10 according to the MSCP spec (was 2)
#define RUX50_MODEL     10

[Rhialto]

I see it's committed, great!
I'll continue with creating a merge request for a pseudo register for the controller model number. Two, actually, since there is also a port model number, although it usually is the same. (But in pdp11_tq.c it may differ).

[markpizz]

As we have seen in practice, these model numbers don't matter in the vast majority of cases, so we could decide to do nothing about the discrepant cases. Or add a few more models so that we have both versions. Or we just add a pseudo register to access the model number, so that you can set any arbitrary value.

and

I'll continue with creating a merge request for a pseudo register for the controller model number. Two, actually, since there is also a port model number, although it usually is the same. (But in pdp11_tq.c it may differ).

Exactly what purpose would such a register serve and what software would use it? The relevant model information is already provided through the existing code and in fact is used by various software on various operating systems.
Examples are:

• The MicroVMS operating system's driver which used the original value provided to not operate.
• RSTS driver which @pkoning2 confirmed the values being reasonable or unreasonable.

Adding simulator visible registers which never existed in real hardware should only be done to serve actually valuable functionality. You should ask Bob Supnik about this.

There is only one example that I know of in all of the VAX and PDP11 simulator code where a single register is sometimes visible to the simulated system. That case exists in the MicroVAX 3900 simulator. It exists as visible to the simulator only when the running simulator has been configured with more memory than the original MicroVAX 3900 was capable of having installed (original hardware supported 64MB). This additional register is used by the software running the simulated system's ROM that then passes the available memory info to operating systems that are booted on that machine. You might ask how that ROM code's knowledge of this extra register get there? I modified the ROM code when Bob implemented this extra register.

Going down the extra register implementation path creates at least one hard to solve complexity. Specifically, the MSCP controllers expose 2 16bit registers in the Unibus/Qbus space. Unlike some devices which have register sets which align on 16 byte boundaries and may not use all of this potential register space, there is no extra space in the 2 16 byte registers, so you'd have to find some other place in the total bus I/O space to implement this and you'd have to support 4 sets of the registers you are proposing since there are 4 RQ devices and additionally TQ as well.

Then some kind of software would need to be written (for each theoretical operating system) to make use of such registers.

A user running a simulator can always determine the configuration of the RQ device simply by entering SHOW RQ{B|C|D} a the sim> prompt.

If, you're not actually proposing implementing simulator visible registers, then a simpler approach would be to use the table in the MSCP spec which you've already referenced to add ALL of the listed hardware models to the settable controller types via SCP commands. With that in place no one would ever need to visit this concept again since the MSCP spec defines all possibilities which were haven't evolved at all since the spec was last modified, and thus no software would exist that depended on any differences.

[Rhialto]

Indeed I am not proposing anything that's visible inside the emulator address space. Just something for the user of the simulator.

Indeed I could make a long list of controller types, listing each of them, but although it's only 8 bits, the list would be 256 entries long and that seems a bit much for something that, indeed, won't be used very often. And since there are 256 port model numbers as well, the product of these is 64K which is really out of line.

Therefore, as a compromise, my thought was to expose it via the somewhat obscure interface

MicroVAX I (KA610) simulator Open SIMH V4.1-0 Current        git commit id: da2181f9+uncommitted-changes
sim> examine rq model,port
MODEL:  00007
PORT:   00007

That's why I called it pseudo-registers, because they are not real registers (from the view inside the simulation) but are examinable with the hypervisor examine command.

With this I found (I think) that the critical value for booting STABA040-1.dsk is actually the PORT value.

Anyway, tomorrow or so I'll create the pull request and then we can see if the ratio between complexity and potential usefulness is good enough.