Show HN: Python running on the Super Nintendo (in-browser demo) (fabian-kuebler.com)

6 points by FabianCarbonara ↗ HN
MicroPython (lexer, compiler and VM) on the SNES: 3.58 MHz 65816, 56 KB Python heap, 16-bit int. The REPL runs right inside the post via EmulatorJS and also works on real hardware via flashcart.

I did this as a benchmark for Claude Fable. When the export ban hit, switching to Opus got the project stuck for three weeks; Fable came back and found the real bug in ninety minutes.

Along the way: 23 compiler bugs and 4 MicroPython bugs, each root-caused with a minimal reproducer and filed upstream.

If you run it on real hardware, I want a picture!

9 comments

[ 3.3 ms ] story [ 30.0 ms ] thread
That's absolutely crazy! Compiler bugs and micropython bugs???

On the other end of the cost scale right now, I'm running multiple Deepseek V4 Flash instances basically constantly practically for free (because I'm poor right now) and I'm impressed by that too.

So this should be comfortably possible on GBA, yes?
Yes, definitely: the GBA is a 32-bit ARM with 256 KB of RAM and mature GCC support, so it sidesteps everything that made this hard: the 16-bit size_t, the far pointers, the barely-stress-tested compiler. The SNES was the fun target though ;)
How do you deal with things like e.g. writing sprite bitmap data to specific locations in the VRAM from Python? Or handling the memory-mapped I/O?
[dead]
(By the way, several of your posts seem to be getting automatically filtered. I vouched for this one; I see nothing wrong. Perhaps someone else thought it was AI-generated.)

Does MicroPython support some concept of an "extension module", at least? It would be nice to be able to load new sprites etc. from Python at runtime.