(last updated: 04-Jul-2017)
The current configuration is in its original 'as acquired' condition, except that I have relocated RX02 dual-floppy unit in the cabinet.
| H9276A | A | B | C | D | |
|---|---|---|---|---|---|
| Q22/CD | 1 | M8189 : KDF11-BA : LSI-11/23+ CPU w/ 2 SLU, LTC, MMU | |||
| 2 | M8067-LH : MSV11-PL : 256KW RAM | ||||
| 3 | M8017 : DLV11-E : Serial Line Unit | (empty) | |||
| 4 | M7957 : DZV11-M : 4-SLU EIA MUX | ||||
| 5 | M7957 : DZV11-M : 4-SLU EIA MUX | ||||
| 6 | M8061 : RLV12 : RL02 controller | ||||
| 7 | M8029 : RXV21 : RX02 controller | (empty) | |||
| 8 | (empty) | (empty) | |||
| 9 | (empty) | (empty) | |||
05-Dec-2005
This system was available for pickup in Darien, Connecticut and I arranged to have a moving van line company collect and ship everything back home. We actually made the trip out to Darien for the event, and spent a number of days enjoying New York City and New England.
14-Dec-2005
First, the peripherals (excepting the LA-36) were cleaned before the CPU box.
The RX02 dual-floppy subsystem was extremely dusty and I cleaned it by first vacuuming every exposed surface, then wiping every reachable nook and crany. The floppy drive units themselves were partially disassembled so that I could re-lubricated the worm gear on the head actuator. Then the subsystem was reassembled.
Each of the RL02 units were partially disassembled, cleaned, and re-assembled. I didn't removed the blower or power supply assembly, but I did remove the logic boards, and vacuumed every surface and corner, along with wiping down with 'baby wipe' to gather all residual dust and/or grime. In each case, the 'course filter' was in a very degraded state and had to be replaced. The foam material was aged to the point that it would simply crumble when handled. I replaced these foam filters with new material cut from a furnace filter pad that traps particulates to 100 microns. If that doesn't do the trick, I don't know what will!
The cpu box was unloaded and all cards were individually vacuumed of accumulated dust. I partially disassembled the box and vacuumed and cleaned with baby wipes. Then everything was reassembled.
This system was fully operational and had been recently powered before being picked up, so there is no need to remove and test the power supplies separately before retesting the whole system.
04-Jan-2006
After reading comments from the ClassicCmp.org mailing list re: the Power Controllers in each bay of the cabinet, I think I know how they work. I've decided the power up the system.
I plugged the daisy-chain cable between units and connected the line to the CPU box. I decided to go for it, so I put a power cord to the CPU box, added a VT100 connected with the short, fat serial cable and hit the power AUX ON switch.
Yeehaw! The system came alive and I got a bootstrap prompt at the terminal (after I added the null-modem adapter)!!
So, we didn't blow up the CPU or memory! The POST test shows 256KW of memory just fine.
So, I connected up RL02 #0 and booted RT11!
Wahoo!
12-Jan-2006
Using Will Kranz's excellent TU58 emulator running on a 486 PC, I was able to successfully image each of the RL02 disk cartridges to disk files. I also imaged the two floppies that were also included in the deal. These images were later burned to CD for safe keeping.
13-Aug-2007
Since I want to move files as quickly as possible from this system to the TU58 emulator, I changed the SLU 2 baud rate on the CPU board to 19.2K (S2:5-8 off).
I reinstalled all of the boards, and fired up to confirm that everything still works (it does!) and that the second SLU line is now at 19.2Kbaud (it is!), so I'm now ready to begin my floppy imaging in earnest.
But...first, I thought I'd learn more about SYSGENing so that I could enable my third RL02 drive, Drive #2, that is. I loaded up a scratch DL02K pack and copied the files and the bootstrap from my RT11 v4.0 distribution cartdridge. Then I ran SYSGEN and made a bunch of choices (some of which I think are wrong, related to the DZV11 stuff) and went ahead and started the build with:
.@SYSBLD
Each monitor took about 30 minutes to assembly and link, and the group of device drivers took another 15 minutes. In the end, I don't think it worked. I renamed the RT11SJ.SYG and DL.SYG files to .SYS and copied the bootstrap, then booted. It booted alright, but still didn't recognize my DL2: drive. More reading is in order.
14-Aug-2007
Well, tonight I tried again, but I took a minimalist approach this time. I only selected the DY, DL, and DD devices, and the Single Job monitor. I selected support for 4 DLx: drives, and then did the build. I renamed just the DL.SYG and RT11SJ.SYG files to .SYS and then copied the bootstrap. I booted, no problem. Still couldn't get a DIR from DL2:, though. Ah...now I get it! The particular RL02K cartridge I had in the DL2: drive is not formatted for RT11, so the system just complained about a bad directory, which is the same error that it gives when the device does not exist, thus my confusion. I loaded another RL02K (Will's Test) and, sure enough, it was readable!
I then unloaded the RL drives, and swapped the RL02Ks between DL0: and DL2:. This put the one with support for four drives in DL2:. I RESTARTed the system, and at the START? prompt, I entered DL2. Yup, it works!
Now, even though it is only v4.0, I've decided to rebuild the whole system, based on the 'factory' SYSGEN settings, except that I'll choose support for four DLx: drives. It'll take a while to build, but that will at least give me a base that I can now work from on a going-forward basis.
Of course, I could do all of this in SIMH and probably have it done very quickly, but I enjoy seeing the actual machine do the work. It gives me a feel for what it was like for actual users of that time.
Once the SYSGENing process was complete (BL, SJ, RB monitors and drivers), I copied Will's DW.SYS driver over. Even though it is a v5.01 driver, it works just fine with this v4.0 system that I'm currently working on. So, for now at least, I'll base my operations on this newly built 4.0 that supports four DLx: drives.
14-Aug-2007
To test my thoughts on floppy imaging, I copied the floppy image files that I captured last week from the RL02K cartridge to the DW: device. From there I tried to use PUTR to extract the files from the big RL02 (DW:) image, but when I mount them with SIMH, or on the real machine via the TU58 emulator, I get "invalid directory" errors. I tried using PUTR's COPY with and without the /BINARY switch, but neither work. As a side note, one strange item with PUTR is that when I copy without the /BINARY switch, the resulting files are not sized the same as the source, they are smaller. It appears that PUTR is only copying the allocated sectors. When I copy with /BINARY, the resulting file is sized as if it were a direct image, but it still doesn't work.
19-Sep-2008
During the past month, I have finally completed the imaging of all the floppies that were included with the Longmont pickup. To do so, I set up a small 486 laptop with Will's TU58 emulator and created images via the 19.2K serial connection. Each image is a separate file, and doesn't require me to later use PUTR to try to extract it from another, bigger image.
In the meantime, this system is standing ready for the next job that comes it's way. Someday, I'd like to try RSTS/E on it with multiple terminals. Thanks to a member of the classiccmp.org mailing list, Ulli Hoerschel, I now have several installation distributions of RSTS/E, but haven't worked out how to use them yet. They are primarily image files of 9-track tapes, so more research required.
17-Jun-2010
After all this time, since acquiring this system, I finally did another review of the module configuration, in anticipation of building and running RSTS/E with multiple terminals. I found that I had a conflict between the DLV11-E (which I believe served as a printer port) and one DZV11. They were both set for the same interrupt vector, namely, 320. Here is the old, original CSR and vector setup as acquired:
- CPU/SLU1 (console): CSR: 777560 Vector: 60 - CPU/SLU2: CSR: 776500 Vector: 300 - DLV11-E: CSR: 776520 Vector: 320 * - DZV11 #1: CSR: 760100 Vector: 310 - DZV11 #2: CSR: 760110 Vector: 320 * - RLV11: CSR: 774400 Vector: 160 - RXV21: CSR: 777170 Vector: 264
A review of the Microcomputers And Memories handbook indicates that the DLV11-E (which has modem control) CSR should be in the 775610+ block not the block for non-modem control SLU modules, so in addition to changing the vector to 330 I also chose to change the CSR to a more appropriate value, namely, 775610.
I removed power from the system cabinet, removed the DLV11-E module and changed the wire-wrap jumpers accordingly.
Well, looks like I made a mistake on the new CSR for the DLV11-E. I had intended it to be 775610, but when I fired up the RSTS/E 7.07 installation and looked using the HARDWR option, it's reporting the CSR as 775710. I must have jumpered one too many bits. Well, it's still in the correct range, so I'll leave it as it at this point. And I no longer have the vector collision, so all is well.
Here is the new address and vector configuration for the system, after these changes were made:
- CPU/SLU1 (console): CSR: 777560 Vector: 60 - CPU/SLU2: CSR: 776500 Vector: 300 - DLV11-E: CSR: 775710 Vector: 330 - DZV11 #1: CSR: 760100 Vector: 310 - DZV11 #2: CSR: 760110 Vector: 320 - RLV11: CSR: 774400 Vector: 160 - RXV21: CSR: 777170 Vector: 264
23-Jun-2010
Over the past two or three days I've used SIMH in an attempt to install some version of RSTS/E. I chose SIMH for this, rather than real hardware, for this because I was unsure about how many drives were required (turns out I needed at least two, three is better) which was indicative of my general ignorance of installing and SYSGENing RSTS/E.
As a bit of background, I used RSTS/E only during one three- or four-month stretch during the summer of 1978. During this time I was working with a Salt Lake City reseller, Lee AIDS. They were a dealer in Digital solutions, and I was hired (amazingly!) at age 20 to do some remedial programming on a an MCBA accounting package written in DIBOL, running under RSTS/E 6 or 7 on what I seem to remember as a PDP-11/40 though it may have been another. If I recall, the transition from RSTS/E version 6 to version 7 was occuring for our customers, and I had to do a couple of SYSGENs during that time, but recall nothing about the process.
It is that background, my first profession computer-related job (as a programmer, no less!), that prompted me to acquire this PDP-11/23+ system in the first place when I learned of it being available, and I've been hoping to someday recreate that experience. Well, I'm getting closer and closer.
Using SIMH, then, I located the companion RL02 disk-based RSTS/E 7.07 distribution, and I also located a 9-track tape-based distribution of version 9.6. Both of these distributions were imaged into files that I could readily download and use with the SIMH PDP-11 simulator.
I wasn't sure how to proceed at first with the RL02 distribution. I didn't learn what each of the three disks was for and in what sequence to use them. So I turned to the tape distribution. Version 9.6 came along well after my 1978 experience with RSTS/E but I thought it would be a good easy way to start learning. I mounted the tapes and booted to the SYSGEN tape. The dialog was very clear, walking me through the handful of steps to install the system. I didn't go through the whole SYSGEN process, just the installation process, and lo, I had a working, running RSTS/E system. Alas, I hardly recognized a thing.
Next step took me back to the version 7.07 distribution. I was now determined to figure this one out. Googling helped. I found a step-by-step recipe for installing this distribution at:
At long last, after half a dozen trials and failures I finally had a good install of RSTS/E 7 running under SIMH with a console SLU and two DZV11 SLU multiplexors (which are accessible by telneting in), along with three RL02 drives, two Rx02 drives, and two TU58 drives, which reflect what this system really has. I didn't do everything right, like not putting every single library add-on package into [1,2], but the system is functional. Now, time to move it to the real machine.
I should point out, that somewhere along the way, while trying to build on SIMH, and thinking I might have to do the installation and SYSGEN on the real hardware, I transferred the distribution from RL01 images to RL02 images. So, now, if I ever want to do so, I can transfer the images to hard media, and do the install on this RL02-based system.
I had built my new RSTS/E installation on an RL02 image file, so all that was required was to copy that image to a real disk cartridge. I fired up RT11, and using Will Kranz' TU58 emulator, I transferred the image to a spare disk cartridge.
And, the sweet smell of success filled the room! The system booted just fine! Much slower than SIMH, but it's alive, it's alive, it's alive! Finally, I'm running RSTS/E, the fulfillment of a long coming goal!
As a side note, I noticed from the boot sequence that the memory map is showing a maximum of only 124KW of memory. This system has 256KW or memory, so what gives. Later web searching suggests, though there are conflicting reports, that RSTS/E 7.0 has support for a maximum of 128KW (256KB). Further reading of the actual 7.0 Release Notes states that this version of RSTS/E 'now' supports the 'new' PDP-11/23 processor. That processor has only 18-bit memory support, since the OS recognizes my system as an 11/23, not the 11/23PLUS that it is, I think that explains the reduced amount of recognized memory.
24-Jun-2010
After completing the cleanup and preparations for using the companion LA120 printing terminal (desribed in separate notes), and with RSTS/E online, I was ready to test everything working together.
At first I connected the LA120 to several of the DZV11 ports, but was not successful, so I then move the connecting cable to the DLV11-E port. I had just reconfigured this device and knew that it was running at 2400baud. I used SETUP on the LA120 to set the communications speed to the same, and pressed a few keys. Lo! I got a response. Printed on the paper, reading as best as I could in the dim corner light, I read:
ajbkdkjf?BYE
PLEASE SAY HELLO
I logged in without difficulty and fiddled around doing a directory listing and otherwise using up lots of paper. Very nice! Now I was cooking, baby! Time to drag out a few VT100s, too!
25-Jun-2010
To start, I swapped the communications cable from the LA120 to a second (non-console) VT100 and after using the terminal's SETUP to configure the communications speed, it showed a good link with the system, and I was able to login to RSTS/E and perform a few superficial tests. All is well.
It was time to tackle the DZV11 ports, and see why I was unable to get much from them before. I was concerned that I might have the cab-kit pigtail cables reversed or that the modules themselves were non-functional. So using the same cable that had been used with the LA120 and VT100 on the DLV11-E port, I connected a VT100 to one of the DZV11 DB25 connectors. On the terminal I was able to get no response to my keystrokes, seeing nothing appear on the screen. I tried various communications speeds, trying 9600, 4800, 2400, even 19200 baud. Nothing.
At that point I seemed to recall something I had read either in the RSTS/E SYSGEN documenation or the DZV11 section of my Peripherals Handbook that the speed of each DZV11 port would default to 300 baud. I tried that speed, and though it was garbled, at last I saw some thing. I would type a line and get a definite response. Time to try just every and any old speed. On the terminal I set the speed to 50, 75, then 110 baud. At 110, the characters cleared up and came through successfully. Slow, slow 10CPI, but working!
Then another recollection hovered in my mind, something about being able to set the terminal speed of the DZV11 port, at the terminal. A quick review of the documentation showed that by using the TTYSET utility, the port speed could be changed. Working at the console, I ran SYSTAT/S to list the running jobs, which gives the terminal number, and I tried setting the speed:
Ready$TTYSET [mumble.......mumble] ? KB13 KB13? SPEED 2400 KB13? ^Z
Ready
Back at the second terminal, I changed it's speed parameters to 2400 buad and it worked! I was able to login and out no trouble. And this confirmed that the port speeds carry over across logins. Once the speed was set, it stayed that way until changed again, or the system was rebooted, at which time all the ports reverted to 110 baud.
Using SYSTAT/S to show the list of running jobs, I could see what the terminal's KB number was, and this allowed me to move the VT100's connecting cable to each of the eight different DZV11 ports and try them out. I was very happy to learn that all ports were active and working, again at 110 baud at first. Using TTYSET I tested each port at 9600 buad and in each case all went well.
I also learned that I could login at the terminal at the slow 110 baud speed, and issue the TTYSET command from there for my own terminal. Of course communication was temporarily interrupted until I changed the VT100s speed to match, but once that was done, the session carried on normally.
On this system, the DZV11 ports are physically arranged this way on the rear of the cabinet:
KB6: - KB9: lower bank, left to right KB10: - KB13: upper bank, left to right
and the DLV11-E port is KB2:.
(I presume that the second CPU SLU will be KB1: if I'm not using it for the TU58 connection. What happened to KB3:, KB4:, and KB5: I don't know.)
A little snooping around, shows that [1,2] contains a file called 'TTY' that is run at startup and I inserted these two lines:
FORCE KB0: KB13: FORCE KB0: SPEED 9600
Upon reboot, these commands are executed and the DZV11 port is set for 9600 baud right at boot time and requires no manual fiddling with communication speeds at the console, or the terminal. This works very well. All I need to do is add lines for each of the other seven ports.
Now it's time to cable up more VT100s!
Copyright © 2006-2025 Jared Blaser. All rights reserved.