main index FIRST OF ALL, did you read all of my P900 notes?

Here I show my P900 C++ UIQ SDK for Mac OS X solution; I still don't have a complete solution like the Linux one but the notes in this page will allow you to create a .SIS file starting from scratch (sources). Also this work must be considered "under GNU GPL license".

Please note: while I expect all this stuff running on every Mac OS X "Tiger" release, I cannot make any warranty except you'll lose some time to read this page and (maybe) test some things. In this page I only describe the steps that I did to get something running on an Apple machine PowerPC-based sporting Mac OS X "Tiger" 10.4.2 and following releases.


Phase 1: install gcc cross-compiler for ARM processors

First, fetch the gcc 3.0/Psion-98-r2 (Symbian build 9/546) source package (the gcc-3[1].0-psion-98r2-9-src.tar.gz file, 36Mb) from the Symbian GCC Improvement project site. Uncompress it somewhere, and enter its src directory.

Edit the gdb/configure.host file and add this line under the "case ${host} in..." statement (beware! not the case-host-cpu!):
powerpc-apple-darwin*) gdb_host=macos ;;

Now select the gcc 3.3 from Mac OS X "Tiger" stock compilers (you can't use the default gcc 4.0 because you would get errors instead of warnings when compiling coff-arm.c and some other file):
sudo gcc_select 3.3

Choose a "prefix" for installing gcc - I suggest $HOME but you may choose, for example, /sw (if you have Fink installed) or /opt/local (if you have DarwinPorts installed):
./configure --prefix=/sw --target=arm-epoc-pe

Now, the setmode stock function doesn't behave as gcc sources expect (and, in Posix-like systems, doesn't actually do anything). Enter the diff directory and add this line soon after the #include commands at the beginning of cmp.c and diff.c and io.c:
#undef HAVE_SETMODE

Edit the mmap-sup.c in the mmalloc directory and add at the very beginning this line (because of the caddr_t type definition):
#include <sys/types.h>

Well, gdb would require some dirty hacking (not just a missing xm.h source and some SERPORT1 "unixcomm" definitions), so have a look at the main Makefile and erase all gdb targets and dependencies (gdb-install, all-gdb, gdb-check...). Don't care about it: you cannot run/debug ARM compiled code on a PowerPC-based machine using only the gdb.

Also dlltool source needs a small patch: you have to change the backslash in the TMP_FORMAT definition of dlltool.c in the binutils directory:
#define TMP_FORMAT "%s/d%d%c%s" /* path, letter, pid, tail */
and define a TMP environment variable specifying a temporary directory. I prefer to add an export TEMP=/tmp in my startup (login) scripts (I used .profile in my home directory), but someone may want to hardwire it in the code because it's a weird thing having only dlltool complaining about "where do I have to put my temporary files?".

Now start make to compile everything. After lots of warnings and compilation steps, it will give out some errors in the arm-epoc-pe subdirectories.

Enter arm-epoc-pe subdirectory and copy there the install-sh of the parent directory (copy it also in the fpu subdirectory) and link in the same arm-epoc-pe subdirectory the configure.host of the newlib child directory. It seems that there was some confusion about naming directories and selecting relative paths or - worse - missing some files.

Don't panic: just return to the main src directory, issue make and wait for next error. Then you will enter again the arm-epoc-pe directory and issue twice this roaring rain of make commands:
for a in `find . -type f | grep Makefile | grep -v Makefile.[ai] `; do pushd `dirname $a `; make; popd; done

Ignore errors, and then return in the main src directory and start make again. After some other work, it will fail.

Now, erase all-target-newlib and configure-target-newlib presence in the main Makefile and just restart make to continue compilation. It shouldn't show any other error up to its end, with the message "make[1]: Nothing to be done for `all'".

Cross your fingers and go with make install (d'oh! I backupped my entire /sw before installing this gcc in it). Note: if the chosen directory tree is not immediately available for writing, then you will need to use sudo make install to continue.

And... ta-daa! You should see finally your precious arm-epoc-pe-* executables in the /sw/bin directory (if you actually installed with --prefix=/sw like me; I don't like touching the real filesystem; i.e., I won't install anything with --prefix=/).

YAY! While I cannot guarantee anything about the above procedure, I can tell you that it was sufficient to get up a running gcc ARM cross-compiler under Mac OS X, good to compile some .APP P900 application programs using the same procedures described in my P900 SDK for Linux page. Work in progress!

Maybe someone will find a less difficult procedure to do. The one described above worked flawlessly on different releases of Mac OS X "Tiger".


Phase 2: the "helpers"

Now that we have the gcc targeted to ARM processor of the P900, we need the custom utilities (sometimes called "helpers"). I've experimented some small things, but I don't know how and when I'll continue hacking source.

A good starting point is Simon's page, targeted for Linux (and gcc 2.95). You do not need to start with sdk2unix 1.6a because this is still the "unpatched" version (maybe it will compile, but it will fail the make regtest test). Simply follow Simon's instructions (getting latest patched sources from Andreh's page) to compile at least the essentials.

In fact, following Simon's links, I found that makesis, bmconv, petran (and its included uidcrc) compile and pass the default tests, while genaif only needs to be changed (redefine its GETLONG and PUTLONG to convert from/to big-endian dwords). For example, replace the two #define lines with:

#define PUTLONG(X) PutLong((char*)&X,fpout)  /* fwrite(&X, sizeof(long)... */
#define GETLONG(X) GetLong((char*)&X,fpin)   /* fread(&X, sizeof(long)... */

int GetLong(char *x, FILE *fp)
{
  char buf[4];
  int i=fread(buf, 4, 1, fp);
  x[0]=buf[3]; x[1]=buf[2]; x[2]=buf[1]; x[3]=buf[0];
  return i;
}

int PutLong(char *buf, FILE *fp)
{
  char x[4];
  x[0]=buf[3]; x[1]=buf[2]; x[2]=buf[1]; x[3]=buf[0];
  return fwrite(x, 4, 1, fp);
}

You must also change these four lines in the uidcsum function in the genaif.c source (the original order was c[0] c[1] c[2] c[3]) because the CRC calculations must be done in "reversed" (big-endian) order of the PowerPC architecture:

      crc1 = docrc16_1(crc1, c[3]);
      crc2 = docrc16_1(crc2, c[2]);
      crc1 = docrc16_1(crc1, c[1]);
      crc2 = docrc16_1(crc2, c[0]);

The makesis utility will compile and pass the test without problems. If this does not happen, then either you have some unpatched makesis 2.0.0 source, or built it without the md5sum utility, or you are experimenting too much with gcc 3.x compilers. I just used gcc 4.0 (in stock with common Apple Mac OS X installs) and the md5sum found in the gcc arm-epoc-pe install described above, and it was all OK.

The rcomp utility would need a lot of work because of its ugly problems: it needs gcc 2.x (not available from standard Mac OS X "Tiger" installs), it needs lot of patches, etc. In my P900 SDK for Linux page and in the P900 Zx Spectrum emulator I had already shown programming examples that do not require .RSC resource files: any program will be happy when compiled for only English language with an .RSC file containing:
0000000: 6b 4a 1f 10 00 00 00 00 89 3f 06 00 df 3c e3 fd
0000010: 01 18 00 00 04 00 00 00 01 90 f8 63 00 00 00 00
0000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000030: 00 00 00 00 14 00 1c 00 1c 00 34 00

Yeah, you read it right: if you want to create the standard .RSC file from the four hex lines above, you just need to give them as input file to xxd as in this example:
xxd -r inputfile.hex.txt >file.rsc

(the xxd utility comes in stock Mac OS X Tiger installs). The minimal resource file is actually of 60 bytes only and does only define "all sections empty".

The bmconv utility also compiles without problems (use make and then make regtest to do all; the bmconv executable remains in its src directory). As stated above, it seems that compiling with gcc 4 instead of gcc 3.x you will get faster and smaller executables.

Yeah, but there's a small bug inside bmconv 1.1.0-2: it's simply too Stakhanovist... :-) it runs well with 12-bit-per-pixel bitmaps (as the ones used in the P900) but distorts the 8-bit and 1-bit bitmaps (the ones I use in my P900 SDK for Linux application icon examples). The bug is in the BitmapCompiler::Write16 function of the pbmcomp.cpp source file: you need only to not to change the order of the bytes. That is, if you patch the two lines of the Write16 function code in this mode:
b[1] = (unsigned char)((v >> 0) & 0xff);
b[0] = (unsigned char)((v >> 8) & 0xff);
then your 8-bit and 1-bit .BMP bitmap files will work again. Yes, this patch will make the bmconv work on 8-bit and 1-bit and not work anymore on 12-bit and 16-bit bitmaps (the make regtest won't pass any test). I did this because I prefer the 8-bit (for color icon) and 1-bit (for bitmask). Debugging this issue will require a lot more time than just patching the two lines above.

Also petran will compile without problems. If you see some errors in inc/h_utl.h or some host/ or pefile/ source, then you are trying to compile the "unpatched" version coming from some old sdk2unix version instead of Andreh's one. The make regtest will report "all OK" only on the latter.

Well, you shouldn't need any extra stuff (except the tools in the P900 UIQ SDK for Linux: the bmpinfo program, the rules include for your makefiles, etc).

My bmpinfo program, given a number of .BMP files, outputs the correct parameters suitable for bmconv utility (slash, "c" if color or nothing if b/w, number of bits, filename - everything without spaces). You can get its sources here.

Note: the makesis sources described above should be a little hacked because makesis will normally leave you some harmless temporary file X:\MKS0\filename.txt after successful creation of a .SIS archive with license text file appended. Just convert those DOS-stylish X:\\ in /tmp/ (in the stub.cpp source file) and change the "backslash to underscore" (sick comment!) loop to a normal backslash-to-slash conversion in the utils.cpp file (TempFileName function). Also, you will need to change something in the source because when writing that "X" file, it will assume "little endian", thus inverting wide-character output data (anyways this will tamper your "license.txt" files only).

Remember that makesis will crash (suck up to the latest byte of your precious disk space) if fed with an UTF16 text file (as you already saw in my P900 SDK for Linux, I like to have a text "license" file shown before installing a .SIS on the phone).

Well, I am now able to create a .SIS file starting from scratch (C++ sources, .BMP bitmaps, and a small Makefile) in my Mac OS X "Tiger" equipped Apple Powerbook. Refer to P900 UIQ SDK for Linux page for details about sources, bitmaps, Makefile and other stuff.

TO DO:

Some small notes: you surely will know that you can strip your executables; C++ executables will be 90% lighter (yay!) after stripping the (normally useless) debugging information.

Remember that all the Symbian SDK stuff was ported to Linux with great efforts, and extra effort was needed because our old Apple machines (non-Intel based) have different "endian" ordering (the poorly written Symbian utilities assume an MS/DOS+Windows box with Intel-style byte ordering).


Future issues - Work in progress!

Yes, completing everything is a rather hard work (ouch!) and I simply don't know if I'll have sufficient spare time to complete it (sigh!) and many other problems and glitches could emerge in future.

I publish this page only to help any volunteers to continue working on it; Symbian seems not interested to move out of that infamous Windoze platform. I already stated that my next palmtop/phone/PDA/etc will be a Linux-based one both because of Symbian operating system (feature rich, but slow and complex and buggy - a.k.a. "Windoze vice") and cross-development platform (man, I simply can't stand a portable device which is unfamiliar to Unix - Linux and Mac OS X).

PLEASE, don't ask me to give out binary files. Releasing sources means inviting other people to work on them; releasing binaries means making developers lazy... :-)