(last updated: 12-Aug-2017)
The current configuration has changed from its original 'as acquired' condition. I removed three boards: M8639-YA RQDX1, M7545 TQK50-AA, and Emulex QD01/D. In their place I am using a single M7555 RQDX3, and I have added a Seagate ST-225 (RD31) hard disk to the system, since it had no hard drive when acquired.
The KD32-AB CPU supports F- and D-type floating point operations.
>>> Uses BC13A or BC18P video/kbd/mouse cable <<<
| H9278-A | A | B | C | D | |
|---|---|---|---|---|---|
| Q22/CD | 1 | M7136 : KD32-AB : MicroVAX I CPU memory control | |||
| 2 | M7135-YA : KD32-AB : MicroVAX I CPU (4MHz) datapath | ||||
| 3 | Camintonn CMV-4000 4MB memory | ||||
| Q22/Q22 | 4 | M7602-YA : VCB01, QVSS : Q-bus Video w/ bitmap graphics | |||
| 5 | M3106 : DZQ11-M : 4-Line EIA MUX | M7555 : RQDX3 : MFM HDD & FDD controller | |||
| 6 | (empty) | (empty) | |||
| 7 | (empty) | (empty) | |||
| 8 | (empty) | (empty) | |||
20-Feb-2006
Picked up this system along with several other uVAXen and PDP-11's in Longmont, Colorado.
04-Mar-2006
After a quick surface vacuuming, I removed the box from the shell. I vacuumed the inside of the shell, and cleaned with 'baby wipes'. It came clean pretty well. There was some kind of 'moving' sticker on the top of the shell, probably from a previous commercial owner's business relocation. The label reads: "Global Van Lines / CTA Room #73". I removed it but will use this sticker as a source of this system's nickname.
I cleaned the external surfaces of the big box, and opened it up for a look-see at what the card cage held. After recording that information, I removed the mass storage section cover and the RX50 floppy drive. I notice that the unknown Emulex card has two ribbon cables the are routed under the card cage to the mass storage section (is this right?). It's probably a hard disk controller of some kind. Once I pull the cards and have a better look at this one, I'll be able to determine if that is true. I cleaned the mass storage section with the vacuum, and carefully wiped it down. I also removed the power cable housing and removed the power connection to the backplane, cleaning what I could in the process.
On the back panel I see that the video and mouse mounting plate is upside-down. I removed the four screws and set it right. I also noted that there is some kind of grounding(?) wire on the expansion board and I see no appropriate location to attach it. I left it tucked in the backpanel housing after reversing it. It was not attached to anything when I removed the plate, it was just tucked in as I have it again.
I reassembled the system, putting the big box back into the shell. Without bezels it looks incomplete, but it's the best that can be done at present.
01-Sep-2006
I wanted to test the power supply, but safely. I disconnected all cables from the power supply which included the backplane. I didn't want to apply power yet to the card set, so I left the power connection to the card cage disconnected, and turned on the switch. Not much happened, the fans didn't spin up, yet I heard a very faint high-frequency coming from the power supply. It obviously needed some kind of load.
I connected power to the floppy drive, leaving the data cables detached. This provided enough load to get the switcher to operate, and when I applied power to the system, I got a couple of clicks from the RX50 floppy drive, but still no fan motion at all. So I think the the power supply is happy, but I don't understand why the fans didn't spin up. There is no fan speed controller on this system, as there is on the VAXstation 3200, so I expected the fans to just come on. Something to check in the future as we continue to explore the system.
12-Sep-2006
While preparing a full system power up I discovered that the small 'grounding wire' from the video and mouse port rear panel assembly is a tiny coax cable, and after learning more about the QVSS system in the past few weeks, it was clear that this connected to the QVSS board somehow. With the boards, removed from the card cage it was easy to see the small golden sleeve that accepts this cable. All the boards were reinstalled and the backplane power connections were reconnected.
I connected a VT220 to the rear console DB25 connector, and powered up. The fans came alive and I had a good power up.
13-Sep-2006
After determining the pinout of the BC15Z VAXstation cable, and reading more about its use with monochrome frame buffers and monitors, I figured that I didn't have much to lose by trying this system with that cable, and the monochrome DEC VR262 monitor. I hooked them up, using the Red Video BNC connection to the monitor (as described on various web sites), and an LK401 keyboard.
Sure enough, I get a signal, and I can see console output!
With no mass storage devices on this system, I can't boot, but I can get the console prompt and type a very few one-character commands.
06-Jul-2010
While searching for some information on which RDxx drives were supported by which RQDX(x) controller, I came across DEC's Micronote #43 that describes this. In reading through I learned that there were several firmware updates to all versions of the RQDX(x) controllers. The initial firmware version of the the RQDX1 could only support the 10MB RD51 drive. A later firmware version (v9.0) ROMs could also support the 20MB RD52. This caused me to examine the board photos from this system, hoping to have enough resolution to make out the ROM labels.
It would appear that I have the updated V9.0 ROM firmware. The photo of the controller shows the roms with hand-written labels, each marked 'E5'. According to the Micronote, the part numbers for first two versions of the firmware ROMs (V7.0 and V8.0) both end in 'E4' while the last update (V9.0) ends in 'E5'. It would appear that my ROMs were upgraded in the field, thus the hand-written label, and the 'E5' is indicative of the latest ROM that supports both the RD51 and the RD52. This is good news. Now, all I need is an RD52 drive, or an equivalent (512 cylinders, 8 heads, 17 sectors).
The Micronote also includes a chart showing which XXDP+ diagnostic may be used in a PDP-11 to format a disk that is attached to each version of the RQDX(x) controllers. As it turns out, the diagnostic 'ZRQCB1' supports all three controllers. So, though I don't have a MicroVAX 2000 or the Field Service Diagnostic tape that supports formatting drives on a VAX, when I get a suitable drive I should be able to use one of my PDP-11s to format the drive using the XXDP+ diagnostic. Then just transfer the controller and drive back to the uVAX.
23-Sep-2012
At last, I have returned to this system. A couple of years ago I tried this sytem, but alas the monochrome monitor VR-262 is now dead. No output, no light to its front panel LED, though I can hear the power supply at work. Well, now that I have two choices, either my 20" Sampro CRT (part of my HP PA-RISC gear) or my new Rainbow 100+'s VR-241, each of which have BNC connections.
Also, along the way, I have acquired several Seagate ST-225 20MB drives and I want to use one with this sytem, finally giving it some mass storage. Of course the RQDX1 controller is designed to work with RD51 and RD52 drives, and this ST-225 is not a match to either, however, it should be able to stand in for the 10MB RD51, since it has the the same number of heads, and a greater number of cylinders. For all intents and purposes, it can be 'shortened' to RD51 specs and used as such.
Sadly, I have no way to format this drive in a VAX. This requires the Field Service Maintenance TK50 tape, which I do not have. Instead, though, I do have the means to format MFM disks using a PDP-11/23 or better (MMU required) and XXDP+ diagnostics software tools. This means, though, that I have to move the RQDX1 to a PDP-11 system, which requies some number of hoops to get a proper MFM cable constructed, or, I can assemble the PDP-11 (CPU, memory, SLU) in this BA23 chassis, which already has the cabling, switch panel, etc. for MFM drives. I am choosing, this time, to take the latter approach.
In preparation for that, I have to remove all the VAX boards from the system, which gives me a chance, after a long delay, to record each board's serial number and configuration settings.
First, a check from my September 1, 2006 notes shows how the back panel cables should be, so I disconnected all the ribbon and small coax cables and removed the back panel. Then removed each board, recording details about it:
1- M7136 : KD32-AB uVAX I Mem Cntlr : s/n Z21445703 Single jumper center above bottom row of ICs installed2- M7135-YA : KD32-AB uVAX I Data Path w/ D floating point : s/n 21584(?) switch block upper-left outboard: 1-7:off 8:on switch block upper-left inboard: 1,3-8:off 2:on jumper block upper-left: 2-3 (inboard pair) jumpered
3- Camintonn CMV-4000 4MB memory : s/n 4101 jumper R:on jumper P:on jumper N:on jumper M:on jumper A/B:lower pair jumpered jumper W1/W2:upper pair jumpered jumper K/L:lower pair jumpered jumper C/D:left vertical pair jumpered switch block SW1: 1-6:on switch block SW2: 1,3-6:on 2:off
4AB- M3106 : 4-SLU Async : s/n KLO8866260 upper-outboard switch block: 1-6,8-10:off 7:on lower-inboard switch block: 1,4-7,9-10:off 2,3,8:on
4CD- G7272 : bus grant
5- M7602-YA : QVSS bit map graphics : s/n AB53301TS1 upper-center switch: C2 lower-inboard switch block: 1-4,6:closed 5,7,8:open lower-outboard switch block: 1-4:open
6AB- M7546 : TK50 controller : s/n EN25283 upper jumper near connector:jumpered upper jumper near N82SI05NG:jumpered lower jumper near N82SI05NG:jumpered lower left corner jumpers from top to bottom:on,on,off,off,on,off,on,off,off,off,off outboard switch block: 1-8:off inboard switch block: 1-8:off
6CD- Emulex QD01 : ST506 MFM disk cntlr : s/n AQ7150 switch block SW1: 1-4:open (1) DISABLE loop on test error (2-4) LUN 0 switch block SW2: 1-5,7,8:off 6:on (1) RUN mode (2) DISABLE auto bootstrap (3-5) CSR Address: 172150 (standard) (6) 22-BIT Addressing (7) 4usec DMA burst (8) RESERVED jumper J4: all off middle-right jumper ABC: AB pair jumpered lower-center jumper DE: off lower-right jumper FG: off
7- M8639-YA : RDRX1 cntr : s/n SG14989843 LUN: 0; upper-left jumper block (LUN): 0-7:off CSR: 160354; lower-center jumper block: A2,A3,A5,A6,A7:on A4,A8-A12:off
At this point, it's time to install PDP-11 boards. From my spares box of dual-sized boards, I installed:
1- M8192 - 11/73 CPU 2- Clearpoint Q-RAM Q11 (44B) 2MB RAM 3- M8043 - DLV11-J 4-SLU
I then cabled up to a VT102, and powered up. It works, I have ODT. Ah, my first microPDP! Ha!
I have no boot ROM or whatever, so I now have to figure out how to boot from the RX50. Perhaps the ROM on the RQDX1 serves as a boot ROM. I shutdown and added the RQDX1 in the fourth row, and repowered. No go. But still ODT works. Executing to 173000 only goes into never-land.
26-Feb-2013
Further work on this project continues. I am documenting the 'MicroPDP-11/73' configuration elsewhere, except for the following.
I found this MSCP bootstrap for the PDP-11:
http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/bootstraps/mscp_rt11.txt076000/005000 012701 172150 012704 076156 012705 004000 010102 010022 005712 100770 031205 000401 042125 001772 014412 006305 100367 105744 001002 010704 005007 005002 005022 020227 017204 103774 105237 017101 010037 017110 111437 017114 114437 017121 012722 017004 010522 012722 017104 010512 024242 005711 005712 100776 005737 017016 001742 000000 020402 004400 000001 000000 017204 100000^M r6/001000^M 076000g^M
Note those are real
on the last three lines. Connect to your 11/23 console port and type in that text. (all lines but the last three have at the end). This will boot DU0. Put this text into a file, e.g. duboot.odt Use Kermit on some other computer to talk to the console port
SET FILE TYPE TEXT SET TRANSMIT PAUSE 10 TRANSMIT duboot.odt CONNECT
TRANSMIT PAUSE 10 (wait 10 ms between characters) seems about right for an 11/73. You might have to send slower for the 11/23.
Modification to boot other than DU0: Start the program one word earlier (075776) For the CLR R0 (005000) instruction, substitute MOV #1, R0 ; to boot drive 1
03-Mar-2013
Other adventures using this chassis to host a MicroPDP-11/73 setup for formatting hard drives is documented elsewhere, but the pertinent details for this whole system are that the RQDX1 was swapped out for an RQDX3 that I had in my spares box, and a Seagate ST-225 20MB hard disk was attached and formatted as an RD31. The RQDX3 is setup with the standard factory configuration (CSR:172150, LUN:0).
Also, now that the RQDX3 is functional with an 'RD31' and the RX50 floppy drive(s), I removed the as-acquired Emulex QD01/D MFM controller, and since this system has no TK50 tape drive, I also removed the M7546 TQK50-AA controller placing it, the Emulex QD01/D and the RQDX1 back into my spares collection. If ever I come across a true RD51 (ST-412) or RD52 (Q540), I'll return the RQDX1 to this system with that drive, making it more true to it's original configuration.
For the record, here is the as-acquired module list:
Rows 1-3 : Q22/CD 1 - M7136 : KD32-AB : MicroVAX I memory control -> 2 - M7135-YA : KD32-AB : MicroVAX I datapath -> 3 - Camintonn CMV-4000 4MB memory -> Rows 4-8 : Q22/Q22 4 - M3106 : DZQ11-M : 4-Line EIA MUX | G7272 Bus Grant 5 - M7602-YA : QVSS : Q-bus Video w/ bitmap graphics -> 6 - M7546 : TQK50-AA : TMSCP controller for TK50 | Emulex QD01 : ST506 MFM disk controller 7 - M8639-YA : RQDX1 : RD51/52 & RX50 controller -> 8 - (empty) | (empty)
05-Mar-2013
While using this system to host a MicroPDP-11/73 rig for the purpose of formatting random hard disks, I learned that the original uVAX I uses plain old Q-Bus memory boards, which suggests that any PDP-11 Q-Bus memory board would work in this uVAX, and this system's Camintonn board should work with a PDP-11, such as the MicroPDP-11/73 I've been working with.
I tested this by replacing the Clearpoint Q11 (Q44) board in the MicroPDP-11/73 configuration with the Camintonn CMV-4000. Indeed it works. However, a SHOW CONFIGURATION command (RT11) on the PDP-11/73 shows that only 3840KB are recognized. This leaves 256KB unaccounted for and I wonder if the board's configuration jumpers are 'wrong' or if there is purposely a hole at the end of memory. I believe that this first uVAX has a maximum of 4MB memory space, and since there must be at least a 8KB hole at the top of RAM for the hardware register space, that might be what's afoot here.
Searching the 'net, I am unable to locate documentation for this board tonight, but I might examine the jumpers and see if I can make sense of them.
02-Jul-2016
With the demise of the VR262 mono monitor, I had to find another device that could be used with this systems graphics subsystem. Here are some results:
- HP 1740 (has SoG capability, but...) = no signal detected - Viewsonic VG2030wm (has SoG) = WORKS!
11-Aug-2017
Somewhere along the way, probably last year, I have created a set of three diagnostic diskettes (RX50 formatted, 5-1/4") and started playing with them today. I find that only the first is bootable with:
>>>B DUA1
but it does run a set of top-level diagnostics on the CPU, Memory, storage devices, DLV11-J (if installed), DZV11 (if installed), DEQNA (if installed), and the QDSS graphic video options.
In my case today I see the following output:
BLAH BLAH BLAH
Searching the web for more information, I located on bitsavers.org a Pocket Service Guide for the MicroVAX I (August 1984, 1st Ed.) which includes information about using the diagnostics (but it only refers to a two-diskette set). Apparently, there are a number of more rigorous diagnostics for each subsystem, which are loaded using a special boot incantation:
>>>B/100 DUA1 Bootfile: [SYS0.SYSMAINT](enter filename here)
It seems that my floppy is either corrupt or maybe I have a different version, and I wasn't able to get the CPU Diagnostic to load (EHKAA.EXE), but I was successful loading and running the Memory Diagnostic (EHXMS.EXE).
The Memory Configuration Test spit out many errors:
Too few memory CSRs presents: expected at least 3, found 1
I'm not sure what that means. The initial, top-level diagnostic reports 3.75MB RAM (3840KB), and that it tested successfully.
Regarding the memory size, I guess this is a 22-bit memory address, so the maximum memory size is 4MB, and with the gap at the top of memory for the hardware addresses, that leaves the system with 3840KB of usable memory. Okay, I get it.
I learned how to run each subtest separately, and each, other than TEST 2, passed with no errors:
TEST 1: CSR Function Test TEST 2: Memory Configuration Test TEST 3: Memory Address Test - Part 1 TEST 4: Memory Address Test - Part 2 TEST 5: Memory Address Test - Part 3 TEST 6: Memory Address Test - Part 4 TEST 7: Worst Case Noise Test TEST 8: Memory Parity Test TEST 9: DATIO Test TEST 10: DATIOB Test TEST 11: Instruction Execution Test TEST 12: Marching 1's and 0's Test
Nonetheless, I am able to say now, with reasonable assurance, that the system is functional and operational. I need to install VMS somehow.
I have suitable versions of (imaged) installation media, but they are 'tapes'. All I have is a RX50 drive, so somehow I need to generate a suitable set of RX50 floppy diskettes. On the other hand, the system was acquired with a TQK50-AA (M7545) module in the backplane, though there was no attached drive, but perhaps I could rig up an external TK50 drive borrowed from another system, get a tape image copied to a real tape, and install from that. Or, on the third hand, I could use a 'tape' image with SIMH installing to a virtual RD31, then image that drive to the real drive. That last one is a challenge since I can't just netboot NetBSD and write the image to the real drive. NetBSD doesn't support the uVAX I.
Copyright © 2006-2025 Jared Blaser. All rights reserved.