The Nintendo GameCube was the first console from Big N with disc-based media. Gone were the cartridges that were absurdly expensive to manufacture. In theory games could be cheaper (yeah, right), and would hold more textures, pictures, and video. Around the time the GameCube hit shelves, your basic home computer started getting DVD burners, and you could walk into Circuit City and buy those tiny little DVD-Rs. But you couldn’t do it. You couldn’t burn GameCube games, at least without advanced soldering skills.
One company did. Datel, a British company that produced the Action Replay, the ‘Game Genie of the GameCube’ figured out how to get around the GameCube’s disc protection. Not only that, but in a decade and a half since the Action Replay came to market, no one has managed to copy their methods. In a fascinating video, [Nathan] takes us around the disc to see how this disc protection scheme actually worked, and how to exploit it to load homebrew games from an SD card.
The Nintendo GameCube disc format is almost, but not quite, the same as a DVD format. On (nearly) every DVD, and almost every GameCube disc, there’s a ‘barcode’ of sorts on the inside of the optical tracks. This burst cutting area (BCA) is unique to every copy that comes off a single master. Additionally, this BCA can only be cut with a YAG laser that’s significantly more powerful than the laser diode in a DVD writer.
But the Action Replay disc from Datel didn’t have this BCA. Why not? The BCA effectively writes over the pits and lands in the first blocks of data in a DVD. Since the BCA is written over data that is already there, you can just encode whatever data the BCA should hold into the raw data of the pits and lands. It’s a brilliant technique that allows consumer equipment to create the Action Replay disc. But surprisingly, this technique wasn’t popularized with the GameCube homebrew scene.
Not that it really mattered, anyway; modchips existed, and with the SD to Memory Card adapter you could run homebrew works without having to burn a disc. That’s exactly what [Nathan] did with his GameCube setup, you can check out the video below.
The Switch is the new hotness and everyone wants Nintendo’s new portable gaming rig nestled in a dock next to their TV, but what about Nintendo’s other portable gaming system? Yes, the New Nintendo 3DS can get a charging dock, and you can 3D print it with swappable plates that make it look like something straight out of the Nintendo store.
[Hobby Hoarder] created this charging dock for the New Nintendo 3DS as a 3D printing project, with the goal of having everything printable without supports, and able to be constructed without any special tools. Printing a box is easy enough, but the real trick is how to charge the 3DS without any special tools. For this, [Hobby Hoarder] turned to the small charging contacts on the side of the console. All you do is apply power and ground to these contacts, and the 3DS charges.
Normally, adding contacts requires pogo pins or hilariously expensive connectors, but [Hobby Hoarder] has an interesting solution: just add some metal contacts constructed from LED leads or paper clips, and mount it on a spring-loaded slider. A regular ‘ol USB cable is scavenged, the wires stripped, and the red and black lines are attached to the spring-loaded slider.
There is a slight issue with the charging voltage in this setup; the 3DS charges at 4.6 Volts, and USB provides 5 Volts. If you want to keep everything within exacting specs, you could add an LDO linear regulator, but there might be issues with heat dissipation. You could use a buck converter, but at 0.4 Volts, you’re probably better off going with the ‘aaay yolo’ theory of engineering.
[Hobby Hoarder] produced a few great videos detailing this build, and one awesome video detailing how to print multicolored faceplates for this charging dock. It’s an excellent project, and a great example of what can be done with 3D printing and simple tools.
Handheld consoles have to make a lot of design choices that their TV connected brethren don’t have to worry about. Battery life is important, as is screen visibility, and the games can’t be too bulky or unwieldy if you’re going to be carrying them around all day. [Chris] is no stranger to building handheld versions of home consoles, and took a few of these lessons on board in his latest portable SNES build.
The motherboard was provided by a SNES Jr., a lightweight, compact model released towards the end of the console’s reign. This was small enough that it required no trimming, however [Chris] elected to replace the inefficient 7805 with a more modern switching regulator. The case was 3D printed on a typical FDM setup, while the buttons were produced on a Form 2 for better dimensional accuracy and surface finish.
The real party piece, however, is the use of an SD2SNES flash cart. This allows a huge variety of ROMs to be loaded onto a single SD card, and played on the original console hardware. This is particularly useful in a portable build, as it becomes possible to carry all the games you could want, rather than having to juggle several full-sized SNES cartridges. The SD2SNES is wired in place permanently inside the console, with an impressive number of patch wires between the motherboard and the cartridge PCB. Despite the long lead length, [Chris] reports no issues with the connection.
There are some limitations – the flash cart doesn’t work properly for games using extra chips on the cartridge, like the SuperFX in Star Fox, for example. Despite this, it’s an excellent, high quality build that we’re sure is a lot of fun to play out and about.
The Nintendo 64 is a classic console now, and much loved, despite losing in commercial stakes to the dominating PlayStation from Sony. It’s one that doesn’t always get as much attention in the homebrew and hacker scene, compared to platforms like the NES and Game Boy. This means the tools required to work with the console aren’t as well-known. However, there’s a remarkably easy way to load homebrew on to the Nintendo 64, if you’ve got the right hardware.
To pull this off, you’ll need a N64 Gameshark, particularly a version higher than 3.0. These included a parallel port and the relevant onboard logic to allow the console to receive data and commands from an attached computer. [Nathan] demonstrates using the gs_libusb utility to deliver homebrew code to the console, using a USB to parallel adapter to make it easy from a modern computer.
That at least seems to be the motivation behind [Morphcat Games] pending release of Micro Mages, a new game for the Nintendo Entertainment System console that takes its inspiration from Super Mario Bros. The interesting bit here is how they managed to stuff so much content into so little space. The video below goes into great detail on that, and it’s a fascinating lesson in optimization. The game logic itself is coded in assembler, which of course is far more efficient than higher level languages. Even so, that took 32 kB of ROM, leaving a mere 8 kB for background elements and foreground sprites.
Through a combination of limited sprite size, tiling of smaller sprites to make larger characters, and reusing tiles by flipping them horizontally or vertically, an impressively complete palette of animated characters was developed. Background elements were similarly deconstructed and reused, resulting in a palette of tiles used to generate all the maps for the game that takes up just 60 bytes. Turning those into playable levels involves more mirroring and some horizontal shifting of tiles, and it looks like quite an engaging playfield.
Yes, there’s a Kickstarter for the game, but we’re mainly intrigued by what it takes to cram a playable game into so little space. Don’t get us wrong – we love the Retro Pie builds too, but seeing the tricks that early game developers relied upon to make things work really gets the creative juices flowing.
Impressively, the game fits in under 28KB, and [Stephane] hasn’t skimped on the development details. The process begun with setting up a basic 3D engine on the Arduboy, followed by some tests of various gameplay ideas. The final implementation bears a strong similarity to the original SNES gameplay. At this point, work moved out of the Arduino IDE into [Stephane]’s custom development environment to speed things along. A PC port was used to save time programming the flash every iteration.
The tricks used to pull this off are many and varied. There are neat hacks used to optimise the storage of the 3D model data, implement lightweight collision detection, and generate random levels. Everything was done in order to make the game fit into the smallest space possible.
Running smooth 3D graphics on a 16MHz 8-bit microcontroller is an impressive feat, and a testament to [Stephane]’s coding abilities. We can’t wait to see more 3D development on the platform. Meanwhile, if the Arduboy doesn’t quite have the look you want, there’s a solution for that too. Video after the break.
If you grew up watching the Pokémon TV series, you’d naturally be familiar with the cries of all your favourite Pocket Monsters. Most of the creatures in the anime tend to say their own name, over and over again. Pour one out for the legions of parents who, upon hearing a distant “PIKA PIKA!”, still involuntarily twitch to this day.
However, the games differ heavily in this area. Generation I of Pokémon was released on the Game Boy, which simply didn’t have the sound capabilities to deliver full bitstream audio. Instead, sounds were synthesized for the various Pokémon based on various parameters. It’s quite a deep and involved system, but never fear – help is at hand via [Retro Game Mechanics Explained].
The video breaks down, at a bitwise level, how the parameters are stored for each Pokémon’s cry, and how they are synthesized. It’s broken down into easily understandable chunks, explaining first how the Game Boy’s sound hardware works, with two pulse channels and a noise channel, before later expanding upon why some Pokémon have the same or similar cries.
It’s a tour de force in retro game reverse engineering, and expertly presented with high quality graphical guides as to what’s going on at the software level. There’s even an emulator you can use to explore the various cries from the original game, and generate your own, too.