Arduino Engine Runs Many Games

A few years ago, [Smashcat] ported a ZX Spectrum game called Manic Miner to the Arduino Uno. The Arduino has less memory than the original Spectrum did, so doing all this on an 8-bit microcontroller was no easy lift. Since then, parts of this original port have been adapted to produce a game engine, allowing [Smashcat] to port several other games to the Arduino Uno as well.

The engine is able to host a 2D map with the ability to scroll, at a resolution of 256×256, as well as up to nine sprites at the same time. The graphics are locked to 50 FPS, but only with a real Arduino Uno that has a crystal oscillator. Some replica boards do not have a timekeeping chip accurate enough to replicate the video signal, which is done without a framebuffer. That signal, as well as two PWM audio channels, are still generated directly as well, with only a few resistors needed to hook everything up to a monitor and a controller, including the option of using an NES controller.

With all of that running on the Arduino and it hooked up to the daughterboard that provides the controller interface as well as the resistors for the video signal to function and a driver for a speaker, the system now runs the original Manic Miner as well as three other games: Scramble, Space Invaders, and Pac Man.

The engine and the rest of the code are available on a GitHub page as well, and there’s even a WebAssembly version available to run various pieces of the software without the specific hardware. The original ZX Spectrum was an interesting machine too that still inspires builds like this, despite it being well over 40 years old now.

Hiding Virtualization From Other Software

The Kernel-based Virtual Machine (KVM) allows Linux systems to function as hypervisors without needing any extra software, but VMs created with it don’t behave exactly like real hardware does. Sometimes that’s important, though, so [sandwich] built a tool called vfio-native that obscures the fact that software might be running in a virtual machine.

There are plenty of the ways that virtual hardware differs from bare metal. The VM may behave slightly differently for obscure instructions in ways that are measurable, it may take slightly longer to perform some tasks, or the hypervisor may simply announce itself directly. vfio-native includes some kernel patches that solve some bugs which address the different behaviors, changes the way that the kernel identifies itself, and attempts to force the CPUs to behave in ways that real hardware would behave. With all of this applied to the virtual machine, it scores a 1/85 against a VM detection tool, with a standard KVM virtual machine scoring 10/85.

For anyone looking to test this out, it’s available in the AUR for Arch Linux. Also, it’s probably worth mentioning that there are more reasons to use this than cheating at Counter-Strike. For example, security researchers testing malware need to know how that software behaves when it thinks its on real hardware, and some may behave in benign ways when confined to virtual machines. Some licensed software also may disable itself when it detects its running in a VM, which can be a nuisance for things like software controlling industrial tools which only run on operating systems that are no longer maintained or hardware that can’t be found anymore. Some other tools we’ve seen before perform similar tasks as well.

Simple, Reliable RF Remote Control

Some of the first remote controls available to consumers used sound, visible light, or even just wires to communicate with their parent device. It was many years between these first rudimentary remotes before they standardized around infrared or RF signaling. Even then it was a while before remote controls were reliable enough to not have to think about anymore. They’ve gotten so good now that there are small modules available that let us quickly build these devices to perform all manner of tasks.

[Igor Brichkov] is demonstrating this project because his garage door remote control suddenly stopped working. The RF receiver and transmitter circuits are readily available and inexpensive, but they need some support circuitry to work properly. The transmitter is paired with an encoder which is provided a binary code by wiring various pins to power and ground. This “code” is sent to the receiver which has a decoder and listens for that specific code. When the codes match it changes the state of one of its pins, which is used in this case to short the garage door’s remote terminals and signal it to open the door.

Although the resulting handheld remote with its single button looks a bit like something from 1950s science-fiction, it’s an effective solution. Especially when compared to possibly trying to reprogram a proprietary remote, find one from a company that doesn’t exist anymore, or rebuild one that operates on a bizarre frequency. With access to the physical hardware, it turns out a lot of things are controlled by just shorting pins together, and anything can do that from wires to RF transmitters.

Continue reading “Simple, Reliable RF Remote Control” →

2026 Retrocomputing Challenge: I Would Do Anything For Serial Data

These days we take high-speed networking for granted, but it can be difficult to get vintage computers talking to modern machines. To help solve this problem [jaime] came up with Meatloaf which can provide files to a Commodore regardless of their location or medium of storage.

Meatloaf is an ESP32 device at its core, which plugs in to any of several Commodore computers through their IEC serial port. Many similar systems exist to bridge the gap between the modern world and the now-retro one, but this one connects to a dedicated service which points towards files no matter where they’re stored. There is some local storage, but it can also retrieve files from any active URL, and Meatloaf retrieves the files and then sends them to the Commodore over that serial link.

Part of what makes this unique is that the user doesn’t need to configure Meatloaf in any particular way, everything is done from the Commodore as long as the URL is known to the user. The system can even parse nested files like archive file types and send them along to the computer just like it would if they were on a period-correct floppy drive. There’s a GitHub project page as well for anyone looking to get into the weeds of this serial data interface.

Using An Unmodded GBA As A Music Synth

The style and sound of older video games is unique enough that they’re still copied in relatively modern games like Undertale, Celeste, or Shovel Knight. There’s also a vibrant chiptune community making music on the older hardware directly. Often this involves hardware modding or otherwise finding chips from older gaming systems to replicate that unique retro gaming sound authentically. But disassembling older systems is not always necessary. Take a look at this Game Boy Advance synthesizer which uses the GBA hardware with no modifications at all.

The key to making this work is the GBA’s multiboot feature, which allowed these systems to send executable code over a link cable to other consoles which didn’t have cartridges. This meant that friends could play multiplayer games without each one needing their own cartridge, but it also means that nowadays people can send their own custom software directly to the console’s RAM without much extra effort. To run the synthesizer software, the GBA is connected to a computer, the software is started, and then when the GBA is powered on the snythesizer is automatically loaded into its RAM. The audio output is played over the headphone jack, and various controls are available on the computer and on the console.

In the video linked below, [Andy] is using the GBA with some other musical hardware and the sounds he’s getting from the unmodified console are impressive. It could certainly be a go-to for anyone interested in getting started in this style of music or who doesn’t want to do something like take apart an original Sega Genesis for the audio circuitry.

Continue reading “Using An Unmodded GBA As A Music Synth” →

NASA Batteries Survive Extreme Cold And Heat

One of the major limits of mass-produced batteries is the electrolyte. From lead-acid to lithium ion, there’s some temperature where the electrolyte will freeze and cause all sorts of problems, from cracked casings to various non-favorable chemical changes in the battery itself. But if there’ a solid electrolyte available, many of the downsides of charging and discharging batteries in extreme cold disappear. These batteries developed by NASA, for example, can survive some wild temperature swings.

The electrolytes used for these batteries are either a ceramic or polymer electrolyte, both of which are solid. In testing, the batteries could meaningfully operate at temperatures of -60° C and up to 80° C on the high end. Further, the solid electrolyte helps protect them even outside of these temperature ranges. Bringing the battery temperature down to -170° C was not enough to damage the battery at all, and using a small heater to bring the temperature back up to its operating range showed no capacity losses or other issues.

These batteries are eventually intended for use in some of the coldest places outside of Earth still accessible to humans (in theory) such as the south pole of the Moon where the temperatures regularly get that cold and stay cold for long periods, especially in permanently-shadowed craters or places on the Moon we might want to put some telescopes eventually. There are other terrestrial situations where these batteries might be useful as well, since they don’t need as much thermal management as other battery types.

Car’s Camera Footage Backed Up To NAS

For as many sensors, cameras, and computers as there are on modern cars, they ought to be a dream to poke around in and customize to one’s liking. Unfortunately they’re generally plagued by the same locked-down, proprietary software that most consumer electronics ship with, making it very difficult to interact with these systems in ways the manufacturer doesn’t approve of. There are a few exceptions to this rule, though, and [Sasha] built this system which backs up the footage from their electric car’s on-board cameras automatically to a NAS.

The system is built around a Raspberry Pi Zero 2 W which plugs directly into a USB port in the car’s glovebox. To set it up, the software only needs to be flashed onto the Pi and then it can be controlled from a smartphone. It can connect to any NAS over a variety of protocols and keeps track of what footage has been backed up, and can even automatically restart a backup if the car drives away before it has completed. It also automatically frees up space on the car’s internal drives by deleting any files that have already been synced to the NAS. All of the data is kept in the user’s control as well, and nothing leaves the LAN unless the user sets up backups to a cloud service on their own.

If you have the correct electric car and a Pi other than a Zero 2 W, [Sasha] also has a package for other Raspberry Pis that should work. Unfortunately this was designed for a specific electric car; other makes and models won’t work with this out of the box, but we hope that won’t stop others from checking out the GitHub page anyway trying to figure out what’s going on under the hoods of their car’s electrical and computer systems. Sometimes this leads to things you might not expect, like using the car itself as a video game controller.