|Emulator updates & HP82240B printer simulation|
Message #1 Posted by Christoph Giesselink on 25 Oct 2011, 2:11 p.m.
In the last weeks I updated Emu48 Classic to v1.51, Emu28 to v1.23 and Emu42 to v1.14. All three emulators for Win32 now contain an interface for a Redeye printer simulation.
Normally the calculator send infrared pulses in the Redeye format to a HP82240 printer. These pulses are decoded inside the HP82240 to a data byte stream. Because I have no real chance to transfer the infrared pulses over an interface inside a PC, I decided to integrate the Redeye format decoder inside the emulator listening at the STL bit of the LED control register at Emu28 and Emu42 and at the half bit frame generator bit at Emu48.
This beginning of this project go back to the year 2002 or 2003. Cyrille send me a decoder sample for Emu48 at this time. I know the Redeye format since I wrote a decoder for it in the early 90'ties, so I find it a good idea. But I also knew that an implementation for Emu42 is much more difficult. So I decided to integrate the Redeye decoder inside Emu42 first. Because I already wrote such an decoder in 8052 assembler, an implementation in C was rapidly done. But in not "Authentic Speed" mode weather a HP28S nor the HP42S was able to print 10 or 20 characters successfully. In "Authentic Speed" mode printing with a HP42S was working, but not with the HP28S. The reason for the HP28S in "Authentic Speed" mode is a timing issue, which base on the timer integration concept inside the Emu42 emulator. So I decided to use a workaround which you normally don't recognize. But the problem in non "Authentic Speed" mode (full running) was still left. I knew that the reason for this misbehaviour was inside the CPU cycle clock measurement (see also my MoHPC article Inside Saturn Emulator Timing, but I had no idea how to solve it. So I cancelled further working on this project for over 7 years. In spring 2011 I restarted the printing project and solved the timing problem. All three emulators now got the Redeye decoder.
But still a printer simulation was missing. IMHO it makes no sense to add a printer simulation to each emulator, so I decided to write a separate HP82240B printer simulation. After my experiences with TCP/IP in Emu71 I decided to use UDP for the inter-process communication between the calculator emulator and the printer simulator. So all emulators send their decoded bytes over IPv4 to the address "localhost" port 5025 by default. The address and port can be changed in the "Settings" dialog.
My new HP82240B printer simulator, available on my homepage at http://hp.giesselink.com/, set the main focus on text input. So the main window is a text mode window only. To support most of the Roman8 and ECMA94 character set, I decided writing an Unicode application with translation tables from the printer fonts to Unicode. So be aware to use a Unicode font which support most of the used characters and when you are doing Copy&Paste to a non Unicode editor, you will get conversation losses. This is a limitation, but after more than 10 years after introducing Unicode to a Windows OS, when should we begin using Unicode? But there's also an optional windows in the printer simulation showing the printer output in the original HP82240B printer font.
As input interface the HP82240B simulator support the native IPv4 UDP interface of the Emu28, Emu42 and Emu48 emulators, a serial COM port interface for the HP48 series wire interface and finally USB over the original HP USB driver used by Conn4x for supporting the HP48GII, HP49G+ and HP50G calculators. The display dump capture over a key isn't supported for the HP49G and later. Since the HP49G calculator the display dump over a key use a HP82240B incompatible format. Use Conn4x for a display dump instead please.
I hope you enjoy using the new printing capability of the emulators. For those which want to add the UDP interface to their own HP82240 emulator or simulator, just integrate a normal UDP server listening for the data byte stream on the given port.
Caution: On slow PC's especially NET books with Intel Atom CPU the printing may not work properly with loosing transferred data or with decoding errors inside the Emu28 and Emu42 emulator.