41–50 of 61 posts
If you don't have a Palm: https://github.com/migueletto/PumpkinOS
There are all kinds of retro stuff that I still love. What is it about Palm OS that you love?
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.
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, u…
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, u…
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...
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, u…
Is your POSE 64-bit fixed or still 32-bit? ISTR running into this problem trying to compile the original from source and have yet to find the round tuit.
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, u…
> 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...
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.
Earlier quoted context omitted.
> 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...
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.
And I have since made it not require any SDK changes.
Earlier quoted context omitted.
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.
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.
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.
Earlier quoted context omitted.
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.
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, unlik…