HP82143A printing - two views of the same medal
|
07-17-2024, 02:10 AM
Post: #1
|
|||
|
|||
HP82143A printing - two views of the same medal
Mike (Stgt) recently made a test print on my HP82240B printer simulation v1.17 in HP82143A mode with the service module ET-11968 in his NutEm/PC. The expected result is shown at "Figure 4-3. Printer Test Output" in the 82143A PRINTER SERVICE MANUAL.
As Mike noticed in his NutEm/PC manual, there's a large discrepancy between the figure 4-3 output and the print output of the HP82143A simulation. One of the main reasons is the printer behavior on the 44 byte character buffer overflow, a part not handled in the HP82143A simulation so far. So a new approach made in v1.18beta2 with implementing the 44 byte character buffer. But there's still a difference between the figure 4-3 output and the v1.18beta2 print output which I could not explain. Before the 1st "TRY OUT INTENSITY SWITCH" row I still have two empty columns in double-wide mode in the character buffer, which then have an effect on printing the first "TRY OUT ..." row. I compared the send byte sequence with the test print source code of the ET-11968 module, I found no difference. I have the MCode trace log from Mike's NutEm/PC run generating the svn.bin data. I specially checked the printer status register reads between sending the last two bytes 0x00, 0xD0 from the downstairs graphic at Code: 41BB 110 NCXQ 4422 [PROBY] until the begin of the "TRY OUT..." messages at Code: 4237 110 NCXQ 4422 [PROBY] The C[13:12] return of Code: 4753 264 PERTCT 9 code between was Code: C=02.. MAN as result of the mode switch and PRT key test. In all cases the BE bit 8 (Buffer Empty) was not set, which is correct because there're are still 3 bytes (0x00, 0x00, 0xD0) left in the character buffer. So I'm mostly sure that the test print byte sequence of NutEm/PC is equal to the one send to the real printer. About buffer size 43 vs. 44 characters, old versions of nonpareil are using 43 character for buffer overflow. At the 82143A PRINTER SERVICE MANUAL at p.2-2 section 2-16: "The character buffer consists of 44 eight-bit registers which are used to store an eight-bit code for each character to be printed." At the 82143A PRINTER OWNER'S HANDBOOK at p.62: "Accumulating Columns A series of column print numbers can be accumulated together into the print buffer using ACCOL (accumulate column). This allows you to print special graphics up to 43 columns wide." Eric began a disassembly of the HP82143A firmware at https://github.com/brouhaha/82143a-mk3870-fw. Here we have a character buffer from address 0x14 to 0x3f which are 44 byte, but it seem to be implemented as ring buffer with a "current" and an "end" pointer. A ring buffer regularly can only hold "buffersize - 1" elements because when Read and Write pointer are equal, this means empty buffer. When filling a ring buffer with "buffersize" elements the Write-pointer will be incremented to the Read-pointer position and we can't distinguish between buffer-full and buffer-empty any more. But using a 43 character buffer in my v1.18beta2 implementation produce a line overflow of the two "barcode" lines each with additional columns in the next line. So 44 seem to be correct. I attached the actual output of v1.17, the output of v1.18beta2 and the send byte sequence (svn.bin) received by the printer simulation. Could any HP8213A expert, familiar with the printer control codes, explain the byte sequence interpretation difference of the figure 4-3 output and the print output of v1.18beta2? ![]() |
|||
07-17-2024, 03:16 AM
(This post was last modified: 07-17-2024 03:17 AM by brouhaha.)
Post: #2
|
|||
|
|||
RE: HP82143A printing - two views of the same medal
(07-17-2024 02:10 AM)Christoph Giesselink Wrote: Here we have a character buffer from address 0x14 to 0x3f which are 44 byte, but it seem to be implemented as ring buffer with a "current" and an "end" pointer. A ring buffer regularly can only hold "buffersize - 1" elements because when Read and Write pointer are equal, this means empty buffer. That property of a circular buffer is true only if there is not some independent mechanism for tracking full vs empty, using at least one additional variable. Such a variable could be a single-bit flag or a buffer fill count. For instance, fi the buffer pointers are equal, and the last buffer operation was a read, then the buffer is empty. If the buffer pointers are equal, and the last buffer operation was a write, then the buffer is full. I suspect that the 82143A firmware does maintain additional state to distinguish full from empty, but I haven't specifically identified the details. |
|||
07-17-2024, 11:22 AM
Post: #3
|
|||
|
|||
RE: HP82143A printing - two views of the same medal
(07-17-2024 02:10 AM)Christoph Giesselink Wrote: I attached the actual output of v1.17, the output of v1.18beta2 and the send byte sequence (svn.bin) received by the printer simulation. Hi Christoph, One thing I noticed is that the 'staircase' is printed by accumulating 45 bytes in total (3*15 columns). The two 'barcode' lines are composed of exactly 44 columns, with the sequence [00,ab,bd,00] after the first and [e0] after the second. In both cases this results in a linefeed following the 'barcode'. So, if the buffer is full (after 44 bytes), there is as you mentioned still the three bytes [00,00,d0] left to handle. My question is who generates the linefeed after the staircase? Both 'barcodes' are followed by a linefeed (but the columns are right justified), but the staircase is left justified and it looks like the two extra bytes [00,00] are added as empty columns just before the first "TRY .." in your output, and the [d0] byte is treated as "abort graphics mode" (so text can follow). The first [00] bytes after the first 'barcode' is probably printed on the line following the 'barcode', but is not visible on the paper, as I assume the [ab,bd] are treated as control characters. Just my 2 cents ... Cheers, Thomas [35/45/55/65/67/97/80 21/25/29C 31E/32E/33E|C/34C/38E 41C|CV|CX 71B 10C/11C/12C/15C|CE/16C 32S|SII/42S 28C|S 48GX/49G/50G 35S 41X] |
|||
07-17-2024, 05:41 PM
Post: #4
|
|||
|
|||
RE: HP82143A printing - two views of the same medal
In one document I found that on a buffer overflow the line is printed in the style of last used EOL (EOLL/EOLR).
So for the barcodes [e8] EOLR is used, for the staircase [e0] EOLL. (07-17-2024 11:22 AM)ThomasF Wrote: The two 'barcode' lines are composed of exactly 44 columns, with the sequence [00,ab,bd,00] after the first and [e0] after the second. In both cases this results in a linefeed following the 'barcode'. Drawing each barcode line is trigged by a buffer overflow. The byte sequence [00,ab,bd,00] is for the empty line between the barcodes. So the [e0] code before the 'staircase' printing is the empty line between 2nd barcode and the 'staircase' and not for printing the 2nd barcode line. (07-17-2024 11:22 AM)ThomasF Wrote: One thing I noticed is that the 'staircase' is printed by accumulating 45 bytes in total (3*15 columns). This is correct follewd by the 2 bytes [00,d0]: Code: 41BB 110 NCXQ 4422 [PROBY] So we have an overall size of 47 bytes for the 'staircase'. (07-17-2024 11:22 AM)ThomasF Wrote: My question is who generates the linefeed after the staircase? In my implementation the 44 byte buffer overflow of drawing the staircase [01,01,01,02,02,02,04,04,04,08,08,08,10,10,10,20,20,20,40,40,40,80,80,80,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00] with 44 byte in [e0] style. The buffer is empty then and reading the next three bytes [00,00,d0] send to the buffer of total 47, which are not printed at this time. After this the user should test the mode switch and print key manually before the test prints the "TRY OUT ..." messages to test the intensity switch. (07-17-2024 11:22 AM)ThomasF Wrote: The first [00] bytes after the first 'barcode' is probably printed on the line following the 'barcode', but is not visible on the paper, as I assume the [ab,bd] are treated as control characters. The control codes [ab,bd] are responsible for the empty line between the two barcodes. This is a log evaluating svn.bin: Code: <- 20 32 Line marked with "<-" are lines reading data from source und put the data into the 44 bytes character buffer. All lines marked with "Rowlength:" are generated by reading a byte from the 44 byte character buffer, evaluating the byte and show the number of columns in the row with the evaluated character number code and as character symbol. Sometimes there are lines evaluted like this: "Rowlength: 0, E8, è" where the evaluated character [E8] is not in the character buffer. These are inserted EOL to advise the printing engine to draw a line left or right adjusted after a buffer overflow. |
|||
07-25-2024, 07:58 PM
Post: #5
|
|||
|
|||
RE: HP82143A printing - two views of the same medal | |||
07-25-2024, 08:39 PM
Post: #6
|
|||
|
|||
RE: HP82143A printing - two views of the same medal
Nice!
What was the Gordian knot? Was is some code you had to interpret in a new way, or was it the buffer handling? Cheers, Thomas [35/45/55/65/67/97/80 21/25/29C 31E/32E/33E|C/34C/38E 41C|CV|CX 71B 10C/11C/12C/15C|CE/16C 32S|SII/42S 28C|S 48GX/49G/50G 35S 41X] |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)