The example we'll use is a very simple Radio Shack, 8 digit LCD calculator with memory, a square root and percent.
One of the keys to a successful simulation is the availability of a manual. Even a simple calculator can have some quirky features, and it is these features that often give the calculator its uniqueness, so it is important to model these if the simulations is meant to document a piece of calculator history. Fortunately the calculator in the example we're using is both sparse in quirky features, and has a manual available on the internet here.
However, having started to model the features of this fine calculator the code started to get bloated with details of the particular features of this model, and this served only to hide the basic structure of the code. So a decision has been made to simplify the code so that only the pertinent features of a simple calculator are modelled. You can always have a go at modifying the code to model the actual calculator features---the manual is available above after all!
The image we'll use of the calculator to be modelled is shown below.
All the basic expected operations will be modelled. So, in general, the basic "<num> <op> <num> =" sequence yields a correct value. Chaining is cut down a little. Something like "2 + 3 +" will still work but "2 + 3 * 6 = " yields 30 not 36---i.e. we won't maintain separate chain registers for adds/subtracts and multiply/divides. Overflow and error handling is much simplified. In these cases "-E-" is displayed, and only an "ON/C" will clear it and initialise the calculator again. No overflow rescaling is done (as per the manual). The manual also states that pressing '=' repeats the last operation, but as repeated pressing of the relavant operation key has the same effect, we won't model this. With these things in mind, we can start constructing a model.