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.
Go back.