Project Logs

Collapse logs

• SD NAND Chips​: Affordable Storage

  Dustin • 01/01/2021 at 13:55 • 0 comments

  I'd been trying to find a permanent and proper way of adding large storage chips to the cartridge, and I finally found something viable: SD Cards on a Chip. They come in 1,2,4, and 8GB capacities, and have the SD controller built in. This could be hooked directly to the Pi GPIO pins, and would just show up as mass storage. I may be able to add a protected read only partition for ROM storage, and have the rest of the cart be available for user storage space. The Thonny Python IDE comes to mind here, allowing the user to store their programs on the cart, instead of having a separate storage device. I was going to simply add an SD card to every cart, but that gets expensive, fast. These chips are about $2.50 USD each, instead of the $9.00 USD or so for an SD card, plus the socket. I was worried about using SD cards as they might come loose over time and they'd certainly make the carts very expensive. Shaving $5.50 or so off each cart's manufacturing cost will help make the system affordable for, which gets it into the hands of more people. With just a blank memory cart, it would be nothing more than a giant flash card for the GPIO Port. The magic comes when other hardware is included in the cart, such as lights, speakers, mics, motor drivers, and whatever else you could want. It's basically just a hat system for the Pi 400, but with a few special features, like possibly being able to boot an OS from the GPIO Port. I was struggling to find flash storage large enough to hold even a few hundred megabytes until I came across this chip. The largest SPI flash chips I found were 8Mbits, so if have to connect a bunch of those up and program something to manage it. The SD system handles everything for me, getting this project going that much faster. I still plan on making some SPI ROM carts for simpler things and retro games. I like the challenge of making ROM carts and stuffing data into them like they used to do. I'm very excited to get some of these chips in for testing and start making my first cart.

• Preparing The Prototype Order

  Dustin • 12/14/2020 at 15:33 • 0 comments

  I decided it's about time to order some hardware and build a test cartridge. For the connecotrs I've found two options: Standard and Tall headers. The standard height would just plug into the GPIO port, but the tall would stick out of the back of the cart, allowing other things to be connected to GPIO at the same time. I like the idea of having a joystick cart that has connectors for things like Commodore or even NES joysticks. That would plug in first, then the game would plug in on top of that. Could get quite crazy looking, but may of the older consoles had tons of hardware that could be plugged in all over. For now, I'll order the standard height so I can get started on a test cart. For the memory chip, I'll be ordering a few of the 4Mbit EEPROM chips. I'll need 1 of them for a single chip cart, and at least 2 for a multi-chip cart. I already have a small stash of protoboard large enough to mount the headers and build a simple board. I just need to see if there is any supporting hardware I need for the EPPROM chips. Accodring to this page, it should be a very simple matter of connectng some wires and running the code. If that's the case(will confirm this connection method is proper for long term use), then these low capacity carts will be very simple. Just a single IC, connected to some of the pins on the header. Seems like a waste of space and hardware, but that can be handled later. I plan to make the carts fairly large to leave room for more advanced carts in the future. I can easily hand wire some test carts when the hardware arrives, so this should be just fine for testing. 

  On a random note, I found a nice looking EEPROM program written in python. I was thinking of how I can make a program that will handle reading of the EEPROM, but no need. I could have this program load on start up, and have it load the EEPROM data into another program. EEPROM-PiPython.

  Pricing

  EEPROMs, with shipping: $15.31 USD

  Headers, free shipping: $8.18 USD

  Total: $23.49 USD

  Price per cart: $3.26 USD

  The price per cart is my cost, not including the solder, wires, and PCBs, all of which I have already. A fab house can likely make these far cheaper and faster than I can, so I'll be designing and ordering some premade boards when I finalize a few designs. There is much to consider, such as physical size, memory type and layout, pin assignments, and even board color. 

  I accomplished what I set out to do with this log, so I'll move onto the next thing.

• Default Boot Considerations

  Dustin • 12/14/2020 at 05:48 • 0 comments

  All of the classice home computers had some sort of environment they booted into when there was no cart inserted. This system should as well. To me, it makes the most sense to have it boot to some sort of Python development environment. I could have it boot a C64 emulator and offer people a BASIC prompt, but that's not exactly practical these days. This system is based off of retro systems, but the goal is to make a modern version of those classics.

  I started looking into different Python IDEs and found mu. It's pretty neat and looks like it might be perfect, except that I can't get it to install on either of my two linux laptops. I've had nothing but terrible luck with software on Linux lately, and it's geting very frustrating. I thought this might be as simple as installing a new program and seeing if I like it, but not so. This is the second program I've tried to work with tonight that just outright fails to install. 

  I decided to do some testing with something I was fairly certain I could actually get to work: Thonny. I actually really like it, just based on the few minutes I spent with it. It's far more complex than the old BASIC prompts, but I didn't feel overwhelmed. One thing I'd love to do is create a custom color scheme for it for this project, and set up a bunch of defaults to make things easier. That reminds me that I need to create a manual for this computer as well. That is a massive project in itself, but one well worth completing. The old manuals were an important part of the home computer experience. The goal is to be able to provide everything needed to get started without internet or messing around. 

  The next step in this part of the project is to get the Pi to boot straight to Thonny and lock out everything else so no one can break the OS. That's probably going to be far more difficult than it sounds. I'll start on that this week and see where I can get. 

  It occurs to me that I'm still very much in the research phase, and it feels like I'm not making any progress here. The cure for that is to get some hardware ordered and start making development hardware. For now, I'll start doing all of my Python coding in Thonny to evaluate it as a default IDE.

• Word Processor Cart 1: Initial Testing

  Dustin • 12/14/2020 at 03:54 • 0 comments

  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. 

• Tiny OS for Pi

  Dustin • 12/07/2020 at 18:48 • 0 comments

  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.

• SPI Interface Stuff

  Dustin • 12/07/2020 at 17:41 • 0 comments

  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
  

• Cartridge ROM Chip Selection

  Dustin • 12/07/2020 at 17:21 • 0 comments

  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...

  Read more »

• OS Testing: Ubuntu MATE 20.10 for Pi

  Dustin • 12/05/2020 at 03:11 • 0 comments

  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.

• More OS Research

  Dustin • 12/04/2020 at 03:59 • 0 comments

  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. 

• Hardware Update: GPIO Boot Mode

  Dustin • 12/04/2020 at 02:44 • 0 comments

  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.

View all 16 project logs