Translating EP102 codes to M-32TL codes

After recoding my EP102 printer emulation to send a stream of print drum sector numbers into the print buffer FIFO, I needed to develop some sort of translator to take those sector numbers and convert them to M-32TL print wheel sector numbers that the M-32TL printer driver could swallow.

This turned out to be harder than I expected.

There are a few functional differences between these printers that needed to be addressed:

1. The sector numbers for some of the non-numeric characters on the numeric columns are different between the EP102 and the M-32TL.
2. The glyphs printed by the EP102 in the two symbol columns are very different from the characters on the M-32TL's single symbol wheel.
3. The M-32TL paper feed is performed during printing a the last (left-most) character on the line. This means that (a) it's necessary to know whether the character being printed is the end of the line, and (b) feeding the paper without printing requires printing a blank character.

One of the issues I really wanted to address is the printing of the two symbol columns to the right of the numbers. Most of the characters the EP102 can print in column 17 are arithmetic operators, and are also found on the M-32TL print wheel it uses to print in its right-most two columns. However, some of the EP102's glyphs are not found on the M-32TL's symbol print wheel, such as the glyph "M+". This is a single glyph on the EP102's drum, but would require printing two characters, "M" and "+", in the two symbol columns of the M-32TL.

Deciding to translate the single EP102 glyph like "M+" into two consecutive M-32TL characters requires the translator to see the EP102 codes for both columns 17 and 18 simultaneously, yet the codes arrive one at a time. To address this, the translator has a 2-stage shift register: when the code for column 18 in the second stage, the code for column 17 is in the first stage. This also helps address the end-of-line problem, because when the last character of the line is in the second stage, the EOL code will appear in the first.

Getting the timing right took quite a bit of work. The data stream starts with a mode code that indicates whether the line should be printed in black or red, followed by the column 18 code, and proceeds from right to left after that. Until the codes for the mode, column 18, and column 17 have been read there will be no output to the printer. From there until the end of the line, the input from the EP102 emulator and the output to the printer move in lock-step, with the printer being the most likely throttling point but the input could throttle too. When the EOL code appears in the first-stage of the shift register, the code in the second stage gets printed even if there is no more data available from the source. Special cases include the appearance of an EOL code as the first (right-most) code, which necessitates printing a space so the paper feed can occur even though an EP102 blank code wasn't received.

Eventually I worked out a scheme that supports this odd pattern while (hopefully) handling all the possible stalls and not-ready conditions.