open-simh / simh

The Open SIMH simulators package
https://opensimh.org/
Other
469 stars 89 forks source link

Device types for DL-11 and DH-11? #22

Closed louis-chretien closed 1 year ago

louis-chretien commented 2 years ago

I'm trying to restore the config of my old RSTS/E system, from around 2000, to working order in SIMH. I managed to recover an old backup tape, and i am able to restore it to a disk image.

But i am running into a bit of a problem.

It seems that RSTS/E is very finicky about device types, and my system had a bunch of DL-11D and DL-11E (for modem control), as well as three DH-11 multiplexers.

Apparently, RSTS/E is able to tell the difference between a KL-11 and a DL-11, and ends up assigning different device designators for them. On my original HARDW LIST from RSTS/E 10.1, the DL-11D were designated DL0: to DL10:, and the DL-11E were DE0: to DE3:

Likewise, the DH-11 interfaces were designated DH0: to DH3:.

On the simulator, RSTS/E gives them designator KL0: to KL14: and the DHU end up being VH0: to VH2:

Option: HA LI

Name Address Vector Comments TT0: 177560 060
RR0: 176700 254 BAE=+050, Units: 0(RM03) 1(RM03) 2(RM03) 3(RM03) 4(RM03) 5(RM03) 6(RM03) 7(RM03) RU0: 172150 P520 RQDX3 Units: 0(RA81) 1(RA81) 2(RA92) 3(RA92) TU0: 172440 224 BAE=+034, Units: 0(TE16 @TM03 #0) 1(TE16 @TM03 #0) LP0: 177514 200 KL0: 176500 300
KL1: 176510 310
KL2: 176520 320
KL3: 176530 330
KL4: 176540 340
KL5: 176550 350
KL6: 176560 360
KL7: 176570 370
KL8: 176600 400
KL9: 176610 410
KL10: 176620 420
KL11: 176630 430
KL12: 176640 440
KL13: 176650 450
KL14: 176660 460
VH0: 160440 470 Sub-lines: 16 VH1: 160460 500 Sub-lines: 16 VH2: 160500 510 Sub-lines: 16 XE0: 174510 120 DELUA Address: 08-00-2B-13-1A-6D

KW11L 177546 100 SR 177570 DR 177570

Hertz = 60.

Other: FPU, SL, 22-Bit, Data space, Cache w/address, System ID = 4660

This has the unfortunate consequence that the keyboard lines end up with the wrong name (_KBFn: becomes _KBGn: inside RSTS/E), and the startup config file can't set the proper device types.

Is there a way to set the device type of those interfaces? Why would RSTS/E be able to tell the difference?

I'm curious that nobody ever ran into that problem before...

pkoning2 commented 2 years ago

For most purposes it doesn't matter if you have a KL or a DL, though DL-11/E does make a difference because it adds full modem control. But if you just want a terminal I/O device, they all are the same. I'll take a look. RSTS looks at obscure details of devices to tell apart variants; chances are SIMH hasn't bothered with that level of detail.

pkoning2 commented 2 years ago

BTW, DH and DHU are entirely different devices. SIMH doesn't' currently emulate DH11.

pkoning2 commented 2 years ago

Ok, so the answer is that KL and DL have different addresses. SIMH uses the KL addresses (starting at 17 776 500) even though it calls it "DL". For DL addresses, start at 17 775 610. That's the non-E version; DL-11/E uses floating addresses.

louis-chretien commented 2 years ago

Got it! after setting the non-standard vector and addresses, RSTS/E detects my DL-11/D and DL-11/E correctly. Unfortunately, it comes into conflict with the DHU devices... Don't know how to solve that one...

set DLI enable set DLO enable set DLI lines=15 set DLI address=17775610 set DLI vector=420 set DLO2 dataset set DLO9 dataset set DLO10 dataset set DLO14 dataset attach DLI 4000

This creates the 15 DL i had. But it does clash with the DH. Probably the vector address? mine was set at 620 and 160020 for the address

pkoning2 commented 2 years ago

160020 is the right floating address for DH11 if you don't have a DJ11. But as I said, SIMH has no DH11 support. It has DHV/DHU support, but that's a completely different device. If you want to replicate the configuration you had originally, you're out of luck, unless you add DH11 emulation to SIMH of course.

louis-chretien commented 2 years ago

If you want to replicate the configuration you had originally, you're out of luck, unless you add DH11 emulation to SIMH of course.

You certainly know how to throw down a gauntlet, don't you? ;)

Well, looking at some info on the net, i found these two PDF manuals:

http://www.bitsavers.org/pdf/dec/unibus/EK-ODH11-OP-002_DH11_Asynchronous_16-line_Multiplexer_Users_Manual_Sep76.pdf

http://www.bitsavers.org/pdf/dec/unibus/EK-DHU11-UG-002_DHU11_Interface_Users_Guide_Nov86.pdf

Would these be enough information to attempt what you are suggesting?

i will definitely study the DHU-11 code and manual, see if i can figure out that thing...

louis-chretien commented 2 years ago

thinking more about this, i thought that tackling a smaller project might be feasible...

I was thinking of adding a "SET TYPE=DL11" to the existing KL-11 driver.

Trouble is, i look into the code and can't really figure out where the address and vectors are set-up.

I was trying to locate the "17 776 500" address you gave me, without much success. I guess i need to brush up on my Unibus knowledge first...

pkoning2 commented 2 years ago

Re gauntlet: yes, that should tell you what you need. The final proof would be in running various OS on the resulting SIMH. RSTS is a good choice; it is known to be picky about details. As for the "set type", that's a possible approach. The address I quoted can be found in the addresses list in the back of the Peripherals Handbook; I used the 1973 edition you can find on Bitsavers.

louis-chretien commented 2 years ago

i'm sorry, i meant the address and vector in the source code of the pdp11_dl.c (or headers). I will dig some more...

markpizz commented 2 years ago

The device bus addresses for v4 Unibus and Qbus devices defaults to the addresses described by the DEC autoconfigure algorithm. These are how the defaults are assigned.

For essentially all devices in a configuration, the user can explicitly set the device and vectors to whatever values that they want in the simulator configuration file. You DO NOT have to change any source code. However historically, once any address or vector is manually assigned, the autoconfiguration algorithm is disabled and any devices enabled after the disabling of autoconfigure must be set manually.

Meanwhile, the simh implementation of the MUX devices generally allow for varying number of instances of the particular mux device type with the number usually specified with a SET DZ LINES=n, or SET DLI LINES=n, or SET VH LINES=n.

This setting of the number of device instances then causes the device address and vectors for each instance to be immediately adjacent in the address/vector space. There is no provision to move different instances to different addresses. I'm not 100% sure, but from your description the difference between the two categories of DL style devices is merely that some have modem capabilities. There is a provision in the current implementation to deal with that on a per instance basis with the SET DLOn DATASET to enable modem signals.

pkoning2 commented 2 years ago

Mark, the issue is that KL and DL (other than /E) are essentially the same device -- but for unknown reasons they have different address ranges. They are both fixed ranges, but separate. So while SIMH says it's simulating "DL" it's actually by default using the address range for KL.
The simplest answer, for the rare cases where you'd care, is to set the address manually. The more complicated answer is to allow SIMH "DL" devices to be set to be either KL or DL, with autoconfigured addresses set accordingly. If you have all the same type that's easy; if you want to allow the SIMH device to be part KL and part DL, it's more complicated. I don't remember this coming up before, so it's probably only very rarely an issue. For that reason "just set the address by hand" is a good answer. Note that for use with RSTS the vectors don't need to be touched. Last but not least, you can also make the change in the RSTS settings (with the HARDWARE option, CSR subcommand); the only drawback is that you have to do that per line, while the CSR address override in SIMH applies to the entire set of devices.

markpizz commented 2 years ago

They are both fixed ranges, but separate. So while SIMH says it's simulating "DL" it's actually by default using the address range for KL.

In the manual referred to "Peripherals Handbook", 1973 edition, on page A-5 there is specific mention of DL11 devices running from address 776500 thru 776676 (16 total DL's). The v4's autoconfiguration logic assigns addresses precisely in this range.

I can't seem to find a reference that suggested that the KL11 and DL11 had different fixed addresses. The only case I can see is the KL11_TeletypeControlManual. From what I can tell, this doesn't really discuss address assignments, but merely has a Chapter 4 Programming section defining registers starting at address 177560 which is the console terminal address and, although the device programming is the same, simh implements it in another device.

Pages 4-132 and 4-133 of this manual also describe the same addresses and mention that KL11 and DL11 are the same.

Where/what document describes different addresses for the KL11 vs the DL11?

pkoning2 commented 2 years ago

I mixed up two things. The RSTS init code has two device table entries, one for 16 units starting at 776500, and one for 16 units starting at 775610. The former it calls "KL" in its displays; the latter "DL". But the comments are clearer:

DEVDEF  KL,16.,10,176500,      ,  ,2VEC, 1.,5   ;KL11/LC11/DL11A/DL11B SINGLE LINE INTERFACE
DEVDEF  DL,31.,10,175610,      ,  ,2VEC, 1.,5   ;DL11C/DL11D SINGLE LINE INTERFACE

and sure enough, this is documented on page A-5 and A-6 of the 1973 Peripherals handbook. Interestingly enough, if I tell SIMH to set the DLI address to 17775610, RSTS boots but doesn't get past the first prompt, no functioning terminal input. That's even though I'm talking to the console which is an entirely different address. I haven't looked at why this might be. Louis was talking about having DL-11/D devices, so indeed those would be at the 17775610 address. My recommendation is to ignore all that and treat those single line interfaces as KL-11 or DL-11/A variant instead.

markpizz commented 2 years ago

Try your RSTS test with the code at the top of the master branch at https://github.com/simh/simh. A change I made recently might suggest what is wrong.

Getting beyond that problem I believe is possible with some fancy config file settings.

Meanwhile, given the current structure of there being a single bus address device in pdp11_dl.c, supporting a combination of devices at 175610 and also at 176500 isn't possible.

pkoning2 commented 2 years ago

Yes, that version starts correctly and recognizes the lines as DL11/C. There's a display error in the utility that implements "show device" so it shows them as "DC" but the kernel state is correct.

wfjm commented 2 years ago

The KL11 and the DL11-A/B are implemented quite differently, but are functionally equivalent. In RSX and in UNIX 6th and 7th edition one driver handles both, and I even wonder how software could distinguish them. The 1976 Peripherals Handbook clearly states on page 4.136:

Address and Vector Assignments
The DL11-A and DL11-B follow the same address and vector assignments as the KL11:
                    Address  Vector   Priority
Console             777560   60/64      BR4
Additional Units    776xx0   floating   BR4

The DL11 User Manual also states clearly that DL11-A/B and KL11 are equivalent for floating vector assignments.

The configuration of the initial posting had

set DLO2  dataset
set DLO9  dataset
set DLO10 dataset
set DLO14 dataset

The lines with modem control are scattered, so it looks like a mix of DL11-A/B and DL11-E.
It's not clear to me what the proper vector assignment of such a setup is because the DL11-E are after the DL11-A/B.

I wonder a bit why a configuration with 15 DL11 is used at all.
In real hardware that's a full UNIBUS backplane filled with single line devices.
Very unlikely that one would have setup a real system like this.
If lines are needed, why not one or two DZ11 ? The DZ11 also offers modem control.
In my setups I use a DL11 as console, and DZ11 to get more lines.

louis-chretien commented 2 years ago

The lines with modem control are scattered, so it looks like a mix of DL11-A/B and DL11-E. It's not clear to me what the proper vector assignment of such a setup is because the DL11-E are after the DL11-A/B.

I wonder a bit why a configuration with 15 DL11 is used at all. In real hardware that's a full UNIBUS backplane filled with single line devices. Very unlikely that one would have setup a real system like this.

Believe me, a system like that existed!

When i was hired in 1982 as a system manager at a local newspaper, we had two identical PDP-11/70, running that config: the main system was an IAS-11/TMS-11 system, for typesetting and newspaper production, while the other was running RSTS/E for accounting software.

The reason for the DL-11 was that IAS required those for newswire input, from different news agencies, via modem and/or satellite links. IAS was unwilling/unable to work with DZ-11.

The three DH-11 were used to connect roughly 48 VT-72 terminal (a special beast in and of itself!) for reporters and editors to produce the daily paper.

If memory serves, DEC used TMS-11 internally, to produce a lot of manuals for documentation (i remember seeing a note to that effect on some RSTS/E manuals)

as for the address and vector assignments, it has more to do with IAS requirements than anything else.

My original posting was to point out that RSTS/E was a bit finicky about addresses for the KL-11 lines. As "pkoning" correctly pointed out, it turns out that the difference from RSTS/E's point of view is the base addresses:

KL addresses start at 17 776 500 DL addresses start at 17 775 610. That's the non-E version; DL-11/E uses floating addresses.

the reason is that if KL-11 has it's normal base address, it is detected as a KLn: device by RSTS/E INIT program, and ends up as KBBn: device once the system is booted.

If the KL-11 has the DL-11 address range, it is detected as a DLn: or DEn: device by INIT, and ends up as a KBCn: device inside RSTS/E.

That makes a world of difference, when you write startup procedures, or reuse old ones... ;)

pkoning2 commented 2 years ago

Re lots of single line devices: I haven't seen that in RSTS/E but I used a RSTS-11 system that looked like that: 11/20, 28 kW memory, 2 x RK05, RF11, TU56, 16 x DL11 (current loop). It wasn't terribly reliable; during the day most of the terminals were in use and 16 jobs on an 11/20 is quite a strain. But it did run. My second year there, it was replaced by an 11/45, 48 kW, RP04, DH11, TU56, and still the two RK05s and RF11. That worked a whole lot better.

markpizz commented 2 years ago

The latest code in the master branch at https://github.com/simh/simh has a new device (implemented in the pdp11_dl.c module) which implements these other DL style devices which had different addresses. The DLCJI and DLCJO support up to 31 serial lines simultaneously with the original DLI and DLO.

larsbrinkhoff commented 1 year ago

I need a DH11 for SITS. Maybe I'll look into it.

larsbrinkhoff commented 1 year ago

DH11 device submitted: #77

pkoning2 commented 1 year ago

Lars's work has now been merged.