IV42 - another calculator for the DM42 hardware

[deetee]

Hello Nigel!

Thank you very much for testing, all comments and hints to improve IV42. This will be my homework for the next days and weeks.

Right now I would like to comment some of your points:

* EXIT and [<=] key
Unfortunately the EXIT key is more flat than the other keys and hard to touch. That's why I decided to make it an exclusive (except OS-functions like file load menu) ON/OFF key (like on the voyage series). So the main CLEAR/BACKSPACE/EXIT/BREAK/DELETE (I used to use on my former projects with 16 key calculators) is the [<=] key - and in (most!) cases additionally the [R/S] key. Unfortunately [<=] exits the program editor and doesn't delete the current program step. I didn't want the user to exit the program editor with the [R/S] key only. But maybe I'm gonna make an exception of this rule and change [<=] with the DEL function key?

* Reset the calculator
Actually IV42 exits when leaving to the OS (DMCP). So some data and settings have to be written to the USB disk (files primarily without file extension, in the folder /IV42). When starting IV42 all saved data (if exist) will be read to the calculator. So if you delete saved files in the USB disk folder /IV42 (set, regs, fkeys, plist) the calculator uses the default (factory) settings.

* The misterious "7"
I also recognized very rarely a "7" in the display without touching the calculator or running a program. But this is not reproducible. I thought it to be some electrostatic effect (my DM42 is always cabled and lies between two laptops) or some disfunction of the DMCP key buffering function (key_pop()). But I have to have a closer look to my code (why 7?, not reproducible?). This seems to be a serious problem ...

* FRAC
Actually (like many functions in FORTH) FRAC starts an internal program (DUP, INT, SUB) to calculate. Normally this works fine (2.5 gives 0.5). Either your 2.5 (as result) isn't exactly 2.5 (ie. 2.499... - try [SHOW]) or the program execution part of IV42 was confused by previous operations. To find this bug I need it to be reproducible. But I'm gonna examine it.

* Programming
Thank you for testing so intense. I need some time to follow you. In general programming is the hardest part of making a calculator. Conditions, branching and loops are doing complicated things. In my tests I found two curiosities (I didn't solve yet): Sometimes you have to end direct entering of numbers with DUP and following DROP (to delete doubled value). Sometimes loops don't end at 0 but on 1 (workaround: 1, ADD before <?). Maybe that helps in your case - but the shame of not solving this is on me.

So far now from me - 1000 thanks again for your help - every hint of you is (at least) on my todo list.
Actually right now I'm trying to extend IV42 with a text editor (to view and edit text files from USB disk) ...

Regards
deetee