Hacker News Reader

Comment by zahlman | Hacker News Reader

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?

Python never touches the PPU: the memory-mapped registers live entirely behind a thin C layer (_snesfb / _snesstage modules). Sprite/tile bitmap data gets packed into VRAM tile banks once at startup; at runtime Python only mutates shadow state (hardware tilemaps, an OAM shadow, a framebuf for the GUI stuff) and once per frame the C side DMAs the dirty buffers across during vblank.

(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.

(Thanks for vouching! I emailed the mods about my account. I think I tripped a filter with a clumsy submission start...)

About the sprites: loading them from Python at runtime actually works. Stage's Bank objects are plain Python bytes (2048 bytes = 16 tiles at 16x16, 4bpp) plus a palette; on first use, _snesstage.bank() converts them to SNES bitplane format and DMAs them into one of 8 VRAM slots.

On extension modules in general: MicroPython has compiled-in C "user modules" (that's what _snesfb/_snesstage are) and dynamically loadable native .mpy modules. But this needs per-architecture relocation support, and the 65816 isn't among the supported targets.

Reply on news.ycombinator.com