Revealing the HP-82242A IR Printer Module

[ThomasF]

Update: 2024-02-20 - Some small corrections in Blinky.pdf, i.e. info about some missing registers.

Some months ago, Andrew showed us all how a Raspberry Pico could be used to read the bus signals from a HP-41, and also how to inject data on the bus so that the Pico could both read and write to the calculator.
I quickly adopted his ideas and build myself a platform that I could use to test and develop code to be able to extend the calculator, and so far I have been able to:

Use multiple serial ports
With the help from Meindert I now use several virtual serial-ports over USB to my PC.
One is showing the command line interface (i.e to configure modules, start trace etc).
Another shows the disassembly trace, one for the printer output and another I use for my virtual wand.

Trace execution
Andrew also showed how to trace execution, which I extended further. I have included a complete disassembler (no symbols yet) so I can trace execution more or less in real-time. Since the buffer in the Pico is limited, I have added ”trace-breakpoint” support which allows me to start and stop tracing on any address in the address space, so I can e.g. disable trace in known loops (like waiting for key input). Using this I can trace for minutes without missing a single instruction.

Add any existing software module
In my Pico I have 16 MB of flash, so I can download a lot of modules, and from a command line tools plug and unplug the modules, specifying which port to put the module in.

Simulate Q-RAM
Any module can be marked as RAM, so I can use tools like the Zenrom to update code or write my own Mcode. Any modules can later be uploaded to the PC.

Virtual wand
As I have shown in a previous post, I added support for the HP-82153 hardware, so I could emulate the wand, i.e. sending barcode data from the Pico to the 41 bus just as the real wand would do.
Now I have also used one serial port for this, so I can ”scan” any barcode with my mouse on the PC which then sends the barcode data directly to the Pico and in to the 41 – so now it is very easy to send any program to the calculator – just as easy as with the real wand and paper barcodes but with the mouse on the PC display instead!

X-Function/X-Memory
The RAM is extended, so I can emulate the X-Memory. This RAM is saved in flash, so the data is persistent, and I can also have multiple banks with X-Memory, and swap between different banks.

And finally the Blinky …
To further test the capabilities of the Pico, I decided to try and emulate the IR-module (since I don't have one). As this module was undocumented, I started to analyze and comment the ROM code and from that I built up a model for the hardware parts of the module. With the help of Meindert, Mike and Christoph I was finally able to emulate the complete module. I have also added an IR-led to the Pico and can now print on the HP-82240A printer from my 41 - mission accomplished!

Where to go from here ...
The Pico I have supports LiPo battery, so the setup is portable (except the configuration which is done over USB (+tracing and Wand)).
So the next step could be to support WiFi and make it completely mobile.
There are also some other interesting projects in the pipe, so keep an eye open ...

Thanks to ...
Meindert who has been very helpful! We have shared a lot of information regarding the Pico environment and he has also helped me with traces from an actual HP82242A.
Mike (who actually managed to emulate most of the module before me in his NutEm/PC) and Christoph (who used this in his V41 to add Blinky support) have also helped out to verify and find faults in my implementation. Christoph even found a fault when using the emulation together with the PPC-ROM, which later was verified by Meindert to be a real problem using a real HP82242A!
And of course Andrew who came up with the idea of using a Pico like this!

What else ...
To feedback to the community I include the ROM-listings that I have commented, and the findings I have done in the Blinky module (sorry for the formatting - it is a living document, and I hope to clean it up going forward).
With this information I hope anyone who is interested in the inner workings could use this as a start.
Please note that all comments are just my interpretation of the actual code, and that there might be both faults and mistakes, so use the information with a big pinch of salt …
Anyhow, my implementation works great, and the information has been proven to work in other implementations as well!
If you have any comments, or find any mistakes in mine, please let me know so I can update and share the documents!

Cheers,
Thomas

[rprosperi]

Amazing stuff Thomas, thanks VERY MUCH for sharing the results of your curiosity and skills with the community. It has long been said among 41 fans that the last remaining big mystery was the inner-working of the Blinky, but now you've not only solved that mystery but also documented it in great detail, for others to learn and benefit from.

Thanks to you, Andrew, Christoph, Jean-Francois, Meindert and Mike, for earlier projects built upon here, and for their help in this important project!

[ThomasF]

(02-19-2024 04:30 PM)rprosperi Wrote:  Amazing stuff Thomas, thanks VERY MUCH for sharing the results of your curiosity and skills with the community. It has long been said among 41 fans that the last remaining big mystery was the inner-working of the Blinky, but now you've not only solved that mystery but also documented it in great detail, for others to learn and benefit from.

Thanks to you, Andrew, Christoph, Jean-Francois, Meindert and Mike, for earlier projects built upon here, and for their help in this important project!

Thanks Bob!

It is so fun and inspiring to dig into this with the new possibilities that this opens up!
I still remember the days when we built MLDL's from scratch, getting the latest tools from PPCJ or TN, and now "everything" can be done in software ...

I just made a small update to Blink.pdf above since I noticed that I had missed some info about some registers, and some other small corrections.

For anyone interesting in how the module works (with focus on the HW api), I recommend to check how TESTP is implemented.
When I started I thought that if I get TESTP to work, then everything would fall into place, and it did (at least to 98% ).
You will find the commented TESTP function in the second bank, starting at 0x6400.

Cheers,
Thomas

[ThomasF]

Hi all,

The other day Meindert notified me of a small peculiar thing in the Blinky.
He noticed that after a print command, e.g. PRA, the module would turn on the CPU again after some seconds.

About 2 seconds after a single PRA, but up to almost 30 seconds for more than 20 consecutive calls to PRA.

He found this while tracing a real Blinky, and this did not happen on my emulated version, so something in the emulation was apparently missing!

This is how I think it works, what I did to solve it ...

When printing, the Blinky keeps track of how much has been printed, at least the number of linefeeds, since printing a full text line takes about the same time as a single line feed. If one calls another print-command directly after the first, this information must be kept between the two commands and so on.

This is mainly done by maintaining a timer that is incremented by a value corresponding to the delay added by each printing command.

When execution is done, this timer is decremented in the background and when reaching zero a service request is issued, the CPU wakes up and handles this.

The service request is done by pulling ISA high until the PWO line goes active, and the CPU starts running again. To know who called, the operating system goes through all modules, checking the last addresses in each ROM for a lookup table and calls any service routines it finds, and the module can do whatever it needs to do.
Note that the CPU has no information about who raised ISA and has to check every module in the system.

So I added a detection of light/deep sleep, as well as a background clock that could feed my emulated Blinky while the CPU was sleeping, and then pull ISA and kickstart the CPU when the timer expired.

This works fine now, so yet one step closer to a complete emulation and understanding of the Blinly Module!

Thanks goes to Meindert for being so observant when helping me with real Blinky traces!

---------------------------

One observation I made while looking through the available documentation on service request was in the excellent HP-41CX Programmer's Handbook where the following list is found which shows the services that are available to modules:

xFF4 Interrupt checked during Pause
xFF5 Interrupt checked if system flag 53 set
xFF6 Interrupt checked on wakeup /not ON key
xFF7 Interrupt checked when HP41 is turned off
xFF8 Interrupt checked just before CPU stops
xFF9 Interrupt checked on wakeup /ON key
xFFA Interrupt checked on MEMORY LOST

But, I think that the description of the FF8 service is misleading, it should be "when enter or leaving light sleep".
This service is called from light sleep wakeup logic, but also when going to light sleep.
Wakeup (xFF6 or xFF9) are related to when leaving deep sleep (i.e. turn on from display off).

Edit: I removed a question about a NPIC instruction, but found the answer
I had misread the document and missed a part ... my fault ...
The instruction in question is used by e.g. the printer to report its status.

Cheers,
Thomas