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.
Automated gameplay ?
I thought the entire point of a game was to play it. A machine to play for you is an interesting exercise but seems inappropriate.
useful for testing games, running unit tests, fuzzy inputs, etc.
worked on something similar for the N64 so I could upload a ROM to a flash cart, and debug the linux kernel I was hacking on
I thought the same about amateur radio. Then FT-8 happened. But that’s another story..
Anyway, the original Famicom (Family Computer) is interesting, too.
The second controller has a microphone inside, so there must be some kind of A/D converter.
There also was the Famicom Disk System, a floppy drive with enhanced sound capabilities..
Last but not least, there are Famiclones/NOACs with a functional (!) keyboard.
They can be used like real computers, in theory.
If there only was a community who had ported software to them. *sigh*
Complex adventures with text-input would be possible, for example.
Some keyboard Famiclones have a printer port, too, which could be used to drive external hardware, like in the MS-DOS/QBasic days.
You are too focused on what you see and not on the ramifications. Besides the benefits listed in the other comment, having a method of automatic input is valuable in machine learning. Getting an AI to learn how to complete a level in the same trial and error way you learned is pretty wild.
Wow
well guess what? people like to create software which plays video games. there’s more to video games than playing them. people spend years writing these games, too! is that also inappropriate?
You could feed the video input into an object detection code like yolo to get the position of Mario and the goombas etc and the build your automation code around that
Is object detection fast enough and reliable enough to not have a significant delayed or even missed inputs? The last time I used it, it was a bit too slow and fuzzy for my liking…
You are right. No one can beat Contra III / Propotector with 3 lives. But I beat it with 30 lives without dying a single time. I had 42 lives when I started the next round.
Isn’t this just a worse TASbot?
Pretty much and it’s the approach I took when I built my TAS bot. The ‘proper’ way is to use an MCU instead of the 4021s, but it’s tricky to get the timing right