Warning -- oo82162A may fail with V41

[mike-stgt]

Warning -- oo82162A may fail with V41 running an HP-41C or CV w/o Time module. Since simulating a CX is not affected I see no need to immediately update oo82162A.

oo82162A simulates an HP-82162A including "PRT" and "ADV" buttons, also a mode selector.

Dialog window of oo82162A

Clipboard_08-22-2025_02.png (3.79 KiB) Viewed 1497 times

Those buttons and the selector switch require a controller emitting auto-IDY frames. The HP-IL module sends them out at a 10 ms pace, same does V41, typically. As kind of a "loop sound check" oo82162A measures the time interval of 20 consecutive IDY frames. In case there are none at all or the interval is outside 25% of the expected 200 ms, I assume there is something wrong, either with the controller or the loop, and the buttons remain inactive.

When you place within the loop an HP-41 equipped with a Dev-IL ROM a considerable delay of IDY frames is expectable. Then the interval must be adjusted in oo82162A.ini as described there. Now with V41 version 9N I observe for the first time also a significant delay if there is no Time chip in the setup (327 ms for 20 IDY frames instead of 208 ms with Time). Christoph is informed.

BTW, there are few others simulating the HP-82162A, while oo82162A is the only one (AFAIK) that prints barcode like the role model.

Example output from oo82162A using PRBC (see Plotter ROM Usr Mnl)

Clipboard_08-22-2025_03.png (370 Bytes) Viewed 1497 times

Alas, I do not know if the bar height is the same, I never saw BC output from real machinery. If it differs recognisable please let me know.

[helengrace]

Thanks for sharing these details! The explanation about the IDY frame timing was very clear. Do you think adjusting the interval in oo82162A.ini is the most reliable fix, or are there alternative approaches?

[mike-stgt]

are there alternative approaches?

IDK about other options to determine if PRT and ADV buttons of a simulated 82162A may work or not. There is another controller using auto-IDY frames but for a different purpose. To measure the pace of IDY frames is a poor stopgap.
That is why I suggest since long to implement a "loop check" that may be executed before traffic starts running through the virtual HP-IL. It will remain a suggestion.
(My "loop check" idea is biased by the commit level mechanism of CMS/TSO Pipelines.)