The UART chip is used in the original Mark~III data buffer design to separate host computer interface timing and data buffer internal hardware sequencer timing from each other. Thus, the UART chip could be replaced with parallel interface logic, perhaps on a ``piggyback'' card that plugs into the UART socket.
The incoming ASCII characters are presented on the bus ``RBR1--8'' (see the schematics ``6004-005'') and a new character is signified by the raising edge of a ``DR'', Data Request, pulse. The UART (or its replacement) has to keep the latest character received on the bus until the acknowledgement line ``/DRR'', Data Request Reset, is pulled down. Actually, the data buffer circuitry seems to rely on that the latest character stays on the bus until a new one replaces it: the logic continues to ``execute'' the latest command character received and if it is replaced on the bus, the logic will continue to function as if it were given a new command.
When the execution logic starts to download buffer contents to the host computer, it will load subsequent bytes into the UART bus ``TBR1--8'' by pulling ``/TBBL'', Transmit Buffer Bus Load, repeatedly low. The logic will wait, however, for the acknowledge line ``TBRE'', Transmit Buffer Empty, to go up before trying to send another byte. So, the UART (or its replacement) can control the data rate by raising ``TBRE'' only after it is ready for another byte. The data buffer sequencer logic places an upper limit to the rate at which data bytes can be loaded to the UART (or its replacement.) The logic functions at the cycle rate of ``UCLK'', 1.6~μs ie. 600~kHz and it takes something like 6--10 cycles to load another data byte, ie. 60--100~kilobytes per second is the maximum output rate attainable with the original sequencer logic.
At the PC end, all methods that require processing handshaking with I/O port commands limit the maximum throughput to be less than around 100~kilobytes per second. For ``LapLink'' the rate should be in the range 20--50~kB/s.
Having a simple digital parallel I/O card in the PC, featuring at least 8+1~input and 8+1~output bits would allow for a very simple replacement for the S1883 UART: a set of wires to the PC Parallel I/O (PIO) card.
Programming handshaking support based on I/O register accesses of the chip on the PIO card would be quite straightforward under Linux.
The problems of this approach include:
There is an ``industry-standard'' way of establishing bidirectional communications with every standard PC parallel printer port, also often called Centronics ports. The protocol is called ``LapLink'' and it originates from the similarly-named software package that allows for file transfers between two MS-DOS PCs using a parallel port ``LapLink'' cable.
The original ``IBM PC compatible'' design uses a PIO chip and its 8~outgoing data and 5~incoming status lines. The original design allowed the direction of data lines to be reversed, but since this was seldom used, most of the modern so called ``multi-I/O'' cards do not implement this feature.
To overcome this limitation, the ``LapLink'' cable symmetrically connects 5~outgoing data bits of one side into the 5~incoming status bits of the other side. A cable that implements this protocol is available commercially as a "Null Printer" or "Turbo LapLink" cable. It can be constructed with two DB-25 male connectors symmetrically connected as follows:
STROBE output 1*
D0->ERROR 2 - 15 15 - 2
D1->SLCT 3 - 13 13 - 3
D2->PAPOUT 4 - 12 12 - 4
D3->ACK 5 - 10 10 - 5
D4->BUSY 6 - 11 11 - 6
D5,D6,D7 are 7*, 8*, 9*
AUTOFD output 14*
INIT output 16*
SLCTIN 17 - 17
extra grounds are 18*,19*,20*,21*,22*,23*,24*
GROUND 25 - 25
* Do not connect these pins on either end
If the cable used has a metallic shield braid it should be connected to the metallic DB-25 shell at one end only.
If this alternative becomes acute and applicable, I'll add here the outline of the protocol ie. how each byte is sent as two handshaked 4-bit nibbles and a sketch of corresponding UART replacement logic.
The main problem with these ``enhanced'' parallel printer ports is that getting definitive documentation of their hardware features and ways to access them from software seems to be very difficult. Many clone vendors do offer these cards at low prices, but they usually come with a skimpy piece of paper just explaining the jumpers on the board. I have been unable to find more documentation how to access the enhanced features of these boards. All I know is that:
All the previously presented ``S1883 UART replacements'' can be designed to include the original UART to preserve the original ``slow'' RS232 connection. The UART data lines can be turned into 3-state buses (or 2-way multiplexers can be used) to allow the original UART chip to ``take over'' the new replacement circuitry.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter