A new old bug in the printer ROM?

[ThomasF]

Hi,

I just built myself an IR-receiver after the description from Martin and Meindert.
The receiver works perfectly, and I thought of doing an emulation of the printer HP82143 since I mainly use the 41.
Yes, there are already some nice emulators, but I wanted it for Linux (and doing it by myself to learn something but also because it is fun ).

I also noticed that the existing emulators don't emulate the 82143 that well, since the pixels are not correctly dimensioned (they are rectangular, not squared) so e.g. when plotting with the 'HP' in the PPC ROM the lines are not aligned. How it is with physical 82240 HW I don't know since I don't have one.

Anyhow, when I started to decode the data sent from the calculator (I use a DM41X since I don't have the IR-module for the 41), I see that the data is basically sent in two modes, text or graphics.

Text is straight forward, using the character set from the printer. And graphics are sent by sending ESC, then the number of bytes followed by 8-bit values describing the corresponding pattern in each column to be printed. Also quite straight forward.

When listing a program, this is done in text-mode. Almost.
Listing this little program results in graphics mode being used:

   

This is the "raw" data sent from the calculator to the printer, I just formatted it for readability:

01*LBL "TEST".
02 RDN.
03 RESC{7:00.08.04.7E.04.08.00}.
04 ENTERESC{7:00.08.04.7E.04.08.00}.
05 XESC{7:00.08.04.7E.04.08.00}2.
06 .END..

So, instead of printing an up-arrow, the calculator draws the graphics for the up-arrow ... !

Is this actually how the printer ROM in the HP41 does it? I would have thought so if the up-arrow wasn't part of the character set of the printer, but the up-arrow is indeed included as character 94.

And if I do the following:
67 ACCHR 104 ACCHR 114 ACCHR 58 ACCHR 94 ACCHR ADV

I get the following result:
   

But, looking at the datastream over IR shows the following:

Chr:ESC{6:00.08.04.7E.04.08}

So, again has the printer ROM replaced the character 94 with graphics instead!
And filling the alphareg with the up-arrow (shift enter in alpha-mode) causes the following to be printed:

   
(Sorry for the "small" picture - click on it for better viewing ..)

The two last characters are not printed correctly (well, printed correctly but not sent by the calculator, the last character is missing and the next to last is replaced by character 0x88 ...)

I verified this with the 82240 emulator by Giesselink, but I have no real hardware to try this on, so I don't know if the "error" is actually in the printer-ROM (which I think), in the DM41X (which I'm using) or somewhere else.

And from what I can see, the same behavior is apparent with chr(7) (down-arrow) and chr(10) (diamond) - they are also sent as graphics instead of the corresponding byte code.

If this is the case, the error has no real effect on the calculator or programs, just that e.g. printing a whole line of these characters is impossible due to buffer overflow.

Is there someone who could verify this on the real HP41 and HP82143 (or with IR-module and the 82240), e.g. by filling the alpha-reg with the characters 7, 10 or 94 and print it (PRA)?

Cheers,
Thomas

[Christoph Giesselink]

Hi Thomas,

(01-16-2023 07:25 PM)ThomasF Wrote:  I also noticed that the existing emulators don't emulate the 82143 that well, since the pixels are not correctly dimensioned (they are rectangular, not squared) so e.g. when plotting with the 'HP' in the PPC ROM the lines are not aligned. How it is with physical 82240 HW I don't know since I don't have one.

That's wrong, they looked like rectangular because you can't stop heating immediately. So when you print out On/Off/On/Off/... the On pixels would be longer. But they are squared.

The HP plotting looks different because a 82143A character has a height of 7 pixel but then you have a gap of 4 lines before the next printable line begins.

The 82240 characters have a height of 8 pixel with no gap to the next line.

(01-16-2023 07:25 PM)ThomasF Wrote:  But, looking at the datastream over IR shows the following:

Chr:ESC{6:00.08.04.7E.04.08}

This is a trick I first seen at the WP34S. The Roman8 character set of the 82240 has no up-arrow (only ECMA94) and so the output is a mixture of text and graphic, in this case the up arrow is graphic.

It's definitely not the output of the printer ROM. SwissMicros is using an interpreter in it's emulation to translate the output of the printer ROM to the commands of the 82240. This may imply that the printer ROM is modified but not necessarily.

Meindert talked in his 2022 Allschwil meeting presentation about a 41CL printing solution which may use a modified version of my 82240B printer simulation. Meanwhile Meindert and I, with most work done by Meindert, expanded the 82240B printer simulation by a 82143 mode. The new mode use an own 82143 character set, using 168 instead of 166 columns and using a font with 7 pixel height and a gap of 4 pixel to the next line.

Since Saturday afternoon I'm able to plot with 'HP' of the PPC ROM on this printer simulation with a modified V41 as data source. The V41 is using an unmodified Printer ROM.

[ThomasF]

Hi Christoph,

Thanks for your reply and comments!

(01-16-2023 10:07 PM)Christoph Giesselink Wrote:  That's wrong, they looked like rectangular because you can't stop heating immediately. So when you print out On/Off/On/Off/... the On pixels would be longer. But they are squared.

Maybe they still are squared, it was just when I compared the 82143 output with the 82240 emulator that I found the 82143 characters to be much more narrower, as if the pixels were higher. And if I printed the pixels 2 units high and one unit wide, the output was very similar to the original 82143 printout (but not perfect) and the plotting was better aligned.
The 82143 output to the left (from the PPC ROM manual) and the 82240 emulator to the right:
   

(01-16-2023 10:07 PM)Christoph Giesselink Wrote:  It's definitely not the output of the printer ROM. SwissMicros is using an interpreter in it's emulation to translate the output of the printer ROM to the commands of the 82240. This may imply that the printer ROM is modified but not necessarily.

Ok, I missed that the 82240 doesn't have the character 7, 10 or 94 in its characterset (at least not as arrows and diamond).
But how does the IR module 82242 solves this? It must also "fool" the printer to print the up-arrow in a program listing (e.g. ENTER^ and R^) or does it switch to ECMA94 mode (but diamond is still not present)?
The following program, how does it work on a HP41 with the IR-module and a 82240 printer?
   
If I run it with '"94 "TST" 10 "TST" 7 "TST" 64 "TST"' I get the following on my 82143 emulator as well as on your 82240 emulator:
   

Cheers,
Thomas

[MeindertKuipers]

I have done some research on several printer options, so let me summarize my findings:

The DM41X uses the original PRINTER-1E ROM. The internal firmware (which is closed source) translates this to an HP82240 IR stream and the printer target is always the original IR printer or the HP82240 simulator. And that is what you see when decoding the stream. This means that from the DM41X it is not possible to print into an HP82143 emulator, unless you manage to translate the character stream back.

There are fundamental protocol differences between HP82143 printing and HP82240. This is all public information. The IR protocol is very well defined, HP82143 printing information is more spread out. Also the character sets are different.

I wanted to implement DM41X similar printing from the HP41CL, using its serial port. A first version is the YPRT rom image, which is a patched version of the PRINTER-1E ROM (can be found on the HP41CL website). The current version does not yet support graphics. It prints quite well in text-only mode into an HP82143 emulator (part of Diego's USB41 project). To support graphics I am working with Christoph to add HP82143 printing to the HP82240 emulator. The first version looks quite promising in graphics mode and as a side effect of this project Christoph is implementing HP82143 printing in V41 as well.

The HP41CL serial printing is now being updated to fully support graphics, and as always the devil is in the details, but I am confident that it will work in the end.

[Christoph Giesselink]

(01-17-2023 05:59 AM)ThomasF Wrote:  Maybe they still are squared, it was just when I compared the 82143 output with the 82240 emulator that I found the 82143 characters to be much more narrower, as if the pixels were higher. And if I printed the pixels 2 units high and one unit wide, the output was very similar to the original 82143 printout (but not perfect) and the plotting was better aligned.

I done some measurements with the aspect ratio and you're right. With pixels 2 units high and one unit wide, you're closer to the original printouts.

These are the moments to rethink decisions I made. But therefore the actual printer simulation is in beta test phase open for changes, so I changed the pixel height from beta4 to beta5.

(01-17-2023 05:59 AM)ThomasF Wrote:  But how does the IR module 82242 solves this? It must also "fool" the printer to print the up-arrow in a program listing (e.g. ENTER^ and R^) or does it switch to ECMA94 mode (but diamond is still not present)?

This may have historical reasons. At the time the first IR module 82242 was sold, HP also sold the HP82240A printer with the Roman8 character set only. This printer was made for the Pioneers and Clamshells calculators. The HP82240B was later introduced to support the ECMA94 character set of the HP48.

Attached my actual printout (HP82240B.exe v1.14b5 and V41.exe R9Ib6) with the "TST" program listing, the "TST" running output, the 3 function HP plot from the PPC example, my character set output and a lower case double width text output.

Thank goodness the V41 has a Turbo button (TAB key). Printing is so slow.

   

[ThomasF]

Hi Christoph,

Thanks for your reply and comments!

The output from your updated HP82240B.exe looks very nice! Looks very close to the original, even the plot is well aligned now

Out of curiosity, how does it achieve this? Is this using the new 82143-mode?
I guess that the HP82240B.exe also could be used with a serial port and RedEye hardware and a real calculator.
I saw that you even got the delta-character correct - nice! The DM41X sends the character 0xBA (186) which is something else in the current 82240 emulator ...

So, this probably leaves me with that the DM41X has some faults in its implementation of the "glue" between the printer ROM and the IR-transmitter.

This is how the DM41X prints the first 128 characters:

Code:

     0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
00  86 82 BA 8E 8C DE BA XX BA BA YY BA 8F A0 BA F0
10  BA BA BA D0 C0 D8 CC AE DA DB CF D3 BA 8B AF 7F
20  20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30  30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
40  40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F
50  50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D ZZ 5F
60  60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F
70  70 71 72 73 74 75 76 77 78 79 7A 87 7C 8D 85 94

XX -> ESC{7:00.10.20.7E.20.10.00} (chr 7)
YY -> ESC{7:00.08.1C.3E.1C.08.00} (chr 10)
ZZ -> ESC{7:00.08.04.7E.04.08.00} (chr 94)

But, I still hope someone could shed some light but running the small test-program on a HP41 with the IR-module (82242) towards a real 82240 or with your emulator.

Best regards,
Thomas

[Christoph Giesselink]

(01-18-2023 07:24 AM)ThomasF Wrote:  Out of curiosity, how does it achieve this? Is this using the new 82143-mode?
I guess that the HP82240B.exe also could be used with a serial port and RedEye hardware and a real calculator.

Yes, It's a complete new mode inside the HP82240B.exe. It was a general decision somewhere in October last year to create a more a less exact font copy of the original printer to fully support all characters in the graphics window. This also allwed us, to build a special Unicode translation table for text mode. The external interface with UDP and serial port is untouched.

The major issue is, on this existing program base we have no return channel for the printer status. But a working printer status is an essential for a proper 82143 output. So V41 holds a copy of the printer status base on the data send to the printer simulation. Example, the printer sends an EOLL (0xE0) or an EOLR (0xE8). This is captured by V41 and sets the EOL and depended on the EOL type the TEO bit in the V41 copy of the printer status register. So on request of the printer ROM we get a correct printer status about EOL. Same I done with mode bits, an essential for lower case, double width and graphic (also known as special column) mode support.

Like with the IR-module (82242) and DM41X, V41 use Flag 15 and 16 to control the MAN/TRACE/NORM mode.

[Tinue]

(01-18-2023 07:24 AM)ThomasF Wrote:  But, I still hope someone could shed some light but running the small test-program on a HP41 with the IR-module (82242) towards a real 82240 or with your emulator.

The user manual of the HP 82242A IR Module suggests that it uses the HP 82240A character set by default. The test program would not initially work with characters codes under 32. However, the module supports a command "MAPON", which turns on a mapping table and would then support codes 1-127.

Interestingly, the DM41X "Thermal Printer" module does not support the HP 82240A character set, and always performs a remapping. So I assume this module has been developed by Swiss Micros, and is neither derived from the 82242 nor the 82143 ROM.

I wonder if the DM41X IR hardware is compatible with the 82242 IR Module, and if thus the 82242 ROM would work. Unfortunately I don't have this ROM, and can't test this myself. Unfortunately the DM41X does not load the module: "Refusing to load unsupported HW module".

[rprosperi]

(10-20-2023 07:56 AM)Tinue Wrote:  

(01-18-2023 07:24 AM)ThomasF Wrote:  But, I still hope someone could shed some light but running the small test-program on a HP41 with the IR-module (82242) towards a real 82240 or with your emulator.

The user manual of the HP 82242A IR Module suggests that it uses the HP 82240A character set by default. The test program would not initially work with characters codes under 32. However, the module supports a command "MAPON", which turns on a mapping table and would then support codes 1-127.

Interestingly, the DM41X "Thermal Printer" module does not support the HP 82240A character set, and always performs a remapping. So I assume this module has been developed by Swiss Micros, and is neither derived from the 82242 nor the 82143 ROM.

I wonder if the DM41X IR hardware is compatible with the 82242 IR Module, and if thus the 82242 ROM would work. Unfortunately I don't have this ROM, and can't test this myself. Unfortunately the DM41X does not load the module: "Refusing to load unsupported HW module".

There is no VASM available for this module (it came out years after the enlightened VASM-releasing attitude was present) so the IO details and internal h/w is undocumented, so this ROM was basically 'blocked' to let users know it would not work.

[MeindertKuipers]

(10-20-2023 07:56 AM)Tinue Wrote:  Interestingly, the DM41X "Thermal Printer" module does not support the HP 82240A character set, and always performs a remapping. So I assume this module has been developed by Swiss Micros, and is neither derived from the 82242 nor the 82143 ROM.

Both are somewhat true. The DM41X uses the unmodified Printer-1E ROM, with its own internal firmware doing a translation from the 82134 output to 82240 IR output. And this translation is good, but obviously not perfect.

The original IR module doe snot load since the MOD file format defines which hardware it runs on, and the DM41X recognizes this. It is easily removed from the MOD file, but this will not give you an HP82240 IR printer.

[Tinue]

(10-21-2023 01:59 PM)MeindertKuipers Wrote:  ...but this will not give you an HP82240 IR printer.

Thanks! It would give me an HP 82242A Infrared Printer Module, if the IR hardware in the DM41X were identical to the one used in the original module ;-)

This module - according to the manual - performs the remapping from the 82240A character set to the one used in the 82143A printer. So I am still wondering why Swiss Micros wrote their own code for the remapping, instead of merely adapting the IR output part of the 82242A to suit the hardware of the DM41X. Then again: The ROM seems to be undocumented any possibly too hard to understand and modify.

[brouhaha]

(10-23-2023 08:11 AM)Tinue Wrote:  So I am still wondering why Swiss Micros wrote their own code for the remapping, instead of merely adapting the IR output part of the 82242A to suit the hardware of the DM41X.

None of the Swiss Micros calculators contain an 82242A.

Using the 82143A's ROM and doing code translation is an obvious way to get the most important functionality. Richard Ottosen and I did that on our prototype calculators starting in 2007.

An alternative would be to use the 82160A printer ROM, but that would be much more complicated for not much benefit.

Quote:Then again: The ROM seems to be undocumented any possibly too hard to understand and modify.

There's a lot more in the 82242A than ROM, but yes, it is also the case that the 82242A ROM code is difficult to understand. I was able to reverse-engineer how HP's PIK (printer interface and keyboard) chip for the 19C/91/92/95C/97 worked from first principles, and also how the CRC (card reader control) chip of the 67/97 worked from first principles, the latter with some assistance from Jacqes Laporte. I looked at the 82242A ROM, and couldn't really begin to make heads or tails of it, aside from the 41 user code portion that is about the same as that in the 82143A and 82160A ROMs. Admittedly I didn't spend a huge amount of time on it. If I were to attack the problem now, I'd wire up an extender to run the 82242A physically at a distance from the calculator port, and monitor the Nut bus lines (clock, SYNC, ISA, DATA, possibly flag) while performing specific printing operations.

The interface inside the 82242A between the HP-41C bus and the infrared LED is totally unknown. The Nut processor is far to slow to modulate the 32.768 kHz IR carrier directly. Aside from that, it is necessary to pace the output in a fairly complicated way, modeling the expected worst-case buffer level in the printer; see the HP Journal article on the 82240A printer for details. There's almost certainly a custom interface chip, and there may or may not be a microcontroller, either as part of that chip or separate from it..

[Tinue]

Thank you for this inside view on the development of the DM41X! The fact that it supports printing at all is amazing; I really love this calculator and have great fun playing around with it.

What I like in the 82242A ROM (based purely on reading its manual) is that it can be switched to support the 82240A natively (with MAPOFF), and then one can also e.g. enable underline printing, or start the self test from the calculator. I didn't really think about it and assumed that there is some sort of serial interface to the IR hardware of the 82242A module that could be simulated, but as you explain it is much more complicated.

Meanwhile I found an older project on Github that converts an Arduino into a Red Eye infrared sender, and with the help of this I can send any data that I like from my computer to see how the printer behaves.

[MeindertKuipers]

The IR communication protocol between the calculator and the HP82240 printer is actually quite well defined. There is a document 82240bte.pdf (you can find it on hpcalc.org) which is the technical interfacing guide for doing anything with the infrared port.
The Blinky IR module for the HP41 module is one of the few remaining white spots on the HP worldmap, although there is a simulation in the NutEM/PC (available from TOS). This is not open source though.

[Tinue]

(10-23-2023 01:04 PM)MeindertKuipers Wrote:  The IR communication protocol between the calculator and the HP82240 printer is actually quite well defined.

Maybe I misunderstood brouhaha, but I think he was talking about the interface inside of the 82242 module. Similar to the way the printer emulators are set up, there will be a part that produces the bytes going to be sent over infrared, and a part that produces the IR pulses out of the bytes.

Nowadays, the IR pulse producer is a microcontroller (Arduino or similar), and possibly in the 82242 module it is set up similarly. If this interface were understood, then one could use the original ROM code of the module, capture the produced bytes and send them to the modern implementation of the pulse producer that is built in to the DM41X.

[MeindertKuipers]

Unfortunately it is not so simple. The Blinky module has a number of registers with status bits and control words, and these are not documented. It would take a lot of monitoring and reverse engineering to sort that out.

[brouhaha]

(10-23-2023 11:21 AM)Tinue Wrote:  Thank you for this inside view on the development of the DM41X!

Sorry, that's not what it was. I was not involved in the DM41X development in any way, and have no association with SwissMicros other than being a customer. Anything I say about the innards of the DM42 or DM41X is my own speculation, though in the area of DM41X infrared printer support, I'm fairly confident in what I've said.

All information I posted was based on my own experiences, engineering prototypes in conjunction with the late Richard Ottosen, that were functionally similar to the DM42 and DM41X. We developed our specific Free42-based and 41-microcode-based prototypes in 2010 to 2012, after having made a series of simpler HP-microcode-based prototypes earlier. I've shown those off at many of the annual HHC conferences. Anyhow, the point being that Rich and I faced some of the same challenges that the engineers at SwissMicros have, and we used the same approach to IR printer support on the 41.

We never made it past prototype stage because we never were able to fund having high-quality casings, keys, etc. manufactured, although we used the same Sharp Memory LCD as the DM42 and DM41X have subsequently used. Rich and I were only developing calculators we were interested in, because no one else was doing it. Once SwissMicros introduced the DM42, which satisfied my desires and partially satisfied Rich's, we felt much less need to try to commercialize what we had. I am very impressed that SwissMicros has actually succeeded in making calculators with a good industrial design, which at this late date is far more of a challenge than writing the firmware (in my opinion as a long-time firmware developer) (when leveraging already-available Free42 source code, or HP-41 microcode).

That hasn't, however, stopped me from working with another friend, John Doran, to develop a one-off (well, actually two-off) Nixie tube calculator running microcode from (and thus simulating) the HP Woodstock and Spice series calculators. We presented that at the recent HHC 2023, and I expect that Eric Rechlin will have the video up on Youtube within the next few weeks. John and I aren't going to be building any more units of this design, but we will make the plans publicly available, including schematics, PCB layouts, and software source code.

[brouhaha]

(10-23-2023 01:04 PM)MeindertKuipers Wrote:  The Blinky IR module for the HP41 module is one of the few remaining white spots on the HP worldmap, although there is a simulation in the NutEM/PC (available from TOS). This is not open source though.

I wasn't aware of that, and it does appear that the author actually figured out quite a bit about how the 82242A hardware works.

That's inspired me to look at my disassembly listings again, and it doesn't seem quite as inscrutable now, I guess that's the benefit of having spent a few more years writing and debugging Nut code.

[ThomasF]

(10-24-2023 11:27 AM)brouhaha Wrote:  That's inspired me to look at my disassembly listings again, and it doesn't seem quite as inscrutable now, I guess that's the benefit of having spent a few more years writing and debugging Nut code.

Yes, the code is (no surprice here) a bit similar to the 82143, but still offers some hurdles to cross ...
Using the Pico2040 I managed to understand the Wand enough to make an emulation of it that works fine now, by tracing the instructions I came to understand the inner works of the Wand data buffer and how it interfaces the Nut using e.g. FI signaling.

I have then started to look at the Blinky, which offers another level of the puzzle - since the HW is unknown.
So far I have realized that there are at least 15 (to my knowledge so far at least 16 bits wide) registers that can be read and written to. Some of these are status registers (like register 7). By emulating these register I can now at least start the calculator and start tracing commands (TESTP e.g. still returns "BAD" but at least it executes!).

Reading an writing to Blinky is done by "READ (r)" and "WRITE (r)" (at least r=0-14 are used), but there is also 16 other instructions that I so far as not come to grip with.

This NPIC instructions used seems to have the following format:
rrrr 111 xxs
-- rrrr is the register in the Blinky (0-14 - have not seen 15 being used)
-- s is the ending PIC instruction (return control to Nut)
-- and xx is the instruction, where 00 = write, 01 = read, and 10 is yet unknown for me (11 I have not seen in the code).

Like the following sequence where we first write to reg 5 which is then followed by two other instructions:

Code:

 6F51 264            SELPF    9
 6F52 178            WRITE (5)
 6F53 1FC            XXX (7)
 6F54 0BD            XXX (2)   ;includes RTNCPU

Since I don't have a Blinky myself, I am not able to trace the execution to see how the XXX instruction alters the bus (or even if it does), but maybe the NutEM/PC could be a way to try and figure out what these instructions do.

Cheers,
Thomas

[ThomasF]

(10-23-2023 08:29 AM)brouhaha Wrote:  

(10-23-2023 08:11 AM)Tinue Wrote:  Then again: The ROM seems to be undocumented any possibly too hard to understand and modify.

There's a lot more in the 82242A than ROM, but yes, it is also the case that the 82242A ROM code is difficult to understand. I was able to reverse-engineer how HP's PIK (printer interface and keyboard) chip for the 19C/91/92/95C/97 worked from first principles, and also how the CRC (card reader control) chip of the 67/97 worked from first principles, the latter with some assistance from Jacqes Laporte. I looked at the 82242A ROM, and couldn't really begin to make heads or tails of it, aside from the 41 user code portion that is about the same as that in the 82143A and 82160A ROMs. Admittedly I didn't spend a huge amount of time on it. If I were to attack the problem now, I'd wire up an extender to run the 82242A physically at a distance from the calculator port, and monitor the Nut bus lines (clock, SYNC, ISA, DATA, possibly flag) while performing specific printing operations.

The interface inside the 82242A between the HP-41C bus and the infrared LED is totally unknown. The Nut processor is far to slow to modulate the 32.768 kHz IR carrier directly. Aside from that, it is necessary to pace the output in a fairly complicated way, modeling the expected worst-case buffer level in the printer; see the HP Journal article on the 82240A printer for details. There's almost certainly a custom interface chip, and there may or may not be a microcontroller, either as part of that chip or separate from it..

I have from the disassembled 82242 ROM now been abled to understand the inner workings of the 82242 to be able to emulate the ROM in my Pico device (see my other posting on that).
There is still one white spot - and that is how the DELAY is handled - if and how it affects the internal timer of the module, but since I have no real module to test with I have left that for future investigations.

And secondly, I have not yet wired up an IR led to the Pico to be able to actually send the IR commands to a printer, right now I only send them on the UART to a PC.
I could connect a transmitter to the PC, but as of now I can just trace the byte sequence in a terminal on the PC, verifying that I got the correct bytes.

But, in short, the module is in two parts, one that handle translation of characters and the output buffer (up to 28 characters) and then sends byte by byte to the hardware side. The hardware side then just sends each byte using the IR led.
The hardware also contains a timer (which is readable from the code) and a busy flag (there seems to be no buffer in the hardware itself - it only works on one character at a time). Probably also instructions to turn the hardware "on" and "off".

With this knowledge, the emulation works fine, all printing commands etc, even the TESTP function works (which even uses functionality and extra RAM that is surprisingly not used by the ROM itself), and (without knowing the inner details of DM41X) I would say that the DM41X should have no problems in handling the HP82242 module - but of cource it needs to emulate the hardware parts.
But since the support for IR is there, this should be of no problem - quite a simple hack with the right tools (I say acting knowingly ...).

Hope to be back when I have everyting in place, i.e. a complete emulation of the HP82242 working in a real 41 printing on the real HP82240 - and as said, only the transmitting IR part is missing right now (which already works in another installation).

Cheers,
Thomas