3 ms·

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 p

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 ;)

zahlman 3mo ago
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?
- FabianCarbonara 3mo ago
  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.
  - zahlman 3mo ago
    (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.
    - FabianCarbonara 3mo ago
      (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.

zahlman 3mo ago

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?

FabianCarbonara 3mo ago
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.
- zahlman 3mo ago
  (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.
  - FabianCarbonara 3mo ago
    (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.