CaSTaway/Palm Sourcecode for Developers

CaSTaway/Palm is open source freeware hosted here; you're welcome to take a peek, make comment, or submit some updates to help out! However, before doing anything you should read this page as you'll need to know the history and some of the legals surrounding it, just so we're all on the same page.

Jeff, skeezix@codejedi.com

A note on brevity:

This code isn't as organized as I'd like, but its more important to have a useful application than to have a pretty codebase right now ;) (See the history below for rational.) Hacked together in high speed in scraps of free time, torn from my previous works, dealing with compiler bugs and moving from one very different build environment to another.. ah well :) But I'll try and give a running commentary here so you can have at least some documentation :)

A note on Codejedi proprietary code:

There isn't any in here. My public works such as this, Kronos, and others, are written with entirely different code than in Codejedi profesional work. You'll see me using the same code between these public projects, and you're welcome to take a look and maybe learn something from it, or submit patches. This is so I can make my public work GPL or BSD licenses, and partake in GPL'd projects, without worrying about conflicts.

A note on the licenses:

CaSTaway/Palm is actually comprised of two entirely separate components (see later for details); the CaSTaway/Palm emu core, derived from CastCE and Castaway, and the front end GUI and Palm libraries that invoke the core as a separate application running with it. The Castaway core is under the GPL. The front end would also be fully GPL except that some of the devices it needs to work on require NDA's and thus the code cannot be released. As such, the front end will be released as GPL or BSD license, without the unreleasable code. That code will be kept private, and versions for those devices will be released separately. So it breaks down like this..

• CaSTaway/Palm core - Gnu Public License
• CaSTaway/Palm frontend - Gnu Public License
• CaSTaway/Palm for Zodiac frontend - Private version of the frontend out of necessity

History of CaSTaway/Palm...

1. TOSEmu (also by me, never released, runs my online Atari ST BBS)
2. STonX (now a sourceforge project)
3. .. begat STonX/GP (also by me, never released)
4. Castaway (sourceforge project)
5. .. begat Castaway/GP (original, garbaged)
6. .. begat CastCE (formerly FaST)
7. .. begat CaSTaway/GP (also by me)
8. .. begat CaSTaway/Palm (CodeWarrior, garbaged)
9. .. begat CaSTaway/Palm (gcc + CodeWarrior, this project)

As you can see, I've been quite an ST fan over the last decade ;) However, as far as CaSTaway/Palm is concerned, only the last 4 parts really matter, but I thought it may be of use to know the other projects I've worked on or with, with regards to the Atari ST.

Castaway (the original project) is a very portable and simple ST and 68000 emulator; very cool. Unfortunately its not very compatible (or at least with all the games I wanted to play, like Time Bandits. :) I did some early porting work of that to GP32 and abandoned it, until CastCE (derived entirely from the original but much improved and optimized) was opened to the public. I jumped on it, making a very solid featured version for the GP32, with many amazing extensions (like keybindings, config files, etc). (Note that I work 10 hours a day 6 days a week, so this was suicidal, but I love the ST so much it just had to be done. The emu later went on to win an award at GP32Spain and is a beloved emu on the platform!)

The Palm OS platform has always been one of my greatest interests of course (witness www.codejedi.com), but the devices were just not powerful enough to be running ST emulators on (though I worked on it on and off for years!)... until the PalmOne Tungsten T3 came out, with 11MB of heap memory :) (You may note that earlier devices like the Sony NX can run CaSTaway/Palm, so why didn't I try it earlier? I got busy with other things, give me a break ;)

When the T|T3 came out, CodeWarrior 9.2 was also freshly out, which was the first CW really viable for doing pnolet's to the extent I wished (pure ARM applications essentially) -- normally I've used gcc with a lot of hacking to do my pnolet work (see XCade). As it is such a huge timesaver over pure gcc pnolets, requiring little evil hacking of code to port it over, it was my preferred approach with this project to use CW9.2; much time was invested into this version, with a clean design and implementation, and I was very pleased with progress... but it just didn't work. Compiler issue after compiler issue was found, from math lib errors (thanks Ben for the replaement math lib) to just purely wrongly emitted ARM code (also thanks to Ben for giving me various fixed for the compiler..). I'd have tracked that down and submitted better error reports to Metrowerks, but the T|T3 had no debug-nub for the PalmSource FAST ARM toolkit, and so debugging was very difficult when the emu 68k core was going off 10,000 opcodes in.. and I'd already sold my T|T1 (which does have a debug num available). No Zodiac in sight for months to come.... so there you go. With my ultra-cramped time schedule, I couldn't waste any more time, so I moved back to my old reliable friend.. gcc. Hopefully I'll return to CW9.3 when it comes out, as its compiler emits a faster runtime, and the environment is much easier for bomined pnolet/68k Palm OS apps.

So after so much trouble with CW (I must say CW is an excellent product overall, its just that the specific things I was doing in CaSTaway/Palm were causing it to trip over its pnolet side; no one else has this level of problem, and I've been using CW for Palm (68k side) for years without a problem. I highly suggest using it, though I also use a lot of gcc as everyone knows ;) I moved to gcc, with a very different design (instead of an integrated 68k/pnolet app, this was to be a more split app, with very separate 68k and pnolet side, with them calling back and forth into each other, etc). Being in a hurry to finally see something after all this CW9.2 work, I went about it quickly... hence the sometimes odd interactoins between the two halves. Note that its a totally different style of operation .. the CW9.2 version was entirely in ARMland with a few calls back to PACE 68k land. The gcc version is a simple kludge.. one entry point, a lot of PACE callbacks, and no globals. (No strings, no global vars or the like, etc.) Everything is pushed into a state structure allocated from 68k-side. Its not as pretty, but it was doable in short order without using any of my Codejedi magic.

And it works very well, so I'll accept the mess, and do some house cleaning soon enough :)