Posted by blkhp19 4 hours ago
Before figuring out how to tackle this project, I needed to know whether it would even be possible. According to a 2021 Reddit comment:
There is a zero percent chance of this ever happening.
Feeling encouraged, I started with the basics: what hardware is in the Wii, and how does it compare to the hardware used in real Macs from the era.
I LOL'dMy favorite was “it’s impossible to know which DB is failing from a stack trace”. I created STAIN (stack traces and instance names): a ruby library that would wrap an object in a viral proxy (all returns from all methods are themselves proxies) that would intercept all exceptions and annotate the call stack with the “stain”ed tag.
They've also been useful more than once, e.g. you can do that to know what iteration of a loop failed. There are of course other ways to do this, but it's hard to beat "stupid, simple, and works everywhere" when normal options (e.g. logs) stop working.
Impressive work! Now run Dolphin on it. ;)
It is not possible to add BLE or WiFi at this time to the MacroPad.
Oh yeah, really? There is a port hanging off the side that can be reconfigured for UART, are you sure Adafruit, what if I add an ESP32?> - Everything is magenta.
was fun too
My favorite part of our online world.
>Go ahead and downvote me. I am correct on every single thing I said
> The Wii uses a PowerPC 750CL processor - an evolution of the PowerPC 750CXe that was used in G3 iBooks and some G3 iMacs.
Hilarious.
> At this point, the system was trying to find a framebuffer driver so that the Mac OS X GUI could be shown. As indicated in the logs, WindowServer was not happy - to fix this, I’d need to write my own framebuffer driver.
I'm surprised by how well abstracted MacOS is (was). The I/O Kit abstraction layers seemed to actually do what they said. A little kudos to the NeXT developers for that.
With that said, I haven't developed drivers for any other platforms, so I really can't say if the abstraction is good compared to what's used by modern systems.
That said, indeed, the abstraction layer here is delightful! I know that some NetBSD devs managed to get PPC Darwin running under a Mach/IOKit compatibility layer back in the day, up to running Xquartz on NetBSD! With NetBSD translating IOKit calls. :-)
Steve was not a developer but he made it his business to care about what they cared about.
But that's a hazy, 20 year old memory.
https://news.ycombinator.com/item?id=10006411
"At some stage in the future we may be able to move IOKit over to a good programming language"
Although if it were me I'd probably annoy the heck out of him asking why he had a Wii on the airplane!
There are definitely no buses that wide.
Can’t wait for his sequel “I received a Cease and Desist Letter from Apple; Feeling encouraged, I registered the trademark ‘Wii subsystem for macOS’”.
I don't think that's a healthy way to look at it - dude was just getting some work done, but maybe I'm a broken human being who's churned out more code than I would ever admit while sitting in 32C on a cross-country flight.
I'm not an LLM post hater, but it definitely has been a bit draining lately. This is exactly what I love to see here.
TIL Wii has only 88MB of RAM. Fortunately games weren't electron-based.
YUV appears to be a PAL-specific color space. I wonder how off an NTSC Wii would be. Presumably it would have the wrong color space until an equivalent conversion scheme was devised for NTSC.
I was surprised to see regional color spaces leak into the project, but I presume that Nintendo's iOS (the coincidentally-named system this is replacing) could handle that abstraction for game developers.
But man, this is way ahead of what I could do. What this dude accomplished blew my mind. Not only the output (running MacOS on a Wii), but the detailed post itself. A-MA-ZING.
Well, okay, that's almost cheating.
The dual-framebuffer solution for the RGB-to-YUV conversion is clever too. 60 conversions per second on that hardware can't be cheap — curious what kind of CPU overhead that adds.