In this file, the version against which a "known problem" is recorded represents the point at which the problem was observed and documented, not necessarily when it was introduced.


Version 0.2 - 1 October 2001

Known Problems

* Assumes large desktop resolution and will consume a disproportionate amount of real estate on low-resolution desktops. Bitmaps will scale appropriately in later versions.

* The indexed (and indirect) GSB and GTO operators have not (yet) been implemented.

* ISZ and DSZ fail to detect zero if the value in I has a fractional component. [fixed 0.206]

* ISZ and DSZ can alter the state of the carry and overflow flags. [fixed 0.206]

* Integer MUL and DIV flag settings are not always correct.

* Double multiply, divide and remainder are not yet implemented. [fixed 0.210]

* The XY conversion that occurs on transition to/from floating point mode is not yet implemented. [fixed 0.205]

* There is no enforced upper limit on program memory. Storage registers are limited to 128. In practical terms, this should not be a problem.

* Floating-point divide-by-zero produces NaN display. Integer divide-by-zero causes abnormal termination. [fixed 0.207]

* The RMD operator does not trap divide-by-zero. [fixed 0.207]

* Divide-by-zero, in the DIV and RMD operators, does not leave the stack as it should. [fixed 0.207]

* There is no "running" display when a program is executing. [fixed 0.209]

* Integer square root does not set the carry flag if there's a remainder. [fixed 0.203]

* There's a bug in the zero-padded display logic that causes single-digit values to remain after CLx. The value is cleared but the display is drawn incorrectly. [fixed 0.203]

* There is a disconcerting pause when a running program is halted (by pressing a key). The only visible indication is the keystroke animation takes a second or two to complete. Perhaps this won't be as obvious when the "running" has been implemented. [fixed 0.209]

* The SHOW operators cannot be stored in programmed sequences. [fixed 0.203]

* Floating point overflow/underflow are not handled gracefully. Unlike the real calculator, the internal floating-point range of the CP-16C is:

x >= 2.2250738585072014e308 && x <= 1.7976931348623158e+308

While we're talking about limits, the simulation's Epsilon is 2.2204460492503131e016.

These limits are imposed by the underlying IEEE 754 double-precision FPUs used by the target platforms. I am open to suggestions as to whether numbers of the these magnitudes are useful and if they are, how we might modify the I/O mechanism to accommodate them.

* CLEAR PREFIX does not show the full mantissa in FLOAT mode. [fixed 0.203]

* Digits not displayed in Scientific Format are rounded into the least significant displayed digit. The HP-16C simply truncates the least significant digits to fit the display.

* The HP-16Cs automatic floating-point display format switching logic is not implemented. Consequently, it is possible to produce values that display incorrectly when the display format is changed. [fixed 0.216]

* In program mode, identical successive lines are displayed incorrectly. The line number does not change. This will surely be as a result of overzealous display optimisation. [fixed 0.206]

* The operator bound to f FLOAT [.] (OpFloatSciFmt) has a flaw that causes it to be incorrectly stored in a programmed sequence. [fixed 0.206]

* Luiz Vieira pointed out that the SST instruction does not display the program line as in the real calculator. [fixed 0.206]

* While I was working on the program-line display for Luiz, I discovered that my SST handles line 000 incorrectly. [fixed 0.206]

* There is a nasty little bug that causes the internal "executing a program" flag to become sticky. [fixed 0.206]

* An attempt to execute a null program produces Error 4. [Fixed 0.208]

Version 0.202 - 9 October

Known Problems

* No change to the problems identified in 0.2.

* Paul Brogger noticed that the inactive key positions on the portrait grid trigger a key-press animation causing disconcerting visual effects. [fixed 0.208]

Changes

This version adds a portrait bitmap and now works on both desktop and PPC.

The value in X can now be copied to the clipboard (if it's not zero and it is visible in the current mode).

I'm experimenting with a minor (subtle) change to the lift handling logic. There is a problem with the original logic that becomes evident when RCL is used to terminate digit entry. The change has only been implemented in interactive mode. When running a program it still uses the flawed logic.


Version 0.203 - 15 October

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* The compiler's optimiser has broken the f STATUS flag display on the desktop version. The flags have been shifted left by one position. Since I've not been archiving the binaries I cannot confirm when this problem was introduced. [fixed 0.204]

* On the PPC, the exponent is not displayed correctly when it is the only element of the display that changes. [fixed 0.204]

* the second exponent digit entered is always displayed as 1 on the PPC. The correct value is placed in X and it will be displayed correctly after ENTER. One- and three-digit exponents display correctly. [fixed 0.205]

* I've broken the clipboard functions. They're only accessible while you are entering a value. They should be active whenever there's a value in the display. [fixed 0.206]

* I was not clever enough with CLEAR PREFIX (see below). It displays the mantissa when in PRGRAM mode which is a little disconcerting. [fixed 0.206]

Changes

Integer square root now sets and clears the carry flag correctly.

I've changed the definition of the show operators so they can be included in programmed sequences.

CLEAR PREFIX now shows the 10-digit mantissa when in FLOAT mode.

I've (partially) implemented the HP-16C's floating-point display formatting logic. The simulator will override the user's format selection if the value to be displayed cannot be represented in the requested format. The simulation is subtly different to the real calculator and I'm still trying to refine my logic to match that of the real device.


Version 0.204 - 16 October

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

Changes

I eliminated the C++ side-effect that was causing the incorrect f STATUS flags display. Sloppy coding on my part.

I fixed the (unicode-related) problem that caused the exponent not to be updated correctly.


Version 0.205 - 17 October

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* The XY conversion "fails" if the simulator is in unsigned integer mode. My implementation is "correct" in that it reciprocates the value regardless of mode. However, the real calculator does not--it behaves as documented on p.59 of the Owner's Handbook. [fixed 0.206]

Changes

I've implemented the XY conversions that occur on transition to/from floating point/integer mode.

I found and fixed the unicode problem that was causing incorrect exponent display on the PPC.


Version 0.206 - 23 October

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* there remain some subtle and unqualified differences with the behaviour of the ISZ and DSZ operators in the integer modes. For most practical purposes, they behave satisfactorily.

* SST causes a fatal access violation when program memory is empty. (Thanks to Paul Brogger for finding this). [fixed 0.208]

Changes

I fixed the clipboard copy/cut problem. I was careless and re-used a variable name.

I altered the XY conversion code so that is behaves just like the real thing. This bothers me since it seems less than useful. I may make this a configurable option in a future version.

I fixed the comparison operator in the program line class. It was not considering the line number. This caused the display driver to incorrectly conclude that two successive lines containing the same instruction were the same.

I found a problem with the operator that sets scientific format floating-point mode. The problem was not evident in run mode but caused a problem when the operator was encoded as an instruction in a programmed sequence.

I stumbled across a couple of latent problems with my implementation of ISZ and DSZ. They now ignore the fractional component of a floating point value and they preserve the state of the carry and overflow flags.

We no longer insert an automagic RTN at the end of program memory if there's a GTO there.

I've now added the change to the lift logic that I introduced to interactive mode in version 0.202 into the program interpreter. This fixes an incompatibility that became evident when testing a complex program against the real calculator (see TEST 011021.001 in Verification.txt). After the change, the simulation and the calculator behave the same. I will do some more testing before I commit to the change.

I changed the Run Mode SST/BST implementation so that it shows the program line. This revealed a subtle behavioural difference that is caused by address zero, a label or both. I will sort this out before I release 206.

I identified and fixed the problem with my handling of line zero. I've regressed some of my test programs and the change seems to be benign.


Version 0.207 - 24 October

I've pushed this one out in a hurry. While I was looking at the div-by-zero code I noticed that it could cause the simulation to crash. I've fixed this and will release it so that the testers will not be inconvenienced.

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

Changes

I've fixed the divide-by-zero exceptions. The DIV and RMD operators now behave as expected.

The stack is now left in the correct state after divide-by-zero.


Version 0.208 - 29 October (2001)

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* The following calculation produces an incorrect result.

	223.1 <enter>
	2972 <+>
	3195.1 <->

	Should be zero. However it returns -4.547474-013. [fixed 0.209]

* CLEAR REG invalidates all storage registers. Attempts to RCL a storage register after the clear will produce Error 3. The HP-16C zeros all storage registers on CLEAR. As a work-arond, do g CLX STO F after you've cleared them. [fixed: 0.319]

* The display handling of EEX entry is broken when more than 7 digits are entered. The number you key in is accepted and will be displayed correctly when you press an entry-terminating key. [fixed 0.209]

* When keying in values for storage (registers) the STO key does not trigger display "reformat" like the real calculator.

* Holding down PREFIX does not hold the full digit display. [later: I have no idea what I meant by this. It appears to be fixed.]

* Using PREFIX after a FLOAT mode overflow shows some dross.

* The "G" flag is not set after a FLOAT mode overflow. [fixed: 0.222]

* Digit keys appear as their grid values in PRGM lines. Compare the display of CF 1:

	42,28,  1 (sim)
	43, 5,  1 (calc)

and x>y:

	   43  39 (sim)
	   43   3 (calc)

This means that the real calculator uses the face value of a digit key rather than its grid position. [fixed: 0.221]

* Insertion/deletion of the decimal point is not rendered correctly in the display. [fixed 0.209]

Changes

There are now stub implementations of the double integer operators. They have been bound to the correct keys but they are otherwise noops.

I've kludged together a fix for the bogus key animation on the portrait layout. Much of the keyboard handling code needs to be streamlined. However this hack will work until I review the code.

The SST program line display logic I added to 0.206 had a fatal flaw which was revealed if there were no stored instructions. I've removed that flaw and SST of an empty program is now benign.

While coding the above fix I noticed an unresolved COMPATCHECK on an attempt to execute a null program. I've corrected the behaviour to match that of the real device. We no longer generate Error 4.

Version 0.209 - 9 April (2004)

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* Passing a negative value to [WSIZE] results in Error 2. The operator should only complain if abs(X) is out of range. [fixed 0.210]

* The display of really large integers (0xffffffffffffffff for example) as an unsigned decimal value is incorrect: 18446744079565199475. [fixed 0.210]

Changes

I corrected what appeared to be an accumulation error in my FLOAT input parser. This appears to have been the cause of the arithmetic error I observed in 0.208.

While working on that I incorporated some experimental code that attempts to round out small errors in the displayed value of X. The "errors" remain in the actual register (and therefore will continue to accumulate).

I changed the cookie on f FLOAT D from SQRTMAXPOW2 to PI so I can play with the precision.

I've implemented the flashing "running" display that the 16C uses to tell you that it's executing a stored program. It looks cute but I doubt that you'll ever see it. (If you can cobble together something that takes a long time you might catch a glimpse. ;-)

I've shortened the delay that occurs when a stored program is executing and you press a key. (Note to self: it's controlled by a pre-processor constant that's passed to worker.cpp by the IDE).

I found (and fixed) a subtle defect in the comparator method of the UniVal (a mediating class that sits between a register and the display). This manifested as a display anomally when a decimal point was inserted/deleted in FLOAT mode.

Version 0.210 - 15 April

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* While working on the double divide I noticed a nasty side-effect of the register subtraction operator. This seems to arise from over-zealous use of pass-by-reference. It will probably be present in many of the Register operator handlers. I'll leave this to be investigated and fixed in a subsequent release.

* the code that renders individual display elements in the LCDpanel class should ideally be self-centering. It's not. It depended on an ill-conceived kludge in the GeoDisplay class' digit width method. I removed the kludge in 0.211 and tweaked the display geometry LUT values to compensate.

* I discovered that the real 16C allows RTN to be entered interactively. I explicitly disallow this. [fixed 0.211]

* CLEAR REG doesn't zero the index register. [fixed 0.211]

* The '.' doesn't work correctly when used out of its documented contexts. I need to explore *exactly* how it is used. For example, the BigNum program uses it as a NOOP after DSZ--useful if all you want is to decrement the index register. [partially fixed 0.211]

* there's a double multipy bug that is only evident with a (small) sub-set of operand values. The calculation (base 10):

  1 675 555 045 913 548 800
x 8 163 739 950 511 554 560
=   741 528 998 990 168 150 (x) msb
  3 272 434 125 478 297 600 (y) lsb

produces the following result in the simulator.

    741 528 997 089 399 322 (x) msb
 16 177 498 857 708 453 888 (y) lsb

[fixed 0.211]

* in PRGM mode anything that would result in Error 1 is range checked as the instruction is entered, not at runtime. As implemented, the simulation checks at runtime.

* while debugging a program concurrently on the calculator and the simulator, I observed a line 0 display (on the calculator) that looked like:

	.----------.
	|000-     F|
	|      prgm|
	`----------'

It turns out that the "F" signifies that there's a pending subroutine return. I can't find it documented but I've run some trials and I'm satisfied that is what it means. The simulator does not (yet) do this. [fixed 0.211]

* the simulator's call stack handling is only a pale imitation of the calculator's. It needs to be brought a lot closer to the real thing.

* calculating 3600 / 24 in base 10 sets oflow. It shouldn't. [fixed 0.211]

* The real calculator range checks numbers as you key them in. It will not accept a digit if that digit would cause the displayed number to exceed the current word size. In addition, when keying digits in signed decimal mode, a digit that would set the sign bit does so and the complement value is displayed as you key it in. Try:

	8 WSIZE
	DEC
	140 (or any number > 127)

The simulator only converts once you press ENTER. To fix this I need to look at either the input buffer display generator or the input buffer itself. I'm loathe to do the latter. It looks like my input buffer design introduces quite a few inconsistencies into the simulation.

* the PPC key bitmaps for the mid position are copies of the down position. I obviously cheated to get it working but I need to fix it (or do I)?

* while single stepping through a program, a GSB transfers control to the line after the target label. This is benign since the label is a noop however the behaviour is different to that of the real calculator which transfers control to the labelled line. [fixed 0.211]

* the value in X after an arithmetic overflow (G annunciator or flag 5) condition is not the same as the value on the real calculator. Try:

	8 WSIZE, UNSD, 127 ENTER 10 *

This is doubtless as a result of different algorithms (and it opens the door for some interesting forensics). Since overflow flags an undefined (un-representable) result, I won't call it a bug. I wonder if anyone ever found a way of exploiting overflow in a program and if they did whether they rely on the numeric result.

Changes

I reworked the [WSIZE] operator. The previous implementation was not an accurate simulation. All the tests I can think of now behave the same as the real 16C.

I implemented double multiplication. I took the easy way out and did it on top of the existing integer ops which meant that I didn't have to redo gobs of the ALU code. It's a little inefficient but it works!

Fuelled by the success of the double multiply, I tackled the double divide and remainder over the easter weekend. Success. It took longer than I expected and I ended up trying two different algorithms. I like this one so much that I might change the ALU code to use it.

I (re)fixed the problem with the decimal display of really large integers. The comments in my code suggest that I'd previously fixed the problem and tested the fix. I suspect there's a compiler problem here. The new code should be functionally the same as the code it replaced.


Version 0.211 - 27 April

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* Hugh Steers (MoHPC) observed that 0.0 / 0.0 produces (quiet) NaN. The real calculator barfs with Error 0. [partially fixed: 0.212]

Changes

I removed (commented out) a kludge I'd put in GeoDisplay::digitWidth(). It was poorly conceived and had an undesirable effect when given some display sizes. I've compensated by tweaking the geometry definitions in the LUT. The tweaks are not a long-term fix. I need to make the Geometry classes auto-centering.

I implemented a new portrait rendering that is compatible with both platforms and have retained the classic rendering for the desktop executable.

I added the index register to those cleared by CLEAR REG. The book doesn't explicitly state that index is cleared but my real 16C certainly clears it.

I changed the handling of the '.' when used in a program sequence while the simulation is in integer mode. Under these circumstances it is ignored which allows it to be used as a NOOP.

The "double multiply" bug I reported in 0.210 turned out to be a problem with the bit test operator which is used by the double multiply code. The same bug was present in the set and clr operators although they were not implicated in this instance. All three were fixed.

I modified the PgmLine class and the display logic so we can report a pending subroutine return just like the real thing. At the very least this will help me replicate the call-stack clearing logic.

I changed the definition of OpReturn and amended the implementation just enough to simulate the interactive use of the RTN operator. I've started an analysis of the operations and side-effects that clear the subroutine call stack. What I've found so far is written up in the commentary above OpReturn::doowop().

I revisited an earlier problem (as noted in code commentary) with the overflow flag within the ALU's adder. I've undone the "fix" I'd put in the code. This seems to work for a few trivial tests and it corrects a bug I observed in 0.210. However since I hadn't previously noted a test case against my "fix" I cannot be certain that it's really fixed. Sigh.

The overflow flag problem (above) prompted me to audit the simulation of the carry (C) and overflow (G) flags. I found the real problem--I am using the CHS handler internally in the display driver and I wasn't preserving the flag state before I called it. CHS was working correctly but the call had the side-effect of altering the arithmetic operators' flags. Every test case I can think of produces the same flag settings as the real calculator.

I changed the way I deal with Labels while a program is executing. The change causes the simulator to behave like the real thing while doing SST. Unfortunately it also means that we execute a NOOP whenever the PC encounters a label. I will probably revisit this.

Version 0.212 - 30 April

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* interactive GTO LABEL positions the PC one line before the target LABEL. [fixed: 0.213]

* the pending subroutine return flag is not cleared after an interactive RTN. [fixed: 0.213]

Changes

I hacked around the 0.0 / 0.0 problem that was reported in 0.211. As it stands I'm explicitly testing for a zero divisor. I'd like to add an indefinite result to the list of FP exceptions but I'm not sure what else that might break.

I disabled the (experimental) code that rounds the displayed value of FP results. I'm back to letting the real FPU results shine through. There are some folk over at MoHPC that are playing with the sim and I'd prefer not to be embarrassed by my naive rounding implementation.

The sequence:

223.1 ENTER
2972 +
3195 -
.1 -

Displays -9.095502-014 with the rounding code disabled (this is one of my test cases). Hugh Steer's case:

2 ENTER
.2 +
.2 +
.2 +
.2 +
.2 +
3 -

Displays 0.000000000 on version 2.011 (rounding code enabled) and 8.881784-016 on version 2.012 (rounding code disabled).

I amended the floating point add and subtract operators as suggested by Hugh Sreers. This change results in both of the above test cases leaving zero in X.

I added support for (desktop) key bindings. There are two maps: an internal default and a user-defined map which is loaded from vkey.map (if it exists) in the installation directory. I have not yet hidden the code that supports the keyboard from the PPC build so there will be no 0.212 for the PPC.

Version 0.213 - 1 May

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

Changes

I changed the ID for the logo bitmap in the about box definition (for the desktop variant). I missed it a couple of weeks ago when I rationalised the resource IDs.

The changes I made to OpGotoLabel::doowop() in 0.211 broke the interactive positioning function. It now checks the context in which it was called and adjusts the PC accordingly.

While testing the above change I noticed that the display logic was incorrectly caching the disposition of the pending subroutine return flag. I fixed the problem which was in the PgmLine::operator==().

Version 0.214 - 2 May

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* Giuseppe Marullo discovered that the the window is sized incorrectly on startup. [fixed: 0.215]

* He also observed that the mouse button-up handler can be broken by moving the mouse off the target while holding down the mouse button. [Fixed: 0.300]

* the icon has disappeared from the task-bar button. [fixed: 0.216]

Changes

Inspired by requests from visitors to the MoHPC, I've added a persistence mechanism to the UI classes. Changes users make to the configuration of the UI are now saved on exit and restored when the simulator is restarted.

I've added another UI option to the desktop variant: users can elect to turn off the windows decoration (title and menu bars) which gives the calculator a cleaner look. To compensate for the (possibly) hidden title bar I allow click-and-drag on any non-active portion of the rendering as a means of moving the window. The state of the decoration is persisted.

This version re-aligns the PPC variant with the desktop release. All changes that have been introduced sonce 0.209 have been incorporated in this version. The virtual key mapping code is explicitly excluded.

Version 0.215 - 3 May

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

Changes

I changed the appearance of the three rendering options on the view menu to "bullet" form. This will re-inforce that these options are mutually exclusive. On the PPC they remain checked (because the API doesn't support the bulleted form).

I fixed a bug in the UI persistence recovery code. I had made a stupid assumption and then failed to test all permutations of the UI rendering settings. Thanks to Giuseppe Marullo for discovering and reporting the problem.

Version 0.216 - 4 May

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

Changes

I have audited and corrected several inconsistencies in the floating-point display formatter. I think I now understand the rules that the real calculator uses when it overrides the user's preferred formatting.

While entering values to test the formatting I was reminded that [.] and BSP handling, while functional, were unlike the real calculator. I've done quite a bit of work to make it mimic the real thing and I've run out of ideas for testing it. I'll call it a night on these changes and allow any further anomalies to be wrung out as I use it.

When I created the naked look (in 0.214) I inadvertently removed the icon from the task-bar button. I've now put it back.

Version 0.217 - 7 May

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

Changes

I added a new class to allow me to conveniently control trace output in debug builds. The class has a minimal footprint in release builds.

I used the above class to reduce the verbosity of the trace output in the frequently called UI methods. It's once again easy to use trace output to track the behaviour of the RPNgine. While working on this I began to weigh the pros and cons of having a separate RPNgine state window.

I corrected a flaw in the Atom class's factory method. It was using a deprecated technique for accessing a Key class instance's human-readable label. This has no impact on the production build.

I refined the program label search implementation. We now behave in a manner consistent with the real calculator. This opens the possibility of employing duplicate labels (which, I confess, was my motivation for doing it).

Version 0.218 - 11 May

Known Problems

* attempts to GTO a label when program memory is empty causes an access violation. [fixed: 0.219]

Changes

We now have the ability to save and load program and register store. Programs and registers are stored in separate files on the host platforms storage system: disk for the desktop platform; flash memory or a storage card on the Pocket PC. Loaded files *replace* the content of program and/or register store. Saved files allow frequently used programs and/or regsiters to be stashed for later use.

As I implemented the load/save mechanism I discovered that the file names I had been using were unworkable on the Pocket PC. I have redefined the nomenclature rules. This forced me to rename three of the simulator's state files. The new naming scheme should be compatible with both platforms from this point forward (or until Microsoft gratuitously change something).

I changed the location of where the control files are stored on the Pocket PC. The new location will allow the application to be installed on PPC removable storage.

Version 0.219 - 12 May

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* saving program or register store to file deletes the content of memory. [fixed: 0.220]

* typing text into the program file name edit control on the save dialog box does not update the reg file name control if the files are ganged. [fixed: 0.220]

Changes

Based on the principle that code is often broken by the last thing you changed, I revisited the label search routines. There I found an untested boundary condition which led to the access violation I observed in 0.218. I've corrected the label search implementation.

Version 0.220 - 13 May

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* it is possible, in program mode, to enter flag values > 5. This will lead to undefined behaviour at run time. [fixed: 0.326]

Changes

I found and corrected the problem that was causing memory to be cleared when it was saved to file. The bug had been there forever. I never noticed it because, until recently, the save methods only ever got called on simulation shutdown.

I've improved the ganging of the two edit controls on the save dialog box.

Version 0.221 - 17 May

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

Changes

I've worked out a mechanism to track the binding of the keys with digit face values. This allows me to correctly mimic the display of these keystrokes in program mode. I've tested every key sequence and they now display correctly.

Version 0.222 - 18 May

Changes

I've moved the handling and representation of floating-point overflow a little closer to that of the real calculator.

Version 0.300 - 29 May

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* the second key of two of the multi-key sequences have flawed animations. These keys will eventually need to be held down, as on the real calculator. Until I implement that function, the animation anomally will remain. The sequences are [MEM], [STATUS], [SST], [BST] and the SHOW functions. [fixed: 0.327]

* the context menus always align with the Pocket PC display which is not necessarily aligned with the calculator rendering. This will probably never be fixed for to do so would require re-implementing the windows menu handling sub-system. I suspect that PPC 2003 will not have this limitation however since I only have an old PPC I can really explore what's capable.

* The portrait rendering will not be usable on a PPC that has the display set for landscape orientation. I'm thinking about how I might deal with this. Until I come up with a solution, use it in landscape mode.

* On the desktop variant, rapid mouse clicks may be interpreted as a double-click. When this happens, the key you were clicking on will be missed. I'll dream up a fix for this very soon. [Fixed: 0.301]

* The copy/cut functions have been disabled. [Fixed: 0.302]

* The disposition of paste hasn't changed--I have yet to implement it. [Fixed: 0.303]

* The background erase flag looks to be set for some UI update functions. [Fixed: 0.313]

Changes

This release introduces a substantially re-written user interface. On the desktop, this should have little effect (although the key animations now work as I had originally planned). On the PPC we now have a fully functional LANDSCAPE mode which occupies the entire PPC screen. This is about as close as this is ever going to get to the real calculator. I've been using it in landscape mode for a few days now and I'm very happy with the result. I hope you will be too.

Version 0.301 - 29 May

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

Changes

Double-clicks are now ignored by the user interface--they serve no useful purpose. This allows rapid calculator key presses on both platforms.

Version 0.302 - 30 May

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

Changes

* I've placed many of the UI command handlers back into the view class, where they belong (I'd moved them into the frame while I was rewriting the UI). I re-routed the command messages accordingly. I've tested every combination I can think of and everything seems to work.

* The above change allowed me to re-activate the copy/cut clipboard functions. Paste remains on the TODO list (because I'm not quite sure how to gracefully deal with the multiple data formats required by the different calculator modes).

* Now that the new display code is complete I've been able to remove some of my diagnostic probes.

Version 0.303 - 1 June

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* values pasted from the clipboard treat the '.' character as the radix point and the ',' (comma) as the digit group separator. This will be "fixed" as soon as the simulator allows you to swap the meaning of these two characters.

* clipboard paste disables stack lift. [Fixed: 0.304]

Changes

I've implemented paste from the clipboard. The function is only active if the clipboard contains character data. The content of the clipboard is interpreted according to the current radix or floating-point mode. The micro-interpreter that handles conversion of the clipboard halts when the first nonsense character is encountered.

In the interests of utility I have not made the interpreter overly restrictive. This allows calculations to be conveniently performed on values copied from other applications. If the value is completely bogus it will be interpreted as zero. For example, the word "feed" is meaningful only in hex mode. If you try really hard you will be able to paste nonsense values.

The pasted value behaves exactly as if it had been recalled from a storage register (as described on p.66 of the Owner's Handbook). While on the subject of the clipboard and defined behaviour, the cut function is simply copy followed by CLx. This intentionally leaves lift disabled.

Version 0.304 - 1 June

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* the bit set, clear and test operators are not correctly range-checked. [Fixed: 0.305]

* WSIZE [1] introduces subtle (and unquantified) aberrant behaviour. [Fixed: 0.305]

Changes

I corrected the code reuse goof that caused paste to leave lift disabled. Ironically I reused the code so that behaviour would be consistent. I should have paid more attention to what I was reusing.

Version 0.305 - 3 June

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* The operators RCL (i), ISZ and DSZ do not (yet) check the validity of the index register in floating point mode.

Changes

I fixed the range-check on the bit set, clear and test operators.

I toned down the over-enthusiastic range checking on the WSIZE operator. This had a serious side-effect iff WSIZE was set to 1 (yeah, a boundary condition).

I've greatly improved the simulation of storage register memory. This portion of the code is almost finished. All that remains is the program/storage partition simulation and implementation of the MEM operator.

Floating point values recalled from storage registers are now checked for validity and Error 6 is raised if they're not.

Version 0.310 - 5 June

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* programmed digits are not "sensitive" to the current integer base. [Fixed: 0.311]

Changes

I've implemented a bitmap loader that can deal with formats other than BMP. This has enabled me to use compressed images for the classic view thereby reducing the executable file size by over 50%. As a comparison, the desktop variant of release 0.305 was 1,974,272 bytes. This release is a relatively meagre 856,064 bytes. This easily meets my (secondary) goal of having the simulator and its support files fit on a floppy disk.

The classic view now has the back-panel "cheat sheet". I'll add this to the other two views at some point in the (not-too-distant) future.

Version 0.311 - 7 June

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

Changes

I fixed the base-sensitivity of digits in program sequences.

I discovered two undocumented key sequences: 42 31 and 42 32. They are bound to RCL (i) (45 31) and RCL I (45 32) on my reference calculator. I added these bindings to the mapping table. I had to derive two new operator classes because in PRGM mode these keys are displayed as if you'd keyed RCL (i) and RCL I. Effectively the undocumented sequences are aliases. The new classes simply clone their base classes and the clones are inserted into the factory's map.

Version 0.312 - 9 June

Changes

I've created a little widget that is used to push the landscape view down on the PPC. In its current form it displays as a little button in the upper-left of the view. Over the next couple of updates I'll make it movable and allow it to display an icon.

The new widget allowed me to remove the kludgy code that was detecting a tap on the logo. The logo will be used to display the cheat sheet in all renderings on both platforms. Of course I have to create the cheat sheets for landscape and portrait before they will be available.

Version 0.313 - 10 June

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

Changes

The new UI widget can now be repositioned. It will snap to the corner closest to where you stop dragging it. The position will be remembered and restored when you restart the sim.

I've removed the temporary logo code and put the logo geometry into the rendering geometry class. I added an accessor to that class.

I created temporary flip-side bitmaps for the portrait and landscape views. I used these to test the flip function in all rendering on both platforms. I had to make a minor change to CalcFace::updateView() to accommodate the flip.

I addressed the (minor) cosmetic problem with background erasure that I introduced with the new UI code in 0.300.

I further optimised the renderer--mainly to accommodate dragging the hider widget across the simulated LCD. If the invalid region is less than the LCD panel area, only the invalid portion is updated.

Version 0.314 - 13 June

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* the ON key doesn't correctly halt the execution of a running program. [Fixed: 0.315]

Changes

I've "wired" in the ON key. It is fully functional but I elected to start the sim with the calculator switched ON. This will change once I have a user preference mechanism in place.

I also implemented the ON/- reset function. I did this mainly as a proof of concept. Eventually I will implement all the ON-key functions. I decided to bend the simulation a little--apologies to the purists--because I could see no benefit in implementing the complex logic to support chorded button presses. The two-key ON functions are accessed by turning the calculator "off" and then pressing the second of the two-key keys and then pressing ON. Thus to reset continuous memory, you would click/tap ON to turn the calculator off, click/tap [-] and then click/tap ON to complete the sequence. WARNING: if you do this you *will* reset the simulated CM.

I updated the stylised portrait and landscape renderings. They now include a proper ON key and legends for X-I and X-(i).

I have created a stub implementation of the user preferences property sheet with a single page. This is disabled in release builds. [Fixed: 0.316]

Version 0.315 - 13 June (unreleased)

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

Changes

I amended RPNgine::exeDispatcher() to correctly deal with an ON key interruption to program execution.

I put mediator wrappers around RPNcore::callStack. The callStack is now protected. I amended the operator code that accessed the stack directly so that it uses the mediator methods.

I corrected the behaviour of GTO [.] nnn WRT the call stack. The stack is now cleared as in the real calculator.

Version 0.316 - 15 June

Changes

I've replaced the ancient (hardwired) stub implementation of the run-time configuration mechanism with a new class and support code to initialise the simulator according to the configuration parameters. The values of the parameters persist across invocations.

I've wired the configuration class into the user preference property sheet. The behaviour of the ON button and the shift keys ([f] and [g]) can be selected via the property sheet (View -> Options...). The property sheet is now accessible in release builds.

I've abstracted the UI interface functions required to support the non-strict ON button functions so that the engine remains platform agnostic. There is a new abstract mediator class that the engine will "call back" when it needs these UI services.

If we ignore commentary, all this was achieved in less than 100 lines of code which is why this major gain in utility is issued as a "minor version" release.

Version 0.317 - 17 June

Changes

I've added the code to support swapping the digit group and radix point separators. You can do this in the traditional manner (./ON) or via the options property sheet. I've included it on the latter to make it simple for people who don't want to use the strictly compatible ON functions.

I added a new page to the property sheet. Its primary purpose is to hold an options reset button which has also been implemented. Pressing the button will return the options to their strictly compatible state.

I defeated the desktop Windows propensity for incorrectly sizing the property sheet and its pages. It is no accident that it now has a form similar to the PPC screen. I had intended that it have the current look from the outset but the people at Micro$oft had other ideas.

Version 0.318 - 23 June (unreleased)

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* [f]STATUS in PRGM mode does not reset the display to the current program step. [fixed: 0.319]

* the Index register is not persistent across invocations. [fixed: 0.319]

* DSZ and ISZ are not available interactively. [fixed: 0.319]

Changes

I discovered and fixed a problem with EEX on input. The real calculator allows you to skip the mantissa. If you do that it assumes a value of 1 (and the display updates appropriately). Now the sim does this too.

Version 0.319 - 1 July

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* the [f]MEM function does not work on the PPC *release* build. The debug build works on both the PPC emulator and on my iPAQ. [fixed: 0.320]

Changes

I've implemented the implicit RTN at the end of program memory and removed the kludge I had in place to simulate it (the kludge automagically inserted a RTN instruction if there wasn't one).

I've completed the implementation of the strictly compatible storage sub-system. When this is enabled (the default) you have 203 bytes of storage memory to be shared between program steps and registers.

I added user control of the fidelity of the program and register memory simulation. In strict mode it behaves like the real thing. In decoupled mode you have up to 999 program lines and 512 64-bit registers. The latter is how the simulation behaved up to this version.

I've implemented the "Status of Memory Allocation" operator ([f]MEM) as described on p.65 of the Owner's Handbook. It behaves as documented if memory fidelity is strictly compatible. If the memory simulation is set to decoupled, [f]MEM shows how many program steps and registers remain.

I rewrote RPNgine::setInpMode() and moved the program line display code into  RPNgine::refreshPanel() which makes the latter more useful.

I fixed a bug in the error dispatcher. It was always resetting the active dispatcher to the run dispatcher which was a little disconcerting if you were in program mode. It now selects either the program or run dispatcher depending on what you were doing.

I changed the implementation of the STATUS operator. The pause and display refresh is now the responsiblility of its helper function. I'm not sure why this was different to the other operators that flip the display. I suspect I did this one first and then changed my thinking. The changed code resets the program mode display correctly.

I can't believe that I wasn't persisting the index register! I even had commentary in the code that claimed that I was. I just checked all previous versions of the RPNgine code in CVS and it's true. Index has never been persisted. It is as of 0x0104.

I bumped the library version to 0x0104. This accommodates persistance of the expanded configuration control structure (0x0103) and the index register (0x0104).

I enabled DSZ and ISZ for interactive use. I'd never tried them on the real calculator and had assumed they were only usable in program mode. While testing the behaviour of my reference 16C I realised that they behave exactly as advertised--which may lead to surprises when the PC gets changed unexpectedly.

Version 0.320 - 2 July

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* access violation occurs after the configuration reset button is pressed (on the main options property page). Thanks to Gordon Dyer for pointing this out. [fixed: 0.321]

Changes

I fixed the problem that was preventing [f]MEM from updating the display on the release PPC build. I tracked it to a mistake I'd made in calculating the length of the intermediate display buffer. I cannot see (at the C++ level) why the code did not work. We were not overrunning the end of the buffer. I can't be bothered looking at the machine code to see what was really happening.

I implemented the visible behaviour of ON/A and ON/D. It produces the "correct" numerical result in integer mode. In floating point mode the bit twiddling is correct but it produces a different numerical result due to the difference in floating point representations.

Version 0.321 - 4 July

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* Recalling the Last X register (using LSTx) behaves incorrectly: it always lifts the stack. [fixed: 0.322]

Changes

I corrected the erroneous method template that was causing the stack corruption that led to the access violation in 0.320. Only a Micro$oft product would allow such a basic coding error to pass unnoticed through the compilation chain. In my defense, the problem only manifested itself in the release compilation. This is why it escaped the lab undetected (and why it took me four hours to locate the problem).

Version 0.322 - 4 August

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* There is a subtle flaw in the ON button handling that becomes manifest if the calculator is off and the button compatibility is changed to non-strict. This was detected by two different users within a couple of days of each other. Thanks David (Brown) and Gordon (Dyer). [fixed: 0.323]

Changes

I've started work on improving the fidelity of the flags simulation. I've put the UI elements for user selection of flag behaviour into place. The UI will remain disabled in the release binaries until I finish this work.

While working on one of my (very old) programs I noticed that LSTx was behaving incorrectly. I curtailed the work on the flags, fixed the LSTx problem and built release binaries for both platforms.

Version 0.323 - 21 August

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* The simulator shuts down when you try to invert 0.0. [fixed: 0.324]

* The digit separator setting is sticky when you use ON [.] to toggle it but its state is neither reflected nor changeable by the options property page. [fixed: 0.324]

Changes

I fixed the ON button flaw that was discovered in 0.322.

I've built a binary for the Hitachi SH3 processor. This makes the simulator available on PPCs that are powered by the SH3 processor (notably the HP Jornada 548). The source code compiled cleanly without change.

The feedback I've had from the testers--David Brown and Gordon Dyer--has been positive. Until I hear otherwise, I will include an SH3 variant in all future releases. Note however that I cannot test that platform myself so YMMV. As always, I depend on your feedback.

Version 0.324 - 29 August

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* the sequence CLEAR REG (42 34) is not programmable (it is on the real calculator).

Changes

For the desktop build I've added the logic necessary to support window position preservation. If the user selects that option on the main property page, the simulation will open at the same position on the desktop as it had when it was last shut down.

I'm now catching a div-by-zero exception in OpInvert::doowop() which stops the sim from aborting when zero is passed to 1/X.

I've changed the handling of the digit separator toggle within the options property sheet. DDX requires that check-boxes be mapped to an int (BOOL) whereas I was using bool. The typeclash was hidden by a lame macro I use to keep the IDE's ClassWizard from barfing. I've changed the mapped variable to BOOL and explicitly type-convert as required.

Version 0.325 - unreleased

Changes

I've added a context menu to hold some common constants. These are simply data entry shortcuts. The constant is placed in X exactly as if you had recalled it from a register (or pasted it from the clipboard).

I've experimentally changed the ordering of the context menu sub-menus so that edit--possibly the most common selection--is on top.

Version 0.326 - 9 September 2004

Changes

The prototype modifier-out-of-range handling is complete. I'm using the flag operators to test the concept. If you key in an invalid flag number you will now get an Error 1 just like the real thing.

Version 0.327 - 27 March 2005

Changes

I've fixed up the behaviour of the "delayed-display" functions: [MEM], [STATUS], [SST], [BST] and the [SHOW] functions. They respond correctly to a click-and-hold and the button-press animation is now synchronous. I have yet to implement the kayboard mapping of this behaviour.

The display hold time defaults to a value that is close to the real calculator's (1100 ms). It can be changed from the options property page (from 0 to 5 seconds in 100 ms increments). The value you select will be persisted.

Version 0.328 - 27 March 2005

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* the SHOW operators do not reset scrolling. They do on the real calculator.

* the bit test operator (B?) fails mysteriously. I don't know why I've never noticed this [fixed: 0.329].

Changes

Fixed the keyboard mapping of the delayed-display functions. Keep in mind that the keyboard mappings do not trigger button-press animations. I may revise this one day.

NOTE: there is no PPC release of this version (because the PPC doesn't contain any keyboard-handling code).

Version 0.329 - 20 December 2005

Changes

The last release for 2005.

I fixed the coding error that was causing the bit test operator to fail.

On the cosmetic side, I've retired the placeholder images for the landscape and portrait cheat sheets and added the actual renderings. I may tweak them a bit but I'm reasonably happy with the current look.

Version 0.330 - 25 January 2006 (unreleased)

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* while playing with a program, written by Valentin Albillo to solve the Towers of Hanoi, I discovered that I've not implemented indirect GSB and GTO. They are documented on p.88 of the Owner's Handbook.

Changes

I corrected a long-standing bug in the NOT operator's code. The simulation uses the compiler's bit complement operator but I had not provided an implementation in the register class. Consequently the bits were being complemented to the width of a machine word and the "overflow" was hidden by the display routine. It was revealed when:

setup: 0-08-1000
[0] NOT [2] [/] ==> 0xFF C (should be 0x7F C)
0xFF ENTER [2] [/] ==> 0x7F C

1's and 2's complement behave as expected.

Version 0.331 - 2 May 2006

Known Problems

Some of the previously identified problems, as noted below (under Changes), were fixed in this build. Those not explicitly mentioned remain.

* Terry Perdue wrote to tell me of a bug he had found when using FLOAT in a program. Doing so consistently produced Error 1. I am able to reproduce the problem. [fixed: 0.332]

Changes

The new BCD code that I've been working on will be compiled and included in debug builds from this version forwards. It will not be available in release builds until it's much more stable. When I turn it on you'll see a note to that effect in this file and a check-box to select IEEE 754 will appear on the Options property pages.

I've implemented the indirect GSB and GTO functions. I keyed in Valentin's program to test GTO. Once I found and fixed the typographic error in the code listing it ran and produced the correct results.

Version 0.332 - 8 May 2006

Changes

I corrected the errant behaviour of the FLOAT operator described (in 0.331) above. I had not specified an overide for OpFloat::complete(). The default (base class) behaviour turned out to not be very useful when running a program.
