Calculators:
bugs, artefacts
There are several reasons for this section on Vintage Calculators. It is interesting to see what mistakes the designers of the very early singleIC calculators made. It helps you to identify which IC a calculator uses without opening it, and.... its fun to play with your calculator! Let me know if you have discovered any more. I have broken this section down to three areas: Bugs (pure mathematical or process mistakes), Artefacts (strange behaviour in an uncertain areas) and Styles (how certain end conditions like overflows are treated). I hope, eventually to include a "Guess the IC" section based on this items. For the key of the symbols see Protocol below. 
Bugs
Post
Divide to Zero bug ICs: TI TMS0851NC Calculators: 
This is rather odd. First take a number and divide by ten until it is zero. Then add a number and the trailing zeros are not suppressed. I suspect this is an artefact from an extra internal digit of precision. 
Key sequence:  (1)(/)(1)(0)(=)(=)(=)(=)etc  0. 
(+)(6)(=)  6.0000000 
Divide
to Negative Zero bug ICs: Toshiba Calculators: 
Two different outcomes for this bug I have found: 
Key sequence:  ()(1)(/)(1)(0)(=)(=)(=)(=)etc  0. 
or:  0.0000000 
Negative
Zero bug ICs: Hitachi et al Calculators: 
This allows you to display minus zero and is quite common. This bug doesnt appear to affect the math of any subsequent calculation, mathematically it is treated exactly the same as true zero 
Key sequence:  (1)()(2)(=)  1. 
(+)(1)(=)  0. 
Pseudo
Fixed Decimal Bug ICs: Calculators: 
Calculators
that do not normally have a switch for fixed decimal notation can sometimes be
forced into almost acting that way. In
this example the three trailing unsuppressed zeros stay during all addition and
subtraction operations until more digits are required.
I usually find that this condition is reset by using a multiply, divide,
root or percentage function when normal operational display returns. 
Key sequence:  (1)(+)(0)(.)(0)(0)(0)(=)  "1.000" 
(+)(2)(=)  "3.000" 
Zero Square Root Bug ICs: Calculators: Prinztronic Mini 7 

Not such a
common one so useful to discover the offending IC. It appears to affect
certain calculations after using the square root and can even cancel the
automatic constant function. Just
one of those things that slipped through the design QA I guess. 
Key sequence:  (1)()(1)(=)  "0." 
(SQRT)  "0.0000000"  
and try:  (0)(.)(1)()(0)(.)(1)(=)  "0." 
(SQRT)  blank display  
and try:  (1)(0)(0)(0)()(1)(0)(0)(0)(=)  "0." 
(SQRT)  "0.0000"  
(and want even more):  (1)(.)(0)(0)(0)(0)(0)(0)(1)(Sqrt)  "1." 
()(1)(=)  "1."  
and just to top it try:  (1)(SQRT)  "1." 
()(n)(=)(=)...  "n." and constant is disabled 
Divide
by Zero artefact
ICs: Calculators: Litton Royal 
The vast majority of calculators will give you an error state if you try to divide a number by zero. There are two main deviations from this (a) the ignore and carry on bug and (b) the clocking digit artefact. Sometimes the standard error state is recoverable and sometimes it is not. To gauge this try pressing (CE) and (n)(=) to see if the error state is generated again after recovery. 
Key sequence  (5)(χ)(0)(=)  
Standard  Result "0", and error flag  
(a) Ignore  "0" and calculations continue  
(b) Clocking  "0a0c00" where c and a is a incrementing number 
Items in
brackets are key presses, i.e. 1+2 would be shown as (1)(+)(2)(=) they are given
for normal logic unless the particular bug is in RPN logic only. Items in quotes are the display result; i.e. the above would show 3 or 3. or 3.00 in fixed decimal mode. 
