(last updated: 16-Jul-2017)
The current configuration is in its original 'as acquired' condition, except that I have removed the DLV11 Parallel module, replacing it with a DEQNA Ethernet module.
5MB total memory -- can support up to 9MB of memory (1MB on CPU + 2 4MB boards).
71MB hard disk -- can support up to 159MB of mass storage on an RD54 (Maxtor XT-2190).
| H9278-A | A | B | C | D | |
|---|---|---|---|---|---|
| Q22/CD | 1 | M7606-ET : KA630-AA : uVAX II CPU (5MHz) w/ 1MB, TOY, ROM | |||
| 2 | M7608-BP : MS630-BB : 4MB RAM | ||||
| 3 | M9047 : bus grant | (empty) | |||
| Q22/Q22 | 4 | M7504 : DEQNA : Ethernet | M3106 : DZQ11-M : 4-SLU async MUX | ||
| 5 | M7546 : TQK50-AA : TK50 cntlr | M7555 : RQDX3 : MFM/floppy cntlr | |||
| 6 | (empty) | (empty) | |||
| 7 | (empty) | (empty) | |||
| 8 | (empty) | (empty) | |||
20-Feb-2006
This unit was part of a large pickup in Longmont, Colorado.
04-Mar-2006
I cleaned the shell with 'baby wipes' and while it came clean, the shell still shows a number of scrapes and scuffs. Also the pedistal has a 2-inch crack on the rear end. Looks like this particular unit has seen some usage.
When I removed the big box from the shell (from the rear) I found a free screw in the bottom of the shell. I can see that it belongs on the cover over the mass storage device section. I put it back.
Inside the big box, however, I saw that this was the cleanest of the three BA23 systems acquired in the Longmont pickup. I removed the mass storage section cover, the card cage cover, and the housing around the fan and power cables.
Upon examination of the card cage, some of the modules are dislodged and askew. Still, everything looked in good shape. I cleaned all of the surfaces with a vacuum and the wipes. I re-seated the modules in the card cage. For now, with the system as clean as it is, I'll just leave them as they are. Eventually, I'll remove them for further identification, but there's no immediate need. I removed the mass storage section cover, the card cage cover, and the rear panel. This unit overall is the cleanest inside of the three BA23 machines that I have.
There is an interesting piggy-back cable taking power from one of the disk drive power cables which then runs under the card cage terminating in two mate-n-lock power connectors on the rear panel. Obviously, some other external devices were pulling power from this system, but I have no idea what they were.
I removed the TK50 and RD53 drives from the box, and noticed that the TK50's latching solenoid cylinder was seriously out of alignment, almost falling out of its mounting. It's just pressed into place, and I expect that one of the hard knocks this system has suffered also nudged the solonoid. I pressed it back into it's proper place, and hope that no real damage has been done to this TK50 unit. Unfortunately, I didn't think to take a photo before putting things right, and it didn't make much sense to do so afterward.
I recall that the RD53 fell out of the enclosure when we were doing the pickup staging in Longmont.
I replaced the mass storage devices (to load the upcoming power supply test) and disconnected all power from the backplane (for the same reason). I left the data cables unconnected to the RD53 drive. I want to prevent any data loss (assuming the drive still works).
04-Mar-2006
Until I learn more about this system, and how it should normally behave on bootup, I wanted to do nothing more than test the power supply. I did this by removing the power connections to the backplane, but attaching power to the mass storage units. I left the data cables detached. With these drives serving as an appropriate load for the switching power supply, I powered up. Both fans came immediately up to speed just fine. There is not a fan speed controller on this system, so the fans will always operate at full speed, I guess.
The RD53 winchester spun up, luckily and apparently without any problems related to the small tumble it took during our pickup preparations. We will determine later if the data is readable. On the TK50, I am not getting a ready light, but rather the power light/button blinks rapidly. If I toggle the button in and out again, the light will show steady for about one second, then return to constant blinking. This is not consistent with the behavior I observed with the VAXstation 3200, which also has a TK50, when I performed this power supply test.
Still, it appears that the power supply is good, and I will come back to further testing when I have more knowledge of what to expect on bootup, and the tools to image the RD53. The first thing that I want to do when the system is functional is to get a snapshot of the drive's contents. Once the image is safely made, then I can begin to experiment withe the configuration and data. I'll be interested to see what's on the system, probably VMS, but maybe some flavor of UNIX.
06-Sep-2006
Since I never actually removed or cleaned the boards in this system yet, before I power it up I want to do so.
I vacuumed all the boards, and the inside of the cage. It was very clean already. Then I reinstalled all the boards and cables, just as I removed them. I still think that there might be a cable reversed somewhere, but better to leave as is for now.
06-Sep-2006
Uh, oh! There's not indication on the rear panel LED when I power up, and the VT100 sees no output. Is the system dead?! There are NO indicatios on any of the board LEDs. Everything is dark. Is the backplane powered? Let me check. No, my notes above indicate that this is NOT connected. Whew! Let me hook it up and we'll try again. Much better!
At least I see LEDs light up and varios digits are cycling through the rear panel LED. Still nothing on the terminal, though. Oh, I had the #2 knob in TEST mode. Switching to the arrow RUN mode and I got a boot!
I grabbed my eBay-souced DEQNA. I pulled the M9047 bus grant card from slot 3 and installed the M7504 in it's place. Should take care of all the bus signals fine.
I rebooted, and was able to read the hardware address via the console commands:
>>> e/p/w 20001920 P 20001920 FF08 >>> e/p/w P 20001922 FF00 >>> e/p/w P 20001924 FF2B >>> e/p/w P 20001926 FF03 >>> e/p/w P 20001928 FF6D >>> e/p/w P 2000192A FFD6 >>>
So, I have a hardware address of 08:00:2B:03:6D:D6 for this DEQNA. When I connected my AUI to TP transciever I see good power indications, and with my Debian box connected through the cross-over ethernet cable, I get a good link indication.
06-Sep-2006
So, now to image the disk. I let the NetBSD install kernel load and when sysinst comes up, I used the Utilities->Configure Network to set up the IP address and exited out of sysinst altogether
Leaving the WRITE-PROTECT switch in, I set the READY switch for the drive on the front panel and rebooted. Again it showed the drive as ra0, and this time it didn't say anything about it being offline.
I finally got something to happen with this command:
dd if=/dev/ra0a of=/tmp/MicroVAX_II_RD53.dsk
All I can say now is that I'm amazed that the hard drive survived the fall to the floor during our pickup in Longmont!
Now, I'll let the box boot to the disk directly, and see what it has on it. This is the output:
2..1..0..Ultrixboot (using VMB version 13)
Loading (a)vmunix ...
Sizes: text = 415888 data = 165088 bss = 203156 Starting at 0x208d
Ultrix V2.2 System #1: Wed Mar 6 12:06:54 EST 1991 real mem = 5238784 avail mem = 3535872 using 183 buffers containing 523254 bytes of memory MicroVAX-II with an FPU Q22 bus klesiu0 at uba0 tmscp1 at klesiu0 csr 174500 vec 774, ipl 17 tms0 at tmscp1 slave 0 uda0 at uba0 uq0 at uda0 csr 172150 vec 770, ipl 17 ra0 at uq0 slave 0 dz0 at uba0 csr 160100 vec 300, ipl 17 ntx0 at uba0 csr 172410 didn't interrupt No NSC adapter present at 80751508 Automatic reboot in progress... Fri Mar 3 15:56:22 EST 1995 /dev/ra0a: 451 files, 4830 used, 2585 free (73 frags, 314 blocks) /dev/rra0g: 2549 files, 41308 used, 539 free (259 fragds, 35 blocks) Fri9 Mar 3 15:57:14 EST 1995 System supports 2 users. check quotas: done. local daemons:. Removing remnant Opser files preserving editor files clearing /tmp standard daemons: update cron accounting erase ^?, kill ^U, intr ^C #
So, there you have it! It's ULTRIX!
I don't think there is anything special to preserve on this disk, but I'll keep the image (of course) and do some more checking later. More poking around reveals that most files are softlinked to another drive, long gone to me. What's here is the barest minimum installation. Nothing really. Ah well. I shut the system down.
I removed the DEQNA card, retuning the bus grant card to it's place in slot 3. The configuration is, now again, back to the original setup.
27-Jul-2007
BAD NEWS! Alas, after fooling around for a couple of hours, out of nowhere, the RD53 (Micropolis) drive spun down. No hints, about it from the OS. It just spun down. I wonder if the motor, or the motor power circuitry, has suddenly gone over the edge? If I power down the system, then power up again, the drive will spin up, then after one or two minutes, it will spin down. The drive's own braking mechanism solonoid stays 'open' but the spindle motor just kind of 'give's up' and the spindle will slowly wind down. I wonder if one of the power transistors that drives this motor is going bad. Without any kind of circuit diagram, I'm up a creek!
20-Apr-2009
Today I examined a possible replacement hard disk that I received a couple of days ago, a Micropolis 1335. I bought this on eBay for a mere $5. It's getting harder and harder to find these kind of 'steals' on eBay. Most sellers of this type of vintage stuff now set pretty high Buy-it-now prices. This drive though appears to have come from a PC, so the seller may not be 'into' the collector's mindset.
The drive has jumpers on W1, W2, and DS1, and has the terminating resistor pack removed. If this came from a PC environment, this would be consistent with a second (or D:) drive. To use this as a primary, the Drive Select jumper should be set to DS2, and the resistor pack should be re-installed.
My drive does not have anything in the R7 position, so I'll need to add that jumper before I try to format this on an RQDXn controller.
As for the resistor pack, perhaps I can scavenge that from the now-defunct original drive. One other thought related to that first drive is that if the drive is okay, but the electronics are bad, a swap of controllers might bring it back to life. Probably would require a reformat, since the specific electronics were replaced.
06-Jul-2010
On a lark, I fired this system up. Sure enough, it booted without a hitch. The hard disk problems are most likely related to heat, and as the drive gets warmer, it starts to flake out. Anyway it worked fine for me today.
I poked around some more in /usr trying to discover a bit more about what's on the system. I am more convinced than ever, now, that this system served as some kind of system monitor for a telephone system switch or 'local office'. I discovered a 'monitor' that I can run if I login as user HCmon and then run 'mainmenu' from the user's local /bin directory. The system tries very hard to connect to external devices it seems but of course it fails. Another option on the menu is to draw a bar graph. When I choose this, I see the system generate several dozen error messages, then it produces some kind of terminal-specific output that doesn't display correctly on the VT131 serving as the console device. This repeats about every 2 minutes. Further investigation shows a sub-menu the has a couple of items that refer to 'trunk statistics' so I'm very sure this system was part of a telco switching office.
While this was going on, I also took the opportunity to move my terminal connection to the four extra serial ports, each in turn. I was able to see good output from the lower three, but the top port is quiet, and I suspect this fourth port may have served as an LP/SP printer port. A quick 'ps aux' indeed shows three 'getty' processes and an 'lpd' process. That would account for all four ports. Indeed this is the case. I used 'print' to add a large text file to the print queue and then switched the console cable to the fourth port. Sure enough, I see the printing document on the terminal. So, we can conclude that the DZQ11-N 4-port SLU module is working well.
09-Jul-2010
First things first. After reading of various horror stories regarding TK50 drives and tape cartridges, I wanted to see if this drive was going to operate properly before inserting my one and only VMS installation tape (previously imaged!). Using a blank TK70 cartridge which has identical physical characteristics I refreshed my memory about how to load and unload the cartridge. The sequence is this:
To load: - check red button is 'out' - raise/extend the TK50 drive handle - insert the tape cartridge until it 'clicks' - lower the handle - press the red button 'in'
To unload: - press the red button 'out' - wait for steady green light with red light off - raise handle - remove tape cartridge - lower handle
This system is old enough that it doesn't have a way to list the connected devices from the console prompt. But I discovered what the TK50 tape drive designation is. At the chevron (>>>) prompt, I used 'b mua0' to try to boot from the tape. It spun for a while, but after about 5 minutes halted with:
>>> b mua02.. ?43 FILESTRUCT, MUA0 ?06 HLT INST PC = 00000EE6 Failure. >>>
A couple of additional tries produced:
>>> b mua02.. ?4D DEVOFFLINE, MUA0 ?06 HLT INST PC = 00000EE6 Failure. >>>
Perhaps this means that my tape is no good, damaged, blank, or otherwise overwritten, or that the drive is faulty. This would be bad, since then I have no other way to install VMS on this system, at least for now.
[I also tried this tape in the VAXstation/GPX and saw the same results. I take it that it is not the drive, rather it is that the tape has been erased or rewritten.]
07-Jul-2015
The last couple of days I have been playing a little more with this system. Further investigations shows that this system is installed with NETEX and HyperChannel software from Network Systems Corporation. I presume that any interconnectivity to and from this system was via the HC. There being no network card or software configuration on the ULTRIX 2.2 system would tend to support that idea.
However, it is time to get this system configured for the network. It was acquired without network capability. I dug out my spares box, and installed a DEQNA card that was part of the large Longmont haul, coupling that with an eBay-sourced bulkhead with the AUI connector. I temporarily installed this by first removing the DRV11 Parallel Interface, inserting the DEQNA in its place. The parallel adapter appears to have been used in the NETEX/HC setup, but is not useful to me at present. Besides, the two external connectors for that parallel board are in the backpanel position(s) that I need to open up for installation of the DEQNA bulkhead assembly. In any case, I have it temporarily rigged up with the DEQNA bulkhead loosely hanging.
The ULTRIX 2.2 installation is more or less a 'full' installation with all the components local to the hard disk, unlike the other uVAXen that I have with have a very minimal installation of the kernel etc, with most of /USR coming from a remote NFS-mounted system. In this case, it's all self-contained, but it is still pretty limited. I don't have any telnet or ftp capabilities, neither as client of server. After further poking around, though, I did notice that /bin contains nfs-mount. Aha! Perhaps I can NFS mount to one of my other servers, and use that as a means of moving files to and from this system. Indeed, after a few false starts, this is exactly what happened.
So, first I discovered that the ethernet device is called qe0. Then I had to update the /etc/hosts file with the servers that I tried (see next paragraph). Turns out the this ULTRIX 2.2 NFS client cannot use the IP address directly in the mount command, rather it needs to lookup the server's name in /etc/hosts.
# ifconfig qe0 192.168.1.200 netmask 255.255.255.0 broadcast 192.168.1.255 # route add default 192.168.1.254 1 # echo 192.168.1.10 astaroth >> /etc/hosts
First, I tried my newest Debian 6.0 server 'humbaba', and though I seemed to have NFS exports and the servers running, the connection was refused. Next I tried Debian 6.0 server 'gusoyn'. Same result. Lastly, I tried my oldest Debian 3.0 server 'astaroth'. It works! I can mount with:
# mount -t nfs astaroth:/home/jared /mnt
So, I now have the means to move files to and from this system, via astaroth. Maybe I'll try building frotz and running zork!
09-Jul-2015
I spent a good deal of today's time fiddling with TK50 tapes, trying to learn more about their operational usage, and trying to discover if I had anything useful on my two TK50 tape cartridges.
The first is labeled "MV II END USER DIAGS 2.2" and I was finally able to get it to load, but after entering the date, it loaded some more tape, then there was a clunk, and nothering else happened, on screen or hardware-wise. Multiple tries gave the same result.
The second is labeled "VMS 5.2-2 BIN 1/1", but I was never able to get it to boot. It would spin for a while, and eventually I would be dumped back to the console with a DEVICE OFFLINE error. Again, multiple tries were unsuccessful.
Sadly, too, during this day's adventures the RD53 drive simply went offline, spinning down on it's own, as I saw years ago. I worked with it some, but was never successful booting from it again.
Copyright © 2006-2025 Jared Blaser. All rights reserved.