There has been a report of program indices going out of sync -- see
http://groups.google.com/group/iphone42s/browse_thread/thread/a5c821e46376ac65
http://groups.google.com/group/iphone42s/browse_thread/thread/c7615637140bbda0
http://groups.google.com/group/iphone42s/browse_thread/thread/fadc61ed7b07f436

Build Mac version compatible with 10.4 and perhaps also 10.3.9, if doable
without rewriting too much.

In the iPhone versions (iphone and iphone2), add functions to query Location
Services (GPS) and the accelerometer.
This functionality should be optional, for perfect 42S compatibility.

All versions: implement the Time Module functions, as far as possible.
This functionality should be optional, for perfect 42S compatibility.

The Mac Dashboard version is ugly; how hard would it be to replace its skin
with something nicer?

Create Android version (this should be possible now with the recently released
Native Development Kit).

The whole flag 11 thing seems flaky on several platforms.
Also, what about  LBL "NASTY"  SF 11  OFF  GTO "NASTY"  ?
I think we should have some kind of check for the case where the calc does OFF
without ever having handled any kind of user events since power-on; it should
either refuse to power off, or clear flag 11 before powering off, or do some
kind of user interaction to give the user a chance to break this potentially
inescapable cycle.

Add clock/timer functions for all platforms. Model them after the HP-41 time
module (with CX extensions), if possible -- that would also provide an obvious
way of making it source code compatible with the 41.

Add accelerometer, location services, and heading (compass) support for the
iPhone & iPod touch.

The ALPHA register should be larger when Byron's 4-line mode is active.
Also, AVIEW should be modified to fully support the 4-line display.

Add keyboard click option for the Pocket PC version.

Add a feature for importing and exporting variables from and to CSV files.

The "print" annunciator should be more noticeable -- make it linger a bit.

On the Z22, the print-out window is not scrolled all the way to the bottom
initially. On the m100, it is. First guess: I'm calculating the scroll bar
position wrong, by assuming that the Z22 has a 320x320 screen -- yes, the Z22
does have the high-density feature set, but it does not have a high-density
screen. Been there before with the high-density skins showing up in the Skin
menu; probably need the same kind of fix here.
Update: on the T|E2, output is not scrolled all the way to the bottom either!

PalmOS version: the application icon does not seem to have a proper mask.
When the Z22's launcher highlights it, the whole icon disappears.
Noticed this with Free42, Life, Filez...

PC keyboard mapping: currently, all PC keyboard keys that generate printable
ASCII characters generate those characters when ALPHA mode is active. This is
nice because it makes it easy to enter text, but it has the undesirable side
effect of overriding some other mappings that would be useful in ALPHA mode,
e.g. '\' for R/S, 'm' for ASTO, etc. It would be nice to have a way to be able
to use the normal mappings in ALPHA mode as well, perhaps by using a special
modifier, e.g. <Win>-\ for R/S, <Win>-m for ASTO, etc., where <Win> is the
Windows key, or Meta, or whatever is available.

On the real HP-42S and Emu42, when running a program using XEQ and picking it
from the program catalog, the menu stays up while the program runs (or rather,
the display is not repainted). In Free42, the display is repainted before
program execution begins. Purely cosmetic perhaps, but still a bug.

Make '\' act as R/S even in ALPHA mode. R/S is important, and the backslash is
not, in the HP-42S part of the universe, anyway.

Just a thought: optionally treat XEQ overflowing the RTN stack as an error (not
just when a return-to-solve or return-to-integ is lost, but in *all* cases).

PalmOS version: add explanation to README.txt about skins -- why they won't
work off an SD card, how to install them properly, yada yada yada.

Decimal version: SQRT(2) returns 1.414213562373095048801688, should be
1.414213562373095048801689. Apparently, BCDFloat::sqrt() simply stops after
computing P digits of the result, rather than computing one extra and then
rounding (only needed if the most significant base-10000 digit of the result is
between 1 and 9, of course).
I haven't investigated yet if it is possible to fix this by simply going
through the digit loop one extra time -- it is possible that this will cause
problems if the precision in the temporaries is exhausted.
I should probably bring this to Hugh Steers' attention; if it can't be fixed
easily, then possible solutions will probably involve using the new
higher-precision BCDDouble type for temporaries; this also opens up the
possibility of using Newton's method, which might be faster than the 'long
division' algorithm.

SOLVE: detect more sign reversals (not just the ones where the sign reversal
brackets a domain error). This isn't strictly a bug, since it is mathematically
impossible to reliably tell poles from zeroes (the real HP-42S doesn't always
get it right either), but there is clearly some room for improvement.

GTK and Motif versions: /proc/acpi support for battery status checking.

PalmOS version: hardware keyboard mapping, using a keymap.txt file and skin-
specific mappings in the *.layout file, like the other Free42 versions.

Plain text program import/export; HP-41 ROM image import.

4 line display of the full stack (maybe just open a separate window for the 4
line display with Courier New font to keep it simple).

Display the full resolution of the calculator, decimal version 25 digits (again
in the extra window with 4 line stack) -- maybe also support FIX/SCI/ENG with
arguments up to 24? (This should of course be optional, for perfect 42S
compatibility.)

Provide a separate window to display the data memory contents.

Provide a separate window to list the program memory.
