Watching the advancement of technology is interesting enough by looking at improved specifications for various components as the years go by. But clock speeds, memory size, and power consumption are all fairly intangible compared to actual implementation of modern technology when compared to days of yore. For example, this $40 microcontroller can do what a video game console was able to do in the 80s for a tenth of the (inflation adjusted) price.
The NESDUE is an emulator for NES games which runs completely on an Arduino Due. The Arduino does have some limitations that have to be worked around to get the Nintendo to work, though. For one, it needs to be overclocked to be playable and it also needs a workaround to get past the memory limit of 96 kB of RAM. From there, a small screen is wired up along with a controller (from a Super Nintendo) and the gaming can begin.
This is an impressive feat for an Arduino platform to accomplish, especially with the amount of memory tweaking that has to happen. This might be the most advanced gaming system available that runs everything on an Arduino, right up there with the Arduinocade which can provide an arcade-like experience straight from the Arduino as well.
That soft SPI connection to the display is gonna be a bigger bottleneck than anything else.
My spitball for that resolution and color depth is only coming up with a megabyte per second or so, I think SPI can handle it, clocked at a decent speed of course.
Looks like it’s softspi to SD so no biggy.
But this always fascinated me https://github.com/juj/fbcp-ili9341 a SPI driver for raspberry pi which effectively diff’s over the data to the slave.
Its intended for driving screens from a pi for retropi purposes.
especially considering these displays can handle sprites, blitting, and scrolling in hardware. you only have to send the parts that change. backgrounds on these consoles are usually stored in tiles so to reconstruct the back ground once a sprite is removed you at most only have to stream at most 4 background tiles back to the screen. then the screen can be scrolled and the newly revealed edge streamed back in. if the sprites move with the background and dont change frames, then they dont have to be undrawn before scrolling. this is very similar to the way the nintendo’s video hardware works.
From the schematic, the display is using hardware SPI, the software SPI is just going to the SD card reader on the back of the display.
That said, with the number of pins available on the Due, I’m wondering why this isn’t using 8-Bit parallel mode on the display and hardware SPI for the card reader?
Yes that would have been additionally more increasedly eleganter.
Ah, I missed that. It still does seem like in the video the slow update is quite noticeable. In the very beginning the transition from a black screen to the Mario screen takes 4-5 frames of the Youtube video. (Counted using the keys).
What if you used a Teensy 4.1 instead?
They already did, the M.C.U.M.E
Runs most console and computer patforms.
https://github.com/Jean-MarcHarvengt/MCUME
You left out: “ARDUIO DUE” as in “fast arm chip” not “8-bit avr”
yea i kind of felt this title was clickbait as one assumes an 8 bit arduino. but even getting it to run on a due is pretty impressive. as arms go due is kind of a slowpoke.
Nice! This is an impressive project that deserves positive feedback rather than nitpicking clock cycles. Plus the developer has documented the build and shared the code. That deserves extra kudos.
This
Why it works in low frequency on the main console 6502
But should the frequency be high for the simulator? by Atmega and ESP32 ?