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 https://github.com/open-simh/simh/issues/271#issuecomment-1630526802 , 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.

[markpizz]

There are indeed a theoretical total of 256 controller types across the whole MSCP protocol. That list has a very large percentage of both unassigned types and software implemented types or types which could never be presented via a Unibus or Qbus controller. The real number is something like 22 controllers across both RQ and TQ.

This certainly doesn't seem excessive but in the end, the actual values very likely will never impact any other software that ever ran on these systems. The point of the detail controller passing it's model was to have valid data recorded in error log entries, and we don't simulate errors so the significance of the value is 0. The single case of the RQDX1 and MicroVMS occurred when this stuff was in its infancy and the driver in the earliest versions checked for the specific hardware it was tested against. After this specific device and OS, all of the OSes didn't take action based on these model values since the rest of the MSCP protocol handled data interactions robustly.

[pkoning2]

I'd have to go back and do some reading, but RSTS has specific code in it for the RC25. Not for the controller, but for the drive. Its problem is that it's two units that spin down together, so if you remove the removable pack, the fixed unit also spins down. RSTS was required to support a configuration with a single RC25 drive (pair) and no other disks, which meant the system disk would be the fixed unit and the removable drive would be whatever removable data the customer needed. So there had to be a way for the OS to survive the system disk being spun down, which normally it doesn't like at all. I know that was accomplished, around V8 I think, but I don't remember any details. Possibly that might be tied to controller type, but maybe it's just a general service that happens to be useful only on that device.

[markpizz]

That may be true and selecting that controller type might engage that logic in the OS, but I'm not sure that the simulation hardware needs to be specifically aware of that detail.

The simulation just has units that have containers attached to them. No specific effort is made to precisely force a configuration to only have 2 drives or to force unit 0 to be a RC25 and the unit 1 to be a RCF25, where the 0 unit is removable and the 1 is fixed. Nothing in the simulation forces more than one drive to spin down since nothing there cares about spinning. The simulator is a VERY FLEXIBLE KLESI controller which could have multiple RA81's attached. :-)

[pkoning2]

True. My intent was just to demonstrate that it's possible for controller type to be relevant to stuff other than error logging. Well, actually in RSTS it also appears in informational displays that are not error logging, but still those are not functional issues, they don't affect software behavior. The RC25 case is an actual body of code that does something significantly different from past behavior. The one thing I don't know right now is whether that behavior is tied to knowledge of the controller or drive type.

[markpizz]

Like the KLESI, many/most of the rest of the "additional" MSCP disk controllers existed to interface a unique drive type. No effort in the simulation exists to specifically associate particular unit drive types to particular related controller. In fact, most users, having been spoiled by the original flexible RQ behaviors to detect (or allow) drive types to be arbitrary really wouldn't want anything that forced controller limitations (1 or 2 units, specific drive types), to be forced by the simulation logic. If someone wants to define a realistic configuration that reflects original hardware, that's fine, but in general not really necessary.

The tape controllers very much fall into mostly one to one relationships with tape drive types as well. With tapes, there really wasn't anything that the OS software knew about relating to capacity. I believe that essentially all counted on drives reporting some sort of end-of-medium condition to reflect the need to change tapes. None of this has been well exercised in the tape domain, but it probably will work if someone tries it and potentially fixes a few minor condition reporting cases...

[markpizz]

The existing RQ implementation allows for up to some 254 units to coexist on one controller along with arbitrary unit plugs for each. That would be a pretty fancy RQDX1 controller that I suspect the MicroVMS might actually be fine with... :-)

[markpizz]

On real hardware, there was no ability to change the types of the 2 drives that came with the KLESI controller. I was joking about the simulation being very flexible. It would be surprising if some OSes didn't get confused by unexpected drive types (and sizes) connected to the RQ device setup as KLESI but with unexpected drives. Doing that would be user error, right?

This rat hole is disjoint from the discussion about merely listing the controller types.

|       2      | UDA50                                    |
+--------------+------------------------------------------+
|       3      | RC25 integrated controller               |
+--------------+------------------------------------------+
|       5      | TU81 integrated controller               |
+--------------+------------------------------------------+
|       6      | UDA5OA                                   |
+--------------+------------------------------------------+
|       7      | RQDX1/RQDX2                              |
+--------------+------------------------------------------+
|       9      | TQK50                                    |
+--------------+------------------------------------------+
|      10      | RUX50                                    |
+--------------+------------------------------------------+
|      12      | KFBTA                                    |
+--------------+------------------------------------------+
|      13      | KDA50-Q                                  |
+--------------+------------------------------------------+
|      14      | TQK70                                    |
+--------------+------------------------------------------+
|      15      | RV20                                     |
+--------------+------------------------------------------+
|      16      | KRQ50                                    |
+--------------+------------------------------------------+
|      18      | KDB50                                    |
+--------------+------------------------------------------+
|      19      | RQDX3                                    |
+--------------+------------------------------------------+
|      20      | see Appendix H, Table H-1                |
+--------------+------------------------------------------+
|      25      | TUK50                                    |
+--------------+------------------------------------------+
|      27      | KDM70                                    |
+--------------+------------------------------------------+
|      29      | TM32                                     |
+--------------+------------------------------------------+
|      30      | RQZX1 (See note 2)                       |
+--------------+------------------------------------------+
|      31      | KCM44 (Polecat)                          |
+--------------+------------------------------------------+
|      65      | TK50-DEBNT                               |
+--------------+------------------------------------------+
|      66      | TBK70                                    |
+--------------+------------------------------------------+

The above list has software and unassigned numbers removed,

Looking through that list, the only one that is possibly useful is the KDB50 which really doesn't add useful functionality that isn't already there in the KDA50/UDA50 and the RQDX controllers.

[Rhialto]

For reference only, I created a merge request #280 so the code is in the open.

Adding the registers affects the save/restore file but since the file format is tagged with register names, this is not a compatibility problem. I did look into the question whether an older save file restored to a newer sim would leave the new registers uninitialized. But since initialization happens already early in the start-up of simh (before the prompt), this won't happen. There is a printf that I left in that demonstrates the fact.

I imagine it might be useful for people who want to study the MicroVAX I boot procedure with the standalone backup 4.0, to easier find out what affects it, and possibly where. One can change the sim and recompile but that's a bit slow.

Anyway, there is no need to merge this, it could be enough to serve as an example of how to add this sort of extra insight into the internals.