(last updated: 18-Jul-2017)
The current configuration is in its original 'as acquired' condition.
>>> Uses BC18Z Video/Kbd/Mouse cable <<<
| BA123 | A | B | C | D | |
|---|---|---|---|---|---|
| Q22/CD | 1 | M7606-AF : KA630-AA : MicroVAX II CPU (5MHz) w/ 1MB, FPP, TOY, ROM | |||
| 2 | M7609-AF : MS630-CA : 8MB RAM | ||||
| 3 | M7609-AF : MS630-CA : 8MB RAM | ||||
| 4 | M7169 : VCB02, QDSS : video cntlr | ||||
| Q22/Q22 | 5 | M7168 : VCB02, QDSS : 4-plane color | |||
| 6 | M7168 : VCB02, QDSS : 4-plane color | ||||
| 7 | M7504 : DEQNA : Ethernet controller | M3106 : DZQ11-M : 4-SLU MUX | |||
| 8 | AVIV TFC909 (Pertec, TS11 compatible) | ||||
| 9 | M9047 Grant Continuity | Micro Seconds QB303 Grant Continuity | |||
| 10 | M7546 : TQK50-AA : TK50 TMSCP cntlr | M7555 : RQDX3 : MFM and floppy MSCP controller | |||
| 11 | Emulex QD21 ESDI MSCP ctrlr | Micro Seconds QB303 Grant Continuity | |||
| 12 | (empty) | (empty) | |||
| (power) | 13 | (empty) | M9058 : RQDX* Distribution Board | ||
20-Feb-2006
This unit was part of a large pickup in Longmont, Colorado.
08-Mar-2006
First a vacuuming and wipe down of all external surfaces. It's a little scuffed, permanently, here and there, especially on the top, and the covering door over the front control panel is missing.
So, trying to get in. I found that loosening the screw on the lower left of the control panel releases the adjacent side panel, which uses snap-on clips along the lower edge to hold it in place (along with the screw, of course). The panel comes out along the bottom, then is lifted slightly to come off completely.
The rear has a corner door to the back panel. Removing the screw (photo'd) allows removal of the left side panel, revealing cover plates, on of which has an inventory of the modules. We'll check our own inventory.
Removed the front panel, now that the side panels are off.
Removed the cover plates on the right side, under the inventory label. Wow! A packed card cage! Also there are (3) hard drives and TK50 cartridge tape drive in the front bays. This system is full!
I pulled all of the boards and drives. Things are pretty dusty. A good vacuuming is needed by the chassis and the boards and drives. I did it!
I removed the hard disk distribution board, cables, the power section base
fan, and the power supply itself. Everything was vacuumed and cleaned.
Now if I can remember how to re-assemble! :)
I couldn't determine the backplane model number. I could see some 'assembly' numbers but nothing looked like the normal Hxxxx type of number. Thinking this number might be hidden behind some of the mounting sheet metal, I decided to remove the backplane as well, which I did by removing the smaller screws from under the power supply section (photo'd). Still had no luck with finding a Hxxxx number, so I've taken the assembly number after all.
Ready to re-assemble.
I relocated the TK50 drive from the top of the hard disk stack on the right side of the cabinet to the left side vertical-mount position. Aesthetical! :)
11-Mar-2006
I plugged the power supply in on my work table and flipped the switch. The fan comes alive! So I think it's going to work without any further efforts.
Re-installed the power cable section fan, power supply, cable section expansion panel plate (2 screws are missing), the drives, all boards and cables. I closed all covers (power supply and card cage), and re-installed the front, left, and right side cabinet panels. Done!
07-Sep-2006
connected a VT100 with the 9-pin cable (pins 8 and 9 shorted), and connected a AUI-to-TP ethernet transceiver. I'm ready to power this guy up! And, hopefully, image the disks.
I set the WRITE-PROTECT switches on all three hard disks, so here we go!
Ha ha! The laughs on me. I powered up and waited, and waited, for something to appear on the terminal. I had the rear-panel knob set to TEST! Ha ha. Okay, here we go again.
Well, with much fiddling with the HALT and RESTART buttons I finally got some output on the terminal (photo), but I don't see any kind of countdown. If I have the rear panel switch set to the arrow (RUN), I never see any terminal output, and the LED shows 'A' continuously. I left it like this for about 5 minutes just to be sure that it wasn't counting some enourmous memory. I figure 5 minutes is long enough for that! So what's going on!?
Fiddling around with the >>> prompt (remember, I never saw a countdown!), I tried:
>>> e/w/p 20001920 P 20001920 FF08
Wohoo! Something, in fact the first two digits of the DEQNA ethernet address. I finished the process and now have the full ethernet MAC address of:
08:00:2B:07:4F:1A
So, let's see what else we can do...
Nothing much. The thing is stuck in some tight loop, that I *can* break into with appropriate pushing of the HALT and RESTART/RUN buttons, but there's nothing I can really do. Something isn't quite right, and I think what I'll do is pull all the cards except the CPU, one MEMORY board, and the RQDX3 controller. If that will boot properly, then I'll definitely get the disk images. After that I can experiment with putting the boards back in one by one, and seeing what happens.
I left the CPU and memory cards in slots 1, 2, and 3.
With all these cards out, I reconnected the terminal, and powered up. I saw it do the countown to >>> prompt.
KA630-A.V1.3Performing normal system tests.
7..6..5..4..3..
Tests completed.
>>>
The system took a while on test 7, and even longer on test 6 (a good 2 minutes), but the others when very quickly.
So, this looks better. I don't have any peripherals connected so I can't do anything else for now. Let's put the ethernet in and see if we can get it to boot NetBSD.
Well, this is good! I was able to:
>>> B XQA0
and got the NetBSD install kernal to load without any troubles. I went ahead and configured the network, but when I exited out to the shell, I couldn't ping my Debian box as I have done with the other boxes. Something else is amiss, here. Though I can ping the VAX from the Debian box. Hmm...
I'll try to image a disk tomorrow.
08-Sep-2006
Just to make sure that I had good communications with this reduced card cage setup, I rebooted the system and then NFS mounted the Debian export. It worked, but when I listed the dir, it gave me the file names and then :Permission denied. I tried to ping the Debian box, got no output, but could CTRL-C it to terminate.
Checking my /etc/bootptab file on the Debian box, showed that I had misnamed the system, so I made that small correction, from 'MicroVAX_II_GPX' to 'VAXstation_II_GPX'. Just for kicks I rebooted.
Suddenly, everything works as expected. I can configure the network, exit sysinst, and ping the Debian box. After mounting the Debian export, I can do a normal 'ls -l' without the permission errors. Hmm... I don't understand, but I'll take it!
08-Sep-2006
I shutdown and installed the MSCP controller for the RD54 hard disks, then rebooted. Still all was just fine, and I went ahead with the imaging command:
# dd if=/dev/ra0a of=/tmp/VAXstation_II_GPX_RD54_O.dsk ra0: no disk label: size 311200 sectors ra0: invalid command (unknown subcode) ( code 1, subcode 96) ra0: invalid command (unknown subcode) ( code 1, subcode 96) 311200+0 records in 311200+0 records out 159334400 bytes transferred in 2682 secs (59408 bytes/sec) #
Fortunately, I saw NO ethernet errors, like I did while imaging the VAXstation 3200's drive. Whew!
I made a second copy of the disk for comparison, and generated MD5 hashes. They matched so I have a good image of drive 'DUA0'.
I imaged the second RD54, 'DUA1', again twice to compare for good copies.
In the meantime, while waiting, I studied some more UNIX documents and noted that when referencing a device the 'c' 'partition' indicates the whole drive. So instead of doing my 'dd' command with 'ra0a', for example, I should really be using 'ra0c'. This is why I've been getting the complaints about not finding a disk label. As it turns out, I've successfully imaged the whole drive with my erroneous reference to the 'a' partition, but, starting with the extra copy of 'DUA1', I used the '/dev/ra1c' as the reference to the disk in my dd command.
During the second copy transfer, I noticed that communications had stopped (the transceiver lights weren't blinking), but I could see an occasional flash on the TX LED, indicating that the VAX was trying to send. On the Debian box, I issued a 'ifdown eth0' command, then a 'ifup eth0' command. This restored communcations again. There appears to be some bit of marginal-ness to the way these two system talk, but less so than there was with the VAXstation 3200.
My MD5 checksums matched, however, so I did get a good copy.
Now, trying to get an image of the Fujitsu ESDI drive has proved to be more difficult. I put the Emulex QD21 controller in with the RQDX3 controller, but NetBSD didn't recognize the Emulex, but still did the RQDX3. I pulled the RQDX3 and had the same result. Maybe the QD21 is configured to use floating addresses that depend on other boards being in the system too.
09-Sep-2006
This morning I'm going to try running the QD21 as the primary MSCP controller, without the RQDX3 installed at all. So, I'll have the CPU, Memory, DEQNA and the QD21.
Before I change the settings of the QD21, here are the original settings:
- SW1 (1-4): open, closed, open, closed - SW2 (1-8): off, off, off, on, on, on, off, off - all Jumpers, off except: P-Q jumpered
Well, this effort paid off! NetBSD now recognizes the controller as ra0. Interesting thing, though, when I NFS mounted the image directory on the Debian box, I can write data, but get those Permission Denied messages when trying to read. Anyway, I imaged the drive and saw this output:
# dd if=/dev/ra0c of=/tmp/VAXstation_II_GPX_Fujitsu_M2264E.dsk ra0: no disk label: size 277848 sectors ra0: drive 0 soft error datagram (continuing): unit 0: level 0 retry 1, lbn 199773: data error (3 symbol ecc) (code 8, subcode 10) ra0: drive 0 soft error datagram (continuing): unit 0: level 0 retry 1, lbn 230496: data error (3 symbol ecc) (code 8, subcode 10) ra0: invalid command (unknown subcode) (code 1, subcode 224) ra0: invalid command (unknown subcode) (code 1, subcode 224) 278800+0 records in 278800+0 records out 142745600 bytes transferred in 2454 secs (58168 bytes/sec) #
I made a second copy for comparison.
I have the box working, but without all of the boards installed. I think I'll reinstall everything as it was, and work troubleshooting it another day. So, I changed the Emulex QD21 settings back to what they were originally, and put all the boards back in, and cabled everything.
19-Oct-2006
I'm going to re-image all of the disks, just to make sure I have true copies of them. My first set of CDs burned on the Presario may be corrupted, so I'm doing another set.
As before, when I power up the system with all of the boards installed I don't see a countdown as expected. Only with some HALT and RESTART button fiddling could I get a console prompt, but I still couldn't get the ethernet (ESA0) to boot. In fact, I don't see anything in the Debian log at all, suggesting that this system is not sending packets in the first place. I'm going to pull cards, as before.
I removed all the cards from slots 7-12, leaving only the CPU, memory, and QDSS video sub-system cards. Still have the same result, so the problem lies in the video system, I guess, since the CPU and memory worked fine in the first round.
After pulling the QDSS cards, with just the CPU and memory cards install, I get the countdown! So, the QDSS is flaky somehow.
Well, pulling all of the cards again gives me another chance to document the board configurations, which I should have done by now. I'll pull the CPU and memory boards, too, to get a complete set of details.
As before, I installed only the CPU, two memory cards, Ethernet, RQDX3, and Emulex QD21 cards. Here we go... Well, bad. I can't get the ethernet to do the MOP. I see that all LEDs on the board are out indicating that it is init'd and ready, and I see a flicker on the transceiver and the ethernet hub, but I don't see anything on the Debian box. Nothing in the logs.
Oh, wait, here's something in the /var/log/syslog. I AM seeing MOP requests from the VAX. I don't know why they werent' showing up before, but here they are now. But, it is still not working on the VAX side.
02-Nov-2006
After more fiddling around, with this and that, including the /etc/exports file on the linux box, and the restarting of all the related deamons on the linux box, along with slotting the AVIV tape controller back in the backplane, and it started to work! I was able to ping the debian box, and do the nfs mount. I don't really understand what it was that made the difference, which is unfortunate since I won't know exactly how to reproduce the setup, but it is working now, at least.
I imaged the first RD54 drive which is labeled "DUA0 ULTRIX" on the control panel:
# dd if=/dev/ra0c of=disk0.dsk
and it completed without error in about 45 minutes.
03-Nov-2006
When I first started up the systems and went through the motions of net-booting NetBSD and trying to mount the nfs export I got a whole host of errors again! I'm now convinced that the DEQNA ethernet board is temperature sensitive, and refuses to work properly until adequately warmed up. After about 10 minutes of fiddling it started to all work. So this would explain away last night's thought that the boot.mop file had been corrupted and after downloading a new copy things started to work. It wasn't the boot.mop file, but just that more time had passed and the DEQNA had warmed up a little more.
I imaged the second drive (labeled "DUA1 VMS V5"):
# dd if=/dev/ra1c of=disk1.dsk
When I returned the image process had finished showing:
311200+0 records in 311200+0 records out 159334400 bytes transferred in 2780 secs (57314 bytes/sec)
There were also a few messages on screen:
qe0: discarding oversize frame (len=1966) qe0: discarding oversize frame (len=1966) qe0: discarding oversize frame (len=1966) ...
Now, for the last drive, I had to make the Emulex QD21 ESDI controller appear at the base address for ESDI controllers. I removed the M7555 controller, and adjusted the switches on the QD21 I imaged Disk 2 (which is now in Disk 0 position, per controller config, and labeled "DUB5 VMS V4") with:
dd if=/dev/ra0c of=disk2.dsk
which finished in about 45 minutes with:
278800+0 records in 278800+0 records out 142745600 bytes transferred in 2531 secs (56398 bytes/sec)
So, all done re-imaging these drives!
I retuned the Emulex QD21 switches to their original settings, re-installed the M7555 MFM controller.
I decided to put all the boards back into the backplane, one by one. I removed the DEQNA and disk controllers, and the AVIV board, and returned the M7168 VCB02/QDSS Base board alone into slot 4, where it originally came from. When I power up the system, with just this one addition, I fail to see the countdown. Looks like this board is the culprit. Thinking it might be shorting against the CPU memory board, I installed a Bus Grant board in slot 4, then the VCB02/QDSS board. Same result, so it must not be shorting of boards, but a problem on or in the video board itself.
Leaving the bus grant board in slot 4 (in place of the VCB02/QDSS) I reinstalled all other boards in the same sequence as they were originally, shifting them ahead at slot 9, leaving those two bus grant cards out of the system. Turns out that all is well when I rebooted. So the problem of not getting the power-on countdown with the backplane populated is related to the VCB02/QDSS board only, it seems. This is better than having muliple boards bad, though I don't know really what to do now with the video controller. How can I fix/re-configure it so that things work? More research I guess.
I installed the video board, but didn't hook up the cables, and closed the system, with the two bus grant cards just tucked into the rear panel compartment.
10-Jul-2010
As mentioned in prior notes, this system will not complete a multi-user (normal) boot to a login prompt. Instead, it seems to get right to the final steps, having mounted filesystems, started all deamons, etc, shows the current date and time, then it goes into an infinite loop and never presents a login prompt.
To overcome this, I have set the drive to WRITE-PROTECT and booted, forcing the system into single-user mode with the root filesystem mounted read-only. I'm unable to remount the root filesystem, though.
I discovered that I can 'properly' boot into single-user mode, after which I can mount the /usr filesystem:
>>> b/2 dua0
{...}
# mount /dev/ra0g /usr
With that, then, I was off and running. I managed to configure the ethernet deveice (lo0) with appropriate parameters, and even NFS mounted an exported directory on Astaroth. Fun while it lasted. I tried to do a full file-by-file copy to this external server with:
# mount -t nfs astaroth:/home/jared /mnt # cd /mnt # mkdir uvaxgpx # cd uvaxgpx # tar -cvf - / | tar -xf -
and managed to damage the local filesystem. Some of the usual utils in /bin have been corrupted, i.e., ls, cat, and others.
I quickly tried to get the system to netboot the old NetBSD-vax 1.5.3 setup that I used for disk imaging, but I am unsuccessful. It looks like the MOP part is working, but then I just get a continuous series of errors on the console about stray interrupts, and nothing else happens. I wanted to restore this disk image to get back to where I was. I gave up for the night.
10-Jul-2010
Next I relocated the Emulex ESDI module so that it was in the contiguous grant chain and booted the drive with VMS 4.7 on it:
>>> b dub5
I see a complete and successful boot of MicroVMS 4.7, and after hitting
10-Jul-2010
With the system shutdown, I took a minute more to re-install the AVIV TFC909 board that I think belongs with the Cipher F891 magtape drive. I shifted the Emulex ESDI module and the DEQNA module to the left, and installed the AVIV TFC909 in the vacated row. Then I powered up and booted to VMS 4.7.
Running the SHOW DEVICES command shows a new addition, the AVIV! it is given as MSA0:, and when I display the full details here is the result:
$ SHOW DEVICES ... Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt MSA0: Online 0 ...$ SHOW DEVICE/FULL MSA0:
Magtape MSA0:, device type TS11, is online, file-oriented device, error logging is enabled.
Error count 0 Operations completed 0 Owner process ** Owner UIC [0,0] Owner process ID 00000000 Dev Prot S:RWED,O:RWED,G:RWED,W:RWED Reference count 0 Default buffer size 2048 Density 1600 Format Normal-11
Volume status: no-unload on dismount, beginning-of-tape, odd parity.
$
So it would seem to be emulating a TS11 device. Now to connect the tape drive.
18-Sep-2011
(More details are given in the Cipher M891 notes...)
Finally, I connected the magtape unit to the AVIV TFC909 (A to A, B to B) and booted the system to VMS 5.1-1 (MUA0:), then tried to explore and use the magtape device. I'm happy to report that the device works very well, ONCE THE TAPE HEADS WERE CLEANED!
There was a black residue fouling the heads and until that was removed I was unable to successfully INITIALIZE or MOUNT a tape. The transport, however, was showing appropriate movement with these commands, and so I felt that this finally confirms that the AVIV TFC909 is indeed a TS11-like controller. After a good tape head cleaning, I was successful at INITing a blank tape and writing and reading from it with VMS.
Also, I tried my TS05 tape unit with thie AVIV controller and it too functions well. So, this at last puts to bed any question of the AVIV TFC909's purpose.
21-Sep-2011
Finding that the first disk is unusable (ULTRIX 3.1 installation) due to my failure to perform a tar correctly a while ago, I decided to restore the disk image that I took from the drive shortly after acquisition.
Sadly, I'm experiencing failures in netbooting NetBSD for the imaging. I am unable to get a reliable download of the NetBSD installation kernel. Sometimes it works, sometimes it does not. If it is successful at getting the installation kernel loaded, the kernel will sometimes boot up, sometimes not, just freezing before it starts sysinst. And if I get through that to sysinst, and set the network configuration, I can't seem to get any network transmissions to work. Pinging won't work, mounting a remote NFS export won't work, etc.
At last, I thought about removing the DEQNA and trying a different ethernet module. I rounded up a spare DELQA (eBay-sourced) and put it in, with SW4 turned OFF which enables MOP booting. I'm seeing even stranger behavior now, and though the 'boot.mop' loader is getting across to the system, the rest of the sequence is altogether different than usual, indication use of RARP, DHCP, etc. I have no idea where that is coming from.
For the record, the DELQA that I'm using was marked with masking tape label of '13', and has a network address of 08:00:2B:06:D8:DC.
04-Oct-2011
A random thought came to me since learning that I can use the big 20" Sampo monitor that came with some HP PA-RISC boxes last year on the my VAXstation 3100 as a graphical display. I am now ready to try that monitor on this system's VCB02 graphical system. I connected the monitor using a video/keyboard/mouse cables (with only one BNC connector) using the GREEN signal to the monitor using my handmade BNC-to-VGA cable. Upon power up, the video flickered and in about 45 seconds I saw the monitor try to display something, but the sync was off, and the image wouldn't stabilize. Looks like I have a Horizontal Sync mis-match. I need to dig up the specifications for both the VCB02 and the Sampo monitor and see what's what. But I doubt that will turn up any usable information. What I will really need is a suitable monitor, say, maybe, a VR290?
Later, I found some information on the Sampo monitor and on the VR260/VR290 monitors:
Resolution HSync VSync
----------- -------- -------
Sampo KDM-2077 1600 x 1280 30-82KHz 50-90Hz (source #1)
1600 x 1280 30-70KHz 50-90Hz (source #2)
DEC VR260 1024 x 864 ? 60Hz
DEC VR262 1280 x 1024 54.5KHz 60Hz
DEC VR290 1024 x 768 54KHz 60Hz
It would appear that the Sampo should handle the input from the VCB02 given the specs of the VR262 and VR290 monitors. Perhaps, since the cable connecting cable had only a single BNC connector, I didn't have it connect to the GREEN line like I believe I had. I'll try again.
06-Oct-2011
I did further research on the various VAXstation video/keyboard/mouse cables that I have, and compared them with other information found online (http://www.antinode.info/dec/). According to the VCB02 Technical Manual (AZ-GLGAB-MN) either the BC18P (mono) or BC18Z (color) are the cables specified for this system.
The following are cables in my inventory:
- BC13A-10 (mono) - BC18P-10 (mono) - BC18T-10 (color), GREEN BNC is damaged, has "GPX" hand-written label - BC23J-03 (color) - BC23K-03 (mono)
I fully sounded out two of my cables, a BC18T (color) and a BC13A (mono). Here is a table of these results, along with other pinout information for other cables:
- 'r' signal return/ground - 'x' component shield (usually tied to DB-15 shield) - '?' unknown/untested but assumedBC13A (mono) ------------ VIDEO Vr V KEYBD 3 2x 2x 1 4 DB-15 01--02--03--04--05--06--07--08--09--10--11--12--13--14--15--SH MOUSE 6 1x 1x 2 3 4 SCREW x x x
BC18P (mono) ------------ VIDEO Vr V KEYBD 2x 2x 3 4 1 DB-15 01--02--03--04--05--06--07--08--09--10--11--12--13--14--15--SH MOUSE 5 2 1x 1x 6 4 3 SCREW x x ?
BC18T (color) [uses MMJ-6 as mouse connector instead of mini-DIN-7] ------------- VIDEO x--RGBr-x R G B KEYBD x x x 2 3 4 1 DB-15 01--02--03--04--05--06--07--08--09--10--11--12--13--14--15--SH MOUSE x x x 6 5 4 2 1 ? SCREW (none)
BC18Z (color) ------------- VIDEO +--RGBr--+ x x R G B KEYBD 2x 2x 2x 2x 2x 3 4 1 DB-15 01--02--03--04--05--06--07--08--09--10--11--12--13--14--15--SH MOUSE 1x 1x 1x 5 2 1x 1x 6 4 3 SCREW x x x x x x
BC19S (color) ------------- VIDEO R RGBr x x G B KEYBD 2x 2x 2x 3 4 1 DB-15 01--02--03--04--05--06--07--08--09--10--11--12--13--14--15--SH MOUSE 1x 5 2 1x 1x 6 4 3 SCREW x x x x
BC23J (color) ------------- VIDEO R x G B DB-15 01--02--03--04--05--06--07--08--09--10--11--12--13--14--15--SH SCREW x x
BC23K (mono) ------------ VIDEO Vr V DB-15 01--02--03--04--05--06--07--08--09--10--11--12--13--14--15--SH SCREW ? ? ?
. KEYBD MOUSE MOUSE RJ12 mini-DIN-7 MMJ-6 (female) (female) (female) _____ +---------+ /1 _ 2\ +-------------+ | 1 2 3 4 | |3 [_] 4| | 1 2 3 4 5 6 | | | | 5 6 7 | | | +---+_+---+ \_+-+_/ +--------+_+--+
It appears that most of the cables that I have are NOT suitable for this system. It turns out that the BC23J and BC23K belong to my VAXstation 3100 model 30. Of the other cables I have, it would seem that only the BC18T IS suitable for this system. It has generally the same pinouts as the BC18Z, except for the mouse. This makes sense since the BC18T uses a MMJ-connected mouse, rather than the ordinary mini-DIN-connected mouse. So, the cable's "GPX" label is probably an accurate indicator that it belongs to this system, and can be used with it.
I need to repair this cable's GREEN BNC connector in order to make use of it, so that goes on my TODO list.
07-Oct-2011
After yesterday's adventures with cable pinouts, and believing that the BC18T that I have is the correct cable to use with this system, I cobbled up a temporary wiring fix to do a quick test tying the RED shield to the GREEN shield to accomodate the broken BNC connector.
Naturally, it worked. I saw good video on my Sampo KDM-2077 SoG monitor. Now just need to create a permanent fix to the cable.
24-Aug-2016
I've been working with my uVAXen for the past week, this one included. A couple of developments to report:
The first RD54 (Maxtor XT-2190) which is DUA0: has bit the dust. It had an installation of Ultrix 4.5 on it. At first it would 'whoop, whoop,...' apparently trying to spin up, but now after more time powered it doesn't even do that, and it fails to come ready (of course!) and is not usable. The RQDX3 controller still recognizes the drive, but it is unresponsive. So, I have removed that drive, for now, and replaced it with a spare Maxtor XT-1140 that I picked up from eBay some time ago. A year or so ago I was able to format that new drive with a modified disk formatter diagnostic on a PDP-11 (see notes elsewhere on that adventure). Even though this new drive formats to about 100MB, it is recognized as an 'RD54' by the controller.
24-Aug-2016
So, with a scratch drive in this system, I thought it was about time to really truly install NetBSD on MicroVAX II and try it out. Tonight I did that with the old NetBSD 1.5.3 that I used years ago to image the drives. Using my Aero-6 laptop as boot server, I was able to install from the NetBSD.org archive everything except for the compiler 'set'. I just ran out of room.
One note that may be useful in the future. At first I had much difficulty getting the NetBSD install kernel to properly download using MOP/TFTP/NFS. At last I un-gzipped the kernel file (netbsd.ram.gz) and tried that. Now I'm getting very reliable downloads. I guess the uVAX II is just too slow to both download and un-gzip at the same time without losing its place.
Well, bottom line, this system is running NetBSD and it works. It is slow, and though it won't help the speed at all, I should try again with a more current release, say 6.1.5. Also, I could eliminate the 16MB swap partition, giving myself that much more storage, hopefully enough to allow installation of the compiler binary set. This system has plenty of RAM and certainly doesn't need any swap for the initial installation process. Then, I could move the whole /usr tree to an NFS mounted drive, and restoring swap partition on the local device. This, then, would give me plenty of storage to run comfortably.
Copyright © 2006-2025 Jared Blaser. All rights reserved.