Add Extra Storage to Your PS4 With Retro Flair

[Frank] came up with a clever way to extend the storage of his PS4. He’s managed to store his digital PS4 games inside of storage devices in the shape of classic NES cartridges. It’s a relatively simple hack on the technical side of things, but the result is a fun and interesting way to store your digital games.

He started out by designing his own 3D model of the NES cartridge. He then printed the cartridge on his Ultimaker 3D printer. The final print is a very good quality replica of the old style cartridge. The trick of this build is that each cartridge actually contains a 2.5″ hard drive. [Frank] can store each game on a separate drive, placing each one in a separate cartridge. He then prints his own 80’s style labels for these current generation games. You would have a hard time noticing that these games are not classic NES games at first glance.

Storing the game in cartridge form is one thing, but reading them into the PS4 is another. The trick is to use a SATA connector attached to the PS4’s motherboard. [Frank’s] project page makes it sound like he was able to plug the SATA cable in without opening the PS4, by attaching the connector to a Popsicle stick and then using that to reach in and plug the connector in place. The other end of the SATA cable goes into a custom 3D printed housing that fits the fake NES cartridges. This housing is attached to the side of the PS4 using machine screws.

Now [Frank] can just slide the cartridge of his choice into the slot and the PS4 instantly reads it. In an age where we try to cram more and more bits into smaller and smaller places, this may not be the most practical build. But sometimes hacking isn’t about being practical. Sometimes it’s simply about having fun. This project is a perfect example. Continue reading “Add Extra Storage to Your PS4 With Retro Flair”

Reprogramming Super Mario World from Inside The Game

[SethBling] recently set a world record speed run of the classic Super Nintendo game Super Mario World on the original SNES hardware. He managed to beat the game in five minutes and 59.6 seconds. How is this possible? He actually reprogrammed the game by moving specific objects to very specific places and then executing a glitch. This method of beating the game was originally discovered by Twitch user [Jeffw356] but it was performed on an emulator. [SethBling] was able to prove that this “credits warp” glitch works on the original hardware.

If you watch the video below, you’ll see [SethBling] visit one of the first available levels in the game. He then proceeds to move certain objects in the game to very specific places. What he’s doing here is manipulating the game’s X coordinate table for the sprites. By moving objects to specific places, he’s manipulating a section of the game’s memory to hold specific values and a specific order. It’s a meticulous process that likely took a lot of practice to get right.

Once the table was setup properly, [SethBling] needed a way to get the SNES to execute the X table as CPU instructions. In Super Mario World, there are special items that Mario can obtain that act as a power up. For example, the mushroom will make him grow in size. Each sprite in the game has a flag to tell the SNES that the item is able to act as a power up. Mario can either collect the power up by himself, or he can use his friendly dinosaur Yoshi to eat the power up, which will also apply the item’s effects to Mario.

The next part of the speed run involves something called the item swap glitch. In the game, Mario can collect coins himself, or Yoshi can also collect them by eating them. A glitch exists where Yoshi can start eating a coin, but Mario jumps off of Yoshi and collects the coin himself simultaneously. The result is that the game knows there is something inside of Yoshi’s mouth but it doesn’t know what. So he ends up holding an empty sprite with no properties. The game just knows that it’s whatever sprite is in sprite slot X.

Now comes the actual item swap. There is an enemy in the game called Chargin’ Chuck. This sprite happens to have the flag set as though it’s a power up. Normally this doesn’t matter because it also has a set flag to tell the game that it cannot be eaten by Yoshi. Also, Chuck is an enemy so it actually hurts Mario rather than act as a power up. So under normal circumstances, this sprite will never actually act as a power up. The developers never programmed the game to properly handle this scenario, because it was supposed to be impossible.

If the coin glitch is performed in a specific location within the level, a Chargin’ Chuck will spawn just after the coin is collected. When the Chuck spawns, it will take that empty sprite slot and suddenly the game believes that Yoshi is holding the Chuck in his mouth. This triggers the power up condition, which as we already know was never programmed into the game. The code ends up jumping to an area of memory that doesn’t contain normal game instructions.

The result of all of this manipulation and glitching is that all of the values in the sprite X coordinate table are executed as CPU instructions. [SethBling] setup this table to hold values that tell the game to jump to the end credits. The console executes them and does as commanded, and the game is over just a few minutes after it began. The video below shows the speed run but doesn’t get too far into the technical details, but you can read more about it here.

This isn’t the first time we’ve seen this type of hack. Speed runs have been performed on Pokemon with very similar techniques. Another hacker managed to program and execute a version of single player pong all from within Pokemon Blue. We can’t wait to see what these game hackers come up with next. Continue reading “Reprogramming Super Mario World from Inside The Game”

Game Boy with Lithium Batteries and USB

[Alan] procured a few Game Boys from a Yahoo auction with the intent of using them for some other projects, but one of the Game Boys was shipped with a very corroded battery which had eaten up one of the terminals. When [Alan] had repaired it, he was left with a Game Boy with no battery terminal at all, so he decided to splice in some lithium-ion batteries.

Not only does the Game Boy now have a new battery pack, but [Alan] was able to source a USB charger to handle the batteries’ charging needs. However, he realized that his battery pack was 3.7 volts, while the Game Boy only needed 3 volts. To lower the voltage of the battery pack to the required voltage, [Alan] grabbed a 1N4148 diode and put it in series with the battery pack, which also helps prevent any accidental reverse polarity.

This isn’t the most technically advanced Game Boy hack we’ve ever seen but it’s great to see new life breathed into these classic video game systems. Not to mention that [Alan] saved some lithium batteries from the landfill!

Game Boy Cartridge Emulator Uses STM32

Game Boys may be old tech, but they still provide challenges to modern hackers. [Dhole] has come up with a cartridge emulator which uses an STMicroelectronics STM32F4 discovery board to do all the work. Until now, most flash cartridges used programmable logic devices, either CPLDs or FPGAs to handle the high-speed logic requirements. [Alex] proved that a microcontroller could emulate a cartridge by using an Arduino to display the “Nintendo” Game Boy boot logo. The Arduino wasn’t fast enough to actually handle high-speed accesses required for game play.

[Dhole] kicked the speed up by moving to the ARM Cortex-M4 based 168 MHz STM32F4. The F4’s  70 GPIO pins can run via internal peripherals at up to 100MHz, which is plenty to handle the 1MHz clock speed of the Game Boy’s bus. Logic levels are an issue, as the STM32 uses 3.3V logic while the Game Boy is a 5V device. Thankfully the STM32’s inputs are 5V tolerant, so things worked just fine.

Simple Game Boy cartridges like Tetris were able to directly map a ROM device into the Game Boys memory space. More complex titles used Memory Block Controller (MBC) chips to map sections of ROM and perform other duties. There were several MBC chips used for various titles, but [Dhole] can emulate MBC1, which is compatible with the largest code base.

One of the coolest tricks [Dhole] implemented was displaying a custom boot logo. The Game Boy used the “Nintendo” logo as a method of copyright protection. If a cartridge didn’t have the logo, the Game Boy wouldn’t run. The logo is actually read twice – once to check the copyright info, and once to display it on the screen. By telling the emulator to change the data available at those addresses after the first read, any graphic can be displayed.

If you’re wondering what a cartridge emulator would be useful for (other than pirating games), you should check out [Jeff Frohwein’s] Gameboy Dev page! [Jeff] has been involved in Game Boy development since the early days. There are literally decades of demos and homebrew games out there for the Game Boy and various derivatives. .

Continue reading “Game Boy Cartridge Emulator Uses STM32″

Hacklet 22 – Retro Console Projects

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!

52001We 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.

 

snes[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!

rgb[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!

snes2[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!

Using Kinect To Play Super Mario Bros 3 On NES Ensures Quick Death

Why do only the new game consoles get all the cool peripherals? Being a man of action, [Paul] set out to change that. He had a Kinect V2 and an original Nintendo and thought it would be fun to get the two to work together.

Thinking it would be easiest to emulate a standard controller, [Paul] surfed the ‘net a bit until he found an excellent article that explained how the NES controller works. It turns out that besides the buttons, there’s only one shift register chip and some pull up resistors in the controller. Instead of soldering leads to a cannibalized NES controller, he decided to stick another shift register and some resistors down on a breadboard with a controller cable connected directly to the chip.

Kinect4NES wiring

An Arduino is used to emulate the buttons presses. The Arduino is running the Firmata sketch that allows toggling of the Arduino pins from a host computer. That host computer runs an application that [Paul] wrote himself using the Kinect V2 SDK that converts the gestures of the player into controller commands which then tells the Arduino which buttons to ‘push’. This is definitely a pretty interesting and involved project, even if the video does make it look very challenging to rescue Princess Toadstool from Bowser and the Koopalings!

If you’d like to help the project or just build one for yourself, check out the source files on the Kinect4NES GitHub page.

Continue reading “Using Kinect To Play Super Mario Bros 3 On NES Ensures Quick Death”

Demystifying NTSC Color And Progressive Scan

NTSC

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.