Gilbert
In April 2017 I got contact to Gilbert. He lives in California, US. In his first email he described some of his projects. One of them is still on the to-do list and will use his DB32000 board (see one at Systems/National Semiconductor). The plan is to use the second processor socket. This is an exciting project and for sure any results will be reported here.
A software project works for the GNU assembler "gas". Support for Series 32000 is getting less in the GNU community year by year. Therefore I was glad to read the following text in one of his emails:
"Since we last emailed, there have been developments with the GNU binutils community. My patch was accepted so that means that ns32k will not be removed from binutils (which includes GNU assembler, linker, objdump, objcopy and some others). However, I did have to volunteer to become the maintainer for “all things ns32k” in binutils. The leaders then immediately gave me some assignments to get started improving the NS32K support. One person also asked if I intended to restore ns32k functionality in GCC, and I said that I might like to do that eventually, but would probably have to do one thing at a time.
In order to help with my binutils work, I have wired up a small 32008-based computer on a breadboard. It’s just the ICU&32008, a static RAM, an EPROM, and a 16550. I wrote a simple Intel-hex downloader and put it into ROM and the board works quite well.
I’ve come across some bugs in the GNU assembler for ns32k and some shortcomings. For instance, as far as I can tell, the GNU assembler doesn’t have the module concept therefore it doesn’t handle the CXP instruction or EXT addressing properly. Also, I haven’t yet figured out a way for it to automatically use label(SB) addressing when specifying just label as an argument when label comes from a .static section. These appear to be a main features of NS32K tools from 30 years ago. I may be mistaken and will investigate further.
As the official maintainer of NS32K in the GNU binutils ;-) I definitely want to make these tools good enough to adequately make use of the entire NS32K architecture, even though there might have to be slight syntax changes from the NS32K tools of the 1980’s."
Even the best microprocessor (Series 32000 is close to that :-)) will not be used if software tools are missing. Thanks to Gilbert the future of the GNU binutils looks promising!
NS32016 based computer built with wire-wrap
Working for the binutils requires solide software knowledge. But Gilbert is doing some good jobs in hardware too. He wrote about this machine:
"The wire-wrap board is a 6Mhz NS32016 board that I built in late 1986 from the Series 32000 Designer Kit (32016 version). It uses the NS32201-6 TCU, NS32016-6 CPU, and NS32081-6 FPU from the designer kit. I did not include the NS32202 ICU, NS32082 MMU or two 27128 TDS EPROMs that also came with the designer kit. The board also has two NS8250A UARTs, two 6264 8Kx8bit static RAMs and two 2764 (8Kx8bit) EPROMs. The single INT line comes from the first serial port. The second serial port does not operate with interrupts. Originally, the computer interfaced to another board that would drive a gas-plasma display similar to the one found in a PLATO V terminal*).
The board still works. It boots the ROMs at 000000h, runs a little program to download more code via the Comm port into RAM at 100000h, and then jumps to it. The module table exists in ROM and therefore cannot be changed.
I made the wire-wrap paper labels on a fairly new technology at the time called a “Laser Printer” ! My University’s Electrical Engineering Department had one in the office. This was before Postscript was common in laser printers and I had a program that used the raw graphics capability of the laser printer to print these labels, top side and bottom side."
*) A photo of the terminal is available at wikipedia.
Fig. 1. Top view of the NS32016 based computer. But where are the capacitors? Below the IC's?
Fig. 2. Bottom view of the NS32016 based computer. The wiring is very clean and tidy.
Fig. 3. A detailed view of the bottom side showing some manually made additions to the labels.
The small inverters drawn on the paper for the 7404 are nice. Some of the inputs have no wire connected to. In this case the output may oscillate if the device is not made in TTL technology.
NS32008 based computer built on a solderless breadboard
Is this crazy? A computer with a 32-bit processor running at 10 MHz build on a solderless breadboard? In my opinion "yes". But Gilbert has done such a project successfully! Here is what he said about it:
"The rat’s nest of wires is a 10Mhz 32008 computer that I started building in April 2017 (just a few weeks ago). I’ve been working on GNU binutils for the assembler and linker for NS32K and I want to work more with the NS32K module linking concept. Module tables must live in the bottom 64k of the address space and my 32016 wire-wrap board’s RAM is up higher. I do have a DB32000 board which has RAM down low, but my DB32000 is unreliable and will crash for no apparent reason after several hours. Instead of re-working my wire-wrap board, I decided to start wiring up a new computer on solderless breadboards. I chose to use the 32008 with the 8-bit bus for a few reasons. First, I don’t need the higher data throughput of a ‘016 or ‘032, but I want the 8-bit bus so that when I’m burning EPROMs for the computer, I only have to burn one. Another bonus is I have a bunch of 61256 static RAM parts so by stacking them and soldering the pins together (except the chip select), I am able to get a quick 64k of RAM with a fewer wires (see picture). Also, the NS32008-10 and NS32201-10 parts are still readily available on ebay. I use a NS16550 for a serial port.
Currently, the firmware downloads an Intel HEX file from the serial port and jumps to it. The computer is still a work in progress. When the changes to my design settle down, I may get more ambitious and create a real circuit board for it. However, it really is quite a feat of the original NS design team that you can just slap together some parts in an afternoon and have a working computer.
I do have the 32008 running at 10Mhz by using a 20Mhz oscillator with the 32201. The static RAM is fairly modern and has no trouble at all with the access time. I’m not so sure about the ROM, it’s a vintage 2716 and I’m not sure of the access time. It seems to run fine without wait-states. I haven’t looked at the read cycle timing chart carefully to see if I’m within specifications. I used the /PER line on the 32201 for the 16550. Again, I didn’t look carefully at the timing charts of the 16550, but overall I don’t access the 16550 often so the 5 wait states is fine."
Fig. 4. This photo is for sure a candidate for the "Photo-of-the-Year" contest!
Again in Figure 4 I don't see any capacitors used for filtering the supply voltage. It is big surprise if the system is running stable without them.
The stacked SRAMs are packaged in a narrow 0.3 inch wide 28-pin DIP. Their access time of 15 ns is ten times faster than required.
Fig. 5. SRAMs caught in the wire jungle ...
Update on the solderless breadboard computer
Still in May 2017 Gilbert told me that his NS32008 system is not running very stable. I suggested to improve the wiring and to add some capacitors. After some time Gilbert sent me a report about what he had to do to solve the problem:
"I took your suggestions and soldered a .1uF cap to the Vcc&GND pins of the 16550 and it didn’t help much. I improved the grounding setup by circling the entire board with a heavier-gauge ground wire which connects to all the ground strips, and put 1uF capacitors between the +5v and ground strips, and shortened the ground wire to the 16550. I also put .1uF caps on all the +5v pins on all the ICs. All these things helped a little bit or changed the behavior somewhat, but I was still having trouble with the wrong data being received from the 16550. I noticed it particularly when transmitting continuously at 19200 baud, every ascii ‘7’ (0x37) would get received as an ascii ‘0’ (0x30), or sometimes even a null byte (0x00). If I put in pauses of a few milliseconds after each character, most often the ‘7’s would come through fine.
In the end, I determined that the 16550 just didn’t have enough ability to drive all the data lines when many were set to 1, so the CPU would receive them as 0s. In the end I had to put in a 74LS245 bus transceiver for just the 16550. This is my first time using the 16550, and now I know that it can’t drive many loads.
The system is now rock-solid stable. I am able to receive data continuously from the serial port at 115200 baud with zero errors. I have burned my new downloading program to another 2716 EPROM and it’s working great. This particular 2716 is apparently a bit slower than the one before and requires one wait state. Fortunately, I can still receive Intel HEX files at 115200 baud. At this speed, I can send an Intel HEX file that fills the entire 64k RAM in about 16 seconds, which is completely sufficient. Most of my test programs will be much smaller anyway. My little downloader program does not use stack or any RAM locations, except for writing the actual data bytes to RAM. Over the years, I’ve programmed many different CPUs (vintage and modern) in assembly and the 32000 series is such a dream to program in."
Fig. 6. The reworked version of the solderless breadboard computer: the wire jungle has grown.
1401plus
In May 2017 Gilbert bought two 1401plus from CED at ebay. Because of problems with the power supply they were very cheap. Gilbert has the idea to write a program for the system to do something different with them.
If he cannot get some documentation about the system (of course he will try) it should be possible to run the existing software in an emulator and see what happens.
Fig. 7. The inside of a 1401plus system.
I still have not found the ADC devices on the boards...
Fig. 8/9. The different NS32GX32 CPUs of the two systems. The orientation of the device name is different.
It is interesting to note that the orientation of the device name is no longer an indication of the place of the reference pin. If you look at a Dual-In-Line package in a way that you can read the device name then pin 1 is always in the lower left corner. Obviously this is no longer true for the Pin-Grid-Array packages in Figure 8 and 9.
This chapter was last modified on 29 May 2017. Next chapter: Indel AG