The first PAPERS prototype, this box was designed and constructed in less than two weeks... although we subsequently spent several months debugging and testing it. The unit connects to four PCs using standard printer cables to go from each PC to the corresponding Centronics connector mounted on the back of PAPERS0. Within the Oak box (with the top attached by velcro) are a power supply, rear-mounted Centronics parallel port connectors, wire-wrapped main circuit board, and wire-wrapped 40-LED display board. The LED display was a tad excessive, and was the vast majority of the power draw, but it looked cute and was helpful in debugging.
The full dynamic barrier mechanism is implemented using just one AMD 22V10 PAL per processor, with a group of TTL drivers used to ensure proper interface levels for the parallel printer ports of four PCs. Each logical barrier synchronization requires 4 port operations (cycles), organized as a barrier followed by an "anti-barrier": the barrier to synchronize, the anti-barrier to ensure that all participating processors have detected that synchronization was achieved.
The only communication supported by the hardware was a 1-bit multibroadcast intended to provide a means for voting on membership in a new barrier mask. However, we observed that arbitrary communication patterns and functions of the aggregate state also could be implemented using this hardware, and thus was born the concept of associating aggregate communications with barriers. If the data bit sent by a PE was the same as the last value sent, the transmission required 4 cycles; otherwise, a fifth cycle was needed to give the changed data bit time to settle (in essence, avoiding a race with the barrier GO signal). Unfortunately, the electrical characteristics of the parallel printer port turned out to be a lot more "interesting" than we had expected. We spent a lot of time in the MSEE 190 undergraduate laboratory debugging noise problems, which isn't too big a surprize when you combine the port characteristics with the wire-wrap jungle inside the box....
Because the parallel printer port supports generation of interrupts, we were very careful to make PAPERS0 able to generate interrupts either when a barrier synchronization was achieved or when a processor sent a "parallel interrupt request." How the interrupt would be triggered was software selectable. However, we quickly realized that latency and OS problems made it unwise for a parallel interrupt to generate a "real" interrupt on the PC, so generation of real PC interrupts was always disabled in our library.
The only thing set in stone is our name.