The Ur-Quan Masters Discussion Forum

The PSP has a port. So does the GP2X. And then the Windows Mobile-based Pocket PCs have one, if I'm not mistaken.

So why don't Palm OS 5 devices get some SC2 goodness? They have somewhat-fast ARM CPUs, ranging from the up-to-180 MHz OMAP CPUs in the Tungsten E, T, and T2, while the rest of the Palms(including the Treo 650 and later)have XScale CPUs that can overclock to around 600 MHz, or so I've heard. (Sadly, the only Palm OS 5 device I have access to is my friend's Tungsten E, and it may not have the power to run UQM.) There's also the Tapwave Zodiac, which has a fairly-weak CPU clocked at around 200 MHz(maybe more, maybe less), but it's equipped with a 2D graphics accelerator that can be put to good use. Most of them also have 320x320 or larger screens, so re-sizing the screens should be no problem.

There are a few problems, though:

-For starters, UQM is designed to run on x86-based hardware, not devices with ARM CPUs. Much of the code will likely require an overhaul.
-The older OMAP-based Palms may not have the brunt to run UQM, and the newer ones might require ridiculous overclocks that drain the battery quickly.

I don't have the skills to make such a port, but I would like to at least discuss the possibility.

Possibility is rather irrelevant if there's noone with the required skills who has the hardware and is willing to do it.
Which answers your question why there are ports for the PSP and GP2X but not for Palms.

There are some other threads about ports for other platforms which talk a bit about requirements and porting problems, a lot of which will also be relevant to Palms. You'll have to use Google with 'site:uqm.stack.nl' (or something similar) as the forum search is currently broken.

I guess I'd better learn how to program for the things, then. I've got to have some sort of portable SC2 fix! (It'll also get other people hooked on SC2, which can only be for the better.)

To possibly ease my work a bit, doesn't the GP2X have ARM CPUs like Palm OS 5 devices? Would that ease the effort involved in a Palm port by using the ARM code as a base, or would it be better off to start from scratch with the x86 code as the base?

Yes, the GP2X uses ARM CPUs, but since UQM is written in C, which processor the compiled code is run on shouldn't matter much. The only relevant point is whether the processor supports fast floating point math.
There are some routines in the UQM code for which assembly is used, but these are optional, for faster scalers.
The most important issue is whether there's a port of SDL for your platform.
You may be able to benefit from some of the work done on other ports, but that will be in the form of code ripped out for size and speed.

Looks like the SDL thing will be a problem, as it appears that many people have attempted to port SDL to Palm OS 5 and have had difficulties. Palm OS 6 would be easier, but no device on the market uses it-not even the new Treo models!

I'll continue my Googling for a bit to see if I strike gold. If not...well, I guess I've got even more work cut out for me. However, this just might lead to a performance increase over having the engine go through SDL and then the OS if I know how to code well enough...

As for other libraries, I've found a GapiDraw library that has Palm OS 5 support. One of its devs claims that it runs circles around SDL in performance (http://www.palminfocenter.com/news/6640/new-game-and-graphics-sdk-ported-to-the-palm-os/).

Discussion in that thread and this one (http://www.palminfocenter.com/news/6858/new-gaming-sdk-for-palm-os-5-handhelds/) also say that maybe SDL isn't so much the problem as the rest of the code that needs to be modified for the sake of the Palm OS itself.

I suppose I'll start by just trying to get a working port, then making optimizations and such from there. Hell, I might try releasing various versions with different APIs and such to see what works better...

EDIT: I think I've found some sort of SDL implementation for Palm OS... (http://www.superwaba.com.br/en/downloads.asp)maybe this could be useful in the port's initial stages.

Now if I could just find where to get the GP2X version's source code...

http://www.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,46,1930

That's one problem solved.

Right now, I'm looking through some "*.c" files in the src folder with WordPad. I'm not quite sure what to change at the moment.

As far as the SDL port source I snagged off of the SuperWaba site I linked earlier is concerned, I'm not sure how to go about getting some compiled library files out of it. I also can't figure out what part of the SuperWaba VM has the SDL port already compiled. I might be better off figuring out how to rip out all of the SDL code and using something else...

I would also like to know what files had to be altered to make the PC-to-GP2X port possible, so that I don't go off altering what I don't need to. (Of course, I'll probably have to change much more in order to get this thing working properly on a Palm OS 5 device, but it helps to have a starting point.)

I'll install the Palm OS development tools tomorrow and tinker around with it a bit to see what compiles and what doesn't.

I think you're missing the point of a library such as SDL. It hides the system specifics and provides a platform-independant layer. So the application programmer only has to code for SDL, instead of for each specific platform.
So if you have a port of SDL for some platform, the largest part of the port to that platform is done.

Now, if SDL isn't available for some platform, you can do what you're suggesting, that is, rip out SDL, and replace the SDL calls in the application by native calls. You'd have to modify each instance of every SDL function call, and the result is a hugely different code from the base code of the application, so if a new version of the application is released, you'll have more work to do.
Or, you could port SDL to the new platform (or at least the parts of it that you need). You'd only have to implement each function once, and the application code remains unchanged, so there won't be any more work when a new version of the application is released. On top of that, other people who want to port their own SDL applications to your platform can use your SDL port.
It should be clear that the latter is much preferable.

Once you've got an SDL port for your platform, what's left to do is to adapt the code to the system specifics that cannot be hidden by a library, such as the size of the screen, or how much memory and disk space are available[1].

[1] Ok, if you really want to, you can hide available system memory by using swap.

I've made some progress and figured out that cygwin is key to compiling this SDL port.

The problem is, it doesn't seem to want to.

After getting some additional files for cygwin and running the autogen.sh command in the libpalm-posix folder that came with the SDL port files, I try running this command as the readme says:

$ ./configure --host=arm-elf --with-palmdev-prefix=<PalmOS SDK root> --prefix=/usr/local/arm-elf
I replace the "PalmOS SDK root" part as needed. And what do I get?

bash: --prefix=/usr/local/arm-elf/: No such file or directory

I guess I'll try deleting that bit, but then I get this:

bash: syntax error near unexpected token 'newline'

This is getting to be a serious pain in the ass, one that I don't know how to rectify.

At least when I get this damn code in library form, it shouldn't be too much work to make a project out of the existing source code since it turns out that my Palm OS IDE uses C.

...Hey, wait a minute! I figured out the answer! Turns out I was leaving the "<" and the ">" in my command line, and that screws everything up. Remove them while retaining the correct path, and PROFIT!

...Until I tried make. And then it errored out. I think it's because I'm using GNUARM 4.x instead of 3.4, and the readme says that the source doesn't support gcc 4.0. To make matters worse, gnuarm.org does NOT have the 3.4 toolchain, and that was the latest source code I could find.

I'm currently Googling for it, but I would appreciate it if someone assisted me with this little problem...

Actually, forget that. I found it. Now, to get this all working...For starters, this version came in a .tar.bz2 file rather than an install .exe. I have no idea where to put the files...

I think I've gotten somewhere by punching in ./configure --prefix=/usr/local/gcc and then make, but after spitting out random gibberish for several minutes, all I get is this:

make: *** [all-gcc] Error 2

I'd never figured it would be this difficult just to get a library to compile...

This is not a matter of "following instructions". You really should know what it all means, if you're going to get anywhere.
It seems to me that when you succeed this will have been a very educational experience.

To be honest, I'm just looking at what's there, studying it to find out what needs to be changed, and test out the changes.

Maybe I don't know what I'm doing, or maybe I'm going off in the wrong direction, but damn it, I want UQM on Palm OS, and if no one else is going to do it, I'll find a way!

You've got to admit, the boy has spirit.

Yup, usually people just remark "wouldn't it be cool if uqm would run on my toaster", as if the reason that we didn't do that before is that we hadn't thought of it.
Not only does NamelessPlayer have a go at it himself, he doesn't give up when he appears not to have all the necessary skills (yet). That is rare.

Looks like I've got even more of a problem.

Just when I think I have a SDL port for Palm OS, this thread (http://www.emuboards.com/invision/lofiversion/index.php/t23494.html) mentions that only the graphics component of SuperWaba's SDL is ported.

Guess this means that I'll have to rip out all of those SDL calls and code in favor of another API, then...The only problem is that I don't know of any special sound and input APIs for Palm OS, which means that I might not even have the benefit of an API and have to code everything myself!

In that case, such a port probably won't come for a while. I have school to tend to, after all.

That thread is over a year old. Maybe SDL is more complete now.

And if it isn't, as I said before replacing those SDL calls by calls to another API is going to be as much work as it would be to add those calls to SDL itself, which would be considerably more useful.

But you could always decide to port UQM without the sound.
What would be more important would be whether the threading subsystem of SDL is ported. You can run UQM without sound, but you (currently) can't run it without threads.

I know it's been a while, and I haven't really done much, but now that I have my own Palm OS 5 device(a Tungsten|C), I can really get cracking.

A sort of upshot to this is that I can start with the 0.6.2 source instead of the 0.5.0 source, so maybe I can figure out a way to get Wi-Fi support working for net melee. (I can't work on Bluetooth net melee support since there is absolutely no way I can think of to get it on the T|C. Why did Palm not include BT and Wi-Fi in one unit until the T|X?)

Also relating to the SDL issue, I found this (http://yoyofr.proboards44.com/index.cgi?board=general&action=display&thread=1169954741&page=1).

What's so important about that thread on an emulator you've probably never heard of before? Scroll down and you'll see this:

"it's pretty much insta-anything as it was with the PSP--considering SDL works right. I presume it would be almost insta-PalmOS too (PalmOS does have SDL thanks to Vilmos), although I haven't tried yet. Might do it right now though"

Tried Googling for "Vilmos", and got all sorts of random crap. However, if there indeed is a more complete Palm OS SDL port out there, I just might have UQM on my T|C sooner than I would have imagined...or maybe I could even have it now if I was willing to swap Palm OS for a not-quite-complete Linux distro (http://hackndev.com/).

For now, though, I should probably get cracking on compiling what I DO have while I'm searching for a more complete SDL port.

NamelessPlayer, I agree with you completely. Palm OS is such a popular operating system that it would be a great boon to UQM if it worked on that OS. No other game on Palm OS would be in its league if it can be ported.

I want to help you in your efforts. I have modest programming skills and have written a small program for Palm OS before.

I am currently working on just what you are working on - compiling SuperWaba's SDL. Sadly, when I downloaded SuperWaba's SDL, it didn't come with libpalm-posix and I cannot find it anywhere else. Do you think you would mind emailing me the SDL that you are using? My email is wherewp at  the domain gmail.com (replace "at the domain" with the @ sign).

Regarding the error you got, you need to replace <PalmOS SDK root> with the actual location of the Palm OS SDK

EDIT: I got libpalm-posix via google code search's cache and compiled SDL. So nevermind about sending the above.

http://www.emuboards.com/invision/lofiversion/index.php/t23494.html

Hey look, a guy named Vilmos talking about SDL stuff!

Some more:

http://www.emuboards.com/invision/lofiversion/index.php/f42.html
http://www.emuboards.com/invision/lofiversion/index.php/t17675.html

Some more digging and it seems that this Vilmos bloke is the author of PalmMAME and Zodiac/PalmOS5 are related somehow, though Zodiac is a development environment? with some application libraries for stuff (TNA?) but is now no longer supported.  So TNA got ported to PalmOS5 and called PNA:

http://www.emuboards.com/invision/lofiversion/index.php/t25079.html
http://www.emuboards.com/invision/lofiversion/index.php/t26978.html

"Vilmos the author of PalmMAME is on vacation. I recommend for the time being that you check out Vilmos' Pocket Dimension board. There is a thread for PalmMAME 17.1 there with detailed installion instructions and help. http://www.pocketdimension.com/cgi-bin/ikonboard/ikonboard.cgi "

You might be able to make an account on either emuboards or pocketdimension and see if you can contact him.  Or ask other people about SDL since they may know.  Or with an account you might be able to 'private message' him or access his email address in his forum account, if he has it.  OR download PalmMAME and see if his contact info is in the documentation.

Hope this helps.

Thanks!

I think I have looked at this SDL port before, and it is superior to the Superwaba port in that is has audio support. However, it also requires significant adaptation to compile with gcc, which may take a while. I figure I might as well start simple using the Superwaba SDL port which only supports graphics.

Just in case I am wrong and it is a different port though, I have emailed Vilmos.

Thanks once again!

I managed to get SDL compiled and have determined how to emulate threading and how to launch ARM code with peal. I am currently struggling with the latter, but have emailed an expert on the subject. I hope to get an SDL sample program working first (since that doesn't require threads). Then, on to uqm!

-Where

Sorry for the delay, but after checking this thread and not seeing any other posts, I decided to take a break from these forums.

I found out that MetaView's Crimson Fields (http://www.metaviewsoft.de/en/Software/PalmOS/Freeware/Crimson/index.html) has a more complete SDL implementation with source available, but I can't figure out how to integrate its SDL code with UQM's since the SDL files are set up very differently. It doesn't help that I don't know much about actual programming, or even if I have my IDEs set up properly.

Oh, and while I'd still love to see UQM on Palm OS(especially if it runs on slow devices like the Tungsten E), I might switch to a Dell Axim X50v with Windows Mobile 5 soon. Is there a port available for that device, preferably with OpenGL-ES support for Intel 2700G hardware acceleration?

The Crimson Fields SDL port sadly requires Codewarrior to work, and Codewarrior costs money... :(

As for a Windows CE port, the official version of SDL supports SDL on Windows CE. In other words, you might be able to compile UQM for Windows CE with no changes to the code.

-Where