Calculators with Support of the 82240 IR-Printer

[Christoph Giesselink]

(07-09-2014 12:51 PM)Martin Hepperle Wrote:  In the meantime I have tested my code with a HP 48G and the WP 34S and the results are as expected. For further tests I used a HP 28S and found the IR-transmission relatively buggy (incomplete data frames, bit errors).

Does anyone have experience with the HP 28S and IR-printing and knows whether there is a known timing problem with the HP 28S? Is the 28 known to be more finicky w.r.t. printing? I have not looked at the signal with an oscilloscope yet.

The HP-28S works successful in connection with a HP-82240A/B printer and with my Redeye-Serial converter.

The main difference between a HP48 and a HP28 is the IR burst and half-bit timing generation.

The HP48 chip Clarke or Yorke has a hardware register called LBR (Led Buffer Register). This register is responsible for sending a half-bit in the REDEYE protocol. The timing of this register is done by hardware and derived from the 32768Hz crystal, so the timing of the IR burst and the half-bit length is very exactly.

In opposite the HP28 and all other calculators using the Lewis chip (2nd Clamshell generation 19B/19BII/28S and High End Pioneer 17B/17BII/27S/42S) or the combination of 1LK7 Saturn and 1LP2 Centipede chip (1st Clamshell generation 18C/28C) don't have this hardware driven register. Here the timing of the half-bit length is completely done by the CPU. Only the generation of the 32kHz IR signal is done in hardware. So on software side you have to open a gate for the exact time of 7 IR burst cycles. Overall the CPU has to control the IR burst length time and the half-bit length time. To make this more difficult the CPU has no constant speed. On the 1LK7 Saturn CPU the CPU strobe frequency (~620kHz) is generated by a LC oscillator, on the 1LR2 Lewis over a PLL from the 32768Hz base frequency to get a CPU strobe frequency of nominal 1MHz. To get a more or less exact timing, the actual CPU speed is measured over the internal timer driven by the 32768Hz crystal. So from time to time the CPU speed is measured to eliminate the CPU speed drift over temperature, humidity, ...

To make it short, the timing accuracy of the REDEYE protocol made my CPU is much less than the one generated by the hardware LBR register inside the HP48 series.

So your method checking the IR state on each half-bit position is less timing tolerant than the solution suggested in HP Journal article (used by my hardware solution and inside the Emu28 and Emu42 simulation). In the suggested solution you are synchronizing your timing at every received bit and not at the beginning of the 12 bit frame.

(07-09-2014 12:51 PM)Martin Hepperle Wrote:  In the end I would like to dump the ROM of the 28S via IR so that I can use it in EMU28.

To stay correct, the 28S can be emulated by Emu42 (with simulation of the 1LR2 Lewis and 1LR3 Sacajawea chip) and the 28C with Emu28 (a simulation of the 1LK7 Saturn in connection with the 1LP2 Centipede chip).