A friendly human over at Reddit recently shared a very fun project that got me thinking. FeatherQuill is basically a Raspberry Pi based laptop that ONLY runs the WordGrinder word processor program. For very long periods of time. No distractions or anything. I instantly fell for this project and came home to start working on creating a cartridge version for the Raspberry Pi. I am currently getting the files together and trying to get this program compiled onto an SD card for use with my Ubuntu based laptop. If that goes well, I could just make a cart with an SD card in it and have the word processor done. 

I've been at this for probably close to an hour, and cannot get the source code for WordGrinder to compile. I get the following error, which I can't find anything that makes sense on. 

make: *** No rule to make target 'src/c/emu/lua-5.1.5/*.[ch]', needed by '.obj/lua'.  Stop.

That is very frustrating, because the makefile even has a place to enter the destination directory. If I could get the damn program to compile, I could probably get it to compile on the SD card I have in my computer and possibly use it as a portable program. I did some research into making a portable linux program and couldn't find anything that makes sense to me. Linux has turned out to be far more complicated than I ever imagined. Even something as seemingly simple as installing a program is a nightmare to me at times. I'm trying to learn it all, but right now I just want to get stuff done. I don't want everything I do to be a multi-hour learning experience. Makes me miss the days before I truly Hated Windows. I am asking around for help on this, and will turn to the developer for help onmaking this a portable program.

I have emailed the creator of the program and will have to wait on that. I played with WordGrinder for a little bit, and found it very pleasant to use. I am set on making a word processing cart with it. I also found a writer who uses the software and is interested in beta testing the WG cart when I get a prototype made. I am working on getting that set up.

I've hit dead ends in the following areas, and need to just start on something else:

WordGrinder (Need to make portable so it can run on any Linux OS)

Making programs portable in general(No idea where to start on this)

Booting from SDIO or SPI interface on the GPIO pins (Need to verify this is possible)

Creating a custom OS for cart loading (Need to do more research and choose an OS)

Making dev carts (need to order hardware)

Many other road blocks.

It's starting to sink in just how much help I'll need for this project. It's a little overwhelming, but I know most of what I am trying to do is possible. I just need to make some big picture decisons and figure out how to get started so I can get to work on everything. 

I found a very interesting thread describing a Pi OS that's about 35MB. I still have no way to boot over GPIO yet, but it would be good for me to learn to make tiny Linux OSs like this anyway. I'm looking at PiCore right now, but am getting burned out on this. I need to go start the project page for another one of my projects.

I'm not too experienced with the SPI interface, but I have used it a few times with pre-made SPI sensors. It worked, but was just returning things like temperature. For what I want to do here, combining many SPI ROM chips, I'm sure I'll need to troubleshoot them at some point. For that, I found a fun guide on Hackaday of all places. I'll add the link below and be done with this log.

What Could Go Wrong: SPI

A Good Start to the Day

While researching what type of memory to use for the cartridges, I came across a nice article on Hackaday: Game Cartridges and the Technology to Make Them Last Forever. This really got me thinking about the old game cartridges, and just how reliable they really are. It seems that as memory density increases, lifespan decreases. With that in mind, I'm glad I've chosen regular old PROM chips, like this 512Kbit EPROM, for the smaller capacity carts. That one can be erased and reprogrammed with UV light, which means the average user couldn't lose their game data without tampering with the cart. Here's another that is a one time write only: 4Mbit PROM. That 4Mbit PROM is the same price as the 512K, far larger, and should be perfect for production. 512K is far more than the original C64 carts could hold, but bank switching allows them to be used on nearly any system. Modern systems, like the Pi can address more than that. For the 4Mbit EPROM, I'm looking at the SPI interface on the Pi, due to it's possible speed of 8Mbits/s or higher. A game filling the entire 4Mbit chip could be loaded in half a second. Nearly instant as far as humans are concerned. This is the level of performance I'm hoping to get to replicate the old days of loading games instantly. I could do with far slower speeds, but do plan to eventually make far larger cartridges, so the faster load time is better. Looking at the available interfaces on the GPIO, I think SPI is the way to go for this project. The main reason for this, is that SPI seems to offer the fastest interface on the GPIO pins, as well as being very easy to work with. I have no experience with UART and very little with I2C, so SPI it is. I just need to make this decision quickly so I can start putting together a hardware list to get some test equipment made. It would be possible to connect many SPI EPROM chips together, eaither using chip select lines, or daisy chaining the chips together. This should allow me to expand the amount of memory in the cartridge almost infinitely, in the case of the daisy chain method. The first chip I've looked at is this 4Mbit SPI EPROM. It runs at 10Mhz, and has a 40 year data retention. 40 years is good, but 200 is better. I searched again and found a far better performing EPROM. This one from Microchip. SPI interface, 50ns access time, 1MBit capacity, 200 year data retention, can be hand soldered if needed, and looks to meet all electrical specifications to work with the Pi. It may need some supporting hardware, but that would be easy enough to add to the cartridge PCB anyway. When I get some extra money for this project, I'll order a few of these and the hardware to make them work and start working with them on the Pi 4 in my camcorder project. I really think these simple SPI EPROM chips are the way to go for this project. As much as I like the huge capacities of modern flash memory, the data retention isn't nearly as good as some of the simpler, lower capacity technologies. If I had my way(read funding), I'd just order custom masked ROM chips for each run of carts. That's too expensive for me right now, and a 200 year data retention rating is good enough for me. Besides, communicating directly with a ROM chip over SPI on the GPIO pins just feels more hacker-like to me than implementing SDIO or USB over GPIO somehow. Simple is better. The limited ROM capacity will also force developers to get creative with their code, which is something I really appreciate. Maybe I will gang up a ton of these, or make a special high capacity cart later for those huge and epic games people like to make. My favorite Linux game these days is Owlboy, and that comes in at 390MB or so on my Linux laptop. The easiest thing to do here would be to make a cart that has an SD card slot inside and just write the game to that and write protect it. Most people would never know, but I would. Not an ideal solution due to added cost of components and such, and I wouldn't feel too great about people paying for an SD card to GPIO adapter, but it would certainly work. I worry about data retention rates of SD cards, especially micro SD cards, but it appears that the memory only accumulates damage when written to. If written to once and locked, it might last a very long time. 

On a side note: Mouser's website is really making me mad. I try to apply filters and it just takes me to their general electronics page. Doesn't do it every time. Just most of the time. It's made searching their site almost unbearable. It's taken me far longer than it should have...

So far, I've narrowed it down to the two cartridge options: Low capacity, and high capacity.

Low Capacity:

1Mbit SPI EPROM, banked together to make various capacity carts in the few MB range. Perfect for retro style and small games. Not very fast read speeds, but should be fine for games of very small sizes. Will require some supporting hardware, but is very simple to work with and very reliable. Should hold code for up to 200 years as long as it isn't abused. I worry that people will buy these carts and they'd lose their data in the person's lifetime, and this chip should prevent that. I also just really want to play around with making large arrays of these and have a really nice looking board full of ROM chips like the old days. Smaller, but still many beautiful chips on a board.  The chip above is a 20Mhz clock max, which is double some of the 4Mbit chips I've looked at. Using a real world example game, Jupiter Lander for the Vic-20, the ROM comes out at 8.2Kbytes, or 65.6Kbits. That's quite small, and could easily fit on the chip I've chosen here. For emulators, these chips should be perfect. The largest NES ROM image I have seen floating around is Kirby's Adventure at 6Mbits. That would require 2 of the 4Mbit chips connected together. I could use a 4Mbit and a 2Mbit chained together, but that might require ordering more than one type of chip, which just adds complexity. That does increase the price of the cartridge, and I have to find a way to split the file neatly between two chips. An interesting problem, but one I'm sure can be solved with some clever code.

High Capacity:

There isn't too much to say here, aside from restating that I plan to use the SDIO interface on the Pi to read SD cards mounted to the cart. I might be able to spice up the boring SD cart with extra hardware somehow and have it do fun things. Perhaps a camera flash bulb that blinds you every time you die or screw up in a game? Or just adding speakers and lights to make a cart more annoying or more fun. Higher capacity carts would cost far more to produce, as the SD cards and their slots are more expensive than the SPI memory chips. Having multiple gigbytes to work with would be nice though, and open up proper gigantic adventure games on the Pi. 

The Ridiculous Cart

Anything above 1MB in size seems to be getting closer to the not-so-practical range. Although, the 48Mbit Tales of Phantasia for the SNES would make a very fun special edition cart. I imagine a see through case, with a PCB populated with 8 4Mbit chips. That would run at 10Mhz, but a cart with 48 1Mbit chips at 20Mhz would be far more impressive. It might even require a double stacked PCB. It would cost me $19.52USD just for the 8 4Mbit chips, or $135.84USD for 48 1Mbit chips. Programming for that 48 chip ROM array might be quite difficult and the performance might be terrible. It would be a very fun project, and something I'd probably make for myself for fun. Finishing that would force me to master these little SPI chips, and would be an awesome little collectible to have. $20 is reasonable for a special edition cart with all kinds of goodies and a classic game, I suppose, but the markup, packaging, and other goodies would probably push it above the $50 mark. $135 just in memory ICs is ridiculous, and the entire cart would probably end up costing a consumer over $200 if it were ever made available. I doubt many people would want one, unless the Pi took off as a serious retro console and the games started to become collectible. It would have to be a very limited release, and I still don't think I could ever justfy making more than one for myself. A fun concept to toy with, but not a viable product. That's most of the fun of it though.

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

Final Thoughts

The three games listed above should provide some good, fun test games for the cart design process. I picked games I would actually play so I don't die of boredom during testing. Jupiter lander is the first game I ever played on a Commodore, jsut yesterday. My cousin and I loved it. Kirby's adventure is a game I've played before, and should force me to learn how to expand the memory bank. SuperTuxKart is one of the very few native linux games I've seen that I enjoy playing and is open source and such.

As much as people say cartridges are dead and everything is going to mass storage, I think there's a place for it still. The carts are perfect for kids and long term storage. People put their heart and soul into games, and to have it stored on a medium that could last over 200 years would be far more satisfying than it only ever existing on server and the fragile hard drives of consumer systems. There's a very satisfying simplicity in ROM storage and it makes me very happy to have physical objects to work with and collect. From a technical standpoint, this entire project is obsolete and pointless. That won't stop me and other people from enjoying cartridge games and other older formats. 

Development Hardware

The first hardware I will get is going to be the 40 pin connector for the GPIO, a handful of the SPI ROM chips, some SD cards, and some SD card slots. That should let me start testing out the hardware and developing the carts. I'm highly considering making a special development cart for myself that uses one of the UV EPROM chips so I can make a UV erasing machine. I've always been fascinated by that type of memory and want to play with one. Perhaps I'll make it a special cart with a glass window over the EPROM chip, with a little door or cover for erasing. Once I get some hardware in, I'll make up a test rig to determine actual throughput of the memory chips and start to come up with game load time figures. 

I'm still very excited about this project as I have wanted to make my own game console for a very long time. It's starting to fall into place at last.

I got all my errands and such done today, and am downloading the OS image now. I've decided to just start testing on my Pi 4 powered camcorder. THe SD card is very difficult to get to, and has caused me to break one. I'm going to set up the Pi to boot from a USB flash drive for further testing. This is good for the development of the camcorder OS, as well as the Cartidge OS. The Cartidge OS will be booting from something other than SD anyway. 

It's been a few hours, I forgot I had start this log. I didn't end up liking the OS, so I'm off to play around with Raspberry Pi OS just to get things working. They just released a new version that includes some nice updates that will make my camcorder project easier. Off to work on that now.

After accidentally cracking the micro SD card that my Pi Camcorder boots from, I started using it's built in Pi 4 for OS testing. I started with Ubuntu Server 20.04.1, then screwd up and updated it to a desktop version. That's all fine and dandy, but I want to give Ubuntu Mate 20.10 a try, as it's got a build for the Pi 4 that has GPIO and such set up. I don't want to download it over my phone hotspot, so I'll have to get it later. If that goes well, I could get familiar with it on the camcorder project, then implement a stripped down version for the Cartridge OS. I found in the docs that Ubuntu Mate 20.04 can't be booted from USB on the Pi, but 20.10 can. As much as I want a barebones OS, I don't know enough about Linux to build one, so I'll just start with a nice desktop OS. 

According to the docs, which I can't link due to a crappy android keyboard error, GPIO boot Mode is only supported on previous versions of the Pi, not the 4. I can't tell if the documentation is out of date, or if that feature really has been removed from the Pi 4 line. I hope it's still possible, as GPIO boot is critical to the design I'm aiming for. Basically, it allows a hardware device to tell the Pi what to boot from, using GPIO pins. This would allow a game cartridge to tell the Pi to boot from usb or SPI. Booting from SPI is on hold as well. Dead end right now. GPIO boot is on hold as well. I don't have a Pi 4 I'm willing to modify to try and get it working, so I'm once again waiting on more hardware, with no budget for it. The lack of knowledge, funds, and support on this project are making it very difficult. I'm still working on making a bootable OS that loads a game immediately. I can make some progress there, but that's about it until I buy more hardware.

I'm using Balena Etcher to write the SD cards, as I know that it works well with the Raspberry Pi.

I started off the OS testing with retropie and didn't care for it at all. It's too stripped down, and too hard to get to things. Decided against it, as it seemed like quite a struggle. I'm not great with Linux though, so that's a big part of it. 

Next I tried Alpine Linux, and couldn't figure out an easy way to install it. Steep learning curve is not what I'm looking for right now. Just need a quick proof of concept. Alpine is out for now.

I looked at Ubuntu Core IOT, but it requires an online account, and I'm sick of making accounts and being tracked by big corporations. Out.

Currently working on Ubuntu Server 20.04.1 for Raspberry Pi. So far, so good. It was easy to get an image and start flashing it to micro SD. Will see how big the installation size is, get a basic Libreto emulator core running on it, then strip out everything else I don't need. I also found another viable OS option: Linux From Scratch. The problem is that it will likely be a steep learning curve. It looks like a great starting point for something closer to a final OS solution.

I ended up having to run out and buy thrift store keyboard for this project. The lack of USB keyboard has beenb driving me nuts. Found a really nice Logitech for $3. Brought it home and cleaned it all up. Finally have Ubuntu Server 20.04.1 running on the Pi. Wifi is set up and running. Installing a GUI onto the server distro to make it easier to develop for. Only had to un a single command:

sudo apt-get install ubuntu-desktop.

That adds over 2GB to the image file size, but it's fine for testing. I imagine I can remove the GUI later, to test the simplified. I may need some of the gui code to display the game, but I can figure that out later.

The GUI is still installing, so it's more waiting around and reasearch.

It installed, but turns out that was just upgrading it to the entire Ubuntu Desktop, and now I have a bunch of crap like an office suite installed... Live and learn. I was pretty tired when I was doing all that. It's many hours later, and I've made homemade gingerbread cookies and snacked a bit. I'm done working on this for the night, so I'll end here.  

Someone on Reddit commented that they wanted a particular game on a cartridge for this system, and it got me thinking about what that would require. The game in particular is Manic Miner for the ZX Spectrum. This would require emulation, as the Pi 400 doesn't have the hardware, or an FPGA that could replicate the hardware. The first emulator that comes to mind is Retroarch, as it is modular and I could include only what is needed to run the game. It has to open the game automatically and run it in full screen, without user input. Luckily, I found a Python API for Retroarch that is very simple and would allow enough control to get this going. Below is the example usage.

RetroArchPythonAPI
A Python API for RetroArch (libretro)

Example Usage:

RETROAPI = RetroArch(retroarch_path='/usr/bin/retroarch',settings_path='settings')

RETROAPI.start("Game Path","Libretro Core Path")

RETROAPI.toggle_fullscreen()

RETROAPI.toggle_fullscreen()

RETROAPI.toggle_pause()

RETROAPI.toggle_pause()

save_state = RETROAPI.save()

RETROAPI.reset()

RETROAPI.load(save_state)

RETROAPI.stop()

It has just enough options to load a game, put it into full screen, reset, and even implement auto save and auto load. Being that I programming in Python these days, I might actually be able to modify this API to add extra features, like the two mentioned above. Inside the main python file are all the parameters of the emulator that can be specified, so you can use it to set up the emulator. I think Retroarch will be the emulator of choice for this project.  

While thinking on this API, I realized that I will likely be running emulators extensively, which brought me to the idea that I may need to overclock the Pi 400 to get things like the Dolphin emulator running at full speed, assuming it can be run at all. That might have to wait until the Vulkan drivers are ready to implement. I'd love to have Super Mario Sunshine, one of my favorite games, on a cartridge for the Pi 400. That's a bigger project, but should be possible in the future. I have to make sure that whatever OS I go with can overclock the Pi, or it might miss out on some of the more resource intensive games out there. Looking at what appears to be the most viable API for the Dolphin emulator, I found it is only being developed for Debian 9. I could just strip down a Debian 9 installation with something like this script, and install the Doplhin emulator, and add whatever supporting software is needed. That stripped down image could just become the default OS for any games that require the Dolphin emulator.  I'd like to hide any and all of the Dolphin interface, and have it boot straight to the game. If I can't interface with the emulator directly, for some reason, I should be able to simulate mouse clicks and keyboard presses to set up and start the game, hiding all of that behind a splash screen or loading screen of some sort. Not ideal, but could be a viable worst case scenario. There's a lot more that will go into this, and I really need to get up to speed with Linux to pull this stuff off. 

After all that research, thinking, and typing, I just realized that there is a Dolphin core for Retroarch... Ignore everything above about a stripped down linux distro. I can just use the Python API for Retroarch for all emulation. Problem solved. It did lead me to find a simple way to strip down a Linux OS, which I may need anyway. Another thought on that is to just use one of the minimalist distros that is built around retroarch, and call it a day. I forgot all about the Retropie distro, and am downloading a copy of that now for testing. I should be able to strip it down, add a few things I need, and build off of that. Can't believe I forgot about it. The download is 845MB, which is pretty big for an OS that will only run one game at a time. THe bigger the OS, the bigger the flash chip needs to be, and may involve upgrading the cart to a bigger flash chip, which could cost more. 

I got the image flashed and started up Retropie, but hit a few dead ends. I don't own a USB keyboard anymore. My old roommate took the USB dongle somehow when he packed up and moved out, and I can't get Retropie to connect to my bluetooth keyboard. I had to use a controller to get it set up and into the main menu. Useless without a keyboard. Stuck again. The Covid lockdown cost me my home, twice, and I ended up getting rid of many of my possesions. The extra time off work is the only reason I'm able to work on these right now, but the lack of project funding is very frustrating right now. I also managed to crack the SD card I was using in my Pi Camcorder project when I removed it with pliers, because it was too hard to get out by hand. Luckily I have my software backed up, but I have to reinstall everything, and that won't be fun. I was going to make an SD card backup, but all of my SD cards were buried somewhere, and I never got around to it. Just found them today, but broke the card before I backed it up... Off to a bad start.

Wrapping this log up and finding something else to do.

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.