←back to thread

StarGrid: A new Palm OS strategy game

(quarters.captaintouch.com)
203 points capitain | 1 comments | | HN request time: 0.213s | source
Show context
csnover ◴[] No.45662582[source]
Last year I tried to extend Retro68 to support Palm OS and made quite a lot of progress, but in the end it ended up being too much work and I abandoned the attempt. I suppose now is as good a time as any to mention that it exists (in a very ugly state with lots of unsquashed commits) in case anyone wants to pick up the mantle.[0] At the least, it has an up-to-date and functioning copy of the Palm OS Emulator which, unlike cloudpilot, retains the debugger code so you can actually debug apps with it.[1] (I also reverse-engineered the dana HAL; this is as far as I know the only open-source version of POSE which supports that hardware.)

The thing that blocked me from being able to make any more progress was a bug in GCC that causes it to ICE generating PC-relative code[2], and I absolutely could not understand GIMPLE nor the GCC internals quickly, nor could I commit any more energy to trying to learn them. (Generating PC-relative code is essential for Palm OS because, unlike Mac OS, code sections are in read-only memory and cannot have relocations, so this mode being broken means it can’t really work.)

It is fair to say that I have no idea how close to actually working things actually are in that fork since GCC/binutils are an absolute nightmare[3] and I am no compiler engineer. Retro68 has some scary-looking hacks to deal with exception handling which wouldn’t work as-is with Palm OS, at the least. (Retro68 is also itself quite a pile of hacks which were clearly made without a good understanding of how GCC works, and without any apparent care to making sure it is easy to rebase atop newer versions of GCC.)

If I were to restart the work again I would probably just have GCC do the bare minimum of emitting code with whatever relocations it can, and then just make Elf2Mac rewrite machine code. Elf2Mac is itself fairly clearly an attempt to avoid having to touch binutils as much as possible, since it redoes a lot of the work that libbfd normally does, which makes sense, because working on GCC/binutils is just awful.[4]

[0] https://github.com/csnover/Retro68/tree/palmos

[1] I tried to make the debugger work with the modern GDB remote protocol instead of the Palm-specific protocol which requires the ancient prc-tools version of GDB, but GDB is also broken <https://sourceware.org/bugzilla/show_bug.cgi?id=32120>, so that never worked very well. GDB’s remote protocol also does not support receiving symbols from the remote on-demand for whatever reason—it only allows to receive an ABI-compatible binary with DWARF symbols, which makes it next to impossible to get symbols out of the ROM, which uses MacsBugs format. Working with DWARF also sucks.

[2] I believe it was https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80786

[3] Just as a tiny example: never in my life have I ever considered that someone would solve the “tabs versus spaces” debate by making the rule “two spaces per indent, unless it is eight spaces, in which case use a tab”. What IDE even supports this??

[4] To be clear, I don’t mean to denigrate all the hard work that has been done over decades to create these tools. The GCC toolchain is a triumph and I am sure that my relative intelligence has something to do with why I struggle with it, compared to all the compiler people who happily work with it every day. Nevertheless, it is a forty-year-old codebase, and everyone seems quite content to continue to work more or less within constraints that made sense in the 1980s, and perhaps not so much in 2025.

replies(2): >>45663760 #>>45663853 #
dmitrygr ◴[] No.45663853[source]
> Last year I tried to extend Retro68 to support Palm OS

I did that 5 years ago and published it on reddit in /r/Palm:

https://old.reddit.com/r/Palm/comments/fu5870/announce_new_g...

and then

https://old.reddit.com/r/Palm/comments/p81m58/announce_new_g...

replies(1): >>45664307 #
csnover ◴[] No.45664307[source]
Yes, I saw that, it would have been really great if the source code had ever been released, instead I had to start from scratch…

My implementation does not require editing SDK headers and the goal was to support multiseg. If I had stopped at 32k single seg it would probably have been working. But I never got quite as far as being able to e.g. test libgcc, so who knows.

replies(1): >>45664621 #
dmitrygr ◴[] No.45664621[source]
Click the second link. The source code is there. First comment. I only didn’t release it initially because I was really busy and sorting out a clean reproducible process to build it took too long. As soon as I was able to, I posted it.

And I have since made it not require any SDK changes.

replies(1): >>45664830 #
csnover ◴[] No.45664830[source]
Oh, how frustrating. I have no idea how I missed that since I feel like I spent quite a while looking for some later update that included the source. Well, thank you for making sure to release it! I did rewrite most of the Retro68 CMake code too, perhaps for similar reasons, so I can understand how that could have been a problem. At least the newer versions of GCC do not have race conditions in their Makefiles, unlike prc-tools-remix. :-)

The work I did was intended to eventually merge and live alongside the existing stuff in Retro68 instead of just blowing it away, with the hope that nothing like this would ever happen again to anyone else, but of course I failed to actually finish the work.

replies(1): >>45664902 #
1. dmitrygr ◴[] No.45664902[source]
I never submit to OSS. It is the same as editing wikipedia -- every time I try, it is a political mess and nonsense galore. (My reasoning: If you are paying me for work, you are welcome to criticize, request amendments, etc. If you are not paying me for work, you thank me profusely for the free work I offered and take it...or don't. I am uninterested in your opinions in that case, or requests for changes unless they are bugs). Anyways, I never had goals of upstreaming anything. I was just trying to help others who wanted a working toolchain. My patches work well. People (not just me) have used them. There are also patches to PilRC i released that add some more bitmap compression modes and fix bugs with multi-depth fonts.