The Web Site to Remember National Semiconductor's Series 32000 Family

My first Unix machine was a Tektronix 6130, the predecessor for the 4132. I built this one from parts ordered through Tektronix Engineering Stock (more information on this below concerning the 4132). I could not buy the main board fully assembled. It came stuffed with the custom parts (PALs mostly), sockets for the CPU and support chips as well as PALs and ROMs, and connectors (expansion backplane connector on the back side of the board), power connector and two connectors on the top side of the board for expansion units (one for a frame buffer graphics system that was never productized), and the other for a memory-expansion daughterboard that, to my knowledge, was also not productized. I recall that this was the case because it was very early in the product, and manufacturing had not geared up yet, so the board I got was only partially built. I had to hand stuff and solder all of the other parts on the board. I do remember that there were a number of mods that I had to make, per instructions that I received, to correct some issues on the board. I have recollection that I ended up starting this project sometime in early 1985.

The 6130 had a ST-506 (Western Digital-based) interface for the internal hard disk drive, which initially was a Micropolis 20MB 5 1/4" full-height drive, and a standard 360K 5 1/4" half-height floppy disk drive. I purchased the hard disk drive and floppy drive through Engineering Stock. The hard disk drive was the most expensive part of the whole system. I also purchased the components for the chassis, the power supply module, expansion bus backplane, and most of the other mechanical . This system didn't run the first time I powered it up. I had a couple of tiny solder-bridges, and an IC socket for one of the support chips for National chips 32016 that was bad. Took a long time to track all of that down, but I did get it running. Installing the first version of UTek from floppy disks took a long time. It was also pretty buggy, and would crash from time to time, and was also quite slow. Things got better with subsequent releases of UTek, and in time, the machine was pretty reliable. It was still rather slow, though. I was used to using a VAX system running 4.2bsd at work over a 9600 baud serial link, and the 6130 was significantly slower than the VAX. If it started paging much, it got painfully slow. I think at the max, this machine had 3MB of RAM, and it didn't take too much going on at once to get it paging. I ran that system until I decided I wanted to upgrade to the 4132 because of SCSI (and faster, larger hard disk drives along with easy addition of external disk drives), and in general, significantly better performance. I put the 6130 aside, and set out to build the 4132. This was, IIRC, sometime in the late '87 to early '88.

As with the 6130, I ordered all of the parts necessary to build the 4132 from Tektronix' Engineering Stock department. At that time, Tektronix employees were entitled to purchase any components that were used to make Tektronix products at Tektronix cost plus 10%. This made acquiring the parts for the machine within reason. The retail price of a base-model 4132 workstation at introduction was around $10,500. I think I ended up spending something around $2,500 to build my system initially. At the time I built it, it was in base configuration, with 1 Megabyte of RAM (on the main board), the 1/4" QIC-24 cartridge tape drive, and I believe a roughly 105 MB full-height 5 1/4" SCSI hard disk (Maxtor, IIRC) drive. The main board for the system was purchased as an assembled part, so it was complete and tested, but did not include the socketed parts, which I also purchased from Engineering Stock. I basically purchased the main board, the National CPU chipset parts, PALs and boot ROMs, the components to build the chassis, the power supply module, the backplane assembly for the expansion ports, the hard disk drive, the 1/4" tape drive, power supply wire harness, internal SCSI cable (for hooking up the hard disk) and tape drive to the SCSI port on the main board, and the SCSI terminator that plugs into the SCSI port on the back panel of the machine, as well as block-off plates for the 3 full-wide expansion slots, as well as one or two block-off plates if I had open half-wide slots (which I did at the beginning). I was able to get my hands on the tapes for installing the OS and diagnostics from friends at work. I put the whole thing together very carefully, following diagrams and text printed in the manufacturing instructions for the machine (which, sadly, I've lost somewhere along the way). The first time I powered it up, it booted up the "diags OS" from 1/4" tape, ran them, passed them, and then went into the standalone SCSI format program that would format the hard disk and ready it for installation of the UTek OS. I hand-entered the defect information, formatted the drive (that took quite a long time), and installed the 2.3 version of UTek for the 4132 just fine. The system, even in base form, was much faster than the 4132 -- fast enough that it pretty much matched the performance of the big VAX (don't remember what model) 4.2bsd system that I used at work. The I/O was slower, but in terms of raw compute speed, and general use response times, it was darned close.

Over time, Tek improved UTek, and eventually UTek 3.0 was introduced, which was derived from Berkeley 4.3bsd, rather than the earlier UTek 2.x versions that were derived from Berkeley 4.2bsd. UTek 3.0 had quite a few improvements in the kernel, and performed much better, especially for TCP/IP networking. There was a version of UTek 3.0 for the 6130, but I never bothered with it, as the 4132 was all around a better machine. The 6130 remained packed up in a crate for years.

At its peak, the 4132 system served as a dial-up public access Unix system serving the Portland, Oregon area, with three dial-in lines. It also served as the controller for a self-developed home automation system that rivaled the commercial home automation systems of today. It was a UUCP node, and provided Email and USENET News services. I had quite a collection of games, including an early version of rogue, gnuchess, hack and nethack, moria, boggle, startrek and more. I had added external SCSI drives (a couple of 300MB 5 1/4" full-height drives that I installed in an old IBM PC case where the floppy drives would go, using the old PC power supply to powr them) using the built-in external SCSI interface on the 4132. I ended up getting a Central Data SCSI terminal server that, with help from one of the kernel guys, I managed to write a driver for. My friend built me a UTek 3.0 kernel with the driver, and that added 8 RS-232 serial ports to the machine via SCSI. I eventually got an Internet connection, made via a router made out of a PC with a 9600 baud modem and an Ethernet card that had a full-time dial-up connection to a very early co-op ISP in Portland called RainNet. That put the 4132 on the Internet, and thus provided FTP and TELNET capabilities to the users, as well as the ability for users that had Internet access to be able to TELNET in rather than dial-in. That made the system amongst the very few Unix systems in private hands that had Internet access.

Along the way, I either purchased through Engineering Stock parts to build various expansion boards. I can't remember exactly how I came to get it, but I did manage to get my hands on one of the bare circuit board for the memory expansion daughterboard for the 6130/4132, which added an additional 2 megabytes of RAM as a daughter board to the main board. I stuffed it with sockets for the DRAM, ordered up the DRAM chips and the bus buffer and address selection chips, and put it all together. It worked first time, amazingly. I also built one of the 2 Megabyte RAM expansion bus boards from parts. I bought an assembled dual RS-232 port expansion bus board, which was quite expensive.

Later on, after the products went end-of-life, quite a load of expansion boards and parts for the machines ended up at the Tektronix Company Store, and I ended up buying few more 1 and 2 megabyte expansion bus boards, quite a few RS-232 boards, a couple of SCSI port expansion bus cards, and a parallel printer-port expansion bus card at bargain basement prices.

I also got my hands on a completely populated graphics frame-buffer (never a product IIRC) daughter card that plugged into either the 6130 or 4132 main board. A special rear panel for the main board provided holes for an external mouse, keyboard, and color monitor connection. I had X-Windows version 11 running on the machine, but it was *profoundly* slow, and didn't hold my interest for long. I ended up selling the frame buffer daughter card and special bezel to one of my friends that had a 4132, along with the custom keyboard and mouse. I still have a tape with the X11R4 for UTek distribution on it...but alas, no hardware to run it on. I think that the graphics daughter board was run by a 32016 also, but can't remember that for sure. I am going to try to have to image that tape if it is still good.

I think that sometime around 1995 or so, I ended up getting a Sun workstation (A Sun Sparcstation SLC), and though the Sparcstation SLC was rather a dog of a machine, it had a monochrome bitmapped display and had a windowing system that made it compelling versus the RS-232 terminal-based 4132. After a time running both systems in parallel, I eventually shut down the 4132, shut down public access (though the Sun machine still had UUCP running on it), and put the 4132 into storage.

Quite a number of years ago, I tried to fire up the 6130...but alas, something is wrong with the main board. It doesn't do much of anything. I didn't devote much effort to trying to fix it. It would be tedious to try to track down what is wrong with it, and is beyond the time I have at this point. I do have full schematics and documentation of the 6130 main board, so it is probably possible to fix it (unless the ROM is bad, which I suspect finding an image for would be next to impossible), but again, time is the issue. I have the main board safely stashed in storage, as well as the cabinet, power supply, and a couple of old Maxtor 1140 and one Maxtor 1105 (ST-506 140MB and 105MB respectively) drives which one of which is likely to have a bootable OS image on, and the floppy drive also stored. I have a couple of spare power supply modules, too. So, someday, I may embark on a project to recover the 6130...and I still have all the original floppies for installing the 2.3 version of UTek on the 6130. Maybe someday.

Back in the summer of 2016, I decided to dig out the 4132 and see if I could get it running. The internal hard disk drive was long gone, but the 1/4" cartridge tape drive was still there. The biggest problem with it was that the OS install media I had was bad. I had made numerous attempts to read it on a Sun system that I have that has a 1/4" QIC 24 tape drive in it. It resisted all attempts to read. Unfortunately, back in the day, I never made an image of it. I made a few pleas over time on the Classic Computer mailing list for installation media or an image of same, but never got a response other than some folks who reminisced about using the 6130/4132 back in the day. Finally I got a response from a kind man who didn't have installation media, but did have disk image from a 4132 system that he had used many years ago. He provided me the image, and using my Sun system, I was able to 'dd' the image to an old 5 1/4" full-height SCSI drive that I had, and from there, I was able to bring the 4132 back online. It passed all the power-on diagnostics straight away, and booted up UTek. The kernel that was on the image was pretty old, and would only recognize 4MB of the installed 7MB of RAM. But, it proved that the machine was still working. I had to rebuild the QIC-24 tape drive, as the capstan rubber had turned in a disgusting sticky black goo (fortunately, I found this out using a scratch tape!). That was a bit of a challenge, but amazingly, a carefully cut piece of rubber automotive fuel line made a perfect replacement.

I had forgotten about a stash of old 5 1/4" SCSI hard disks that I had packed away in a storage crate with a bunch of desiccant bags. I stumbled across the crate one day not long ago, and there were quite a few old Maxtor and HP 5 1/4" SCSI disks. I hooked each one up, one at a time, to my Sun system (a vintage Sun Ultra 60), and low and behold, one of HP drives was the boot drive for the 4132 from years ago. I did a full dd image of it while I had it on the Sun machine, and then popped it into the 4132. It booted up first thing, and was a much more current kernel and distribution that was on the disk image that I had received earlier.

There is a pretty decent C (based on the Berkeley 4.2bsd 'cc' compiler) for the machine. It was more classic K&R C rather than the Posix C that is common today. So, a lot of programs developed under Linux and other more modern Unix operating systems take a bit of work to port, but it can be done. There are pretty major differences in library routines that can be somewhat painful to deal with. Classic C programs written in for the DEC VAX-based 4.2bsd K&R C environment compile and run just fine. Somewhere along the line, I ended up with the source to an early version of the classic and groundbreaking game "rogue", and it compiled straight away and ran perfectly. It was really cool in the day to have my own machine that ran rogue. The compiler distribution tape (which was an extra-cost option) came with a bunch of other tools, including RCS (revision control system), make, the 'vi' and emacs editors, and the adb debugger that had been ported into the UTek/32016 environment. I have the distribution tape, but haven't tried to read/image it yet.

We received limited tester time in Santa Clara but lucky for me the silicon was mostly functional when I arrived, so it was easier to debug in a test board."

The concept of "debugging" was quite loose, something that is also common at that time. Basically you run a program that checks itself by executing compares. Not very efficient and very cumbersome to write good tests. Things changed a lot when a smart programmer wrote a random generator. That was a good first step that produced many interesting pipeline faults.

I used the tool to blast the design with a random program and then run the same on a simulation model. That process cleared bugs that were based on implementation that differed from the model, i.e. "lost in translation"... I'd estimate roughly 20 bugs were found this way, since many were found earlier by much more laborious methods. In particular, there was one dynamic latch structure that relied on "bootstrapping" technique that nobody dared question. After finding several bugs that were narrowed down to that structure, I went over the complete design and replaced that with a conventional latch. That was the major advance in reliability in 1985.

I went on and created a "system environment" that generated random interrupts. The interrupt handler did nothing and the random program was supposed to finish without any changes due to the interrupts. This step cleared a few more bugs.

In early 1986 there were two chronic bugs that we were not able to isolate logically. One had to do with data bits flipping. After a lot of analysis we realized that the bug occures when many bits in a 32-bit data move were flipped. We wrote several diagnostics and ran these programs on a GenRad tester and indeed it was a consistent issue. In the end, we looked at the layout and found a bus that was crossing a control line at 90 degrees (on adjascent layers). The control line was floating at a certain phase of the clock but the state it contained was significant. To prove the issue we had to drop a probe on that wire, something you cannot do in today's processes... The extra capacitance of the probe was enough to stop the flipping of the data on that line. First big problem solved.

The very last issue had to do with the MMU. You could not run Unix without the MMU so it was crucial that we solve this issue. I remember sitting in the lab with a logic analyzer hooked up to the external MMU interface and clicking the button, hoping to catch some anomaly. It took two weeks that the stars lined up just right and my finger hit the capture button exactly when the board hang. The MMU protocol was not working as designed!

Logically the design was correct, but the implementation was a bit less than ideal. The CPU and MMU were assumed to be asynchronous to each other, since at that time we did not have great tools to equalize clocks. That required that you capture the interface and re-capture it to minimize metastability. Unfortunately, the implementation split the signal before synchronizing it properly and it was registered in two different flops. Sometimes when you pushed the clock rate these two flops did not agree... You don't have a feel for metastability until you experience it in the flesh...

I took some consolation from knowing that the smart guys at IBM missed a similar glitch (about 20 years earlier) which eventually led to the invention of "atomic operations" such as a test-and-set.

So, in April 1986 we finally had a clean implementation of the NS32016 and NS32032. All these fixes made it to the 10MHz CMOS (single-metal double-poly!) implementation, but the market did not believe the application engineers anymore and a fine 32-bit CPU was relegated to controller applications. That was really sad.

I remember a single-board Unix system that we used for testing. It dawned on me that we had at that time a simulator written in C which was compatible with the logic language of the one written in Pascal. I compiled the simulator on that board to gauge the speed vs the dedicated VAX 11/780 I had at my disposal and also against a time-sharing batch process on a big IBM mainframe. The single-board computer ran at least three times faster than the VAX. If you want history in the making, there it was. The doom of DEC and the minicomputers was written on that small single-board computer!

The lessons learned in that time period made it to the verification team of the NS32532. A new instruction simulator was written, which output the changes after each instruction and a simulation environment registered these changes and checked all the write transactions to registers and the memory model (at the boundary) against them. Any anomaly was immediately identified but in a pipelined design you're not always sure where the problem started so we had an actual simulator that allowed you to go back in time a few clocks!

Later I worked with Verilog and it was extremely frustrating not to have such capability.

In some sense, National had extremely advanced simulation and verification tools in 1986, when most other successful processor designs were still running basic diagnostics. But all that is not visible to the customers and the other guys eventually caught up, especially with manpower migration from National Israel.

That was the end of an era that will probably never repeat again in our lifetime."