BasiCalc Spreadsheet ported

[netzerohero]

Here's my port of the BasiCalc spreadsheet from 1982 that originally ran on an Apple-II running AppleSoft Basic.
Requires rp6502 FW>=0.12 for the console's addressable-cursor, running the rp6502's EhBasic.

BASICALC_20250901.txt

• Use ctrl-U & ctrl-H to move either up-down or left-right. (These are the original Apple-II keys.)
• Use spacebar to toggle.
• Use ! to force spreadsheet calculation.
• Use & for summation.
• Use @ to clear cell at current cursor.
• '/' (slash) brings-up a menu.

Load and Save don't fully work; EhBasic cannot easily access the rp6502's filesystem.
(However, though it is clunky, one can save and load spreadsheets using minicom's ascii file transfer features as a work-around.)

Don't expect Excel or LibreCalc performance. :)

Here is some history in a cross-post.

[rumbledethumps]

Vibes of CP/M watching it draw.

[rumbledethumps]

Here's how you can use rp6502.py and VSCode to automate things.
https://github.com/rumbledethumps/basicalc

[netzerohero]

Hello @rumbledethumps ,

Thank you for the above additions into rp6502.py.

For the 1st time since late 2023 I updated my vscode-cc65 tool-chain to latest in main (commit f643021), to try-out the recent changes in rp6502.py (where the above additions for basic workflow were also introduced.)
Issue: When using the latest rp6502.py, VSCode compile->link-debug/load automation breaks in function::code_page() on the last line (line-61) on the return statement:

def code_page(self, timeout: float = DEFAULT_TIMEOUT) -> str:
"""Fetch code page to use for terminal encoding"""
self.serial.write(b"set cp\r")
self.wait_for_prompt(":", timeout)
result = self.serial.read_until().decode("ascii")
return f"cp{re.sub(r"[^0-9]", "", result)}"

I'm not at all fluent w/ python, but the last-line doesn't appear well-formed. Can you pls inspect?
Thank you.

[rumbledethumps]

See if the fix from @James-HoneyBadger works for you.
picocomputer/vscode-cc65@0729c0b

[WojciechGw]

Thank you for your effort.

Please check this simple case:
A1 = 100
A2 = 0.23
A3 = A1*A2
For me, the result in A3 is equal to 22.00 ...

[netzerohero]

As a follow-up, I found references in the historical literature of the bug you exposed. It has plagued this code since 1982 with various ports! Here is a reference from Softalk Sept-1982 of 'the fix' after the original code was published (and as implemented now):

And a port to the H89 in REMark magazine mentioned the bug and the 'fix' in a follow-up article in 1983 (EhBASIC does not support the INSTR string function):

In short: like today - history is repeating itself.

[WojciechGw]

Hello @netzerohero :)

Thank you for your detailed explanations :)

I found other workaround

A1=100
A2=0.23
A3=A1*100*A2*100/10000

and result in A3 is correct :)

[netzerohero]

Hello @WojciechGw ,

Thanks for sharing your work-around.

This continued to puzzle me; I did a little more research.
I believe the issue is with EhBasic's limited precision of its floating-point representation and the use of the INT() function.
EhBasic: Floating point numbers are represented as four-bytes (32-bits) : 7-bit exponent, 1-sign-bit, 24-bit (3-bytes) mantissa.
Applesoft: Floating point numbers are a five-bytes (40-bits) with a signed 8-bit exponent and a 4-byte (31-bit) mantissa

Try the following:
100 A = 100 * 0.23
110 B = INT(A)
120 PRINT A, B

EhBasic produces: 23 22
Applesoft produces: 23 23

Using the ":F" format option bypasses the code using the INT() function.

[rumbledethumps]

I suspect EhBASIC shaved off a few bytes by skipping round to nearest, ties to even.

[rumbledethumps]

This needs more thought than I want to give it, but here is a starting point.
https://github.com/picocomputer/ehbasic/blob/main/src/basic.s#L5857-L5873