Hackaday Prize Entry: A Pic32 Game Console

The official theme of the 2015 Hackaday Prize is to build something that matters. Solving the challenges facing the world is hard, and retro video games, despite what you read on Hackaday, do not matter.

That doesn’t mean there’s not space for the weird, esoteric builds out there; we have a best product prize that will dump $100k, a six month residency in the Hackaday Design Lab, and contacts with a lot of engineers with expertise in manufacturing. [Alex]’s extremely ow cost game console on a Pic32 is exactly what this prize category is looking for.

[Alex]’s project – XORYA – is based on the Pic32MX170F256, a chip that runs up to 50MHz, has 256kB of flash, and a full 64k of RAM. This is far beyond what the guys at Atari imagined back in the 70s, allowing the XORYA to have some amazing graphics.

Right now most of the build is dedicated to fleshing out the video system, and [Alex] has a great demo: rendering the Mandelbrot set in real time in 16 colors on an NTSC display with a resolution of 160×100. That’s a single-chip game console that’s right up there with the Uzebox, and a great example of the potential of the best product category for this year’s Hackaday Prize.


The 2015 Hackaday Prize is sponsored by:

Building A Modern Retro Console

There are a few dozen classic re-imaginings of classic game consoles, using hardware ranging from the ATMegas of the Uzebox to everyone’s favorite, stuffing some ROMs on a Raspi and calling it a day. You don’t necessarily learn anything doing that, which puts [Mike]’s custom game console head and shoulders above the rest.

The build started off as a plan for a Z80 computer with a dual ATMega GPU. He progressed far enough in the design where it would have been a masterpiece, but the inability to mill double-sided boards at home killed the design. Plans then moved on to an FPGA, then to an ATMega with the Analog Device AD725 PAL/NTSC encoder chip. That idea had a similar architecture to the Uzebox, but [Mike] wanted more power. He eventually settled on a PIC32 with the AD725.

This setup was capable of pumping out some impressive graphics, but for moving bits to a screen, you need DMA. [Mike] ran into a problem where the DMA timer runs at a maximum rate of 3.7 MHz. It’s a problem documented in a few projects, leading [Mike] to change his plan once again, this time to the STM32F4.

The bugs are worked out, and now [Mike] can stream a whole lot of pixels to a screen while still having some processing power left over to play a game. It’s a project that’s more than a year and a half old at this point, and so far he’s learned a lot.

Arduino Tetris on a Multiplexed LED Matrix

[Alex] needed a project for his microcomputer circuits class. He wanted something that would challenge him on both the electronics side of things, as well as the programming side. He ended up designing an 8 by 16 grid of LED’s that was turned into a game of Tetris.

He arranged all 128 LED’s into the grid on a piece of perfboard. All of the anodes were bent over and connected together into rows of 8 LED’s. The cathodes were bent perpendicularly and forms columns of 16 LED’s. This way, if power is applied to one row and a single column is grounded, one LED will light up at the intersection. This method only works reliably to light up a single LED at a time. With that in mind, [Alex] needed to have a very high “refresh rate” for his display. He only ever lights up one LED at a time, but he scans through the 128 LED’s so fast that persistence of vision prevents you from noticing. To the human eye, it looks like multiple LED’s are lit up simultaneously.

[Alex] planned to use an Arduino to control this display, but it doesn’t have enough outputs on its own to control all of those lights. He ended up using multiple 74138 decoder/multiplexer IC’s to control the LED’s. Since the columns have inverted outputs, he couldn’t just hook them straight up to the LED’s. Instead he had to run the signals through a set of PNP transistors to flip the logic. This setup allowed [Alex] to control all 128 LED’s with just seven bits, but it was too slow for him.

His solution was to control the multiplexers with counter IC’s. The Arduino can just increment the counter up to the appropriate LED. The Arduino then controls the state of the LED using the active high enable line from the column multiplexer chip.

[Alex] wanted more than just a static image to show off on his new display, so he programmed in a version of Tetris. The controller is just a piece of perfboard with four push buttons. He had to work out all of the programming to ensure the game ran smoothly while properly updating the screen and simultaneously reading the controller for new input. All of this ran on the Arduino.

Can’t get enough Tetris hacks? Try these on for size.

Repairing and Reviewing a 1976 PONG Clone

Hackaday alum [Todd] has been searching for an old PONG clone for the last two years. This variant is called, “The Name of the Game”. [Todd] has fond memories of playing this game with his sister when they were young. Unfortunately, being the hacker that he is, [Todd] tore the game apart when he was just 14 to build his own Commodore 64 peripherals. He’s been wanting to make it up to his sister ever since, and he finally found a copy of this game to give to his sister last Christmas.

After opening up the box, [Todd] quickly noticed something strange with the power connector. It looked a bit charred and was wiggling inside of the enclosure. This is indicative of a bad solder joint. [Todd] decided he’d better open it up and have a look before applying power to the device.

It was a good thing he did, because the power connector was barely connected at all. A simple soldering job fixed the problem. While the case was still opened, [Todd] did some sleuthing and noticed that someone else had likely made repairs to several other solder joints. He also looked for any possible short circuits, but everything else looked fine. The system ended up working perfectly the first time it was started.

The end of the video shows that even after all this time, simple games like this can still capture our attention and be fun to play for hours at a time. [Todd] is working on part 2 of this series, where he’ll do a much more in-depth review of the system. You can watch part 1 below. Continue reading “Repairing and Reviewing a 1976 PONG Clone”

Boxing Trainer Uses DIY Force Sensors

A team of Cornell students have designed and built their own electronic boxing trainer system. The product of their work is a game similar to Whack-A-Mole. There are five square pads organized roughly into the shape of a human torso and head. Each pad will light up based on a pre-programmed pattern. When the pad lights up, it’s the player’s job to punch it! The game keeps track of the player’s accuracy as well as their reaction time.

The team was trying to keep their budget under $100, which meant that off the shelf components would be too costly. To remedy this, they designed their own force sensors. The sensors are basically a sandwich of a few different materials. In the center is a 10″ by 10″ square of ESD foam. Pressed against it is a 1/2″ thick sheet of insulating foam rubber. This foam rubber sheet has 1/4″ slits cut into it, resulting in something that looks like jail bars. Sandwiching these two pieces of foam is fine aluminum window screen. Copper wire is fixed the screen using conductive glue. Finally, the whole thing is sandwiched between flattened pieces of corrugated cardboard to protect the screen.

The sensors are mounted flat against a wall. When a user punches a sensor, it compresses. This compression causes the resistance between the two pieces of aluminum screen to change. The resistance can be measured to detect a hit. The students found that if the sensor is hit harder, more surface area becomes compressed. This results in a greater change in resistance and can then be measured as a more powerful hit. Unfortunately it would need to be calibrated depending on what is hitting the sensor, since the size of the hitter can throw off calibration.

Each sensor pad is surrounded by a strip of LEDs. The LEDs light up to indicate which pad the user is supposed to hit. Everything is controlled by an ATMEGA 1284p microcontroller. This is the latest in a string of student projects to come out of Cornell. Make sure to watch the demonstration video below. Continue reading “Boxing Trainer Uses DIY Force Sensors”

STEAM Carnival Hacker Preview Day

Last week we wrote about the guys over at TwoBitCircus and their upcoming STEAM Carnival. This Thursday we managed to make it down to the Hacker Preview day where they showed us all the toys and games that will be exhibited over the weekend.

The preview day went pretty well until the evening, when unexpected power problems occurred and the site lost power for a little while. But this is why you have a preview day right? Organizer [Brent Bushnell] even commented that he should have put a BETA badge on the ticket. Thankfully the outage coincided with the food truck arriving so everyone stopped for a burger.

Sadly all the fire based pieces were not active on the preview day since they didn’t have the appropriate safety measures in place yet, but they did get to show us most of their games. My personal favorites were the Hobby Horse Racing, and the Laser Foosball.

Here’s a quick run down of some of the stand out pieces.

Continue reading “STEAM Carnival Hacker Preview Day”

Sprite Graphics Accelerator on an FPGA

A demo running on a FPGA sprite accelerator

Graphics accelerators move operations to hardware, where they can be executed much faster. This is what allows your Raspberry Pi to display high definition video decently. [Andy]’s latest build is a 2D sprite engine, featuring hardware accelerated graphics on an FPGA.

In the simplest mode, the sprite engine just passes commands through to the LCD. This allows for basic control. The fun part sprite mode, which allows for sprites to be loaded onto the FPGA. At that point, you can show, hide, and move the sprite. By overlapping many sprites, you something like the demo shown above.

The FPGA is from Xilinx, and uses their Block RAM IP to store the state of the sprites. The actual sprite data is contained on a 128 Mb external flash chip, since they require significant space.

The game logic runs on a STM32 Cortex M4 microcontroller which communicates with the FPGA and orders the sprites around. The FPGA then deals with generating frames and sending them to the LCD screen, freeing up the microcontroller.

If you’re wondering about the LCD itself, it’s 3.2″, 640 x 360, and taken from a Ericsson U5 Vivaz cellphone. [Andy] has a detailed writeup on reverse engineering it. After the break, he gives us a video overview of the whole system.

Continue reading “Sprite Graphics Accelerator on an FPGA”