PISC – Addendum and Erratum

My original memory I/O board PISC 1.0a


During the build process of my PISC I did discover a few issues with the original circuit diagram as found here: https://bradrodriguez.com/papers/pisc.pdf

I’ll now document these discoveries.

One should perhaps mention (again) that this is largely of academic interest only. As duplication of this project would require two key Integrated Circuits. Namely 4 x 74181 ALUs and 8 x 74172 Register file chips. Sadly both of which are now so long out of production that they are nearly impossible to source.

But for the sake of completeness…


1. The 74LS541 being used as the 8 bit Parallel input port as shown on the Memory board (page three) is depicted in reverse. The data output pins (Y1-Y8) from the ‘541 chip should face inwards. Connected to internal data bus and not outwards as shown.


2. On page one of the circuit diagram set. The “ALU” circuit shows the “A=B” pull-up resistor to VCC (designated only as R?) as being 10K ohms. In practice I found that this value worked properly while clocking the circuit with a test signal in the sub Kilo-Hertz range. But as soon as the clock was lifted to 5 MHz the “A=B” signal could not be latched reliably. Reducing this resistor to 4.7K ohms solved the problem. This issue could be build specific of course.


3. The legacy 2651 IC used for the serial port, the “Programmable Communications Interface” is just not fast enough. At least when the system is clocked at 5 Mhz it isn’t. At 5 MHz we have a clock period of 200ns. My 2651 datasheet shows that after the 2651 CE/ pin is asserted the “Data Delay Time for Read (tDD)” is to be 250ns worst case. So we would be somewhat “over-clocking” the 2651 even if we had the entire 200ns.

We don’t. The SIO/ select line to the 2651 CE/ pin is gated via a 74F139 using the CLK signal. This means that SIO/ is only active for the second half of the clock cycle or 100ns in other words. The 2651 cannot operate successfully inside this 100ns window.

So just how fast can the 2651 actually run?

By replacing the master crystal with a pulse generator I was able to determine experimentally that my particular 2651 sample would run to about 2.89 MHz before it started dropping characters. This equates to a clock period of 346.02ns or a 2651 CE/ pulse width of about 173ns. So while still “over-clocking” according to the datasheet it looks like we could get away with 200ns. So my short term fix was to simply halve the clock speed. Changing the master crystal from 10 MHz to 5 MHz resulted in a 2.5 MHz system clock with a 400ns period. Half of which was 200ns which kept the 2651 entirely happy.

My PISC ran this way for well over a year, rock solid, never missing a beat. More recently I created a Wait State board which inserts a single wait state when accessing I/O devices in the 8 bit expansion bus. This allowed me to try running at Brad’s original  5 MHz design specification. At 5 Mhz it gives a good illusion of running. But every so often I’ll get a ‘glitch’ which hangs the machine. So in the interim I have de-rated the system to run at 4 MHz minus any wait states during I/O. At 4 MHz it is once again reliable.

4. While still on the subject of serial ports and the 2651. There is a conceptual problem with the way the 2651 serial port has been interfaced. In the original PISC 1.0a schematic, the deliberately simplified device selection scheme has the 2651 chip enable signal CE/ active whenever address lines A15 and A14 were set low and high respectively. This means that the serial port will respond to any address in an entire 16K block from $4000 to $7FFF. This in itself this is not the issue.

The problem is that PISC uses the Address Bus, otherwise known as the A-Register Bus not only for memory addressing but also for all internal ALU computations. So any ALU operation that just happens to accidentally set the A-Register bits B15 low and B14 high will trigger the CE/ line of the 2651. Now you might expect this to result in a bus contention clash. It does not. The PISC Memory I/O board is tri-state buffered with two 74ALS245’s. Data from the Memory I/O board is only routed to the internal system bus when MRD/ is asserted. Something that does not happen during an ALU operation. So there are no bus contention issue. But the 2651 is still activated for a Read operation.


The 2651 is controlled by a chip enable CE/ and a single RD/ WR control pin. The 2651 chip has no separate control signals for Read and Write. It is a single pin acting as a toggle. The circuit shows this pin connected to the MWR signal (high on write). So this arrangement effectively places the 2651 in Read mode by default. All this added together results in the 2651 dropping any character stored in its single character receive buffer each time an ALU operation happens to set A-Reg B15 low and B14 high.

This character is placed on the Memory I/O cards local data bus by the 2651 and then simply ‘lost’. A most unfortunate state of affairs that somewhat hampers software development of file transfer protocols 🙂

The solution to this conundrum?

It was fairly trivial to re-arrange the circuit so that the CE/ signal to the 2651 is only enabled when the PISC is truly doing either a Read MRD/ or Write MWR/ operation and this is exactly what I did.