Numbers are wonderful things when applied to technical specifications. Take [Bobricius]’ handheld Arduino-based game console. With an 8×8 LED matrix for a display it’s not going to win any prizes, but while he’s pushing the boundaries of dubious specification claims he’s not strictly telling any lies with his tongue-in-cheek statement that the graphics are 64-bit.
Jokes aside, it’s a neatly done build using a DIP version of the Arduino MCU and all through-hole components on a custom PCB. Power comes from a CR2032 cell, and it includes three buttons and a small piezoelectric speaker. He’s implemented a whole slew of games, including clones of Pong, Breakout, and Tetris, and judging by the video below it’s surprisingly playable.
Now you might look at this console and wonder what the big deal is. After all, there are plenty of similar designs to be found, and it’s nothing new. Of course, it’s a neat project for any hacker or maker, but we can see that this would make a great starter project for the younger person in your life who wants to try their hands at building something electronic. All through-hole construction for easy soldering, and a neat game at the end of it all.
He’s posted a full write-up of the design process as well as the hackaday.io page linked above, so if you fancy building one yourself there’s nothing to stop you too squeezing 64 bits of graphical goodness from an Arduino.
Continue reading “This Arduino Console Has 64 Bit Graphics”
There’s no holy war holier than establishing whether PC games are superior to console games (they are). But even so, there’s no denying that there are some good console titles out there. What if you’d still like to play them using a mouse and keyboard? If you’re [Agent86], you’d build up the most ridiculous chain of fun electronics to get the job done.
Now there is an overpriced off-the-shelf solution for this problem, and a pre-existing open-source project that’ll get the same job done for only a few bucks in parts. But there’s nothing like the fun in solving a problem your own way, with your own tangle of wires, darn it all! The details of the build span four (4!) pages in [Agent86]’s blog, so settle down with a warm cup of coffee.
Here’s the summary: an Xbox 360 controller is taken apart and turned into an Xbox controller. The buttons and joysticks are put under computer control via a Teensy microcontroller. GPIOs press the controller’s buttons, and digipots replace the analog sticks. Software on the Teensy drives the digipots and presses the buttons, interpreting a custom protocol sent over USB from the computer, which also gets some custom software to send the signals.
So if you’re keeping score: a button press on a keyboard is converted to USB, sent to a PC, converted to a custom serial protocol, sent to a Teensy which emulates a human for a controller that then coverts the signals back into the Xbox’s USB protocol. Pshwew!
Along the way, there’s learning at every stage, which is really the point of an exercise like this. And [Agent86] says that it mostly works, with some glitches in the mouse-to-joystick mapping. But if you’re interested in any part of this crazy chain, you’ve now got a model for each of them.
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.
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.
The PC Engine was pretty popular in Japan, but only the coolest kids in America had the US edition, the TurboGrafx16. These two systems weren’t exactly the same; the TurboGrafx-16’s data bus was flipped so the games were made to be incompatible, and the US games have a region lockout. [Kaz] looked at the existing hacks for running Japanese games on US systems, and every single one of them required modding a console. Thinking he could do better, he came up with the PC-Henshin, an adapter and CPLD that allows Japanese game to run on US consoles.
To take care of the mixed up lines on the PC card connector between the US and Japanese variants, a few adapter cards are available. That’s great, but they only solve one part of the compatibility problem. The region lockout routine found on nearly every American title mean PC Engine consoles can’t run TurboGrafx-16 games. [Kaz] used a small, cheap CPLD to read the data bus, patch everything as it is read out, and turns a Japanese console into something that can play American games.
Continue reading “A PC Engine to TurboGrafx-16 Converter”
[Dylan] created an easy to make gaming console with an Arduino Uno, a makeshift button, an analog stick, and a TFT LCD touchscreen shield. Plus, he fashioned together a simple button with some duct tape.
So far, he has made 2 games. One is the infamous Pong. The other is a ‘Guess the Number’ type experience. The whole project is run within the code, and does not access the bootloader directly like you would with 2boots or a regular Gameduino adapter.
Build instructions can be found on [Dylan]’s hackaday.io project page (linked above). Essentially, all that is needed is to gather up the supplies, then take the button and analog stick and complete a circuit, fitting the open wires into the slots at digital pin 9. Solder the wires in place and connect ground to ground, 5v to 5v, x to A4, and y to A5. Add the TFT shield, insert a micro SD card, and upload a game.
To see it in action, check out the video after the break:
Continue reading “The BlueOkiris Gameduino Console”
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.