The bulk of the hack was inspired by a Sega Emulator built in a controller which he saw on Hackaday a couple of years back. It’s simply a Sega-like USB gamepad which has a hub and thumb drive internalized. The hardware changes on [sonicdude10’s] version gets rid of the old thumb drive and replaces it with one that supports U3. This is a hardware emulation trick supported by some USB drives which allows them to enumerate as CD drives instead of USB mass storage. Autoplay for CD drives is still functional in Windows.

We’ve heard a bit about U3 over the years. There was a now-dead hack covered all the way back in 2006. And we even found a comment suggesting its use for USB-based game emulators. [sonicdude10] points to two useful tools that let him customize how U3 performs. u3_tool is a multitool for tweaking how the hardware behaves, u3-autorun makes customization of the auto-launching app a snap.

Everyone loves arcade games, and it didn’t take long for designers to figure out that people would love to take the fun home. The home gaming console market has been around for decades. Through the early days of battery-powered pong style consoles through Atari and the video game crash of the early 80’s, to the late 8 and 16 bit era spearheaded by The Nintendo Entertainment System and The Sega Master System and beyond, consoles have become a staple of the hacker home. This week’s Hacklet features some of the best retro console projects from Hackaday.io!

We start with [ThunderSqueak] saving the world with her Atari 5200 Custom Controller Build. For those who don’t know, the Atari 5200 “Super System” was an 8 bit system ahead of its time. The 5200 was also saddled with on of the worst controller designs ever. The buttons would stop responding after a few hours of game play. With 17 buttons, (including a full number pad), that was a pretty major design flaw! [ThunderSqueak] hacked a cheap commercial fighting game stick to make it work with the 5200. 12 individual buttons were wired in a matrix to replace the telephone style keys on the original 5200 controller. Atari’s non-centering analog stick was converted over to a standard 4 switch arcade style stick. [ThunderSqueak] did leave the original pots accessible in the bottom of the enclosure for centering adjustments. Many 5200 games work great with the new setup.

[DackR] is bringing back the glory days of Nintendo with Super Famicade, a homebrew 4 SNES arcade system inspired by Nintendo’s Super System. Nintendo’s original Super System played several customized versions of games which were available on the Super Nintendo Entertainment System (SNES). [DackR] is building his own with parts from four SNES consoles. He’s also adding a few features, like a touch screen, video overlay, and enhanced RGB.

He’s going to add custom memory monitoring hardware, which will allow him to check how many lives a player has left and handle coin operation, all without the original Super System Hardware. If you’re curious what the original Super Systems looked like, check out Hackaday’s Tokyo Speedrun video.You might just catch a glimpse of one!

[Bentendo64] is improving on the past with RGB For ‘Murica. European systems have enjoyed the higher quality afforded by separate red, green and blue video lines for decades. North American gamers, however were stuck in the composite or S-Video realm until shortly before the HDTV age. [Bentendo64] had an old hotel CRT based monitor, and decided to hack an RGB input. After opening up the back of the set, he removed the yolk board and added direct inputs to the video amplifiers. We’re not sure if this mod will work with every CRT, but it can’t hurt to try! Just be sure to discharge those high voltage capacitors before wrenching on these old video systems. Even if a set has been unplugged for days, the caps can give a seriously painful (and dangerous) shock!

[Ingo S] is also working to improve the SNES with SNES AmbiPak, a mod which brings ambient lighting and “rumble pack” controller feedback to the vintage Super Nintendo. [Ingo S] used the popular SNES9X emulator to figure out where game data is stored while the SNES is running. His proof of concept was the original F-ZERO SNES game. [Ingo S] found that Every time the player’s car hits the wall, the system would perform a write on address 3E:0C23. All he would need to do is monitor that address on the real hardware, and rumble the controller on a write. The real hardware proved to be a bit harder to work with though. Even these “slow” vintage systems clock their ram at around 3MHz, way too fast for an Arduino to catch a bus access. [Ingo S] is solving that problem with a Xilinx XC9572 Complex Programmable Logic Device (CPLD). CPLDs can be thought of as little brothers to Field Programmable Gate Arras (FPGAs). Even though they generally have less “room” for logic inside, CPLDs run plenty fast for decoding memory addresses. With this change, [Ingo S] is back on track to building his SNES rumble pack!

It feels like we just got started – but we’re already out of space for this week’s Hacklet! As always, see you next week. Same hack time, same hack channel, bringing you the best of Hackaday.io!

Remember the Sega Saturn? You know, that short-lived game system of the mid 90’s. Well, [c_mon] is still a fan and decided to make a portable version with a built in screen.

As you can see from the photos, the main case is made from wood, plywood to be exact. Several pieces of the plywood were cut out using a CNC Router and laminated together to achieve the full height needed to enclose the internal electronics. The finished case takes up a little less real estate than the original, however it is slightly taller.

You may recognize the screen as an old PSOne unit. The screen was taken part and housed in it’s own wooden enclosure which is hinged to the main case. The video is supplied to the screen by a composite output from the Saturn. There is no unique CD lid either, the screen functions as one when it is folded down. For sound there are a couple built in powered speakers that tap into the stock audio output.

To ad a little pizzazz, [c_mon] routed in a groove in the top to accept some EL wire. There are also some cool engravings in the wooden case, including the Saturn Automobile Manufacturer logo on the top of the screen lid…. whoops!

Black and white NTSC is simple – it can, and was, done with vacuum tubes for a long, long time. Color is just weird, though. It runs at 29.976 frames per second, uses different phases of the carrier for different colors, and generally takes a while to wrap your head around. [Sagar] is doing a series on the intricacies of NTSC, and the latest post deals with color and progressive scanning versus interlacing, or as it is better known, how classic game consoles and home computers generate video.

The test bed for [Sagar]’s video experimentations is a circuit containing an ATMega16, a 4-bit shift register, and a 14.31818 MHz clock. This clock is much faster than the 3.579545 MHz clock in an NTSC carrier frequency – exactly four times as fast – allowing the shift register to output four different phases of the carrier frequency a 0°, 90°. 180°, and 270°. Playing with some of the pins on the ATMega in the circuit results in a palette being generated on any old TV.

NTSC requires interlaced scanning, or sending an entire screen of even lines, then an entire screen of odd lines, at around 60 fields per second. The Nintendos and Segas of yesteryear didn’t bother with this, instead opting to send half the vertical resolution at double the frame rate. This is known as a progressive scan. [Sagar] found that this resulted in some image artifacts when displayed on a modern LCD, and moving back to an interlaced mode fixed the problem. All the code and files are up on the gits. If you’re feeling adventurous, this is exactly how projects like the Uzebox have created homebrew game consoles using little more than the ATMega found in [Sagar]’s build.

While most homebrew video game development has focused on the original NES, Atari consoles, and has produced a few SNES games, there is another console out there that hasn’t seen much love. Sega’s classic console, the Genesis or Mega Drive, depending on where you’re from, was an extremely capable machine with amazing capabilities for its time. [Chris] figured the Mega Drive would make a good target for an all-in-one development kit, and with a lot of work he managed to put one together.

The standard cartridge for the Genesis or Mega Drive is just a simple ROM chip wired directly into the console’s address space. [Chris] took a cheap FPGA and some dual port ram to create a seamless interface between the modern world and the inside of this ancient console, allowing him to load every Mega Drive game off an SD card, as well as use modern tools to modify old games, or even create new ones.

To demonstrate his dev kit, [Chris] took a copy of Sonic 1, and using the debugger and GDB, gave himself infinite lives. It’s a very cool demonstration, searching through all the commands executed by the Megadrive CPU with the standard Linux debugging tools.Going through the trace, [Chris] found the instruction that decremented that value representing Sonics lives, replaced it with NOPs, in effect giving himself infinite lives. This is a lot like how the Game Genie works, only using much, much better tools.

Of course a USB dev kit wouldn’t be much use if it could only modify existing games. The real power of [Chris]’ work comes from being able to develop your own demos, games, and homebrew apps.

[Chris] needed to write a small homebrew Mega Drive app for the ROM loader portion of his dev kit using SGDK. Disassembling his own code with the dev kit, he was able to take a look at the instructions, and potentially even modify his loader.

It’s a really impressive technical accomplishment, and something that could be a boon to the extremely small homebrew scene for the Mega Drive. All the boards, code, and everything else are available over on [Chris]’ github, with the entire project written up on hackaday.io. Videos below.

Some hackers have managed to convert an STM32 development into a Sega Master System emulator. This means Sonic the Hedgehog running on an ARM Cortex-M4.

This hack has a number of parts. First, [Alessandro Rocchegiani] showed off a video of his Sega Master System emulator running on the STM32F429 Discovery development board. This first version used the on board 2.4″ TFT LCD screen.

[Fabrice] was working with this STM32 Discovery board already. He had developed an expansion board that added a number of features to the development kit, including an R-2R DAC for video output. When [Fabrice] found out about the Sega Master System emulator, he worked with [Alessandro] and his son [Fabrizio] to get VGA output working. They also added support for the Wii controller using [Fabrice]’s Wii library. The result is a Sega Master System emulator with VGA output at 640 x 480, with 16 bit color and Wii controller support.

You can watch a video of both the LCD and VGA versions of the hack after the break.

Those of us old enough to remember blowing into cartridges will probably remember the Game Genie – a device that plugs in to an NES, SNES, Sega Genesis, or Game Boy that gives the player extra lives, items, changes the difficulty, or otherwise modifies the gameplay. To someone who doesn’t yet know where the 1-up is in the first level of Super Mario Bros., the Game Genie seems magical. There is, of course, a rhyme and reason behind the Genie and [The Mighty Mike Master] put together a great walkthrough of how the Game Genie works.

There are two varieties of Game Genie codes – 6-character codes and 8-character codes. Both these types of codes translate into a 15-bit address in the game ROM (from 0x8000 to 0xFFFF for the 6502-based NES) and a data byte. For the 6-character codes, whenever the address referenced by the Game Genie code is accessed, a specific data byte is returned. Thus, infinite lives become a reality with just a 6-character code.

Some games, especially ones made in the late years of their respective systems, use memory mapping to increase the code and data provided on the cartridges. Since areas of data are constantly being taken in and out of the CPU’s address space, merely returning a set value whenever a specific address is accessed would be disastrous. For this bank-switching setup, the Game Genie uses an 8-bit code; it’s just like the 6-bit code, only with the addition of a ‘compare’ byte. Using an 8-bit code, the Game Genie returns a specific byte if the compare bytes are equal. Otherwise, the Genie lets hands off the original data to the CPU.

Of course, all this information could be gleaned from the original patent for the Game Genie. As for the circuitry inside the Game Genie, there’s really not much aside from an un-Googleable GAL (general array logic) and a tiny epoxied microcontroller. It’s an amazingly simple device for all the amazement it imbued in our young impressionable minds.