Compilation with PalmOS Development Suite
Brought to you by:
pputzer
Menu
▾
▴
Hello,
I just downloaded the PalmOS Development Suite, and thought that I'd see if I could compile DiddleBug (one of my favorite Palm apps) with it.
I thought I would get the latest compilable version from the files section, but I was surprised to see that there is no source distribution. (As there is not even a mentioning of where to get the sources in the binary distribution readme/documentation, you have a problem with the GPL. It is not enough to say that you can get the latest version from a certain place. To comply with the GPL you have to provide the exact sources used to build the binary distribution.)
As the exact version didn't really bother me I got the latest version from CVS. I managed to include it into Eclipse but the compilation fails:
1. Makefile.basic - Had to change the OS version from palmos5r3 to palmos5r4. No problem.
2. Compilation then failed with the message:
In file included from diddlebug.c:61:
Handspring5/68K/System/HsExt.h:34: warning: `_OS_CALL_WITH_UNPOPPED_16BIT_SELECTOR' redefined
/PalmDev/sdk-5r4/include/PalmTypes.h:229: warning: this is the location of the previous definition
In file included from diddlebug.c:45:
Vga.h:168: parse error before `_Str'
Vga.h:174: parse error before `_Str'
Vga.h:181: parse error before `_Str'
Vga.h:188: parse error before `_Str'
Does anybody have any idea of what went wrong?
Also, I'm wondering. How far are you from color support? What is lacking?
Regards,
Dov
Hi!
GPL> Oh, you can get all versions of the source from CVS, including those that have been used for the binary distributions. You just have to use the right version tag (DIDDLEBUG_<major version>_<minor version> for release versions, DIDDLEBUG_<major>_<minor>_BETA_<beta number> for beta versions. But you're right that there should be a small pointer to CVS in the README.
Compilation> Well, I don't use Eclipse/PODS for DiddleBug development, so I can only partially help you here. Obviously DiddleBug hasn't been adapted to the new SDK in some time, so compilation problems are not really a surprise. The culprit in this case, Vga.h is necessary for HandEra 330 support. You should probably edit this file, since the device is not supported anymore. Well, maybe one could just chuck support for the HandEra out of the window, but that would probably be more work.
Greetings,
Peter
PS: I haven't done anything regarding color support yet. It needs a whole new dataformat that should probably support arbitrary resolutions, too. I simply haven't tackled that yet. I'd like to use PNG as the native format, but there is no port of libpng to PalmOS that I know of (palmOne probably has one, but the headers are not public and the lib is not available on all devices). I have created a small PNG parser from scratch for sending sketches by mail, but that is rather fragile and only handles 160x160 resp. 320x320 bitmaps at the moment (black & white images).
I did some progress tonight with the compilation after entering lots of #ifdef HANDERA ... #endif and #ifdef TREO...#endif. The TREO ifdefs are related to HsNavDrawFocusRing() which I don't have and to duplication of definitions in HsExt.h and HsNav.h.Where did you get these libraries from?
Regarding Eclipse, there is really nothing new here. It is still compilation through makefiles and gcc. It is actually very annoying to work like this, as the installation of PODS destroyed my normal cygwin installation. But as their is no emulator for PalmOS 5.4 for Linux, I don't have much of a choice. :-(
So in the end the compilation worked, but linking failed with the message:
/usr/m68k-palmos/bin/ld: region coderes is full (DiddleBug-english section .text)
I understand from the net that this happens if you have to many verbose strings in your program. But what is not clear to me is why it is happening me and not you? I have not changed any of the strings after all. I'll make another effort trimming down all the strings, and will see if that takes care of the linking problem.
Regarding your wish to go PNG, I am not sure how much it will give. As you say you will have to do quite a bit of coding in order to support it and in the end it is not clear what you will gain compared to using the zlib library straight. In terms of compression I believe that all that png is doing is to do different types of prediction comparison between two subsequent lines of pixel data. The rest is just plain zlib compression. Try it by comparing the size of a png file to a gzip'd ppm file. There really isn't much of a difference. In any case I certainly don't think it is worth waiting for PNG within the database before attacking color. You can also always tag the sketches in the database with their types and leave room for future types. I would suggest creating a simple key value format which in the first iteration would be uncompressed, and then add zlib compression. Making a png converter on the host computer should then be trivial.
Regards,
Dov
I got compilation to work. I just had to install pilotrc and recompile. Don't know what happened first time. Next time, I'll play around with painting in color. :-)
Hi!
What exactly did you change? I installed SDK 5.4 and found that somehow it doesn't like HandEra's SDK (which admittetly is pretty old by now). I'd like to keep HandEra support if it doesn't cost too much, but if I don't find a solution for these troubles soon, I guess I will just remove it. I don't know how many people are still using the HandEra 330 anyway, probably not many.
As for color graphics> I'd like to have a new data format that fulfills these criteria:
* Arbitrary color depth - on grayscale devices, only grayscale or b & w images should be stored to conserve space (make this a user preference).
* Arbitrary size (within certain limits, i.e. integer multiples of the screen resolution?) => scrolling
I still would like to see a PNG-based implementation because I need to support a PC format anyway for Send support (mailing sketches directly from the Palm). BMP would be another possibility, but that format is not very good for full color graphics.
Greetings,
Peter
In my limited spare time I am playing around with the sources, seeing what it takes to get color drawing to work. I'm pretty much using brute force just in order to learn how things work. I don't know if anything useful will come out of it.
Regarding the format, I have nothing against PNG, quite the opposite. I just think that it might be quicker to use a simpler format. Translating anything into png is pretty much trivial on the desktop.
It would be neat to do additional things like antialiased lines and circles, alpha channel support, multi-layer support, scriptable drawing etc. But I guess that I'm getting carried away.
I'll add some screenshots if I get as far as having something to show.
Regards,
Dov