LED cubes are all the rage right now, and rightly so given the amount of work that goes into them and the interesting things people find to do with them. Not content to make yet another position-sensitive display or an abstract design, though, [Greig Stewart] opted for something a bit more ambitious: an LED cube with a playable game of Castlevania.
As ambitious projects often do, this one required leveraging the previous art, some of which we’ve featured before. [Greig] pulled inspiration and information from cube builders like [polyfloyd], [Greg Davill], and [kbob] to put the six 64-LED matrix panels to work. Getting the structural elements figured out was an early stumbling block, but [Greig] pulled it off with 3D-printed brackets and a hinge that’s a work of art in itself; the whole thing looks like something the Borg would have built. The Raspberry Pi inside made a Gameboy emulator possible, and his first stab at it was to have six different games running at once, one on each panel. He settled on just one game, the classic side-scroller Castlevania, played on just four of the panels. Some wizardry was required to de-scroll the game so that the character walks around the cube rather than having the background scroll; you can check out the results in the clip below.
Currently, the cube sits on a lazy susan with a small motor controlling the swiveling in response to a foot control. [Greig] wants to put the motor under control of the game so that physical scrolling is synced with gameplay; we heartily endorse that plan and look forward to the results.
Classic games consoles played their games from cartridges, plastic bricks that held a PCB with the game code on it ready to be run by the console hardware. You might therefore expect them to be an easy prospect for emulation, given that the code can be extracted from whatever ROM they contain. But as anyone with an interest in the subject will tell you, some cartridges included extra hardware to boost the capabilities of their games, and this makes the job of an emulator significantly more complex.
[Byuu] has penned an article exploring this topic across a variety of consoles, with in-depth analyses of special-case cartridges. We see the obvious examples such as the DSP coprocessors famously used on some SNES games, as well as Nintendo’s Super Game Boy that contained an entire Game Boy on a chip.
But perhaps more interesting are the edge-case cartridges which didn’t contain special hardware. Capcom’s Rockman X had a copy protection feature that sabotaged the game if it detected RAM at a frequently used save game address emulated by copiers. Unfortunately this could also be triggered accidentally, so every one of the first generation Rockman X cartridges had a manually attached bodge wire that a faithful emulator must replicate. There is also the case of the Sega Genesis F22 Interceptor, which contained an 8-bit ROM where most cartridges for this 68000-powered platform had a 16-bit part. Simple attempts to copy this cartridge result in the upper 8 bits having random values due to the floating data lines, which yet again an emulator must handle correctly.
It’s a subject with a variety as huge as the number of console developers and their games, and a field in which new quirks are constantly being unearthed. While most of us don’t spend our time peering into dusty cartridges, we’re grateful for this insight into that world.
When the only tool you have is a hammer, all problems look like nails. And if your goal is to emulate the behavior of an FPGA but your only tools are FPGAs, then your nail-and-hammer issue starts getting a little bit interesting. That’s at least what a group of students at Cornell recently found when learning about the Xilinx FPGA used by a researcher in the 1990s by programming its functionality into another FPGA.
Using outdated hardware to recreate a technical paper from decades ago might be possible, but an easier solution was simply to emulate the Xilinx in a more modern FPGA, the Cyclone V FPGA from Terasic. This allows much easier manipulation of I/O as well as reducing the hassle required to reprogram the device. Once all of that was set up, it was much simpler to perform the desired task originally set up in that 90s paper: using evolutionary algorithms to discriminate between different inputs.
While we will leave the investigation into the algorithms and the I/O used in this project as an academic exercise for the reader, this does serve as a good reminder that we don’t always have to have the exact hardware on hand to get the job done. Old computers can be duplicated on less expensive, more modern equipment, and of course video games from days of yore are a snap to play on other hardware now too.
Join editors Mike Szczys and Elliot Williams as they recount a week of fascinating hacks. We take a good look at the PMS150C, a microcontroller that literally costs pennies but can only be flashed once. SNES emulators have a new trick up their sleeves to make low-def a lot less low, and you retro enthusiasts will either hate or love the NES zapper chandelier. Elliot’s enamored by a bike computer running Android core, and both Mike and Elliot delve into the food hacking scene, be it meat, chocolate, coffee, or of course frosting!
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
This is likely not to come as much of a shock to you, but the ESP8266 is pretty popular. At this point, we’re more surprised when a project that hits the tip line doesn’t utilize this incredibly cheap WiFi-enabled microcontroller. If you’re making a gadget that needs to connect to the Internet, there’s a good chance some member of the ESP family is going to be a good choice. But is it a one-trick MCU?
Well, judging by software frameworks like the “Little Game Engine” created by [Igor], it looks like the ESP is expanding its reach into offline projects as well. While it might not turn the ESP8266 into a next-gen gaming powerhouse, we’ve got to admit that the demos shown off so far are pretty impressive. When paired with a couple of buttons and a TFT display such as the ILI9341, the ESP could make for a particularly pocket-friendly game system.
The game engine that [Igor] has developed provides the programmer with a virtual screen resolution of 128×128, a background layer, and 32 sprites which offer built-in tricks like collision detection and rotation. All while running at a respectable 20 frames per second. This environment is ideal for the sort of 2D scrolling games that dominated the 8 and 16-bit era of gaming, and as seen in the video after the break, it can even pull off a fairly decent clone of “Flappy Bird”.
In addition, [Igor] created an online emulator and compiler which allows you to develop games using his engine right in your web browser. You can load up a selection of example programs and execute them to see what the engine is capable of, then try your hand at developing your own game before ever having to put the hardware together. Incidentally, the performance of this online development environment is fantastic; with even the fairly complex “Flappy Bird” example code compiling and starting in the emulator nearly instantaneously.
Microcontrollers come in a broad swathe of capabilities these days. There are the venerable 8-bit micros that have been around forever and valiantly crunch away, all the way up to modern 32-bit powerhouses with advanced peripherals and huge amounts of RAM and ROM. If you’re blinking a few LEDs or opening a garage door, the former is fine. For what [Jared] had in mind, a little more horsepower was required.
[Jared]’s project started out as an experiment with composite video output on a STM32F446RE microcontroller. Using a 4-bit resistor DAC, the device was able to output NTSC signals, using interrupts and NOPs to handle timing. The hardware worked, and was tested by playing the entirety of Star Wars: A New Hope from an SD card.
Attention then turned to creating a Game Boy emulator for the platform. After many hurdles with various bugs and edge cases, things started working, albeit slowly. The Pokemon game ROM wouldn’t fit in the microcontroller’s limited flash storage, so [Jared] implemented a complicated bank switching scheme. This combined with the limited computational resources meant the game was playable, but limited to just 10 FPS.
Enter the STM32H7. With over double the clock speed and capable of 856 DMIPS versus 225 of the original chip, things were coming together. Pokemon now ran at 60 FPS, and the built-in DAC greatly improved the sound. The DMA subsystem allowed further performance gains, and even running in debug mode, performance far exceeded that of the previous hardware.
With unit prices of most microcontrollers being remarkably low, it goes to show that once you’ve tapped out on performance on one platform, there’s usually a faster option available. It’s possible to emulate the Game Boy on the ESP-32 too, as Sprite_TM showed us in 2016. Video after the break.
We’re not allowed to have TV here in the Hackaday Wonder Bunker, but occasionally we’ll pool together the bandwidth credits they pay us in and gather ’round the old 3.5 inch TFT LCD to watch whatever Netflix assures us is 93% to our liking. That’s how we found out they’ve made a show based on, of all things, one of the Castlevania games for the NES. We wanted to play the game to understand the backstory, but since it hails from the era of gaming where primitive graphics had to be supplemented with soul-crushing difficulty, we didn’t get very far.
But thanks to a very impressive project developed by [Michael Birken] maybe we’ll have it all figured out by the time we’ve saved enough credits to watch Season 2 (no spoilers, please). The software, which he’s quick to point out is not an example of machine learning, is an attempt to condense his personal knowledge of how to play Castlevania into a plugin for the Nintaco NES emulator. The end result is CastlevaniaBot, which is capable of playing through the original Castlevania from start to finish without human intervention. You can even stop and start it at will, so it can play through the parts you don’t want to do yourself.
[Michael] started this project with a simple premise: if he could make a bot successfully navigate the many levels of Dracula’s castle, then getting it to kill a few monsters along the way should be easy enough. Accordingly, he spent a lot of time perfecting the path-finding for CastlevaniaBot, which included manually playing through the entire game in order to get an accurate map of the background images. These images were then analyzed to identify things like walls and stairs, so the bot would know where it could and couldn’t move protagonist Simon Belmont. No matter what the bot is doing during the game it always considers where it is and where it needs to be going, as there’s a time limit for each stage to contend with. Continue reading “AI Bot Plays Castlevania So You Don’t Have To”→