Cartridge Connector Durability

I've been researching the various details of this project for a few years now. The main sticking point has been the physical interface between the cartridge and the Pi GPIO pins. Plugging and unplugging PiHATs is quite a physically stressful operation, and exposes the GPIO pins to severe and constant stress, which can destroy them over time. Looking into various options, such as Pogo pins and card edge connectors has turned up a few options.

Looking back in time reveals options that have stood the rest of time, such as the card edge connectors used in computers and video game consoles. Information on the connectors used is difficult to find. Omniball pogo pins would likely be the most durable solution in the long run, but also a very expensive option. I could design a base station that uses a 40 contact omniball connection, but it might not end up being a standard option. Such an interface would be ideal for use in a test station for testing outgoing cartridges, as well as industrial, scientific, and other severe use cases. A quick search turns up a 10 contact single row connector at over $13 USD per piece. 4 would be required to interface all 40 pins of the cartridge. $52 for just the mating pins would be very hard to justify to most people. The connectors also have screw mounts on each end. This would require either modifying the connectors to sit closer together, modifying the cartridge edge connector design, or possibly both. It might be worth designing the edge connection to accept the omniball pogo pins, so long as they could still be used with a standard card edge connector. This depends on the pitch of the pins. It could complicate the design a little bit, but also open up a far more durable, though expensive connection option. There is also the question of holding force with the omniball pogo pins, and the ability to mount them horizontally. They may not be a viable option for many reasons.

A card edge connector is the current choice. If needed, a durability testing rig can be made to test the failure point of various types of card edge connectors, as real world data is very difficult to find. Some card edge connectors, such as PCIe used for graphics cards, are rated for 20 to maybe 50 mating cycles, yet have been found to survive hundreds of cycles without failure. These reports are anecdotal, and come from various forum posts about test bench PCs. As I already have an automated press machine in the works, it would not be hard to design testing equipment and procedures for determining the approximate lifespan of various card edge connectors. As this system is designed for use mainly with children or industrial users, who are both very hard on equipment, it's vital to find a reliable connection method between cartridge and cartridge slot. The old card edge connectors of the past have proven their worth over decades of use, accumulating thousands of mating cycles. The production methods for the cartridges are well known and easy to replicate, but the card edge connectors are harder to verify. The best option I have found is to check the data sheets for materials used, choose suitable candidates, and test them to failure to determine average lifespan. I could skip this step and choose a card edge connector from a reputable brand and hope for the best, but I'd rather not risk early failure and recalls. The ultimate goal is to provide an excellent experience.

Once the automated press prototype is completed, I will start designing the hardware and testing procedures for card edge connectors. The process would involve counting the number of cycles the machine has completed, as well as the number of successful connections each pin has made. Any discrepancy would be considered a failure. This is likely going to be a rather complicated testing procedure, requiring custom hardware. I find such testing to be worthwhile. LTT Labs comes to mind here.

Data Storage Options

I've looked at many different types of data storage over the past few years. From EEPROM chips with maybe a few megabytes of capacity, to SD cards with many gigabytes of capacity, to custom USB flash device designs. Not all cartridges would require mass storage options, or even any storage at all. Some might be purely hardware. Some might require just enough persistent storage to save user settings. I've used the EEPROM on an Arduino in the past to save settings between power cycles to great effect. I know SD cards can be connected to the SDIO interface on the Raspberry Pi's GPIO pins. In the end I think I will implement the footprint for both EEPROM and micro SD cards. The EEPROM design is quite simple as it's just a simple SMT footprint. Implementing a micro SD card is a little more complicated. I could have an SD card slot soldered onto each cartridge. This is easy and standard practice. It adds expense and another failure point to the board though. I've considered the XTX SD flash chips that can be mounted SMT style, but they're very niche, often not available in large quantities, have low capacity, and are just generally harder to source. That makes them an unsustainable option. Micro SD cards are cheap, abundant, and well established. The plan is to simply place pads matching the SD card's onto the board, and reflow the chips into place. I'm not sure I could get the PCB manufacturer to do this, but I could certainly do it myself, if needed. I know there is a smaller PCB company in Colorado that has done some very interesting custom work as well. They may be able to handle that step. If not, I can always make jigs. It might be possible to have the solder pads extend out past the SD card so that a soldering iron could be used to flow solder underneath the card without heating too much of the board. My upcoming automated press project could be used to install the cards as well. Some sort of raised components could also be used to align the SD card on the PCB, such as resistors, or even dummy resistors. I'm sure there is a simple solution to mass soldering micro SD cards to PCBs. I'll just have to try it for myself. I've seen one insta ce of someone reflowing micro SD cards to a custom PCB. Details are scarce, but it has been done.

The benefits of simply soldering a micro SD card to a PCB are numerous. Being able to choose from the large variety of cards is a huge advantage. SLC industrial cards would provide ultimate reliability at greater expense. Large databases, like offline versions of Wikipedia could be stuffed into large SD cards, and then hardware write protected to protect the cells from write damage.

At this point in time I am planning to add a few EEPROM spaces to the design, as well as at least one micro SD card space. Solving the big problems will get this project moving once again. I can fairly safely say that I've solved the data storage problems with EEPROM and micro SD cards. The connector problems still remain. It would be easy to just slap whatever cheap connector I can source onto the system and hope for the best. I'm considering this an industrial design and want to be able to certify the design. This will be one of the big projects under my design business, and it has to perform very well. It also has to be fun and satisfying to use. There are no modern retro style cartridge systems that I know of doing any of this. The Raspberry Pi 400 is still my favorite computer of all time and would make an excellent cartridge based system. I don't know of anyone else designing such things, and I want one quite badly. That means I have to just make it myself. It could help pay the bills some day, which is an added bonus. Until I can sort out the big details, this project will remain just an idea. Good progress has been made though.

Today turned out to be a very productive day for the project. I recently decided to make a base station that plugs into the GPIO header.

It would add an upward facing card edge connector, as well as some additional features. Additional features might include a USB hub for connecting extra controllers and peripherals, possibly a headphone jack to add audio output to the Pi 400, a status light, and "Eject" and "Reset" buttons. The base station would extend out to the right edge of the Pi 400 to allow a place to hold down the base for pulling up on the cartridge for removal. Feet on the bottom would give support to the base for inserting carts to avoid damaging the GPIO header pins.

I will start testing software with the MMC Pi Hat from PiShop. The final carts will use SD memory chips on a custom board, but the hat will allow me to test out the PiCart management software. This software would run in the background and allow loading of data from the carts and saving data back to them. The goal is to automate the experience as much as possible for end users. Plug in a cart, software opens, enjoy.

This winter has been rough for me so far, but this project gives me something to look forward, and keep me busy.

I ended up designing a very basic rendering of the base station an a cart in Inkscape. I've been very frustrated using Inkscape until today, but pushing past some of the initial learning curve has given me much more confidence in myself and this project.

Test Software:

Game: Duke Nukem 3D(Native Pi Version)

Word Processor Cart: WordGrinder

Boot Without Cart Inserted: Thonny

Current Options Under Consideration:

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) Boot from Flash Memory Over GPIO Pins (Ideal Solution)

OS and program code are stored on SD NAND chips, connected to the SDIO GPIO port. GPIO Boot Mode would tell the Pi to boot from SDIO, which would load the minimal OS and program code.

GPIO Boot Mode holds some clues, and then there's this GitHub link, referring 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. I have yet to find a way to actually implement this and will start elsewhere first.

2) Install a Program to Load and Manage PiCart Hardware

A special program is made to load the carts that could run on boot, and is installed into the main OS. That would be less reliable, as there are so many OS varieties that people could be running, and you'd have to install something. I often run into problems with software I installed, so this is far from ideal, but would likely be the easiest to implement, and therefor, the most likely to get done. Starting here. 

3) Boot from a Custom OS to Load and Manage PiCart Hardware

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, but one I will explore. This would be ideal for children and education use as there would be no software to install. Once a minimal OS is chosen, a custom image will be made for use with these carts.

4) Bootable USB Drive

Have a tiny USB flash drive that boots the cart load OS, and just leave it plugged into one of the USB 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 I PiCart is detected. Otherwise, the system would boot from the usual boot device. 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.

I've had to put this project on the back burner, and out of mind, so many times that it's absurd. It makes me rather angry. I've been thinking more on this recently, though, as I settle into my new home and job.

Some of the biggest hurdles have been a few crucial decisions in tools and methods. I've found time to finally research and decide on a few tools.

PCB Design software: KiCAD

PCB manufacturing: Camptech, Canada

Game engine: Godot

Pixel art editor: Pixelorama

Cartridge case material: PCB

 First game: Bird Battle(name subject to change)

Development system: Atari VCS

Development OS: Pop!_OS

Connector type: card edge, pin header, magnetic pogo pins

The above represent most of the tough decisions I had to make. I'll elaborate further on those in a future update. Time is limited as I settle into my new home and job. New camera gear is on the way, so video logs are likely in the future.

I have the Atari VCS and it's 1TB SSD waiting for this project. I'll get it ready this weekend and start working on the game design and PCB designs. I need to learn the entire process of game development and PCB development for this project. I have a SoundStripe account for audio assets, and will purchase some game asset packs to help speed up development. I have very little time, so I won't be doing things the hard way any longer. Game engines and premade assets will get the first prototype working, and I can fill in the skill gaps later.

After thinking about pogo pins a little longer, I decided that a card Edge Connectors option should be delevoped as well. They're durable, cheap, and easy to implement. The removal and insertion force for a card Edge Connectors, even with 40 pins, should be lower and less damage prone than with a 40 pin header connected directly to the Pi GPIO pins. Offering a card Edge adapter, as well as simple pin header connection on the carts would allow kids to handle the carts with less risk of damage to the GPIO pins(when using a card Edge connector), while allowing others to use the simpler and cheaper pin header. I dislike connecting anything to the GPIO header as the force required to insert and remove is fairly high and could cause damage to the system.

The simplest card Edge connector setup would be to just have the carts lay flat and plug the edge directly into the GPIO pins on the Pi 400. This would leave the cart sticking out of the back, and difficult to see when insterted. I'd prefer it to stand up right, so I could design a right angle edge connector adapter that would let the carts plug in vertically. There are benefits to both, and I will develop both and test. Vertical carts have the benefit of being visible at all times, which is handy for displays, speakers, and various switches. Horizontal carts have the advantage of not blocking the view of a display sitting on the same surface as the Pi 400, as well as being able to support things on top of them. Like coffee mugs and other hazards to electronics. A postal scale cart comes to mind here.

There are endless possibilities with this project and feature creep has to be managed to ever make any progress on it. I'll be buying some hardware and setting aside time to work on this soon. I have other large projects planned, but this one may end up being the most satisfying in the end.

This project has been stalled out for quite a while due to my lack of knowledge, funds, and working hardware. I recently found the 8086 makes an eMMC HAT that works with the Pi 4 that only requires a quick edit to the config.txt file. I failed to get the SD flash chips to work previously and gave up for a while. I just found this HAT and decided to start looking into this again. While not exactly what I'm looking for, it is close enough to allow me to actually get this working and start developing software for the system. The SD flash chips act just like an SD card, but in a smaller and cheaper form factor. I plan to order a few of these HATs quite soon and will start testing when they arrive. I still dream of making my own custom cartridges for the Pi 400, including boxes with proper box art, instruction manuals, and all sorts of fun features. I start learning KiCAD soon and will get some rest PCBs ordered.

Update: Found a link to said device.

eMMC HAT for Raspberry Pi

A quick search of Digikey brings up the cheapest pogo pins at $0.59 each. At this price, it would cost $23.60 per board to break out all 40 GPIO pins using pogo pins. It's unlikely that anything other than the initial prototyping boards, or a dedicated development board would need all 40 GPIO. A typical PiCart board may need 10 pins, costing $5.90 per board in pogo pins. There may be cheaper off brand pins available, but I refuse to sacrifice quality on such a vital component. A bad electrical connection caused by a faulty pogo Pin would likely render the entire board useless and impossible to troubleshoot for the intended users. If my initial testing goes well, I may place a very large order to get a bulk discount on the pins. I may also be able to get them through the PCB fab house directly at a better price, with assembly.

Though the price of these pins is off putting, I still plan to use them unless I can find a better solution. Edge connectors do come to mind though.

Initial Research suggests that using pogo pins, mated to gold plated pads should provide a good electrical connection between cartridge and GPIO pins. Pogo pins are far more expensive than typical header pins, but eliminating the wear and tear on the Pi GPIO pins is the primary concern. I'd planned on waiting until I had a working board design, then adding pogo pins, but I have less time to work on this porject and work out PCB bugs, so I'll likely design a simple prototyping board that simply breaks out all GPIO pins to traces, connected to pogo pins. Essentially a PiHAT breadboard with pogo pins instead of pin headers. The adapter that connects to the Pi should be fairly simple as well, and at least allow me to start testing the hardware concepts immediately. Strong magnets in both the board and adapter would hold the two together, with the pogo pins providing electrical connection. Once I get some experience with KiCAD, I'll design both boards and get some prototypes made for testing. After finalizing the physical connection between boards, I can start on the case, which will also be PCB. The cases will need to be hand assembled, which will add to the cost of production. The extra cost is acceptable as these boards are meant to be used in educational environments, by children. I work with children and know how destructive they can be. I also work in industrial food production, so I know the value of quality, durability, and good design of equipment.

This is still a top priority project for me, and the most exciting one o have going on. I hope to have the prototype boards ordered in the next month or so. Funding is no longer an issue, but time and energy are severely limited. I may pay someone to design the prototype board for me just to get it done even faster. I'd normally never consider such a thing, but I will break my DIY rules for things that I already have a good understanding of. I will not outsource essential code design until I'm a good enough programmer to disect and check other coder's work. This is still a learning project for me, but it has stalled due to lack of time and skills.

Random Updates

With the new job consuming 60 hours a week, plus commute time and extra sleep, I have had very little time to dedicate to any of my projects. This project comes to mind at times, and I wish I had the skill to just sit down and knock it out quickly. I am still learning all the needed skills, so progress is painfully slow. On a brighter note, funding for the project will be readily available in the next few weeks to months, and I could just order everything I need all at once and get started. I plan to order a few more Pi 400 kits. I have my main one, which I still use as my daily driver laptop and Jellyfin server. I am typing on it now. I'd rather not use it for testing. I plan to buy a Pi 400 as a dedicated Jellyfin server, another as a test platform for this project, and maybe even another as a backup, or for a secondary development platform so I can work on 2 projects at the same time. I'll be ordering some bulk SD cards, and setting up a formatting station for managing and backing them up. I currently don't have enough space for so many Pis, as I'm renting from a friend, but I should be setting up a workshop here soon and will have ample room.

OS Support

I know that it makes the most sense to support the official Raspberry Pi OS, and that's where I'll likely start, but I also want full support for Pop!_OS by System76 as I've found it to be the best daily driver OS on the Pi to date. They're a small, friendly company who I suspect would really enjoy this project, and I might be able to get some official support, even if it's just some advice over email. I use Pop OS on my Pi 400, only switching it out for Raspberry Pi OS to run my Jellyfin server. Once Jellyfin has offical support for Ubuntu 21.10, I'll switch over to Pop OS entirely. I feel that it would make a friendlier experience for kids as well, since the entire OS is geared towards the scientific, engineering, and educational fields. Ideally, the system could be ported to any Linux OS, but that isn't always feasible. I'm sure Windows 11 will continue to mature on the Pi, and I may end up supporting it at some point, but not right away. I can't stand Windows, and will avoid it as long as I can.

Physical Cartridge Connection

This is a very important aspect of the project to me. I've been thinking about wear and tear for years, but have started thinking more deeply about it as a new maintenance engineer. I watch these industrial machines wear themselves out and fall apart in a matter of hours to days, where most consumer equipment would last years. It's quite the eye opener. With the PiCarts, I want to build to an industrial standard, as I know these systems may end up in the hands or children, with their sticky, maximum-effort hands, and complete disregard for strain relief and longevity. I don't blame them, I just understand them. The biggest failure point I have identified so far is the GPIO pins on the Pi 400. Though recessed, they remain exposed and vulnerable. Plugging and unplugging things to and from the GPIO port also requires a significant amount of force, especially if not done straight on.

I have been really enjoying the magnetic connectors I have on my phone charging cable, as well as the magnetic phone stand I built. I'd like to be able to integrate such a feature into the PiCarts, if feasible, for use with educational systems. The typical hacker will do fine with the regular pins. The matter of being able to short pins still needs addressed. I have been considering pogo pins on the carts, and an adapter that plugs into the GPIO port. I could possibly have the contacts on the Pi side adapter recessed into a PCB, with longer pogo pins on the cart that would fit down into those recesses, and connect when they are safe from the poking and prodding of various objects. This would protect the power pins on the Pi from being shorted. Rare earth magnets in the cart and the adapter could be used to hold the cart to the system, while allowing them to come apart if the system was mishandled. I am always cautious with strong magnets, as they can interfere with electronics that may be used with the system, such as magnetic compasses. I suspect this would not be a major issue in the vast majority of cases. Engineering and manufacturing latches would likely be expensive, and/or require tedious hand assembly. I am designing this system to be mass produced at a reasonable price, even if I ever only use it for myself. It's a learning experience. Another advantage of using magnets in both the base and cart is that they can be set up to only allow the cart to be connected in one orientation. Opposing magnets would repel the cart if inserted upside down, stopping all but the most determined from connecting it the wrong way.

Removing the magnetic adapter from the Pi might also be tricky as well. I need an adapter that is as small as possible to keep the cart from jutting way out from the Pi and putting extra strain on things. It might come down to using a screwdriver or other tool to gently pry the adapter off the Pi. This would be nice for institutional use as it would be difficult to remove and steal. An extra thick PCB for the adapter, with the edges left blank for prying the adapter from the back of the Pi. Something like a guitar pick or credit card could be used to pry it off with any luck. Otherwise, it would have to be a tool. I could integrate some sort of pull cord as well, but that would put all of the force on a few very small parts and likely break something or stress the board too much. Maybe I could even make a custom tool to pull it off and just include one with each adapter, or as an extra. PCB should be strong enough for a little pry bar

Software Safety Systems

Software is where I struggle the most, as I am a novice programmer. I have to consider the fact that these carts will be removed at the worst of times, and what effects it will have on cart software and user data, the host OS, and the hardware. This will likely be the hardest part of the project for me to tackle, but will force me to learn many new skills. The end goal is to be able to unplug the cart at any point and plug in a new one without having to reboot the system, or lose data. This may not be possible, depending on the Pi firmware and OS, but a decent experience should be possible. A read only file system on the cart's storage should help significantly, and auto-saving and backup of user data can mitigate much of the data loss. There is always a chance that the system could lose power during a write operation, or that the cart could be removed during a write operation. I will look up some industry standard ways of dealing with this in the industrial field. I have some proper industrial PLC systems at work to play with, so I may be able to find out how they handle such failures and implement similar methods. Data loss for a tech savvy adult is frustrating when a backup restore is needed, but can be completely discouraging to a kid when all their game saves and project files disappear.

As a kid, I annoyed my parents to no end making them rewind the same few VHS tapes for me several times a day so I could rewatch things over and over again. It also annoyed me to no end when my favorite tapes wore out and died. Sad times to be a kid. These days, we have far better technology. I was listening to a song by Omnia called "The Well" and really enjoyed the story it tells, though simple. It reminded me of the animated tale of The Deathly Hollows from the Harry Potter movie. It got me thinking about how to get more story time into the world. Then I remembered my project here. I imagined having a cartridge that you could just plug in and it would play videos. You could put anything you want on them of course, but something useful and educational would be best. Unless you're like me and like to binge watch Futurama or Spongebob on shuffle. There would be obvious licensing conflicts with selling copyrighted media, so a blank cart with an SD slot or built in flash memory and the video player software could just be sold.

The hardware would be simple enough and could be a generic design that could be used for media playback of any kind. Headphone jack, media control buttons, perhaps volume control, a "shuffle" button, maybe even a small screen for controlling the software. Another option could be to add a small screen to the GPIO port such as a Pimoroni Hyperpixel 4" display. Being able to watch TV on a tiny display attached to the keyboard and work on a larger HDMI monitor would be quite nice. Also being able to leave the main monitor off, or take the Pi 400 on the road and play media with a tiny display would be great. Such a cart would end up being more expensive than most other carts, as the display itself is rather expensive. Would be well worth it for what I do. I have a Vilros Pidock 400 that turns the Pi 400 into a laptop, but the display uses a fair bit of power and has no brightness control at all, which bothers me at night. Sometimes I wish I could just hit a single button and have something start playing, like a random TV show or movie. Another thought occurred to me: the Pi 400 doesn't have much processing power, and playing media on it will slow it down and may make it less pleasant to use. This could be solved by adding something like a Raspberry Pi Zero 2 W to the cart to handle the actual playback. That would add options to have it stream things from other sources as well.

Possible hardware:

• Pimoroni HyperPixel 4" Display: $65
• Adafruit Cyberdeck Hat: $9

The two pieces of hardware above would be enough to get me started, with only buttons needed. A custom board with buttons and audio output would make up the finished item.

Software wise, I'd either use VLC Media Player for playback, or maybe write a custom program using ffmpeg as the backend. It would be easy to let feature creep take over on this and never get it done. Sticking to the core functions would leave it with play, pause, stop, rewind, fast forward, next, back, and volume controls.

This particular cart will have to wait until I get a few other pieces of the puzzle put together, but it would be something that I would use regularly as I work.The thought occurred to make a version or some sort of cable that would let it connect to a Pi 400 in the Pidock 400 and mount to the main screen to act as a secondary display as well.