Another bug in Free42 (3.0.14)

[J-F Garnier]

Here is a (maybe not-so-new) bug in Free42 found in the middle of a quite complex program that wasn't giving the right answer, until I single-step and checked each intermediate calculations.

Do:
open a new program space (GTO ..)
go to BASE menu, activate the HEX mode,
go to PROG mode, with BASE menu still active,
The HEXM indicator is turned off as expected,
enter the number 27,
exit BASE menu, exit PROG mode,
single step the program line,
you see the number 27,
you get 39.
The program line looks as a normal 27 decimal number, but is actually 27 hex.

Checked on Free42 Decimal, Windows version 3.0.14
On older Free42 1.x, 2.x, the program line is changed to 39, which is incorrect vs the HP-42S, but at least visible :-)

J-F

[Vincent Weber]

Funny you mention this now, because I sent yesterday to Thomas report of something similar.

I noticed that Free42/Plus42 let you enter a hex number e.g. 1ABC in programs, as long as you enter program mode starting from the BASE menu. The real 42S does not let you do that, the A... F menu is blocked by "restricted operation". Once there the 1ABC number stays under this form, unlike the 32SII that let you enter such numbers but translate them to the current base mode. Since the 42S doesn't have a global BASE mode, this solution couldn't apply anyway...

Is this an intended extension, or just a lack of entry error checking?

[Thomas Okken]

I noticed a few days ago that you were able to enter hexadecimal numbers in PRGM mode, and I made it so that it will leave the A...F menu when you enter PRGM mode. This change is in 3.0.15. However, that change only addresses half the issue, the other half being that HEXM mode is still in effect, while number entry in PRGM mode should always be decimal.

It looks like this has never been handled correctly, but before 2.5.23, it didn't lead to such weird results, because what you saw in the program line once number entry was complete was always decimal. Since 2.5.23, the way the number looks when it was entered is remembered, in order to preserve the difference between 1000 and 1E3 etc., and that's how you can now end up with something that looks like 55 while it really is 85. You can also tell what's happening because you can't enter decimal points or exponents while in this mode.

So, I'll have to fix the number entry logic so that it always assumes DECM mode when PRGM mode is active.

[Vincent Weber]

The other solution being enhancing the 42 to behave like the 32SII, but that may be too much of a stretch. The 32SII has a BASE mode that is global, i.e. Once set it applies everywhere in the calc, with dedicated annunciators to indicate the current mode. The 42S has just a BASE menu, that changes the BASE mode only as long as you stay in this menu. It therefore makes it difficult to get consistency between the way a number was entered in the first place and its current display.

But I think the feature to enter a HEX number in a program step is useful, and this is a pity that the lesser 32SII can do it, but not the mighty 42S. Oh well...