Introduction
Wow! A new desktop calculator for Commodore. Programmed all by myself in BASIC. Wow, so impressed! Or not. Doesn't even have decimals.
No, it's not the best thing since sliced bread, but it was fun. And it's just a start -- there's a bigger goal I'll get to in a while...
This was a puzzle programming exercise I challenged myself with. How to make the calculator, especially with the operator precedence feature.
Link: LOAD"CALC64",8
Implementation
Let's go through how it was implemented.
User Interface
First was the design of the user interface, by creating PRINT statements. Used reverse text to make a rectangular box with the keys displayed.
How to click on a key? I'm so used to a mouse or touch interface. Oops, Commodore doesn't have that usually, or not so easy. Ignoring the 1351 mouse for now. Most Commodore users are used to using the keyboard or joystick. Forget the joystick, this is not a game! Keyboard entry one key at a time will do just fine. Note that ENTER also acts as =, and DEL is equivalent to ←, and X is a synonym for *.
Entry of digits was the first processing, accepting up to the limit of the display. This stored as a string (V$) with keyed entries appended.
I started with 7 digits, but outgrew that in testing and increased to 9 digits.
At first, only positive numbers were supported, then fixed it to support negative numbers, with the negative sign taking up a position in the display. The N key toggles a number entry between positive and negative and back again.
Entries allowed by this calculator are interleaved numbers and binary (two argument) operators. Note that immediate operators like C and N usually take effect immediately, whereas binary operators require multiple arguments and a finalization (another binary operator or =).
There are exceptions allowed in entries to overwrite the prior value or the prior operator. Examples:
- 1+1=3 keyed entries will replace the 2 with a 3
- 2+x3 will replace the addition operator with multiplication operator
Precedence needs a Stack
One design requirement I set for myself was to include operator precedence. This means that multiplication and division have the same higher precedence over addition and subtraction at the same lower precedence. Usually math is evaluated left to right, but due to precedence issues, other operators may need to be done first. In other words the expression 1+2x3 is equivalent to 1 + (2x3) and then 1 + 6 and finally evaluates to 7. But 1 x 2 + 3 is equivalent to (1x2) + 3, then 2 + 3, and finally 5.
I simply put numbers and operators interchangeably on a stack in order of entry until enough information is present to start evaluating.
Rule 1 - if user presses =, then evaluate
Rule 2 - if first operator is multiplication or division, once the second number is finalized with a second operator, simply evaluate the first expressionRule 3 - if first operator is addition or subtraction, defer until the second operator and third number is finalized (third operator present!), then figure out what to do - either evaluate first or second expression, reducing the work
Subroutines
Error conditions
