82104A simulated

82104A

82104A simulated

Postby mike-stgt » Mon Jan 18, 2021 11:45 am

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:
CR.png
Different input formats possible
CR.png (8.53 KiB) Viewed 2626 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.
Last edited by mike-stgt on Wed Feb 17, 2021 4:04 pm, edited 1 time in total.
mike-stgt
.........
.........
 
Posts: 82
Joined: Tue Dec 24, 2019 12:12 pm

Re: 82104A simulated

Postby mike-stgt » Wed Jan 27, 2021 10:28 am

"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
.........
.........
 
Posts: 82
Joined: Tue Dec 24, 2019 12:12 pm

Re: 82104A simulated

Postby mike-stgt » Thu Feb 04, 2021 12:35 am

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
.........
.........
 
Posts: 82
Joined: Tue Dec 24, 2019 12:12 pm

Re: 82104A simulated

Postby mike-stgt » Wed Feb 17, 2021 5:46 pm

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 :)

Edit: ZIP removed, replaced by update in next append
mike-stgt
.........
.........
 
Posts: 82
Joined: Tue Dec 24, 2019 12:12 pm

Re: 82104A simulated

Postby mike-stgt » Fri May 14, 2021 10:28 am

Bugfix update: (i) copy of X register on 16C in integer mode crashed, (ii) a NOP directly after a skipped XQ effectuated a RTN as well, and (iii) 82143A formerly restricted to 32k characters only (about 1600 lines) may now print 8k ZENROM listing in one run (that is independently of Blinky).

Additional feature: CR may now use also program and data files in LIF disk dumps (file type E080 and E0D0).

About the different card types: types 1..4 stem from HP-67/97, namely Tony's emulators. He saves every single track in a file of its own, what results in a handling in line with the role model. In contrast, my CR simulation bundles tracks belonging together in one file, using a self-acting "insert next card" for read and write. Respecting Tony's and my approach and also mind errors like NO ROOM gives some chance for mistakes. Holler if you find one.
Attachments
ooNUreFIP.zip
No source inside
(284.89 KiB) Downloaded 20 times
mike-stgt
.........
.........
 
Posts: 82
Joined: Tue Dec 24, 2019 12:12 pm


Return to Card Reader

Who is online

Users browsing this forum: No registered users and 1 guest