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

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

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

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

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

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

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.

Adding A Co-Processor To Help SNES Games With Slowdown

The Super Nintendo port of Gradius III is notable for being close to the arcade original, with its large, bright and colorful graphics. However, due to the limitation of the console’s hardware, the port is also well known for having constant slowdowns during gameplay, particularly during later sections. [Vitor] hacked away at the game and made a patched version of the ROM use a co-processor to eliminate those issues.

The slowdown seen here in Gradius is not uncommon to SNES players, many games of that era suffer from it when several sprites appear on the screen at once. This is partially due to the aging CPU Nintendo chose, supposedly in order to maintain NES backwards compatibility before the idea got scrapped. Unable to complete its tasks by the time the next frame needs to be shown, the hardware skips frames to let the processor catch up before it can continue. This is perceived as the aforementioned slowdown.

Around the later stage of the SNES’s life, games started using additional chips inside the cartridges in order to enhance the console’s performance. One of them is the SA1, which is a co-processor with the same core as the main CPU, only with a higher clock rate. By using it, games had more time to run through the logic and graphics manipulation before the next frame. What [Vitor] did was port those parts of Gradius III to the SA1, essentially making it just like any other enhanced cartridge from back in the day.

Unlike previous efforts we’ve seen to overclock the SNES by giving it a longer blanking time, this method works perfectly on real unmodified hardware. You can see the results of his efforts after the break, particularly around stage 2 where several bubbles fill the screen on the second video.

Continue reading “Adding A Co-Processor To Help SNES Games With Slowdown”