SDL2 for macOS 9 “rough draft”(macintoshgarden.org)
macintoshgarden.org
SDL2 for macOS 9 “rough draft”
https://macintoshgarden.org/apps/sdl2-macos-9-rough-draft
61 comments
Retro68 is indeed very cool, I started writing some Think C and it is fun to code on such a tiny screen but Retro68 allowing you to code on your regular dev environment using more modern C has been great. I've been playing around with it last week to make some applications (not a plug because these projects suck!) - If anyone wants a simple Retro68 application boilerplate to start off with:
- Chatbot: https://github.com/yocontra/macintosh-ai/
- Game: https://github.com/yocontra/maccraft (Doesn't work very well atm, making a game run well on a macintosh plus is hard!)
I wasn't even alive when these computers were out but enjoying coding for them - something to be said about the simple interfaces (both in C and UI) and challenge of making things work with the constraints of the hardware.
Retro68 community has some really neat stuff like MacHTTP (https://github.com/antscode/MacHTTP) as well so you can offload some work to services (assuming you buy one of the many SCSI Wifi thingys).
- Chatbot: https://github.com/yocontra/macintosh-ai/
- Game: https://github.com/yocontra/maccraft (Doesn't work very well atm, making a game run well on a macintosh plus is hard!)
I wasn't even alive when these computers were out but enjoying coding for them - something to be said about the simple interfaces (both in C and UI) and challenge of making things work with the constraints of the hardware.
Retro68 community has some really neat stuff like MacHTTP (https://github.com/antscode/MacHTTP) as well so you can offload some work to services (assuming you buy one of the many SCSI Wifi thingys).
I tried a little bit 20+ years ago. Bought a 'road Apple' Performa for $50, download Pangea's game programming book, can't remember if I used MPW or CodeWarrior...
It wasn't anywhere near as simple as DOS game programming was so I think I just installed YellowDog and used that Mac as a webserver.
https://www.pangeasoft.net/book/buy.html
Edit: I just opened that PDF and I think that's a newer version or I remembered the book wrong.
It wasn't anywhere near as simple as DOS game programming was so I think I just installed YellowDog and used that Mac as a webserver.
https://www.pangeasoft.net/book/buy.html
Edit: I just opened that PDF and I think that's a newer version or I remembered the book wrong.
Perhaps the book was "The Black Art of Macintosh Game Programming" [0]? That was a fun book I got myself.
---
[0]: https://archive.org/details/blackartofmacint00ties
---
[0]: https://archive.org/details/blackartofmacint00ties
I love retro68, but as much as I love it I'm frustrated the"black box" dependency on CMake to specify the build process + app metadata (e.g. distinguishing between apps and desktop accessories which treat system globals differently, rsrc compiling, resource fork creation, etc.) My first instinct with (hobbyist) programs is to go for a lean and mean makefile.
Wondering what I could do with it ... I rewrote Glypha (an old Mac shareware game I wrote) using modern SDL2. Might be fun to try to "back port" (?) it to OS 9 on top of SDL2 (rather than the clunkier CopyBits() calls I used in the original shareware game).
Nice, I hadn't heard about that before. The original Mac game was really fun, but your new Steam version looks way smoother. I like how the UI's like an old B&W Mac UI but with Egyptian touches thrown in. If you don't mind me asking, what was the new version written in (C, C++, something else)? Were you able to reuse any of the logic from the original Pascal version, or was everything more or less done from scratch?
I'd love to hear how that goes. I've never written any code for OS 9 or earlier. I have heard many things about the brilliance of QuickDraw for writing very fast 2D drawing code on the very limited hardware of the time. I have not heard anything about the actual experience of writing software with QuickDraw calls.
I'd also be really interested to know how SDL2 would fare by comparison. Would it be as fast on old hardware? It wasn't built with the assumptions of that old hardware in mind, so I would be very surprised if it performed as well.
I'd also be really interested to know how SDL2 would fare by comparison. Would it be as fast on old hardware? It wasn't built with the assumptions of that old hardware in mind, so I would be very surprised if it performed as well.
Thank you for providing me with many hours of entertainment on our old Performa 6360 many years ago! Bought the new version on Steam, too.
And you have given me plenty of entertainment in my retirement. You keep up the good work.
The funny part is I think the SDL2 porter implemented most of the software rendering with ... CopyBits!
I'm here for this. Going to start building a first class competitor to Elder Scrolls Arena this weekend for my Mac SE/30. And do it better.
Love the enthusiasm and commitment.
There is no such thing as "macOS 9".
"Mac OS 9" or "OS9" does, however, exist.
"Mac OS 9" or "OS9" does, however, exist.
Ya.. A mod edited the title and didn't change it back.
So Mac OS9 is PowerPC macs, but this also covers 68k macs with OS 7.6:
> Compatibility Architecture: 68k PPC MacOS 9 PPC, MacOS 7.6 M68k, using CodeWarrior 6 and 7 Pro.
> Compatibility Architecture: 68k PPC MacOS 9 PPC, MacOS 7.6 M68k, using CodeWarrior 6 and 7 Pro.
Whenever I think that the time I invested in some of the mini-projects is lost/wasted time and that it was probably better choice to do just about anything else instead - I come across something like this. The only thing I can conclude is that there is no such thing as wasted time, as long you enjoy the road.
Kudos.
Kudos.
Pretty cool!
I have heard stories of people in 2025 creating a fat macOS binary containing arm64, x86_64, x86, and ppc slices.
I hope that we can get virtualization of x86_64 macOS on arm64 hosts. It would be really cool to be able to do such a thing solely on a modern machine!
I have heard stories of people in 2025 creating a fat macOS binary containing arm64, x86_64, x86, and ppc slices.
I hope that we can get virtualization of x86_64 macOS on arm64 hosts. It would be really cool to be able to do such a thing solely on a modern machine!
You can't virtualize a different architecture. Virtualization means that the guest OS runs natively on the host CPU with some sort of hypervisor. Do you mean emulation?
What is the best option for having an experience like "DosBox but for 68K macs"?
+1 this question. I notice QEMU can do 68k these days, apparently, including MacOS 7 & 8:
https://wiki.qemu.org/Documentation/Platforms/m68k#Running_M...
https://wiki.qemu.org/Documentation/Platforms/m68k#Running_M...
Just to understand the context ... would an SDL2 driver for Mac OS 9 enable first-class support for Mac OS 9 as a guest OS in modern VM hypervisors?
No, this is not something that would enable a VM. This allows SDL2 code to be used in the classic Mac OS as a library.
[deleted]
Uh, did an editor change the title? I's MacOS 9, not macOS 9 ;) This is classic Macintosh. Please change it back to the original.
It's Mac OS 9, title cased with a space between the words https://i1.wp.com/lowendmac.com/wp-content/uploads/about-mac...
Extremely cool project!
Extremely cool project!
True true, I just submitted it with the casing of the original title. Though actually if you read the page they've tested support down to Mac OS 7.6!
I think it's amazing that we would have a new way to make apps running on macOS 9 systems since with a well known standard such as SDL2 we could make far more apps.
New exotic stuff:
- UXN for MacOS 9
- ScummVM, maybe modern games could run under a G4 with Altivec
- Netsurf with the SDL front end
- UXN for MacOS 9
- ScummVM, maybe modern games could run under a G4 with Altivec
- Netsurf with the SDL front end
> - ScummVM, maybe modern games could run under a G4 with Altivec
Having done some testing for the PPC version of ScummVM on 10.4 I can say that it won't run many of the more modern games because none of those machines supported shaders on the GPU, which many of the more modern ScummVM supported games like Thimbleweed Park depend on. A software shader implementation could be added in theory if someone had the gumption to build it but it would most likely be unusably slow on those older machines.
Having done some testing for the PPC version of ScummVM on 10.4 I can say that it won't run many of the more modern games because none of those machines supported shaders on the GPU, which many of the more modern ScummVM supported games like Thimbleweed Park depend on. A software shader implementation could be added in theory if someone had the gumption to build it but it would most likely be unusably slow on those older machines.
TinyGL works, it's being used under the 3D rendering settings at ScummVM. Forget advanced FX, but this is ScummVM, they could implement a simpler version of them.
Looks neat! SDL seems open to supporting legacy platforms, so hopefully it'll get mainlined at some point (at this point, may be more likely if they port SDL3 though, SDL2 is in maintenance mode). Does anyone know if it's possible to use a new compiler for this rather than CodeWarrior 7? It would make it easier to port stuff to Mac OS 9 if you don't also have to deal with the compiler only supporting old C/C++ standards.
> compiler only supporting old C/C++ standards.
That's from back when the c++ standard was a rough suggestion. I had to use code warrior 10 for a project back in 2008ish (when standards compliance seemed to actually be picking up real steam across gcc/llvm/msvc) and it was painful how many things that were standard/supported across the other compilers that would break, we ended up basically falling back to closer to c with classes than anything that would resemble modern (at the time) c++.
That's from back when the c++ standard was a rough suggestion. I had to use code warrior 10 for a project back in 2008ish (when standards compliance seemed to actually be picking up real steam across gcc/llvm/msvc) and it was painful how many things that were standard/supported across the other compilers that would break, we ended up basically falling back to closer to c with classes than anything that would resemble modern (at the time) c++.
Retro68k allows you to build with gcc12 https://github.com/autc04/Retro68
The classic 68k Mac binary model is pretty far from what LLVM and GCC support even if they still have backends capable of compiling to older 68k CPUs (I'm not sure if that's case). Executable code is stored in the resource fork; the Mac SDKs require a compiler with support for a special syntax for trap-table based calls; the classic Mac Toolbox expects Pascal-format strings for most things.
helfire mentions Retro68; if you look at its README, you can get an idea of the scope of modifications required.
helfire mentions Retro68; if you look at its README, you can get an idea of the scope of modifications required.
Is SDL2 just something that everyone is expected to know what it is? I was thinking it was about a Software Development Lifecycle on Mac0S9, but it clearly isn't... but there is no where in this post or that page that explains what SDL2 is.
>Is SDL2 just something that everyone is expected to know what it is?
No but it's assumed that if use a site like HN you can figure it out?
No but it's assumed that if use a site like HN you can figure it out?
Fair, and I did, after I commented. Not exactly sure why I felt so compelled to comment, maybe because I was frustrated trying to find on the linked page what it was talking about.
I thought it was an actual game for a good chunk of time.
I thought it was an actual game for a good chunk of time.
I think that anyone that doesn't know what SDL2 is probably won't care about this announcement. Besides, when I search for "SDL2" on Google, the first 5 pages were all about the Simple Direct Media Layer library, so there shouldn't be any uncertainty.
What exactly is your background? MY first idea was that you might be very young but your account is from 2010.
Not knowing SDL feels like someone having no idea what C++ or Unreal Engine is. I am curious how you managed to avoid learning about SDL despite being on hacker news.
Not knowing SDL feels like someone having no idea what C++ or Unreal Engine is. I am curious how you managed to avoid learning about SDL despite being on hacker news.
https://xkcd.com/1053/ seems relevant here. :)
I don't know what to say other than I am pretty sure I have never encountered it before. I have been coding for over 30 years, 20 years professionally, and have never seen it. You can see by my account age and comment history that I have been active on HN for 15 years.
I actually have interest in game programming, too. So I don't know.
I am sure I'll encounter it 10 times this week now, good old Baeder-Meinhoff
I actually have interest in game programming, too. So I don't know.
I am sure I'll encounter it 10 times this week now, good old Baeder-Meinhoff
Oh you absolutely will. I guarantee you, you have used a lot of software that is using SDL.
https://steamdb.info/tech/SDK/SDL/
Though to be fair it kind of makes sense that you would have never used SDL yourself. It you never go that far down the stack and do stuff like write your own game engine and the like, you wouldn't really need to know it. I guess I am more aware of software dependencies as a Linux user? That is my only explanation or maybe you are really just one of those lucky 10000.
https://steamdb.info/tech/SDK/SDL/
Though to be fair it kind of makes sense that you would have never used SDL yourself. It you never go that far down the stack and do stuff like write your own game engine and the like, you wouldn't really need to know it. I guess I am more aware of software dependencies as a Linux user? That is my only explanation or maybe you are really just one of those lucky 10000.
> Not knowing SDL feels like someone having no idea what C++ or Unreal Engine is.
I've literally never even heard the term SDL before this. I would say that it's nowhere near the same class of ubiquity as the other two examples you gave.
I've literally never even heard the term SDL before this. I would say that it's nowhere near the same class of ubiquity as the other two examples you gave.
There are far more games written in SDL than in Unreal Engine.
Granted that is trivially true because Unreal Engine itself and many, many other engines use SDL internally but still. So yeah, is is way MORE ubiquitous than Unreal Engine.
I guess there is just less awareness because SDL is a lower level detail that most people don't really need to care about. It just works and powers a huge chunk of our games and software.
Nothing wrong with not knowing about it, it is just interesting to me that even in tech spaces some people are not aware of SDL. I am sure there is a lot of things I don't know either.
Granted that is trivially true because Unreal Engine itself and many, many other engines use SDL internally but still. So yeah, is is way MORE ubiquitous than Unreal Engine.
I guess there is just less awareness because SDL is a lower level detail that most people don't really need to care about. It just works and powers a huge chunk of our games and software.
Nothing wrong with not knowing about it, it is just interesting to me that even in tech spaces some people are not aware of SDL. I am sure there is a lot of things I don't know either.
This is so hilarious for me, for whom SDL is truly legendary (literally decades of often daily use), and who constantly gets downvoted into a smoking hole in a ground for expressing the same sentiment about every random 7 week old JS framework or Grafana monitoring extension or whatever... the militant webdev bias on HN is super clear.
The recently released SDL3 is hot shit today, BTW: https://wiki.libsdl.org/SDL3/FrontPage
The recently released SDL3 is hot shit today, BTW: https://wiki.libsdl.org/SDL3/FrontPage
As far as libraries go, this one is pretty well known. If you ever need to make a small game or custom gui, it's fairly easy to pick, very performant and very portable.
Love everything going on here. Now if someone could just send me an old Pismo powerbook...
Wouldn't it be easier to cross-compile using a modern LLVM/GCC? I assume both have 68k backends?
I was really confused by the mention of 68k at first since MacOS 8.6 dropped support for that, but following the link it looks like it supports System 7 as well.
Cross-compiling would be faster (than emulation or too-old hardware), but I have never heard it called "easy". There are a lot of projects out there that need special configuration, and many don't even support the HOSTCC variable, etc. And that's before considering the importance of system libraries.
Cross-compiling would be faster (than emulation or too-old hardware), but I have never heard it called "easy". There are a lot of projects out there that need special configuration, and many don't even support the HOSTCC variable, etc. And that's before considering the importance of system libraries.
I commented that because the author said "dealing with the foibles of CodeWarrior". I guess in the scenario cross-compiling wouldn't be easy, but possibly easier?
Cool to see. SDL 1 went back to System 7, awesomely enough.
Before that you had... Sprite Animation Toolkit by Ingemar Ragnemalm which powered Escape Velocity, etc.
Before that you had... Sprite Animation Toolkit by Ingemar Ragnemalm which powered Escape Velocity, etc.
Uhm, nothing says what SDL is? The description is an interesting story about the struggles of getting vintage code to build; but it assumes that the reader knows what the thing is to begin with.
Isn't it easier to Google then?
Also, what's next? "Care to explain what is this `linux` thing?"
Also, what's next? "Care to explain what is this `linux` thing?"
If you do not know what it is, nor cant be arsed to look it up perhaps hackernews is not the correct discussion forum for you. Lurk more.
I've been here longer than you, and have an order of magnitude more karma than you do.
This isn't Reddit. Imaginary internet points don't matter here.
Back in the day when this stuff was modern I didn't have many resources or people to talk to about it, so exploring what could have been is an interesting endeavor.
https://github.com/autc04/Retro68 https://amendhub.com/