The program cartridge is the key hardware component of this project, and I need to define it's function as well as I can. At it's most basic level, it will consist of a PCB, populated with one or more flash memory chips, running on an SPI interface, with all supporting components populating the board as well. The SPI interface was chosen because it can be booted from, according to Raspberry Pi documentation, and is accessible on the GPIO header. This means that no other hardware will be needed, and the cart can boot from itself and bypass any OS on the Pi, leaving all user data untouched. With GPIO Boot Mode enabled and configured, there would be no need to choose a boot device on start up. With a cart plugged in, the cart would pull a specified GPIO pin high, telling the Pi which device to boot from. As long as the SPI interface on the GPIO pins can be selected, it will boot from the flash chip in the cart. This requires setup on the Pi, which appears to be permanent, from cursory glances at the documentation. I believe it requires modifying bits in the Pi firmware. This would mean users would need to run a program to enable cartridge boot on their Pi. The problem with this is that it requires a GPIO pin to be pulled high on boot, so no more booting without extra hardware attached. This is a problem for those who would use their Pi for other things, but ideal for a dedicated cartridge based system. There could be a dummy cart of some sort used to boot the Pi, which would allow selection of a boot device such as SD, USB, or SPI. You could actually have a carts that have different operating systems on them and boot carts exclusively, like the old home computers used to do. 

Booting carts without enabling GPIO Boot Mode:

If unwilling to modify their Pi to enable automatic booting of their carts, one could simply restart the Pi and select the SPI bus as a one time boot device. This would start the cart without making any changes to the Pi. Next restart would take the user back to their usual OS of choice. I still have much research to do on these theories of operation, but things are looking promising so far.

While investigating how to boot from something connected to GPIO, I found this article that claims to have gotten an SD card to work on a Pi Zero, connected to GPIO headers. This is a great start, as it means programs could at least be loaded over GPIO. It may be slow, but that might not be a problem for simple games. I'm not sure if the system could be made to boot from an SD card attached to the SPI interface though. 

Cartridge Cases:

For the cart cases, I would go with injection molded plastic, if possible, but start with 3D printed prototypes. I have a feeling that cart production is going to be very expensive, but I will worry about that later. I could probably mold resin for small batches if needed. The hard part for me is going to be designing the case. I don't have a Pi 400 to work with yet, so there's that. With the carts come labels. Labels should be rather easy, as any old printer would work with quality sticker paper. I happen to own a decent photo printer with new ink in it. There's also the giant vinyl printer and cutter at the local library that is incredibly cheap to run. They even have a permanent adhesive vinyl I could print labels on. Hand apply to carts and done. 

Cartridge Connectors:

For the cart connector, I found these dual row, 40 pin female connectors. Solder onto a PCB and go. I'll order a set of these when I get my Pi 400 and use them to start developing carts and such for it. I'm sure a fab house could get and install these cheaper, but these are good enough for prototyping purposes and small production runs. I worry about the strain that will be put on the Pi 400's GPIO port if it enters service as a cartridge port. Bent pins and worn out connections come to mind. Part of me wants to open up the 400 and put a more robust connector for the system and carts. Testing and small production runs would determine if that would be needed. A test Pi that is having many carts run through it would show just how long it would last. I could even have the system record how many times a cart was inserted and removed to get an idea of failure rates. All of this is production scale thinking, but it's best to plan that way in case this turns out to be more popular than I expected, and I decide to start supplying hardware at some point. I'll keep everything open source, but I wouldn't mind helping game developers publish their creations someday. At the very leat, I'll publish and sell my own carts eventually. 

Other cart features:

The carts, being plugged into the GPIO port, could actually do far more than just load an OS and games. They could provide all sorts of interfaces. It could even allow extra hardware to be added for use with games. Not much comes to mind, but custom controllers could be a thing. Basically Hats, but in a 400 friendly form factor. This needs to, and will likely become a thing anyway, so why not start working on it and use what comes along? Thoughts of the robot arm that the Commodre 64 could control pop up. You could have a robot arm kit that plugs into the GPIO port and loads up a custom OS and software on boot. Just like the old days, but with modern capabilities. I realize I just ramble on about various possibilities. Software testing will begin soon enough. Bills need paid first, then I can start having more fun with this.

Hardware Damage Concerns:

It occurs to me that people will try to plug the carts in upside down. Mostly children, I assume, just to see what happens. I know I would have as a kid. I imagine this could damage the Pi, so there needs to be a way to prevent this. The fact that the Pi would have to be lifted off the ground to physically install a cart should deter most, but not all. Adding a protrusion to the cart, and requiring a notch to be cut into the Pi 400 would help, but I'm trying to avoid any hardware modifcations to the system. Another issue that arises is the fact that the GPIO pins could be in any sort of state when the cart is plugged in. Someone could have them all set high and plug in a cart, which would likely damage things. Having an onboard SO would help the cart out, assuming all pins could be disconnected, internally, until the cart safely boots and sets the pin states. I need to research this more, but definitely something to keep in mind. It's easy to provide a hacker friendly experience with a Raspberry Pi, much hard to make a reliable kid friendly experience. The GPIO pins would also need to be protected from kids, but that would be far more difficult, as the Pi might be used to boot from SD and have people playing with the pins. I'll focus on making sure the carts don't fry the system, and let the console owners take responibility for their own system hardware.