HP97 The journey begins

[teenix]

(11-22-2021 02:18 AM)Paul Dale Wrote:  As for sending lumps of data, that should be fine. The printer does some buffering.
Pauli

Hi Pauli,

Yes that is correct. It has a 200 print column data buffer (166 for graphics). The 97 will only need 120 of those for a full buffer of its data, unless I double space the characters to make them more readable, and then it will require 140.

The problem lies in the way the 97 processes the print data. The PIK chip has different commands than can be sent for character access and the 97 uses just two of them.

If anyone is interested, this is the way it works.

The PIK character ROM has 64 characters available and to address them all, a 6 bit ROM address must be sent to the PIK. (6 bits give 0 - 63) This is one of the commands.

The second command for the 97 tells the PIK to treat the incoming data as a 4 bit address. When it receives this command the 4 bits become the high order of the 6 bits and bits 1 and 0 are both set to 1. Thus inside the PIK, it still ends up with a 6 bit address. These characters are more likely to be printed and are... 0..9, DP, -, +, *, Space or End Of Line.

For the normal 97, there is up to 20 characters per print line and there are 6 bits per print character, so up to 6 x 20 = 120 bits of information for a full line. However, the C register, where the data originates from before it is sent to the PIK chip, has only has 56 bits available. (14 x 4 bit nibbles)

If the Microcode is to print " 0.00 *** "

It could output it as Command #2 as (HEX)...

Reg C = (Nibb 13) 00 FF F0 A0 0E ED DD (Nibb 0)

This is sent to the printer from regC as 56 bits, Nibb 0 bit 0 -> Nibb 13 bit 3


or it could send it as Command #2
However, in this case 6 bit digits will be expected by the PIK, represented here as binary.

* * * Spc Spc 0 0 . 0 EOL
110111 110111 110111 111011 111011 000011 000011 101011 000011 111111

If put into 4 bit nibble form for regC it becomes
1101 1111 0111 1101 1111 1011 1110 1100 0011 0000 1110 1011 0000 1111 1111

This is 15 nibbles or 60 bits of data and is bigger than regC can hold.

The 97 Microcode will split the print data into two separate commands.

4 bit command #2 for ***SpcSpc
regC = FFFFFFFFFEEDDD

and

4 bit command #2 for 00.0EOL
regC = FFFFFFFFFE0A00 (Note: the microcode added a space before the EOL)

The print lines are all terminated with EOL characters. However when regC is sent to the PIK, which is exactly the same hardware functioning as writing regC to RAM, the PIK will immediately start printing. It keeps a pointer to the character being printed and in the example above, before that index has time to get to the EOL, the second regC transfer will take place. This overwrites the EOL in the buffer (with char 0) in this case, and the only EOL for the print line now follows the last space to be printed. Thus the print carriage will start returning at the second EOL that was sent.

You may see a problem here, in that if no EOL was in the data, the carriage will bang into the printer frame at the other end and the motor will keep pushing it, probably stripping the soft idler gear on the printer mechanism, which is why I think it was made this way. My 97 CPU board will always insert a last EOL whether needed or not and keeps track of how many characters are being sent.

The problem for the 97S IR printer is that even though the print lines are all terminated with EOL characters, you don't know if it is the last packet of data to be sent for that print line. For example, printing a line of a program will take 3 packets of data, but for an outside observer, the packet count is not known.

Further to this, there might be multiple print lines coming all with varying packet sizes. An example would be printing the result of a calculation in Trace mode, or printing 224 steps of a program.

cheers

Tony