IV42 - another calculator for the DM42 hardware

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