Test Games:
Single chip: Jupiter Lander for Commodore Vic-20: 0.0656Mbits
Multi-chip low capacity: Kirby's adventure for Nintendo Entertainment System: 6Mbits
Multi-chip high capacity: Tales of Phantasia for SNES: 48Mbits
High Capacity: SuperTuxKart for Linux: ~1GB
Word Processor Cart: WordGrinder
Boot Without Cart Inserted: Python programming environment
I have a few ideas on how I might get the Pi to boot into an OS stored on a ROM chip connected to GPIO. I know the ideal solution is a bit of a stretch, but I feel it's well worth investigating.
1) (Ideal solution)
OS and program code are stored on ROM chips, connected to the SPI GPIO port. GPIO Boot Mode would tell the Pi to boot from SPI, which would load the minimal OS and program code.
GPIO Boot Mode holds some clues, and then there's this GitHub link, refering to booting from EEPROM over SPI on the GPIO ports. It is possible, but not implemented, because the developers don't have a compelling reason to implement it. If we provide a compelling reason, we might just see it implemented and have our modern retro console for the masses in the Pi 400. I think, if we get enough people on board with this, THEN propose it to the developers, they might just add SPI boot functionality, which people do seem to want. It would open up many other options as well. I think getting some retro game developers involved and getting their feedback would be very helpful here. If anyone else can add the code to enable SPI boot, we could go that route. Sadly, I have nowhere near the knowledge and skill required to implement it, or I would.
2) (Not ideal, but likely far easier)
A special program is made to load the carts that could run on boot, and is installed into the SD card OS. That would be less reliable, as there are so many OSes that people could be running, and you'd have to install something. I always run into problems with software I installed, so this is far from ideal. Seems easy though.
3) (Similar to above)
Use a special SD card that just loads a minimal OS that looks for the cartridges to boot. This would require swapping SD cards, which is a hassle and would risk wearing out the SD car slot prematurely. This is my least favorite option.
4) (Most likey right now)
Have a tiny USB flash drive that boots the cart load OS, and just leave it plugged into one of the USB 2.0 ports at all times. USB ports are more robust, so I wouldn't feel as bad about plugging and unplugging it regularly. You could program the flash drive with a standardized cart boot OS, then use the GPIO Boot Mode to tell the Pi to boot from USB. If the developer of the cart needed to add code to the Cart Load OS, the OS could check for a certain code in the cart ROM and install it to the OS flash drive, updating the OS via cart. This would allow developers to add whatever features they want, and wouldn't be nearly as limited by the OS. The problem with that is that there would be a chance of bugs developing in the OS. It might actually be best to just write protect the USB drive and force developers to load everything they need into RAM.
This system is essentially two parts right now: ROM cart and boot drive. The hardware should be simple enough, but the software to getting working in the ideal manner is a bit beyond me at the moment. I plan to keep it all open source, of course, and just want to see it happen.
buy devterm https://www.clockworkpi.com/product-page/devterm-kit-a0402 or pinephone ;)