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”

Doing What Id Couldn’t: Returning Music To Jaguar Doom

While the rest of the world has by and large forgotten the Atari Jaguar, the generously marketed console still has a fan base, and even some dedicated hackers prodding away at it. [Cyrano Jones] is one of them, and he managed something many considered unthinkable: restoring in-game music to the Jaguar port of Doom.

The Jaguar version of the classic shooter was developed by id Software themselves, and is generally considered one of the better console ports. For example, the large number of buttons on the Jaguar controller allowed players to select weapons directly rather than having to cycle through them. Unfortunately, the complete lack of music during gameplay was a glaring omission that took several points off of an otherwise fairly solid presentation.

The common culprit blamed for this was that the Jaguar’s DSP was already being used for math processing, so it didn’t have any cycles left for music playback. Coupled with a tight deadline, id probably cut their losses and released it without in-game music rather than try and spend more time engineering a solution. To compensate for the lack of in-game music, id did include the famous soundtrack in the intermission screens rather than entirely strip it out.

As [Cyrano] found out by studying the source code that’s been available since 2003, sound effects in the Jaguar version of Doom are played using something called a “ring buffer”: a cyclical fixed-length data buffer which constantly gets outputted as audio. With a patch of unused memory he could fit a second ring buffer in, rendering the music to it with close to no performance hit elsewhere in the code and then mixing both buffers for the final audio output. It looks as though id already had some of this solution in place, but with enough issues that forced them to abandon the idea in order to release the game on time.

Software hacks are not the only things that the Jaguar fan base can do though, and a fine example of a hardware one is this custom mod showing what it could’ve looked like with the CD add-on in an integrated unit.

Continue reading “Doing What Id Couldn’t: Returning Music To Jaguar Doom”

The Evolution Of Wireless Game Controllers

The story goes that Atari was developing a premium model of their popular home video game console, the Atari 2600, for the 1981 fiscal year. Internally known as the Stella RC, this model revision promised touch sensitive game selection toggles, LED indicators, and onboard storage for the controllers. The focus of the project, however, was the “RC” in Stella RC which stood for remote control. Atari engineers wanted to free players from the constraints of the wires that fettered them to their televisions.

Problem with the prototypes was that the RF transmitters in the controllers were powerful enough to send a signal over a 1000 ft. radius, and they interfered with a number of the remote garage door openers on the market. Not to mention that if there were another Stella RC console on the same channel in an apartment building, or simply across the street, you could be playing somebody else’s Pitfall run. The mounting tower of challenges to making a product that the FCC would stamp their approval on were too great. So Atari decided to abandon the pioneering Stella RC project. Physical proof of the first wireless game controllers would have been eliminated at that point if it were created by any other company… but prototypes mysteriously left the office in some peculiar ways.

“Atari had abandoned the project at the time…[an Atari engineer] thought it would be a great idea to give his girlfriend’s son a videogame system to play with…I can’t [comment] about the relationship itself or what happened after 1981, but that’s how this system left Atari…and why it still exists today.”

Joe Cody, Atari2600.com

Atari did eventually get around to releasing some wireless RF 2600 joysticks that the FCC would approve. A couple years after abandoning the Stella RC project they released the Atari 2600 Remote Control Joysticks at a $69.95 MSRP (roughly $180 adjusted for inflation). The gigantic price tag mixed with the video game market “dropping off the cliff” in 1983 saw few ever getting to know the bliss of wire-free video game action. It was obvious that RF game controllers were simply ahead of their time, but there had to be cheaper alternatives on the horizon.

Out of Sight, Out of Control with IR Schemes

Nintendo AVS 1985 Display
Nintendo AVS console deck and IR controller on display.

Video games were a dirty word in America in 1985. While games themselves were still happening on the microcomputer platforms, the home console business was virtually non-existent. Over in Japan, Nintendo was raking in money hand over fist selling video games on their Famicom console. They sought to replicate that success in North America by introducing a revised model of the Famicom, but it had to impress the tech journos that would be attending its reveal at the Consumer Electronics Show (CES).

The prototype system was called the Nintendo Advanced Video System (AVS). It would feature a keyboard, a cassette tape drive, and most importantly two wireless controllers. The controllers used infrared (IR) communication and the receiver was built-into the console deck itself. Each controller featured a square metallic directional pad and four action buttons that gave the impression of brushed aluminum. The advancement in video game controller technology was too good to be true though, because the entire system received a makeover before releasing as the Nintendo Entertainment System (NES) that Christmas. The NES lacked the keyboard, the tape drive, and the IR controllers and its change in materials hardly captured the high-end flash of the AVS. The removal of IR meant the device was cheaper to manufacture. A decision that ultimately helped the NES to become a breakout success that in turn brought back dedicated video game consoles single-handedly.

Continue reading “The Evolution Of Wireless Game Controllers”