Richard
Richard's coprocessor board was inspired by an article in the Byte magazine of August 1985. The article described in detail a PC add-on board based on a Series 32000 microprocessor: the Definicon DSI-32 coprocessor board. Richard was excited and began in 1986 to build an own version of this board. Luckily he was able to get most of the software (except the compilers) and the powerful second generation NS32332 CPU. Definicon has used the first generation NS32032 CPU.
The mentioned Byte article is available online at archive.org.
Richard worked on the board for three years. In the 1980's PCB technology was difficult and expensive. Therefore the board was build with wire-wrap technology. To lower the design risks the operating frequency was limited to 5 MHz. Another reason was that a 10 MHz NS32081 FPU was expensive too. In the beginning the board used DRAM as main memory. But due to an unidentified bug the DRAM was taken off and SRAM was build in. Later Richard found out that the two-phase clock of the CPU was connected inverted. The density of the SRAM chips was 256 kbits and their package was a 28-pin DIP. The large package resulted in a space disadvantage compared to DRAM chips. To overcome this limitation Richard build small towers of four SRAM chips and used four towers for 512 kbytes of RAM. Instead of PALs electrically erasable GALs were used for the glue logic.
The final tests took place in 1989 on a PC-AT. After all the hard work it was a proud moment for Richard to see all tests passing without any error.
Fig. 1. Richard's coprocessor board with the SRAM towers at the right edge.
Around 2008 Richard decided to upgrade his board. The SRAM towers were not very reliable and cheap SRAMs were available with 4 Mbits density. Four of them were build in and make now 2 Mbytes of main memory. The next two photos show the board after the upgrade.
Fig. 2. Top view of Richard's coprocessor board after the SRAM upgrade.
Fig. 3. Bottom view of Richard's coprocessor board.
In September 2015 Richard and I tested the board again. We used a modern PC which has still two ISA slots. The operating system for the test was Windows 95. The next photo shows the PC with the installed coprocessor board.
Fig. 4. Richard's coprocessor board sitting in his host system.
The three screen shots below show that the old board is still fully functional. If you want more information about the software see Software/Definicon .
Fig. 5. The first test to run: the hardware test.
Fig. 6. A character based graphis test.
Fig. 7. The monitor program running in full screen mode.
In September 2017 Richard and I got access to the Greenhills compiler for the Definicon board. Our first goal was to compile the Dhrystone benchmark and let it run.
Fig. 8. The Dhrystone benchmark is now running. In the top right corner the compile command with the used options is shown.
The source code of Dhrystone contains a long list of systems which have been benchmarked. The following table only shows the entries for National Semiconductor and the new result of Richard.
| Machine | CPU | Oper. Sys. | Compiler | Dhry. no Regs | Dhrystone Regs |
|---|---|---|---|---|---|
| NSC ICM-3216 | NS32016-10MHz | UNIX SVR2 | cc | 1041 | 1084 |
| Sequent Balance 8000 | NS32032-10MHz | Dynix 2.0 | cc | 1250 | 1315 |
| IBM PC/DSI-32 | NS32032-10MHz | MSDOS 3.1 | GreenHills 2.14 | 1282 | 1315 |
| Richard | NS32332 5MHz | Windows 95 | GreenHills 2.14 | 793 (1.1) | - |
The results in the table are for Dhrystone 1.0 except for Richard. Dhrystone 1.1 is a little slower. There will be new numbers in the near future. The NS32332 is obviously faster and clearly outperforms the first generation of CPUs.
If somebody wants to play with an old benchmark, here is the source code: dhrystone.c
From "Richard" to "Udo"?
In September 2022 Richard gave me the board. But its story will remain here.
To run the board in my old 486 PC (which was also used for the Opus board, see Systems/Opus) I had to build an adapter board because the board can only be used in a vertical position. The next Figure shows the construcion.
Fig. 9. The Definicon rebuild is running in my old PC only with an adapter board.
During my first tests I saw from time to time an ABORT trap of the NS32332 CPU. Richard had never seen this behavior. The ABORT killed the running program and it was clear that I had to find the root cause.
I have no logic analyzer or a digital oscilloscope to catch random signals. Therefore I build a small logic analyzer out of an FPGA board with an IDE interface to get the necessary 5V interface. A simple program visualize the measurement results in text form.
First I wanted to have a 50 MHz sample rate. This is my standard frequency for my TRIPUTER project. But there is also 100 MHz available for the memory interface. So I changed to a 100 MHz sample rate. And this was a good decision.
The ABORT pin of the NS32332 CPU is also used as RESET. If the pin is active low for a longer period it is interpreted by the CPU as a RESET. If it is a short pulse it is an ABORT. The RESET signal is generated by the NS32201 TCU. Therefore their RESET input must be observed. This signal is comeing from a PAL. The PAL is connected to RSTDEV of the ISA bus.
Fig. 10. The crucial measurement that indicates the cause of the ABORT.
Figure 10 shows what happend in my PC. The first line shows RSTDEV. The second line is the signal between the PAL and the TCU. The third line is RESET to the CPU. Each character represents a 10 ns time step. Obviously there is a glitch on the RSTDEV signal. The PAL is able to transfer this glitch to the TCU. The TCU generates out of this glitch a pulse which is 1.5 clock cycles wide: the ABORT.
The old PAL is not very fast. It is astonishing that it can handle such short signals. The timing makes it clear why the ABORT only occures from time to time. The glitch must be captured by the TCU. 10 ns later and the TCU doesn't see it. And I'm not sure that I would have seen the glitch if the logic analyzer runs with 50 MHz...
A simple analog filter at the input of the PAL suppresses the glitch. The Definicon rebuild is now running stable.
The next topic was the output of a test program from Definicon. It should be circles and lines but it was only colorful letters. It turned out that the driver ANSI.SYS was not installed on this PC and other PCs from Richard.
Fig. 11. The circles and lines are back. We haven't seen them for many years.
The last topic for the moment was the program LOAD. This is the PC program which interfaces with the Definicon system. The rebuild is not using an interrupt to inform the PC that it needs a service. Therefore the PC polls a memory location in the Definicon memory. This is not very clever because it blocks the NS32332 CPU from accessing its memory (the PC requests a HOLD).
Richard was able to compile a new LOAD which does an IO polling instead of the memory polling. Now the benchmark results are much better, i.e. the score for Dhrystone jumped by 75% !
| Machine | CPU | Oper. Sys. | Compiler | Dhry. no Regs | Dhrystone Regs |
|---|---|---|---|---|---|
| Richard | NS32332 5MHz | MSDOS 6.2 | GreenHills 2.14 | 1388 (1.1) | - |
My favorite benchmark Linpack increased from 22.8 kFlops to 36.6 kFlops although the FPU is running only at 5 MHz. At the nominal speed of 15 MHz of the CPU the Linpack result will be over 100 kFlops. And the rebuild does not use the burst mode of the NS32332 CPU...
This chapter was last modified on 15 February 2023. Next chapter: Sequent