Removed some Palm-related junk.

android/app/src/main/java/com/thomasokken/free42/Free42Activity.java

@@ -1744,12 +1744,10 @@ private static class CoreSettings {
      * 'bits' is a pointer to a 1 bpp (monochrome) bitmap. The bits within a byte
      * are laid out with left corresponding to least significant, right
      * corresponding to most significant; this corresponds to the convention for
-     * X11 images, but it is the reverse of the convention for MacOS and its
-     * derivatives (Microsoft Windows and PalmOS).
+     * X11 images, but it is the reverse of the convention for MacOS and Windows.
      * The bytes are laid out sequentially, that is, bits[0] is at the top
      * left corner, bits[1] is to the right of bits[0], bits[2] is to the right of
-     * bits[1], and so on; this corresponds to X11, MacOS, Windows, and PalmOS
-     * usage.
+     * bits[1], and so on; this corresponds to X11, MacOS, and Windows usage.
      * 'bytesperline' is the number of bytes per line of the bitmap; this means
      * that the bits just below bits[0] are at bits[bytesperline].
      * 'x', 'y', 'width', and 'height' define the part of the bitmap that needs to

common/core_commands3.cc

@@ -633,11 +633,10 @@ int docmd_dim(arg_struct *arg) {
 
 int docmd_dot(arg_struct *arg) {
     /* TODO: look for range errors in intermediate results.
-     * Right now, 1e300+1e300i DOT 1e300-1e300i returns NaN
-     * on the Palm, because two infinities of opposite signs
-     * are added. (Why no NaN on the PC? Weird stuff: doing
-     * "d = xre * yre + xim * yim" yields a different result
-     * than "d = xre * yre ; d += xim * yim". Go figure.)
+     * Right now, 1e6000+1e6000i DOT 1e6000-1e6000i returns NaN
+     * in the Decimal build, because two infinities of opposite
+     * signs are added. 1e300+1e300i DOT 1e300-1e300i probably
+     * does the same in the Binary build.
      */
     vartype *v;
     if (reg_x->type == TYPE_STRING || reg_y->type == TYPE_STRING)

common/core_display.cc

@@ -43,7 +43,7 @@
 #endif
 
 
-static char bigchars[130][5] =
+static const char bigchars[130][5] =
     {
         { 0x08, 0x08, 0x2a, 0x08, 0x08 },
         { 0x22, 0x14, 0x08, 0x14, 0x22 },
@@ -177,7 +177,7 @@ static char bigchars[130][5] =
         { 0x04, 0x08, 0x70, 0x08, 0x04 }
     };
 
-static char smallchars[329] =
+static const char smallchars[329] =
     {
         0x00, 0x00, 0x00,
         0x5c,
@@ -844,16 +844,11 @@ void draw_char(int x, int y, char c) {
     mark_dirty(Y, X, Y + 8, X + 5);
 }
 
-void get_char(char *bits, char c) {
-    /* TODO - it should be possible to simply return bigchars[c],
-     * but that crashes on the Palm. Looks like a compiler bug.
-     */
-    int i;
+const char *get_char(char c) {
     unsigned char uc = (unsigned char) c;
     if (uc >= 130)
         uc -= 128;
-    for (i = 0; i < 5; i++)
-        bits[i] = bigchars[uc][i];
+    return bigchars[uc];
 }
 
 void draw_string(int x, int y, const char *s, int length) {

common/core_display.h

@@ -34,7 +34,7 @@ void fly_goose();
 void squeak();
 void tone(int n);
 void draw_char(int x, int y, char c);
-void get_char(char *bits, char c);
+const char *get_char(char c);
 void draw_string(int x, int y, const char *s, int length);
 void clear_row(int row);
 

common/core_globals.cc

@@ -2767,14 +2767,8 @@ bool load_state(int4 ver) {
 
     if (ver < 4) {
         /* Before state file version 4, I used to save the BCD table in the
-         * state file. As of state file version 4, the Unix and Windows
-         * versions don't do that any more because they don't need to
-         * (generating the table on startup is fast enough); the PalmOS version
-         * now persists the BCD table in a database, which is faster because it
-         * doesn't need to be loaded and saved each time the application is
-         * started and stopped.
-         * This code is to skip the saved BCD table in state versions up to
-         * and including version 3.
+         * state file. We don't use the BCD table any more, so all this code
+         * does is skip it.
          */
         int min_pow2, max_pow2;
         uint4 n1, n2, n3, n4, n;

common/core_helpers.cc

@@ -567,9 +567,8 @@ void print_text(const char *text, int length, int left_justified) {
     for (i = 0; i < 162; i++)
         bitmap[i] = 0;
     for (i = 0; i < bufptr; i++) {
-        char charbits[5];
         int j;
-        get_char(charbits, buf[i]);
+        const char *charbits = get_char(buf[i]);
         for (j = 0; j < 5; j++) {
             int x1 = i * 6 + j;
             int x2 = x1 + 1;

common/core_keydown.cc

@@ -609,17 +609,6 @@ void keydown_command_entry(int shift, int key) {
          * at the same time. When we're at length 0, we have to handle
          * both possibilities and pick the right one.
          */
-
-        /* On the Palm, we accept 0-9 as alphanumeric in this case;
-         * if the user wants numeric, it's easy enough to just tap
-         * the appropriate keys on the virtual keyboard.
-         * On PCs, on the other hand, we want the number keys to
-         * behave like they always do, so you can enter LBL 00 without
-         * having to use the virtual keyboard. If an alpha LBL with
-         * a name starting with '0'-'9' is desired, the user will have
-         * to use the usual trick: activate a submenu of ALPHA by
-         * pressing any menu key (F1-F6), and then typing the number.
-         */
         if ((mode_commandmenu == MENU_ALPHA1 || mode_commandmenu == MENU_ALPHA2)
                 && key >= 1024 + '0' && key <= 1024 + '9')
             switch (key - 1024) {

common/core_main.cc

@@ -552,9 +552,9 @@ int core_powercycle() {
          * OFF on the keyboard returns code 70 and stops program execution; and
          * when the auto-poweroff timeout expires, code 70 is returned but
          * program execution continues.
-         * Since Free42 can be shut down in ways the HP-42S can't (exiting the
-         * application, or turning off power on a Palm), I have to fake it a
-         * bit; I put 70 in X as if the user had done OFF twice on a real 42S.
+         * Since Free42 can be shut down in a way the HP-42S can't, by exiting
+         * the application, I have to fake it a bit; I put 70 in X as if the
+         * user had done OFF twice on a real 42S.
          */
         vartype *seventy = new_real(70);
         if (seventy != NULL) {

common/core_main.h

@@ -82,10 +82,9 @@ int core_menu();
  * The shell uses this function to check if the core is in "alpha" mode (i.e.
  * the ALPHA menu or any of its submenus is active). This affects how events
  * from the keyboard (the real PC keyboard, not the on-screen one emulated by
- * Free42) or PalmOS Graffiti device are handled: in alpha mode, printable
- * ASCII characters are sent straight to the core; outside alpha mode, all
- * key events are translated sequences of HP-42S key events according to the
- * keymap file.
+ * Free42) are handled: in alpha mode, printable ASCII characters are sent
+ * straight to the core; outside alpha mode, all key events are translated
+ * sequences of HP-42S key events according to the keymap file.
  */
 int core_alpha_menu();
 

common/core_math2.cc

@@ -310,10 +310,7 @@ int math_gamma(phloat phx, phloat *phgamma) {
 /* copied from the GNU C Library, version 2.2.5, and modified */
 /* to conform to the coding conventions used in Free42.       */
 /* Dependencies on the IEEE-754 format have been removed.     */
-/* It is included here because on PalmOS, MathLib does        */
-/* not provide gamma at all, and on Linux, I'm not sure       */
-/* how it works (the lack of documentation does not help!).   */
-/* Better safe than sorry, and it's not that big anyway.      */
+/* It is included here because on it is missing in VC++ 2008. */
 /**************************************************************/
 
 /*
@@ -394,17 +391,7 @@ int math_gamma(phloat phx, phloat *phgamma) {
  *
  */
 
-/* NOTE (ThO): if the 'const' in this code is not commented out, the
- * PalmOS build of Free42 malfunctions in GAMMA (wrong results,
- * memory access weirdness). This isn't the first time I've noticed
- * m68k-palmos-gcc acting weird in the presence of const globals.
- * It probably puts them in the wrong section or something. I should debug
- * this, and add section attributes where needed, but since Free42 doesn't
- * use that much global space anyway, and the variables below are only
- * something like 500 bytes altogether, I just work around the issue by
- * putting them in the read/write global area.
- */
-static /*const*/ double
+static const double
 half=  5.00000000000000000000e-01, /* 0x3FE00000, 0x00000000 */
 one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
 pi  =  3.14159265358979311600e+00, /* 0x400921FB, 0x54442D18 */

common/core_variables.cc

@@ -24,12 +24,7 @@
 
 
 // We cache vartype_real, vartype_complex, and vartype_string instances, to
-// cut down on the malloc/free overhead. This overhead is particularly painful
-// in the PalmOS ARM version, because it has to do an ARM-to-68K call for each
-// malloc or free, and that's a performance killer when running programs.
-// TODO: Pools may cause memory fragmentation. To fix, override malloc() and
-// realloc() with versions that empty the pools and retry before returning
-// NULL.
+// cut down on the malloc/free overhead.
 
 typedef struct pool_real {
     vartype_real r;

common/shell.h

@@ -28,12 +28,10 @@
  * 'bits' is a pointer to a 1 bpp (monochrome) bitmap. The bits within a byte
  * are laid out with left corresponding to least significant, right
  * corresponding to most significant; this corresponds to the convention for
- * X11 images, but it is the reverse of the convention for MacOS and its
- * derivatives (Microsoft Windows and PalmOS).
+ * X11 images, but it is the reverse of the convention for MacOS and Windows.
  * The bytes are laid out sequentially, that is, bits[0] is at the top
  * left corner, bits[1] is to the right of bits[0], bits[2] is to the right of
- * bits[1], and so on; this corresponds to X11, MacOS, Windows, and PalmOS
- * usage.
+ * bits[1], and so on; this corresponds to X11, MacOS, and Windows usage.
  * 'bytesperline' is the number of bytes per line of the bitmap; this means
  * that the bits just below bits[0] are at bits[bytesperline].
  * 'x', 'y', 'width', and 'height' define the part of the bitmap that needs to