New WP34S unit

[ebs]

Another one here converted an HP30b into a WP34S, yes in 2023, the project doesn't seem as died since the last build (3916) is from this month.

The WP34S is just superb, the only issue I have found is that in integer/base mode the input is still limited to 12 digits, imho should be possible to enter more with scroll like in HP16C and Casio CM-100.

The procedure I followed for flashing is similar to the Arduino one (thanks adamkov) with these differences:

• I used a CP201x USB to UART/Serial converter (3.3 V lines)
• I connected the TxD, RxD wires directly form the CP201x connector, without breadboard
  • TxD from CP201x to Calculator In (J35, row 1, col 1)
  • RxD from CP201x to Calculator Out (J33, row 1, col 2)
    
• I used two paper clips, one for reset and another one with two parallel pins to erase
• I used only one CR2032 battery and connected the negative terminal of the empty receptacle to GND of CP201x with an alligator, no external power supply for the calculator
• I used a PC with Ubuntu and wp34sflashcmd for flashing
  

This setup worked like a charm. I hope this can be useful for somebody.

Finally I would like to give thanks to Paul, Walter, Marcus and many others that contributed to this great project. Special thanks to spiff72 who in 2023 provides overlays for WP34S and many other calculators.

Edited: Added TxD and RxD scheme to the HP30b connector

[Paul Dale]

Quote:the only issue I have found is that in integer/base mode the input is still limited to 12 digits, imho should be possible to enter more with scroll like in HP16C and Casio CM-100.

If you can figure out where to store the extra input line characters in the 1 bit of remaining RAM, there might just be enough flash to implement it

Pauli

[Nigel (UK)]

(10-26-2023 04:17 AM)Paul Dale Wrote:  

Quote:the only issue I have found is that in integer/base mode the input is still limited to 12 digits, imho should be possible to enter more with scroll like in HP16C and Casio CM-100.

If you can figure out where to store the extra input line characters in the 1 bit of remaining RAM, there might just be enough flash to implement it

Pauli

I think the command line buffer is already long enough to do this:

Code:


#define CMDLINELEN      19      /* 12 mantissa + dot + sign + E + sign + 3 exponent = 19 */

When entering an integer there wouldn't be a dot, E, exponent sign or digits, so a sixteen-digit integer should be ok.

To try this out, I've changed the digit entry limit from 12 to 16 in integer modes. I've added code so that digits 13-15 appear in the exponent; if there are sixteen digits, the whole display scrolls left.

Surprisingly this seems to work both on the emulator and on the real hardware. The code changes are minimal. There are, however, two new variables: an int and a *char both local to an "if" statement in the function disp_x() in display.c.

I haven't uploaded it yet; does it seem safe, or at least not obviously unsafe, to release?

Nigel (UK)

P.S. I see 65 downloads from the WP34S Sourceforge page over the last week - it's not dead yet!

[ebs]

Nigel, first of all, many thanks to try to do the impossible!

(10-27-2023 01:24 PM)Nigel (UK) Wrote:  To try this out, I've changed the digit entry limit from 12 to 16 in integer modes. I've added code so that digits 13-15 appear in the exponent; if there are sixteen digits, the whole display scrolls left.

Wouldn't that clobber the base/overflow/carry indicator? Would be better just do the scroll with digits 13-16? Just my suggestion.

[Nigel (UK)]

(10-27-2023 07:29 PM)ebs Wrote:  Wouldn't that clobber the base/overflow/carry indicator? Would be better just do the scroll with digits 13-16? Just my suggestion.

The indicator is only affected when more than 12 digits are entered, and only during number entry. Everything is back to normal once a non-digit key is pressed.

The disappearance of the indicator acts as a reminder that a long number is being entered.

Your way would work too, of course! I’ll upload what I’ve done later today or tomorrow and you can see how it works in practice.

Nigel (UK)

[Nigel (UK)]

I’ve uploaded it now. Release 3917 is in the building!

Nigel (UK)

[Paul Dale]

I was aware that the input buffer was longer than the 12 digits displayed. However, to enter a full sized negative number in binary, 65 characters are required and there isn't space for that. Hence my comment.

Nonetheless, increasing the input size to 16 is an improvement but this doesn't allow entry of all 64 bit integers in any base. It could likely go to 19 characters which would allow unsigned input for bases 11 and above and signed input for bases 12 and above. Still a long way from the ideal.


We've got windowing indicators, mightn't they be useful to show long number input without overwriting the exponent? At least in the 7 segment portion of the display. The graphical component isn't require for input IMO.

[Nigel (UK)]

(10-28-2023 12:26 AM)Paul Dale Wrote:  I was aware that the input buffer was longer than the 12 digits displayed. However, to enter a full sized negative number in binary, 65 characters are required and there isn't space for that. Hence my comment.

Nonetheless, increasing the input size to 16 is an improvement but this doesn't allow entry of all 64 bit integers in any base. It could likely go to 19 characters which would allow unsigned input for bases 11 and above and signed input for bases 12 and above. Still a long way from the ideal.


We've got windowing indicators, mightn't they be useful to show long number input without overwriting the exponent? At least in the 7 segment portion of the display. The graphical component isn't require for input IMO.

I admit that I never thought about extending the input to allow for 64-bit binary numbers. To me, 16 characters allowing 64-bit hex input seemed enough. However, it might be possible to go further. You are right about using the "windowing" during input - I considered it but took a short cut instead.

When you said that "only one bit of RAM remains", how literally did you mean it? Is there still room for new non-static variables to be introduced during number input? Or must any new code repurpose variables that already exist?

If you can't remember, I quite understand! It's all a long time ago...

Nigel (UK)

[ebs]

3917 flashed and tested, it works as intended by Nigel.

[Nigel (UK)]

There's now release 3918, which does indeed allow for the input of 64-bit binary numbers without using any extra RAM. In any integer mode you can now enter as many digits as you like - once you've entered more than 12 the display scrolls to the left, and you get the window bar indicators in the alpha line. Of course if you enter more than 64 bits' worth of digits (or fewer, depending on the word size), earlier ones are lost. It all seems to work, both on the emulator and on the actual calculator, but any bug reports would be welcome.

Nigel (UK)

[Paul Dale]

Nice work Nigel. One comment about the change:

Code:

long long int _cmdlineint;

probably should be unsigned to avoid problems.

I also don't see support for entering negative numbers, although I've not installed the firmware (no serial ports anymore to program with). The sign character is included in the input buffer & it will likely corrupt the number being entered.

[Paul Dale]

(10-28-2023 09:53 AM)Nigel (UK) Wrote:  When you said that "only one bit of RAM remains", how literally did you mean it? Is there still room for new non-static variables to be introduced during number input? Or must any new code repurpose variables that already exist?

It might have been two bits. The non-obvious part is that the calculator is essentially powered down between keystrokes so the spacious 4k of RAM loses it contents. That restricts things to the 2k of non-volatile RAM.

It would be possible to grab more RAM by reducing the number of registers and program steps both of which are less than ideal.

What you did repurposing the input buffer is a neat solution. There's plenty of space there for a 64 bit integer and its sign. Does backspace work correctly?

[Nigel (UK)]

Backspace does work, and - I believe - so does entering negative numbers. CmdLineDot is used to hold the sign. Making the long long int unsigned is probably a good idea: I haven’t noticed any problems, but I have not been diligently searching for them!

Nigel (UK)

[Paul Dale]

Thanks, I didn't check the code too deeply.

Pauli

[ebs]

Nigel, 3918 works as you described.

But the loss of the most significant digits when WSIZE is surpassed could be a bit confusing, specially in LZOFF mode in binary, if a one followed by zeros is lost all that zeros suddenly disappear. Would be better if possible when the limit of WSIZE is reached, trigger a "Too long error"?

[Nigel (UK)]

(11-04-2023 08:22 PM)ebs Wrote:  Nigel, 3918 works as you described.

But the loss of the most significant digits when WSIZE is surpassed could be a bit confusing, specially in LZOFF mode in binary, if a one followed by zeros is lost all that zeros suddenly disappear. Would be better if possible when the limit of WSIZE is reached, trigger a "Too long error"?

On the calculator as it was previously, nothing special happens when WSIZE is passed. With an 8-bit word size I could enter "12345678" in hex mode; it only changes to "78" when the command line is processed (ENTER or another operation). I agree that the issue you have identified is more of a problem.

Initially I did intend to count up digits and flash up a warning when too many are entered. The problem is that the number of digits varies with the base. In bases 2, 4, 8, 16 it's easy to work out; in other bases the number of digits allowed depends on the exact digits that are entered. If I could think of a quick way to spot when overflow occurs I'd implement it, but so far I haven't managed this. That doesn't mean it can't be done or even that it's hard; any ideas are welcome! Any method has to be light on RAM (not too many extra variables) and ideally really short. The calculator's flash space is filling up - the code so far has used up a few hundred bytes, which isn't too bad, but how much more is justified?

I actually think it's rather fun to type in a long base 9 number and watch the digits go crazy when too many have been entered! But that's just me, perhaps.

I'm about to upload r3919, which contains a couple of bugfixes. I'll continue to think about the problem - as I've said, it's easy to do it in the most commonly used bases, and perhaps that's enough.

Thank you so much for your feedback!

Nigel (UK)

[Nigel (UK)]

Release 3919 is now uploaded. It contains a couple of bugfixes for long integer entry - CmdLineInt is now an unsigned long long int, and the code now works correctly on the Qt emulator.

I've added a short file in the doc folder. This is what it contains:

Quote:From r3918 onwards the WP34S no longer limits entries in integer mode to 12 digits. So if you wish to enter the base 7 number 100200300400500600100 then you can do so directly. Once 12 digits have been entered the display scrolls to the left, and the "window bars" appear in the status line. During entry the <- key deletes digits and the +/- key changes the sign, as expected.

There is no upper limit to the number of keys that can be entered! However, the maximum word size is still 64 bits. Once the number entered exceeds this limit, earlier digits are lost. In bases other than 2, 4, 8, and 16, the number displayed suddenly changes when 64 bits are exceeded.

Behind the scenes, instead of storing a long string of keypresses, the code calculates and updates the number entered as each key is pressed:

new number = (old number * base) + key pressed.

When the backspace key is pressed, this is reversed:

new number = old number / base

(this is integer division). Rather than the 64 bytes needed to store the full command line for a 64-bit binary number, this method only requires 64 bits! By letting these 8 bytes share memory space with the command line, no extra RAM is used. Since the actual hardware only has one or two spare bytes of non-volatile RAM this space-saving is vital. (The actual code takes up a few hundred extra bytes of flash memory.)

I've tested this code on the calculator, the Windows emulator, and (on Linux) on the Qt emulator. It seems to work as intended, but testing by other users would be much appreciated.

If you don't want your calculator to have this feature, either use r3916 or build the project with the line #define LONG_INTMODE_ENTRY (near the start of features.h) commented out.

Nigel (UK)

[Nigel (UK)]

(11-04-2023 09:44 PM)Nigel (UK) Wrote:  

(11-04-2023 08:22 PM)ebs Wrote:  Nigel, 3918 works as you described.

But the loss of the most significant digits when WSIZE is surpassed could be a bit confusing, specially in LZOFF mode in binary, if a one followed by zeros is lost all that zeros suddenly disappear. Would be better if possible when the limit of WSIZE is reached, trigger a "Too long error"?

<snip>
Initially I did intend to count up digits and flash up a warning when too many are entered. The problem is that the number of digits varies with the base. In bases 2, 4, 8, 16 it's easy to work out; in other bases the number of digits allowed depends on the exact digits that are entered. If I could think of a quick way to spot when overflow occurs I'd implement it, but so far I haven't managed this.
<snip>

I've thought about it now and I think it can be done quite straightforwardly. If I'm right, I'll upload something tomorrow! Thanks again for bringing up this matter.

Nigel (UK)

[Paul Dale]

The integer code is already able to detect overflows -- it might be possible to reuse some of it.

I don't know if the version of gcc being used for target builds is recent enough (I'd guess not) but there are builtins for detecting integer overflow etc: __builtin_add_overflow and __builtin_mul_overflow.

[Nigel (UK)]

Release 3920 is uploaded. The calculator now returns a "Too Long" error when a keypress would leave the entered number requiring more than 64 bits of storage.

Nigel (UK)