The Nintendo Switch CPU Exposed

Ever wonder what’s inside a Nintendo Switch? Well, the chip is an Nvidia Tegra X1. However, if you peel back a layer, there are four ARM CPU cores inside — specifically Cortex A57 cores, which take up about two square millimeters of space on the die. The whole cluster, including some cache memory, takes up just over 13 square millimeters. [ClamChowder] takes us inside the Cortex A57 inside the Nintendo Switch in a recent post.

Interestingly, the X1 also has four A53 cores, which are more power efficient, but according to the post, Nintendo doesn’t use them. The 4 GB of DRAM is LPDDR4 memory with a theoretical bandwidth of 25.6 GB/s.

The post details the out-of-order execution and branch prediction used to improve performance. We can’t help but marvel that in our lifetime, we’ve seen computers go from giant, expensive machines to the point where a game console has 8 CPU cores and advanced things like out-of-order execution. Still, [ClamChowder] makes the point that the Switch’s processor is anemic by today’s standards, and can’t even compare with an outdated desktop CPU.

Want to program the ARM in assembly language? We can help you get started. You can even do it on a breadboard, though the LPC1114 is a pretty far cry from what even the Switch is packing under the hood.

Resurrecting A Bricked Wii U With A Raspberry Pi Pico

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.

Continue reading “Resurrecting A Bricked Wii U With A Raspberry Pi Pico”

Why Game Boy IPS Screens Flicker

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.

Continue reading “Why Game Boy IPS Screens Flicker”

Reverse-Engineered GBA Board Could Come In Handy

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!

Game Graphics: Racing The Beam

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”.

Continue reading “Game Graphics: Racing The Beam”

Can An 8-Bit Light Gun Work On A Modern TV?

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.

Light gun image: Evan-Amos, Public domain.

Implementing MegaTextures On Real Nintendo 64 Hardware

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.

Determining which textures are visible to the player.

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.

Continue reading “Implementing MegaTextures On Real Nintendo 64 Hardware”