There are reports that some Nintendo Wii U systems out in the wild are falling victim to mysterious failures. As is so often the case, certain error codes have been found in common across failed units out in the community, and [Voultar] decided to investigate to see if he could fix this problem with a little hacking.
[Voultar] wasn’t able to source a Wii U with the much-discussed NAND failure mode, but he was able to source a number of supposedly bricked Wii U systems displaying the error codes 160-0101 and 160-0103. The hack is achieved with an exploit in the Wii U’s USB Host Stack descriptor parsing module, developed by [GaryOderNichts]. It allows the injection of a payload that lets one run unsigned code on the Wii U, achieved via a Raspberry Pi Pico. The Pico is ultimately used to boot off an SD card running a recovery program for the Wii U. By resetting the Wii U’s “coldboot title ID”, it solves the error and gets the console booting properly, as per normal.
[Voultar] was able to fix five consoles displaying the common error messages, which we’d call a win. It’s not going to be a fix for every failed Wii U out there, but if you’ve got the dreaded 160-0101 or -0103 errors, it might be worth a shot.
The Nintendo Game Boy was a very popular handheld in its time, but its display technology has not aged gracefully. Ripping out the original screen and dropping in a modern IPS LCD is a popular mod, but that often comes with a weird flicker now and then. [makho] is here to explain why.
The problem was that the Game Boy didn’t have any way to do transparency in the original hardware. Instead, sprites that were supposed to be a little bit transparent were instead flickered on and off rapidly. The original LCD was so slow that this flicker would be largely hidden, with the sprites in question looking suitably transparent. However, switch to a modern IPS LCD with its faster refresh rate, and the flickering will be readily visible. So it’s not a bug — it’s something that was intentionally done by developers that were designing for the screen technology of the 1980s, not the 2020s.
IPS screens have become the must-have upgrade for modern Game Boy users. Most would tell you the improved image quality and rich color is worth a little flicker here and there.
Retro gear is beloved, both for what it can do, and what it reminds us of. Nostalgia is a powerful thing, after all. But then, so is corrosion — and the latter has a habit of killing hardware and driving up prices for remaining units. Thankfully, hard workers like [NatalieTheNerd] are out there, creating reproduction PCBs to keep old hardware alive. Her Game Boy Advance (GBA) reproduction PCB is a great tool for the restoration and modding communities.
The board was reverse engineered, with [Natalie] sharing various scans and schematics of the GBA’s motherboard on the Modded Game Boy Club website. The project recreates the AGB-CPU-03 version of the GBA, and is designed to be produced on a 1 mm board with an ENIG process. You can combine the PCB with some salvaged parts and a new shell and build yourself a remarkably fresh GBA, if you so desire.
Beyond it’s intended use, [Natalie] points out the board outlines could be used as a basis for RetroPie or ESP32 projects that fit into a standard Game Boy Advance form factor. We love that idea. We’ve seen [Natalie’s] work before too, in the form of this neat little macropad. Nifty as always!
Have you ever wondered how the graphics in your favorite video games worked? This is the start of a series on game graphics, and what better place to start than how exactly the original Mario Bros. got those glorious pixely pixels onto the screen. Buckle in, because we’re “racing the beam” with systems like the NES, Commodore 64, and many other classics from the 1980s.
And to understand the 1980’s, it’s important to understand how the televisions of the time worked. Cathode Ray Tube (CRT) televisions work by precisely bombarding a phosphor layer with electrons, which excites the phosphor, which then releases visible light. The beam scans from left to right then top to bottom, giving each pixel a small fraction of a second of time. All of this effectively means that pixel data needs be sent at the same time as when the pixels are being lit up, which is why this type of graphics is often dubbed “racing the beam”.
It’s an accepted part of retro gaming lore, that 8-bit consoles perform best when used with an original CRT TV. One of the reason for this is usually cited as being because the frame buffer and scaler circuit necessary for driving an LCD panel induces a delay not present on the original, and in particular this makes playing games which relied on a light gun impossible to play. It’s a subject [Nicole Branagan] takes a look at, and asks whether there are any ways to use a classic light gun with a modern TV.
Along the way we’re treated to an in-depth look at the tech behind light gun games, how the gun contained a photodiode which on the NES was triggered by the brief showing of a frame with a white square where the target would sit, and on the Sega consoles by a white screen with an on-board timer counting the screen position at which the gun was aimed.
The conclusion is that the delay means you won’t be playing Duck Hunt or Hogan’s Alley on your 4K TV, but interestingly, all is not lost. There are modified versions of the games that take account of the delay, or an interesting lightgun emulator using a WiiMote. We’d be happy at playing either way, just as long as we can take pot-shots at the annoying Duck Hunt dog.
As amazing and groundbreaking as the Nintendo 64 was, over the years it has also become synonymous with blurry textures and liberal use of Gouraud shading as its most strongly defining visual features. In a recent video, [James Lambert] covers how the system’s minuscule 4 kB texture memory (TMEM) can be circumvented using mipmapping. By loading progressively more detailed textures (each in 4 kB chunks) in a level-of-detail (LoD), the visual fidelity can be maximized while keeping rendering speeds relatively zippy, as the real-time demo proves.
This project was made for the N64brew 2023, with the source code available on [James]’s GitHub account. Although impressive, it bears noting that mipmapping was not an unknown approach in 1996, and many approaches were used to work around the N64’s physical limitations.
In the case of mipmapping, [James]’s demo perfectly demonstrates the problematic nature of mipmapping, as it dramatically increases the storage requirements for the textures, hitting 40 MB just for this one single room, for a system that supports up to 64 MB cartridges.
Ultimately, this shows that the 4 kB TMEM was not the only issue with the N64, with the limited (and expensive) mask ROMs for the cartridges proving to be an insurmountable obstacle that systems like Sony’s PlayStation largely did not have to contend with. With roomy 650 MB+ optical storage, the PS1 got instead tripped up by the glacial access and loading speeds of optical media and its soggy-potato-powered GPU.
Seeing demonstrations like these manage to wonderfully highlight the bottlenecks in these old consoles, and makes one wonder about what could have been, even in an era before 1 TB solid-state drives and direct resource streaming between GPU and said storage.
Game consoles typically support a limited number of input devices, meaning that console games are often completely optimized for the default controller supplied with that platform. Nintendo’s tendency to completely reinvent their controllers pretty much every generation can therefore become a little irritating, especially when they also enable their newer consoles to play games from their back catalog. So when [Robson Couto] found that using the Switch’s Joy-Cons was a bit awkward for playing emulated Nintendo 64 games, he decided to figure out how to connect real N64 controllers to a Nintendo Switch.
While you can buy modern N64-style controllers for the Switch, even straight from Nintendo themselves, [Robson] thought it would be way more interesting to reuse an old controller and implement the translation step from scratch. In the video (embedded below) he takes a deep dive into all the timing details of the N64 controller protocol, which is basically a 1-wire setup, and explains how to use an STM32F411 BlackPill board to read out the controller’s buttons and joystick.
Next, he explores how to map the resulting data to the USB HID protocol used by the Switch. Most of the buttons have a clear one-on-one mapping, but since the “minus”, “capture” and “home” buttons are missing on the N64 controller, he chose to map these to button combinations unlikely to be used during regular gameplay. [Robson] also ran into the common issue of the analog joystick having a poorly-defined maximum range, for which he added a rudimentary auto-calibration feature.
Finally, he designed and 3D-printed a neat enclosure for his system with an N64 controller port on one side and a USB port on the other. By 3D-printing the whole thing he also avoided having to either source the non-standard connector or permanently modify his hardware. The end result of [Robson]’s project is an unobtrusive gadget that connects classic controllers to modern hardware – but of course, the reverse process is very much possible, too. If you want, you can even play N64 games with a mouse and keyboard.