Game Cube Hot Tub Animation Brought Into Real World

Unlike the current era where most consumer electronics are black rectangles, or the early 90s where most consumer electronics were black rectangles, we got a brief glimmer of color, light, and hope in the 2000s. Cell phones had all kinds of shapes and sizes, laptops came in bright colors, and even video game consoles got in on the fun. The Nintendo GameCube not only featured its namesake shape but came in several vibrant colors, most famously a bright purple. In fact, its design was such a hit that it continues to inspire artists and console modders alike. An animator named [kidd.gorgeous] recently envisioned a GameCube as a hot tub, and [BigRig Creates] set out to make this animation a reality.

Of course, this won’t be a life-sized hot tub capable of holding a human, but [BigRig Creates] did want it to be a usable, playable Game Cube with all of the features from the animation present in the final version. Since the lid won’t be operational with a hot tub model on the top lest all of the water spill out every time a game is changed, he’s modified it with some modern tools to hold his games inside the console itself. With the case open he’s also added the LED accent lighting featured in the animation as well as added the 3D-printed hot tub to the top. The hot tub is filled with mineral oil for electronics safety, and has a small pump built in to give the appearance of a working hot tub.

The buttons around the outside are functional as well, toggling the various lighting features and hot tub operation. And of course, the console diorama is fully playable, with the staircase railing able to easily detach in order to access the leftmost controller ports. It’s a faithful adaptation of the original animation, and [BigRig Creates] has a few games on queue that are properly themed for the new hot tub addition like Wave Race 64, Super Mario Sunshine, and Pool Paradise.

Continue reading “Game Cube Hot Tub Animation Brought Into Real World”

DOOM On A Fancy Smart Toaster

Although toasters should be among the most boring appliances in a household – with perhaps just a focus on making their toasting more deterministic rather than somewhere between ‘still frozen’ and ‘charcoal’ – somehow companies keep churning out toasters that just add very confusing ‘smart’ features. Of course, if a toaster adds a big touch screen and significant processing power, you may as well run DOOM on it, as was [Aaron Christophel]’s reflexive response.

While unboxing the Aeco Toastlab Elite toaster, [Aaron] is positively dumbfounded that they didn’t also add WiFi to the thing. Although on the bright side, that should mean no firmware updates being pushed via the internet. During the disassembly it can be seen that there’s an unpopulated pad for a WiFi chip and an antenna connection, making it clear that the PCB is a general purpose PCB that will see use in other appliances.

The SoC is marked up as a K660L with an external flash chip. Dumping the firmware is very easy, with highly accessible UART that spits out a ‘Welcome to ArtInChip Luban-Lite’ message. After some reverse-engineering the SoC turned out to be a rebranded RISC-V-based ArtInChip D133CxS, with a very usable SDK by the manufacturer. From there it was easy enough to get DOOM to run, with the bonus feature of needing to complete a level before the toaster will give the slice back.

Continue reading DOOM On A Fancy Smart Toaster”

Making The Forgotten 1982 Game Adventure Canoe Run On MAME

A Taito Egret II mini arcade cabinet.
A Taito Egret II mini arcade cabinet.

A while back [Jack] came across a Taito arcade game that neither he nor any of his mates recognized. The game was Adventure Canoe and part of the collection of forty preinstalled games on a Taito Egret II mini arcade cabinet. Yet despite [Jack] and his buddies being avid 1980s arcade enthusiasts, this 1982 title for the Z80-based Taito SJ system was completely unfamiliar to them.

When even a web search turned up extremely few details, [Jack] did the only reasonable thing and borrowed the rather expensive mini arcade for hopefully some extracting of the game ROM.

As expensive as this mini arcade is, it features the typical ARM-based SoC and Linux-based firmware. Although you can totally dump the Flash, [Jack] found that the firmware update ZIP file was a much easier target to poke at and hopefully extract the ROMs from.

Of course, Taito used password-protected ZIP files within the firmware, leading to some reverse-engineering to find the passwords. The first was ‘hidden’ as plain text in the egret2 binary. For the remainder of the ZIP files the password wasn’t as readily found, but required some sleuthing. This took the form of dynamic runtime analysis with gdb, using information previously gleaned from a Ghidra analysis. Eventually this yielded the final passwords.

Extracting the game’s ROM files this way allowed for them to be adapted to the format that MAME expects, after which the game just had to be added to the emulator’s source files. With this done the game fired right up, and [Jack] was able to play the game without any trouble.

Digging Into The Twilight Hack That Brought Us Wii Homebrew

With each new game console, there’s an effort to get around whatever restrictions exist to run your own software on it. In the case of the Nintendo Wii, the system was cracked through one of its most popular games — The Legend of Zelda: Twilight Princess. How this hack works was recently covered in detail by [Skawo].

The key for this ‘Twilight Hack‘ is to use a modified game save that allows you to run arbitrary code from an SD card, something which was first patched out of the Wii firmware with version 3.3. As shown in the video using the source code, the basic concept is that the name of Link’s horse in the game is changed in the save file to be longer than the allocated buffer, which leads to a buffer overflow that can be used to reach the application loader code.

Interestingly, while the horse’s name can only be 8 characters long, and the buffer is 16 bytes (due to ShiftJIS two-byte encoding), the save file loading code allocates no less than 100 bytes, for some reason. Since the code uses strcpy() instead of strncpy() (or C11’s strncpy_s()), it will happily keep copying until it finds that magic 0x00 string terminator. Basically the horse can have any name that fits within the save file’s buffer, just with no null-byte until our specially crafted payload has been copied over.

Although it took Nintendo a few months to respond to this hack, eventually it was patched out in a rather brutal fashion by simply searching for and wiping any modified save files. Naturally this didn’t stop hackers from finding ways to circumvent this save file check, which led to more counter-fixes by Nintendo, which led to more exploits, ad nauseam.

Even with firmware update 4.0 finally sunsetting the Twilight Hack, hackers would keep finding more ways to get their previous Homebrew Channel installed, not to mention so that they could keep watching DVDs on a Wii.

Continue reading “Digging Into The Twilight Hack That Brought Us Wii Homebrew”

It looks like osu!, but it's actually Trombone Champ

Implementing A Rhythm Game Entirely In A GPU Shader

Most rhythm games have a community creating custom charts, and Trombone Champ is no exception. What is exceptional, however, [CraftedCart]’s osu! played in a Trombone Champ chart.

It all started as a challenge to make the most unserious chart possible. Among some other ideas, [CraftedCart] eventually decides to make an osu! chart but play it in Trombone Champ. Okay, not a problem, let’s just–oh, you can’t run arbitrary code without a making a mod. So instead, they decided to use shaders on the GPU. There are, of course, all sorts of problems with such an idea. Being stuck in the fixed render pipeline of a game, you can’t just add any resources to your shader you want. This leads to using textures as memory, both the game state and the osu! chart are actually textures. Another interesting one is getting user input into the shader. [CraftedCart] solves that by connecting the position of the game object the background is rendered to to the cursor; then, the shader reads the world to local transform matrix to determine the mouse position. Finally, the graphics the player ends up seeing are rendered using ray marching.

Video after the break.
Continue reading “Implementing A Rhythm Game Entirely In A GPU Shader”

Playing DVDs On The Sega Dreamcast

Although the Sega Dreamcast had many good qualities that made it beloved by the thousands of people who bought the console, one glaring omission was the lack of DVD video capabilities. Despite its optical drive being theoretically capable of such a feat, Sega had opted to use the GD-ROM disc format to not have to cough up DVD licensing fees, while the PlayStation 2 could play DVD movies. Fortunately it’s possible to hack DVD capability into the Dreamcast if you aren’t too fussy about the details, as [Throaty Mumbo] recently demonstrated.

For the Tl;dw folk among us, there’s a GitHub repository that contains the basic summary and all needed files. Suffice it to say that it is a bit of a kludge, but on the bright side it does not require one to modify the Dreamcast. Instead it uses a Pico 2 board that emulates a Sega DreamEye camera on the Dreamcast’s Maple bus via the controller port. The Dreamcast then requests image data as if from said camera.

On the DVD side of things there’s a Raspberry Pi 5 that connects to an external USB DVD drive and which encodes the video for transmission via USB to the Pico 2 board. Although somewhat sketchy, it totally serves to get DVDs playing on the Dreamcast. If only Sega had not skimped on those license fees, perhaps.

Continue reading “Playing DVDs On The Sega Dreamcast”

The D In DNS Stands For DOOM

As literally everything ought to be able to play DOOM in some fashion, [Adam Rice] recently set out to make the venerable DNS finally play the game after far too many decades of being DOOM-less. You may be wondering how video games and a boring domain records database relate to each other. This is where DNS TXT records come into play, which are essentially fields for arbitrary data with no requirements or limitations on this payload, other than a 2,000 character limit.

Add to this the concept of DNS zones which can contain thousands of records and the inkling of a plan begins to form. Essentially the entire game (in C#) is fetched from TXT records, loaded into memory and run from there. This is in some ways a benign form of how DNS TXT records can be abused by people with less harmless intentions, though [Adam] admits to using the Claude chatbot to help with the code, so YMMV.

The engine and WAD file with the game’s resources are compressed to fit into 1.7 MB along with a 1.2 MB DLL bundle, requiring 1,966 TXT records in Base64 encoding on a Cloudflare Pro DNS zone. With a free Cloudflare account you’d need to split it across multiple zones. With the TXT records synced across the globe, every caching DNS server in the world now has a copy of DOOM on it, for better or worse.

You can find the project source on GitHub if you want to give this a shake yourself.

Thanks to [MrRTFM] for the tip.