There are several reasons for this:

• The page cache is 1-way and keeps no statistics. We could keep statistics about what pages get swapped in/out the most and use n-way caching that could make use of this.
• The page cache size and mapping could be chosen in a much smarter way. Need to think about how region flushes etc. interacts with this.
• We could transmit cached pages to RAM in the background using DMA. NOTE: It seems like the CSn behavior is pretty crappy with SPI and I haven't managed to get it to behave properly. Moving to QSPI PIO would allow solving this issue at the same time if we're careful to design it to be DMA-friendly.
• We use SPI, not QSPI. This would require PIO, need to investigate available resources for this.
• It is not entirely certain why but page rx doesn't work beyond 25MHz even though we use the supposedly 125MHz compatible command. Using a PCB might make this more bearable.
• The page size is 1KiB. This reduces the amount of hard faults we encounter but it also means we transfer much more data than good caching would need. However reducing the transfer size causes issues (probably on page tx, as page rx seems fine). It's possible that raising CE soon enough would prevent this from happening. As it is not currently tied to SPI, it is possible that it is just raised too late.

Automatic builds for all supported platforms & testing on the desktop platform would be a plus, especially as we gain testing support.

This would be a huge nice to have by now because:

• We are reaching the point where accurate emulation matters. Automatically testing edge cases especially for some API drawing functions may be useful, e.g. to optimize code more aggressively while reducing the testing workload.
• Test-driven development would make sense in some cases while implementing the API. String rendering, RNG, and some other things could benefit from this approach, in particular.
• We could probably do some nice testing against PICO-8 by injecting a printh of the PICO-8 memory somewhere in update functions. This would allow detecting subtle bugs and differences in the implementation especially if performed automatically.
• Fuzzing the API to detect differences in parameter count handling or argument type handling may unravel some inaccuracies in the interface implementation.

This raises a few issues:

• CMake does not support cross-compilation for different architectures within the same build directory. Making two build directories is possible, but this would likely need some tinkering with VSC so that the CMake integration isn't dogcrap to use. If external development is ever opened up this has to be tackled. Ideally only one command should be run to compile for both arches and execute tests, at least as an option. Emulating ARMv6-M with qemu or something is an option but would be complicated to set up, would make instrumentation difficult, and is of limited use since recent bugs that were difficult to debug happened both on the Pico and on the desktop builds.
• How to even execute tests? We could use CTest from CMake, but how about running the tests themselves? Integration tests might be easier to implement in pure Python, unit tests might be a lot easier to make using Catch or a similar library.

Ideally when these ideas mature out a little this issue could be split up into several with a "USB support" tag.

USB mass storage

This would allow for copying games to the flash and to update the firmware. This should preferably allow to reserve some amount of storage for the firmware, should be bricking-resilient to an extent, and not wipe out games and config on flashing.
Maybe this could both take .p8 and .p8.png but perform some sort of preprocessing and compression on the fly which would allow storing probably more than twice as many cartridges.
Also maybe something that would make loading cartridges from BBS easier?

Usage as a desktop PICO-8 monitor/gamepad?

It would be really nice if you could just plug in yocto-8 hardware, open up PICO-8 and have seamless integration: the PICO-8 display would be mirrored on the device and you could use it as a gamepad as well.
This may be a bit complicated to implement, and how would one even do that on Windows without a custom driver?
We don't really want to use an existing display interface since a pico-8 framebuffer is paletted and would be much lighter to send over without compression.

Pluggable mouse and keyboard

This would really be an extra, but if it's possible without too much development workload, why not? AFAIK tinyUSB should have plenty of examples for something like that, and it seems like that in the next minor pico SDK support for this should be better.

External USB storage

I don't think this would be very useful since a few MB of Flash should already hold plenty of cartridges, and this would require at least having a FAT32 driver.

There is a number of things that could be done to reduce RAM usage, at varying levels of complexity:

• Pre-compiling the core functions that are declared as Lua.
• Allowing some strings to live in Flash rather than having to let Lua allocate them.