Squid-Con Brings Joy To All

While we’re always happy to see accessibility aids come into fruition, most of them focus on daily tasks, not that there’s anything wrong with that. But what about having some fun? That’s the idea behind [Akaki Kuumeri]’s accessibly-awesome Joy-Con controller, the Squid-Con, which provides access to every button with just one hand. It even has tripod and AMPS mounts.

The joysticks themselves are controlled with the thumb and pinky, although some of [Akaki]’s beta testers changed it up a bit. That’s okay, because it’s designed to be comfortable in a variety of positions for either hand. As for the ABXY buttons, those are actuated using 3D-printed arms that connect to a central piece which [Akaki] calls the turbine.

But perhaps the coolest part of this project is the flexures that actuate the shoulder buttons (L, R, zL, and zR) on the controllers. It’s a series of four arms that are actuated by bringing the fingers back toward the palm. If all of this sounds confusing, just check out the video after the break.

We love flexures around here, and we’ve seen them in everything from cat feeding calendars to 6-DOF positioners to completely new kinds of joysticks.

Continue reading “Squid-Con Brings Joy To All”

Decompiling Sonic Runners

Usually, when you hear about games being decompiled and rebuilt, the games are often decades-old relics, loving and saved from the ravages of time. [MattKC] recently set out to decompile the 2015 game Sonic Runners.

The game was a 2D endless runner released on mobile platforms. Despite getting praise for the gameplay, it received mixed reviews for the pop-up ads and pay-to-play elements. A little over a year later, the game was discontinued. However, the game required a constant online connection, so once the servers were offline, it rendered the over five million downloads unplayable.

A team of developers worked to reverse engineer the server, and with a little bit of binary hacking, the client could be patched to connect to a community-hosted server instead. However, as phones with notched displays came out and suggestions for improvements stacked up, the community realized a new client would bring immense benefits. Compared to many decompilation projects, Sonic Runners was pretty easy as it uses Unity, which means most of the code is in C#. Unfortunately, the build of Unity used by the game is from 2012, meaning many of the tools designed for much later versions of Unity were inoperable.

However, one native code library called UnmanagedProcess was designed to confuse reverse engineering efforts. The library handled AES encryption and communication with the server. Luckily, the library was a later addition, and earlier versions of its functions still lingered in the C# code. Since an open source server already existed, it was trivial to validate the changes. Additionally, all the shaders were in OpenGL Shading Language (GLSL), which meant rewriting them in High-Level Shading Language (HLSL) and checking that they matched the original GLSL when building for Android.

Now the client has new game modes, no ads, and a proper offline mode. The community continues adding new features and refining the game, which is very satisfying. If you’re curious about reverse engineering, [Matthew Alt] can help you get started.

Continue reading “Decompiling Sonic Runners

Automation For The NES

Old hardware might not be anywhere close to as powerful as modern technology, but it does have a few perks. Aesthetics can of course drive the popularity of things like retro gaming systems, but the ease of understanding the underpinnings of their inner workings is also critical. The Nintendo Entertainment System, now nearly four decades old, is a relatively simple machine by modern standards and this lends the system to plenty of modifications, like this controller that allows the system to be somewhat automated.

The original NES controller used a fairly simple shift register to send button presses to the system. The system outputted a latch signal to the controller, the shift register would take as input the current state of the buttons, and then would send them one-by-one to the system at a rate of around 1000 times per second. These signals can be sent without a controller easily enough, too. This build uses a CD4021 shift register, which is the same as the original controller, but instead of reading button states it accepts its inputs from a separate computer via a latching circuit. In this case, the separate computer is a custom design that came about through adapting cassette storage for a 6502-based computer, but it could come from anything else just as easily.

With this system in place, it’s possible to automate gameplay to some extent. Since the system can’t get feedback about the game in its current state, it requires some precise timing to get it to play the game well, and a lot of tuning needs to go into it. This isn’t just a one-off, either. Similar methods are how we get tool-assisted speedruns of games and although these are often done in emulators instead of on real hardware, they can result in some interesting exploits.

Continue reading “Automation For The NES”

Install ChimeraOS And Never Leave The Sofa

There are some projects that initially don’t seem to make sense, but actually turn out to have valid use cases. ChimeraOS appears to be one of those. The idea is that if you own a gaming PC, but it is not necessarily located where you want to be all the time (like in a gaming den or office for example) then ChimeraOS allows you to play games on it remotely via a local machine. That machine may be a media PC attached to your main TV, or perhaps a mobile device like a steam deck.

With support for AMD GPUs only, there is one issue with deployment — if you’re an Nvidia owner you’re out of luck — the premise is to be able to boot up into a gaming-friendly environment with minimal fuss. Hook up a controller and you’re good to go. Support is also there for a few mobile devices, specifically some Aokzoe, Aya Neo, and OneXPlayer devices as well as some preliminary support for the Asus ROG Ally not to mention the Steam Deck as we touched on earlier. From a software perspective, it obviously supports the Steam platform but also Epic Games, Good Old Games (GOG), and tentatively a mention of console platforms. Sadly the website doesn’t mention much detail on that last bit, but there are some tantalizing hints in the project’s Twitter/X/whatever feed. Reading the release notes, there are mentions of PCSX2 (Playstation 2) Super Game Boy and Atari platforms, so digging into the GitHub repo might be instructive, or you know, actually installing it and trying. This scribe doesn’t own an AMD GPU so that isn’t an option, but do drop us a line in the comments if you’ve tried it and how it works for you.

Many of us at Hackday are avid gamers, especially of the retro kind, which is why we really like these projects. Here’s a nice game controller you can print yourself. For self-builds, there’s nothing quite like the satisfaction of a DIY arcade machine, but what if you think outside the box?

Running DOOM In A Keycap Takes Careful Work

Shoehorning DOOM into different hardware is a classic hacker’s exercise, and [TheKeebProject] managed to squeeze the 1993 classic into a custom keycap with the help of a Raspberry Pi RP2040, a custom PCB, and a clear resin enclosure. It even has a speaker for sound!

All processing is done inside the keycap, which is a clever feat. There is a USB connection, but it’s only for power and keyboard controls, so it’s completely playable without needing a whole lot of external support. The custom PCB and code are based off an earlier RP2040 DOOM project, and [TheKeebProject] has certainly made it their own by managing to get everything so tightly integrated. There’s a quick video mashup embedded below. There’s still a bit of work to do, but the code and design files are all on GitHub should you wish for a closer look.

Making DOOM physically smaller is a good challenge, but we’d like to remind fans that we’ve also seen DOOM shrink in terms of power consumption, all the way down to 1 mW.

Continue reading “Running DOOM In A Keycap Takes Careful Work”

Super Mario In Sed, Sort Of

We definitely needed to reach for a sed reference guide for this one, but looking at the animated GIF of the script running, it is recognizably Super Mario Bros. albeit with minimal gameplay beyond jumping obstacles and avoiding or destroying koopas et al. Creator [Ivan Chebykin] is for certain a master of the dark arts.

Digging in a bit deeper, it’s not strictly speaking 100% sed. A wrapper shell script is required to interface to the shell and grab the keyboard input to pass along. This is simply because sed is a stream processor, and as such it requires text to be fed into it, and it produces a text output. It has no way of reading the terminal input directly, hence the wrapper script. However, all the game logic and ‘graphics’ rendering is pure sed, so that’s perfectly reasonable.

Such programming demos are a great way to hone the finer points of various tools we use every day, whilst not being serious enough to matter if we fail. Pushing the boundaries of what can be done with these basic nuts and bolts we take for granted, is for us the very essence of software hacking, and bravo we say.

Reckon you could top this? Show us! In the meantime, here’s a guide to hacking the recently released Game and Watch, and then doing the decent thing and running DOOM on it. Finally, sed is notoriously tricky to work with, so to help here’s a graphical debugger to make things a little clearer.

It’s Snake, In A QR Code, But Smaller

We’re not sure that many of you have recognised the need in your life for an x86 machine code program encoded into a QR code, but following on from someone else work [donno2048] has created a super-tiny Snake clone in assembly which comes in at only 85 bytes long. It fits far better in a QR code than the previous effort, but perhaps more useful is a web page demo which runs an in-browser DOS compatibility library. We followed the compilation instructions and got it running on our Manjaro installation, with the result of a somewhat unplayable but recognisable Snake, we’re guessing because it was written for a slower platform. The web version is more usable, and allows us to investigate its operation more thoroughly.

To achieve a working game in so little code is an impressive feat, and since we found different keys responded on machines with different keyboards we’re curious how it does its keyboard input. Also we think it has the Snake bug where turning back on yourself means instant game over. We would be interested to hear the views in the comments of readers who know something about x86 assembly, to help explain these points.