New Gaming SDK for Palm OS 5 Handhelds

ha, im saying that and my favorite games are zork, MUDS and moria.. :)

jeff

The Shadow knows!

Anyway, I'm very interested on that part about "the hassle of porting to OS 5". Do you have any details? Why a hassle? Do you know of any outstanding troubles when porting existing code to Palm OS? I've wondering lately why there seems to be much more porting going on for PocketPCs than for Palms...

On the other hand, "SDL compiles for WinCE and runs rather nicely in fact. Fullscreen and
windowed video work properly, as does audio. Keyboard support is currently a little buggy last time I checked."

Those are comments from 2001 and 2002. Looks like there is nothing more recent than that.
-------------

Gmigueis, the fact is they even have had GCC ported, which was certainly NOT created on Windows. So they really look like having a quite easier time porting a variety of software.

You seem interested in gaming. Did you know that MAME was ported about 2 (3?) years ago to PocketPC? (and that was not created on Win32, either :P)

But please, explain a little bit more:

You talk about apps being designed for the SDK you have developed yourself. And you seem to say that you use SDL on the desktop but not on the rest of platforms.

...but if that's the case, that leaves us again on the starting point! That's not porting or being portable; that's just avoiding unavailable stuff.

There are programs that take profit of libSDL to be portable; those programas will be usable on WindowsCE / PocketPC and Symbian because libSDL has been ported there too.
But, since there is no port for Palm OS, the program using the lib won't be portable either. (Right?)

an application written to be portable is different than an application written with desktop assumptions, regardless of the libraries used

What do you mean with "desktop assumptions"? And, how does that relate to the libSDL subject? It was created to be portable, and has been ported to other platforms. So why it hasn't been ported to Palm OS?

And, finally, I have to ask again:
MAME has been ported to PocketPC and, I just learnt, to Symbian - and lots of other platforms, of course. So it's portable. Do you mean that it could be "easily" ported to Palm OS?

You mention ScummVM. Well, ironically, that's exactly the ONE example I know of open source, portable code that is compilable for Palm OS (pity it won't use sound...does that work on PPC?). I wonder how they managed that. And, more important, why they are the only ones!

If it has "other workings", then it's NOT the same function. PERHAPS it's a straightforward substitute, perhaps NOT. I'm trying to get info, no suppositions (as you can see, I can make them myself :P). Do you have any PalmOS programming experience, please?

THE point is that porting between this machines is NEVER very hard - they all have input methods, displays, memory, you know :)

Of course all machines have the same "base capabilities" - kind of. Even more, we all know any Turing machine can act as any other Turing machine. The problem at hand is not that one; it rather is: is it too difficult?

You say "it is not very hard". What does that exactly means? :P Let's say I've seen much more detailed discussions. Look for "Palm" on libsdl.org's forums.

(Precissely, there I found a post by someone saying something akin to what you're saying now, making the subject sound almost easy. Guess what? His last post was on 2001 and never came back... and, of course, libSDL is still not ported to PalmOS. If it's that easy, and since you seem interested, perhaps you should just have a shot at it :P)

So porting SDL apps is not just porting SDL; its as above with malloc() (and easy map to MemPtrNew or MemGluePtrNew), the harder part is dealing with the fact its a totally different environment -- In OS5 you don't write a 68k or a ARM app, you write both in one.. it starts as 68k and then goes to PNO/ARM. Thats unheard of in the rtest of the IT industry, and so apps are not written that way. Apps generally assume they can use fopen() to get a file, but on Palm OS and especially in a PNO/ARM, you need to write your own fopen() wrapper to do the job.

So SDL is only one aspect; its the entire rest of it that is the real trouble.

(In repsonse to distant above, that is why my SDK does.. I have a standard set of fucntions across all platforms. It is just imeplemented in libC and SDL on some desktop platforms, and as other native controls on others. Its a lot more than just SDL :)

People write apps in different ways; a stylus is not a mouse and so a lot of the issues with quick ports come there.

As to say MAME, MAME is portable in a sense where it can be compiled for windows, mac, unix, using a pile (a large pile) of OS dependant code that the MAME core hooks into. So to make a Palm OS version, someone has to make the Palm OS dependant code, just liek the Windows dependant code has to be made. Thats not a 1 day job, so no one has bothered to do it. Its a few days job, and the number of people into ARM pno coding is small, and the numebr of peopel into emualtion is small, and trherefore the union of them is smaller still. Its not hard, just a bnit of tedious work someone needs to do. (And not me, I'm already maxxed out if you've seen my project list ;)

Also note the MAME peopel didn't think small platforms or aim for super efficient; ie: Look at the application size on your desktop and see if you want a multi-megabytye application on your handheld. Also note that its designed to run all the thousands of games form one binary, and it doesn't even worry about memoiry.. if you don't have enough memory, buy more it says.

So to make a MAME for handhelds, it needs severe trimming (go see what MAME for Pocket PC *is* ;) .. maybe break it up into a half dozen little-MAMEs, each doing a subset of the supported games, say.

Thats the porting work; GAPI has nothign to do with it. The *APPLICATION* was not deisgned to be ported to tiny environments.

So making a MAME port that *compiles* and maybe could conceivably run the smallest game is not a problem; makign a GOOD PORT (define at your leisure) is work.

jeff

The Shadow knows!

I ported ColEm Coleco emu from Marat Fayzullin to Palm OS in about 2 hours (to first successful run), and spent a few more hours over a few days making it a little nicer. Voila, see Columbo. So it can be done quite rapidly :)

jeff

The Shadow knows!

For example: Motorola made "some" modifications to GCC ("thousands of lines") so it could compile for the Altivec extensions on their PowerPC processors, and then published the changes... so those changes are now (after some refining) included on the standard GCC. Net result: you can now compile for Altivec using the free GCC and a number of free tools that depend on it. That means more developers.

Perhaps Palm would not need to make such an effort; they could just prepare some C libs more closely resembling the standards, so again anyone using GCC would compile for Palm more easily. (and more so since they are now pushing officially Eclipse+GCC now, aren't they?)

I'm talking about things like really hiding the Palm OS memory management specifics behind a malloc; or more generally, provide those wrappers that looks like a lot of developers will have to re-invent themselves.
Perhaps they could even get to the point of offering some input/output adaptor so standard C code using stdin/stdout could at least work (exactly like Metrowerks did with its SIOUX on the Mac OS some time ago, which made available a "terminal window" on the pre-OS X, CLI-averse Mac OS)...

(erm, perhaps Metrowerks is already doing that for Palm now? Dunno... :P)

Surely all of this would just be (mainly?) some help for developers; there's still the subject of the simple recompile vs. the real, thorough port...
...but I still believe some apps would be useful even with a simple recompile.

Any insight?

(I'm even thinking that if Palm* provided a standard enough environment and took the effort of porting some key "standard" things, like libSDL... well, wouldn't that open a whole lot of opportunities for the platform? Why wait for third party APIs and then make developers pay for them, when there are free alternatives?)
(self-answer: well, I guess this clashes with the Java subject. There's no good JVM for Palm, so it certainly looks like Palm* are not interested on taking profit of "standards"...)

However, I won't go that far as to ask for a filesystem just to have better compatibility with the rest of the world; but certainly I'd ask for some way to hide the no-filesystem details from developers who only need to open a few files.
Anyway, I have no idea what does exactly the VFS mean for a programmer... so perhaps that's its purpose and I could be saying nonsense here.

I'd really longing to try some things...