IV42 - another calculator for the DM42 hardware

[deetee]

Hi!

I proudly present IV42 - a powerful programable RPN calculator for the DM42 hardware based on FORTH.

For more information have a look at https://github.com/zooxo/IV42
or see a short video at https://youtu.be/sDT_JJClNMI.

Thanks in advance for any comment, suggestion or bug to make IV42 faster, more versatile, stable and intuitive.

Regards
deetee

[vaklaff]

Hello deetee

I took a short glance yesterday - just the docs, ENOTIME for pretty much anything these days - and I think it’s just great!

[Nigel (UK)]

(03-17-2022 06:56 AM)deetee Wrote:  Hi!

I proudly present IV42 - a powerful programable RPN calculator for the DM42 hardware based on FORTH.

For more information have a look at https://github.com/zooxo/IV42
or see a short video at https://youtu.be/sDT_JJClNMI.

Thanks in advance for any comment, suggestion or bug to make IV42 faster, more versatile, stable and intuitive.

Regards
deetee

Excellent! I like new calculators. It's good to see the DM42 hardware being used like this.

I've been playing for a while to get the hang of IV42. One thing that keeps catching me out is that pressing <- when entering a program leaves program mode rather than deleting an instruction. I know this is deliberate (and of course there is a delete function key), but given how other calculators use this key it might help to change this.

Another thing that takes some getting used to is that EXIT (nearly always) turns the calculator off. This is clearly deliberate and I'm sure I'll be happy with it soon.

Two things that would be nice: a way to single-step through a program, executing one step at a time; and a way to reset the calculator state without deleting programs. I know that the stack can be cleared, but I've found that the same program doesn't always seem to run in the same way. Being able to start from a definite state would help debugging.

Now onto a few problems that I'm having. Here's a program I've been playing with:

Code:


 0  BEG
 1  2
 2  /
 3  DUP
 4  FRAC
 5  0
 6  <>?
 7  IF 
 8  6
 9  *
10  1
11  +
12  THEN
13  HOLD
14  DUP
15  1
16  =?
17  UNTL
18  END

This is supposed to be a "3n+1" program. If odd, a number n is replaced by 3n+1; if even, it's replaced by n/2. It is supposed to end when n=1. The HOLD command in line 13 halts the program to show the new value of n.

This is the only program in the calculator.

First possible issue: while entering the program, sometimes a key doesn't register with one press. After the second press, the desired command is entered, followed by the number "7"! I know that the DM42 keyboard isn't always perfect, but on my calculator it is pretty good. A keyboard fault alone wouldn't explain the "7"s.

After the program is entered, I clear the stack. I then enter "5" and press XEQ to run the program. I get 16 and the program halts. Pressing R/S repeatedly gives 8, 4, 2, and 1. This is exactly what should happen. The status line shows that nothing is accumulating in the stack: at the HOLD instruction, the displayed number is all that there is. This is as expected.

I would expect the next press of R/S to end the program. The 1 =? test should be true and UNTL shouldn't jump back to BEG any more. This doesn't happen. What does happen next isn't always the same.

Sometimes, continuing to press R/S gives a series of 0s. Sometimes, pressing R/S leads to a repeated loop of 4, 2, 1 again and again. Continuing to press R/S eventually leads to the series of 0s.

Once the series of 0s begins the stack starts to grow. Pressing the R-downarrow key (ROT) brings up 77 (sevens again!) and a number that gets smaller each time the R/S key is pressed. After the first zero, this number is 1/7277 (more sevens!!).

I've considered that rounding error might be an explanation, but adding an INT instruction after the HOLD doesn't change things. It also wouldn't explain why the 0s aren't always reached immediately.

Finally, once the 0s have been reached, try typing in 2.5 (for example) and then executing FRAC from the catalogue. At present this gives zero instead of 0.5. At other times, for previous versions of the program it has given other seemingly random numbers.

I hope these observations are useful. Many thanks again for an excellent program!

Nigel (UK)

[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

[Feierabend]

(03-17-2022 06:56 AM)deetee Wrote:  Hi!

I proudly present IV42 - a powerful programable RPN calculator for the DM42 hardware based on FORTH.

For more information have a look at https://github.com/zooxo/IV42
or see a short video at https://youtu.be/sDT_JJClNMI.

Thanks in advance for any comment, suggestion or bug to make IV42 faster, more versatile, stable and intuitive.

Regards
deetee

Thank you for sharing your wonderful creation!

I love some of the ideas you implemented, notably the large digits and the goal of using of the DM42 keyboard as-is. I love its unique aesthetics. I also think that the three rows of function keys work very well.

I am intrigued by the possibilities of the large stack, but so far, I have not been able to make good use of it.

I like the simple graphing features. They could be even more useful with some kind of labelling (be it large or small digits, just to indicate min and max x and y).

I also encountered the "mysterious 7" glitch. In my case, I am sometimes able to reproduce it by quickly pressing up or down when editing a program: it sometimes randomly inserts number 7. I also noticed it happening when pressing other keys quickly: for instance pressing 5 (or any other number) and ENTER several times in sequence quickly will insert number 7 here and there. I noticed that when this happens, the display, which is usually very fast and responsive, slows down for some fractions of a second, and I can see the image being (re)drawn horizontal line by horizontal line (slower than usual).

Regarding documentation, I think that providing few calculator program examples would be useful.

[deetee]

Hello Feierabend!

Thank you very much for trying and testing IV42. Each of your hints are on my ToDoList for the next version.

Some words to your comments:
* Forth offers some kind of 'infinite stack' (memory is cheap these days) - I limited this number to 26 (A-Z). There are differences to regular HP calculators regarding ROT or entering (4x) a constant value to the stack. On the other hand you can use more than 4 registers for programs running or use PICK or STKS (sum up stack).

* There is definitely some kind of 'dimensionsless' feeling when viewing graphics (especially when zooming or shifting). But displaying 4 numbers (x/y min/max) will reduce space or cover the graphics. That's why I decided to push the 4 numbers (xmin, smax, ymin, ymax) to the stack when leaving the graphics mode.

* The 'misterious 7 glitch' remains unsolved so far - but I am quite sure this is related to the keyboard buffer system the OS (DMCP) offers. Good for fast number typing but somehow misterious primarily when changing the keyboard reading mode between 'wait for key' (key_pop()) and 'scan key' (sys_last_key()).

The next version has a TEXT EDITOR (using the 3 rows of function keys to simulate a half QWERT-keyboard + left-right-flipping) and runs the LEGENDARY HP-35 ROM (for reminiscence reasons). By the way the last one needs the 'scan key mode' - so leaving HP-35 pushes a misterious 7 to the stack for sure.

My further plan is to integrate a BASIC interpreter - I'm quite far with it.
My wish is to implement MICROPYTHON which is unfortunately far beyond my capabilities - where an excellent coder (fnord) failed (https://forum.micropython.org/viewtopic.php?f=3&t=8156) so far.

Regards
deetee