I started with CLion, and found the UX to be completely foreign (not at all Mac-like) and overall frustrating to use.

Xcode is definitely not perfect, but it's IDE I'm most used to, so I ended up doing my most of my editing in it.

I considered this! There were a lot of things I wanted to try but didn't want the timeline of this project to blow up any more than it already had. Now that I've done the hard part of writing about it and publishing it, I can revisit some of these ideas :)

It looks like between Linux and NetBSD on the Wii there's quite a bit of work in those areas.

Thanks! The project was mostly C for the bootloader and C++ for the drivers.

As for which part was the most challenging... probably understanding the IOKit driver model. I really would have benefitted from having an expert explain some of the concepts to me, and give me some advice about how to structure my own drivers.

I see. Very interesting project. Do you think that you're going to post it on GitHub?

Your ports were a huge inspiration - thanks for contributing so much to this space!

So when will you port MacOS X to the Wii U? Two more CPU cores and 2GB of RAM instead of 88MB!

That would be a surprisingly cheap way to get a decent "vintage" Mac system considering the cheap resale on WiiUs.

Where are you finding cheap WiiUs? I've wanted to pick one up for a while and find them to be exorbitantly expensive, especially the controllers.

The gamepads often cost more than the console itself, because they're region locked and you can't use the console without one.

There is an attempt to clone the functionality of the gamepad ongoing that's somewhat usable: https://github.com/vanilla-wiiu/vanilla

I saw console-only Wii Us in Book Off in Japan for ~US$30.

I'm intrigued by this technique! Will look into it, thanks for the tip!

sample impl is in rePalm sources, but i described basically all there is to it :)

saves a lot of CPU

This would work for an idle screen but I can't imagine this would be very efficient for real use, unless the hardware cursor is put in some other framebuffer (I assume it's not otherwise the author would have probably mentioned it?)

on computer timescales, humans are basically motionless, as long as there is motion, you do the 60Hz update, occasionally you take a page fault too, not a high cost compared to a screenfull of colorpsace conversion. But when display is not changing you save a lot of cpu power.

But also Wii has the gpu abilities to trivially support hardware cursor

Last I checked, the 60fps frame buffer conversion resulted in the system idling at 18% CPU. Certainly not ideal. I'd love to optimize this further.

Presumably Wii has AltiVec that you could use to accelerate the conversion? Did you happen to look into the code the compiler generates for your loop around rgbrgb16toycbycr?

Yes - this project (and countless others) would not have been possible without the incredible work to hack the Wii from Team Twiizers (now fail0verflow) back in the day. The work they did was a huge inspiration for me getting into computer science when I was a teenager.

I was - incredible views indeed!

Your post and pictures brightened up my day. Thanks!

Very cool! I'd love to learn more. That seems extra challenging considering Mac OS 9 is closed source!

Thank you for the kind words :)