Pi Pico Project Plays Pong Perfectly

May 13, 2021 by Zach Zeman 9 Comments

Even as technology keeps progressing, we find ourselves coming back to the classics again and again. Pong is quite possibly the classic game, and the Raspberry Pi Pico is one of the latest microcontrollers. So [Nick Bild] combined them expertly in his Pico Pong project, which includes gesture controls and a custom VGA output.

Rolling your own VGA signal is no simple feat, and this project takes full advantage of the Pico’s features to pull it off. Display data is buffered in memory, while a Programmable I/O (PIO) program reads straight from the buffer via Direct Memory Access (DMA) and writes straight to the display. This allows for nanosecond-precision while leaving the CPU free to handle inputs and run the game. Even with the display work offloaded, the ARM processor had to be massively overclocked at 258 MHz, well over its 133 MHz specs, to make things run smoothly. And still [Nick] found himself limited to a 640×350 resolution and serendipitously-retro-accurate monochrome color scheme.

Gesture controls come from a pair of IR light beams hooked up to the GPIO. IR LEDs shine up toward reflectors, and the light bounces back down to detectors. Blocking one of the beams causes your paddle to move up or down, which looks pretty responsive in the video (embedded below).

We’ve seen [Nick] play Pong before, though at that time it was handheld and based on the venerable 6502. And just recently we wrote about the Raspberry Pi Pico powering another classic game: Snake.

Continue reading “Pi Pico Project Plays Pong Perfectly” →

Solid Oak Arcade Cabinet: When Particle Board Won’t Do

January 8, 2021 by Bryan Cockfield 25 Comments

Having an arcade cabinet of one’s own is a common dream among those who grew up during the video game arcade heyday of the 80s and early 90s. It’s a fairly common build that doesn’t take too much specialized knowledge to build. This cabinet, on the other hand, pulled out all of the stops for the cabinet itself, demonstrating an impressive level of woodworking expertise.

The cabinet enclosure is made with red oak boards, which the creator [Obstreperuss] sawed and planed and then glued together to create the various panels (more details are available on his Imgur album). The Mario artwork on the sides and front aren’t just vinyl stickers, either. He used various hardwoods cut into small squares to create pixel art inlays in the oak faces. After the fancy woodwork was completed, the build was finished out with some USB arcade controllers, a flat-panel screen, and a Raspberry Pi to run the games.

While the internals are pretty standard, we have to commend the incredible quality of the woodworking. It’s an impressive homage to classic arcade machines and we wouldn’t mind a similar one in our own homes. If you’re lacking the woodworking equipment, though, it’s possible to get a refined (yet smaller) arcade cabinet for yourself with a 3D printer instead.

Continue reading “Solid Oak Arcade Cabinet: When Particle Board Won’t Do” →

Jerry Lawson And The Fairchild Channel F; Father Of The Video Game Cartridge

July 14, 2020 by Jenny List 14 Comments

The video game console is now a home entertainment hub that pulls in all forms of entertainment via an internet connection, but probably for most readers it was first experienced as an offline device that hooked up to the TV and for which new game software had to be bought as cartridges or for later models, discs. Stepping back through the history of gaming is an unbroken line to the 1970s, but which manufacturer had the first machine whose games could be purchased separately from the console? The answer is not that which first comes to mind, and the story behind its creation doesn’t contain the names you are familiar with today.

The Fairchild Channel F never managed to beat its rival, the Atari 2600, in the hearts of American youngsters so its creator Jerry Lawson isn’t a well-known figure mentioned in the same breath as Atari’s Nolan Bushnell or Apple’s two Steves, but without this now-forgotten console the history of gaming would have been considerably different.

Continue reading “Jerry Lawson And The Fairchild Channel F; Father Of The Video Game Cartridge” →

Dad Makes Xbox And Nintendo Work Together To Bridge The Accessibility Gap

January 28, 2020 by Erin Pinheiro 11 Comments

In the last few years, console and controller manufacturers have been making great strides in accessibility engineering in order to improve the inclusiveness of people with different motor disabilities into the gaming world. One such example is the Xbox Adaptive Controller, which [Rory Steel] has used to build his daughter a fully customized controller to allow her to play Breath of the Wild on the Nintendo Switch.

His build plan is outlined in just a few Twitter videos, and sadly we don’t have a detailed walkthrough on how to build our own just yet, though he mentions plans on making such guide in the future. In the mean time, it’s not too hard to speculate on some specifics. The Adaptive Controller can use USB-C for communication, as the Switch also does with its Pro controller in wired mode. Interfacing the two is as simple as using an adapter to bridge the gap between the two vendors.

The joysticks are each wired into generic gamepads which act as the left and right sticks, each one being a separate USB input into the Adaptive Controller, while each one of the button inputs is broken out to 3.5mm jacks on its back, making them dead simple to wire to the sixteen arcade buttons surrounding the sticks. The layout might look unconventional to us, and [Rory] mentions this is simply a prototype that will be improved upon in the future after real-world testing. The size of his daughter’s smile tells us this is already a success in her eyes.

This is not the first time we’ve seen a build with the Xbox Adaptive Controller, and it’s nice to see just how well it enables parents to build their kids controllers they can use more easily, seeing as how before its introduction these kinds of controllers usually required the expertise for tearing expensive official controllers apart in ways the manufacturers never expected. We can only hope that going forward, this sort of accessibility becomes more the norm and less the exception.

[via Kotaku, thanks Itay for the tip!]

All The Games In One Cartridge

January 27, 2020 by Bryan Cockfield 16 Comments

The original Game Boy was a smash success for Nintendo and has an amazing collection of games. You might relive some childhood nostalgia by booting up a Game Boy emulator, but to really get the full experience you’ll need the battery-draining green-tinted original hardware. Thanks to modern technology you can also load all of the games at one time on the original hardware with this STM32 cartridge that fits right in.

The device can load any Game Boy game (and homebrews) and ROMs can be sent to the cartridge via USB. There were are a lot of hurdles to getting this working properly, the largest of which is power management. A normal cartridge has a battery backup for save data, but using a small coin cell to run an STM32 would kill the battery quickly. To get around that, the cartridge writes the states to nonvolatile memory and then shuts itself off, although this has the side effect of crashing the Game Boy.

The creator of this project, [Emeryth], noted that we featured a similar project from [Dhole] a few years ago, also involving an STM32. [Emeryth] decided that it would be fun to build his own project anyway, and it’s certainly an interesting take on GameBoy hacking. He also has the files for this project available on his Git Hub page.

Porting Quake To An IPod Classic Is No Easy Task

January 25, 2020 by Erin Pinheiro 9 Comments

We didn’t think we’d see another hack involving the aging iPod Classic here on Hackaday again, yet [Franklin Wei] surprises us with a brand new port of Quake for the sixth-generation iPod released some thirteen years ago. Is Quake the new 90s FPS that’ll get put into every device hackers can get their hands on?

The port works on top of RockBox, a custom firmware for the iPod and other portable media players. This isn’t the first game on the device. A source port of Doom has been available for years. [Franklin] decided to use Simple DirectMedia Layer (SDL) to make his job easier. That doesn’t mean this was an easy task though, as [Franklin] describes very interesting bugs that kept him from finishing his work for about two years.

The first problem was that the GCC compiler he was using was apparently not optimizing time-critical sound mixing routines. [Franklin] decided enough was enough and dug into ARM assembly to re-write those parts of the code by hand. He managed to squeeze out a speed increase of about 60%. Even better, he ran into a prime example of a bug that would get triggered by a very specific sound sample length running through his code. Thankfully, with all of that sorted, the port is now released and we can all enjoy cramping our hands around tiny screens to frag some low-poly monsters.

If you need to repair your sixth-generation iPod before you can do that though, no need to worry since they seem to not be so hard to service by yourself. And if the battery life and disk space aren’t quite what they used to be, there’s also the option to bulk it up for winter. Check out the Quake port in action after the break.

Continue reading “Porting Quake To An IPod Classic Is No Easy Task” →

Exploring Early ’90s Video Game Architecture With Another World

January 17, 2020 by Sharon Lin 21 Comments

Curious about past computer architectures? Software engineer [Fabien Sanglard] has been experimenting with porting Another World, an action-adventure platformer, to different machines and comparing the results in his “Polygons of Another World” project.

The results are pretty interesting. Due to the game’s polygon-based graphics, optimizations vary widely across different architectures, with tricks allowing the software to run on hardware released five years before the game’s publication. The consoles explored are primarily from the early ’90s, ranging from the Amiga 500, Atari ST, IBM PC, and Super Nintendo to the Sega Genesis.

The actual game contains very little code, with the original version at 6000 lines of assembly and the PC DOS executable only containing 20 KiB. The executable simply exists as a virtual machine host that reads and executes uint8_t opcodes, with most of the business logic implemented with bytecode. The graphics use 16 palette-based colors, despite the Amiga 500 supporting up to 32 colors. However, the aesthetics still fit the game nicely, with some very pleasant pixel art.

There’s a plethora of cool tricks that emerge in each of the ports, starting with the original Amiga 500 execution. Prior to the existence of the CPU/GPU architecture, microprocessors had blitters – logic blocks that rapidly modified data within the memory, capable of copying large swathes of data in parallel with the CPU, freeing up the CPU for other operations.

To display the visuals, a framebuffer containing a bitmap drives the display. There are three framebuffers used, two for double buffering and one for saving the background composition to avoid redrawing static polygons. Within the framebuffer, several tricks are used to improve the graphical experience. For scenes with translucent hues, special values are interpreted from the framebuffer index by “reading the framebuffer index, adding 0x8 and writing back”.

Challenges also come when manipulating pixels given each machine’s CPU and bus bandwidth limitations. For filling in bits, the blitter uses a feature called “Area Fill Mode” that scans left to right to find edges, rendering the bit arrays with spaces between lines filled in. Since the framebuffer is stored in five separate areas of memory – or bitplanes – this requires drawing the lines and filling in areas four times, multiplying by the hundreds of polygons rendered by the engine. The solution was to set up a temporary “scratchpad” buffer and rendering a polygon into the clean space. The polygon can then get copied to the screen area with a masked blit operation since the blitter can render anywhere in memory.

Intrigued? The series continues with deep dives into Atari ST, IBM PC, and upcoming writeups on SEGA Genesis/MegaDrive.