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.

Pressing any key during PSE should halt program execution and execute the
keystroke. This could be a bit tricky to implement because the current PSE
implementation simply freezes the UI for 1 second; proper keyboard handling
will require a whole new core state (similar to the GETKEY state).

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.
