82104A simulated

[mike-stgt]

My Nut Firmware Interpreter now simulates also the 82104A card reader. All tracks belonging to a set of cards are written into a single file. Reading from file "inserts" self-acting all tracks of the set. In addition, cards from Tony Nixon's very convenient HP97 emulator are read also.

No noise, no animation, only a simple joint between simulated HP41 and PC file system:

Different input formats possible

CR.png (8.53 KiB) Viewed 1172 times

Tony Nixon was so kind and told me very detailed about the data on magnetic cards of HP67/97. Besides a bemusing change of lsb/msb in representation, it is at most the repetition of the checksum what makes a difference to HP41 cards. Nonetheless it is a pleasure for me to have in this respect a complete simulation of the 82104A.

A word about the format of the resulting PC files. Tony conceals the content of his files for understandable, good reasons. I do respect this and don't want to jeopardize his "moral fence" to keep the data integrity of his files. For this reason, I also conceal my card's content (by translation, not transliteration) and will not publish neither the source how I read the HP67/97 cards nor how I deal with mine.

/M.

1st Edit: Replaced ZIP with an updated version that reads besides mag. cards also RAW files from V41. In case of RAW file bundles (containing several END-separated routines), only the first programs is taken in.

2nd Edit: Replaced ZIP with an updated version. Reading RAW bundles offers the remaining program/~s as "RestOfBundle.RAW" to read next. Very handy as it allows to decide what to keep of the bundle.

3rd Edit: Removed ZIP, find an important update three appends further down.

[mike-stgt]

"82104A Card Reader Owners Handbook" state in paragraph 'Reading a Program From a Card', step 3b, how to use key assignments (of global labels in the program) written on the card. At present that holds true within my simulation for card decks of filetype *.41CRM and in future (V41 release R9F or R10, whatever comes first) also for user code files (filetype *.RAW).

The current V41 release R9E (and several before I guess) removes assignment data when saving and when reading RAW files. Christoph was so kind to act on my petition and affirms to keep the data when writing user code files in future. This will neither affect reading this files with V41 nor Emu42, but allows easy use of previous key assignments -- my CR simulation is prepared today already. (To be honest, it is a feature of the CR, not of my firmware interpreter.)

Note: consciously or at least intentionally RAW files originating either from V41 or Emu42 running an HP42S are not distinguishable, neither by filetype nor a tag within the file. So it is users' competence not to apply a wrong file, my CR simulation is not prepared to sort it out.

/M.

[mike-stgt]

Red Neon Alert!
Do not use with the a. m. CR simulation RAW files from other sources than V41 or other emulators not running an HP41C/CV/CX. It may lead to MEMORY LOST or even worse, end in silently wrong results.
Reason: "Compiled" jump distance data in GTO and XEQ to local labels is written to magnetic cards and used when read back in. Same when using RAW files as cards substitute. Currently there is no bulletproof way to distinguish RAW files from a virtual HP-41 or HP-42. Apparently the coding of jump distances is incompatible, GTO or XEQ from HP-42 executed on HP-41 will -- when already compiled -- jump to the wrong spot, even outside the program, even past the permanent .END.

[mike-stgt]

An update that deserves its own append.

Why? -- Some RAW files as magnetic card surrogate could jeopardize the program execution.

How? -- To deal with RAW file bundles (containing several programs in one file) the content past the first END is used as next input. If this remnant is junk not terminated with an END (or at least containing another one), the CR "goes berserk".

Now? -- RAW files w/o END are rejected.

A few words more: Currently there exist some funny RAW files on Warren's DVD, directory [DVD]\Users Library USA\raw, all a multiple of 256 in size. Past the first END they are filled up with some kind of holdover. I came across it by chance, when looking how many RAW files are there and if there are differences.

BTW, calculator program containing RAW files will intentionally remain undistinguishable by an easily observed mark (only those from HP-32Sii under Emu42 are tagged). My plea was declined to use in future an END with last nibble 'F' instead of 'D' for RAW files originating from V41. Main reasons: i) too few users not worth the effort, and ii) the vast amount of 'D'-ending RAW files already existing since long. Well, I agree with i) but for ii) a little 'run-once' routine should be no problem. This idea made me look into some RAW files a bit here and there -- what resulted now in the fix of a. m. bug