Running unofficial code on a Nintendo Game Boy has long been a solved problem. However, you still need a way to get that code onto the handheld console. The Squareboi cartridge promises to do just that, as created by [ALXCO-Hardware].
It’s a well-featured cartridge, with up to 4 MB of ROM storage onboard. It also features a ferromagnetic RAM part for savegame storage, which doesn’t need a battery to hang on to your precious data. It’s designed to be compatible with the vast majority of Game Boy and Game Boy Color games, with efforts made to support the most common mapping schemes. It can be built using entirely through-hole components, and is readily programmable via an Arduino.
For those eager to tinker with code on the Game Boy, diving into the Squareboi is a great way to get closer to the bare metal and understand what’s really going on at the low level. Those interested in building their own can get all the relevant details over on Github.
We’ve seen similar hacks before, too, like the cartridge that brought Wikipedia to the humble Nintendo handheld. If you’ve been whipping up your own Nintendo hacks, be sure to drop us a line!
FeRAM is a great addition. I really like that I can go back to my Sonic & Knuckles saves years or decades later and know that my save is intact. I had to backup my wifes Pokemon Yellow save before swapping the battery. FeRAM is a great addition to any homebrew/flash cart.
You may want to check that save data: my wife’s cartridge ended up unable to save any more, which led to some surgery to replace the FRAM chip. Nothing pin-compatible is made any more, but there are plenty of designs for breakout boards available on the Net.
https://www.embedded.com/frams-as-alternatives-to-flash-memory-in-embedded-designs/
Is the write speed of FRAM really appropriate here compared to flash memory?
It’s a matter of compatibility. Existing game boy software uses battery-backed SRAM for its save data, and expects write operations to happen in a single cycle. Using flash for save storage would require patching all existing programs, which is not feasible.
The cart does use flash for ROM storage, however, since the programmer has purpose-made software to bypass that limitation.
To think that this comment was written in 2022, unbelievable…
It’s the duck’s guts. Terrible, Muriel.
Not that happy with the FRAM, some games use the external RAM as exactly that, a RAM expansion. And as FRAM has a finite lifespan it is not a good idea to have some game hammering away at it.
FeRAM has an extremely long lifetime, so I wouldn’t worry about it.
Flash memory is rated for ~10^4 write cycles, EEPROM is good for ~10^6 write cycles, while FeRAM is rated for ~10^14 write cycles.
To put in perspective how much write endurance FeRAM has: Imagine you have two SLC SSDs. You write and rewrite to the first SSD until it is worn out. At this point, you replace the first SSD, and write once to the second SSD. You repeat this process until the second SSD is worn out. That is approximately how many write cycles FeRAM is good for.
The part you are missing is that read cycles also degrade FeRAM. Depending on the game, that could exceed 10^14 reads very quickly.
Back of the napkin calculation: at 10^14 reads/writes (because reads are destructive), assuming a game were to read every cycle at the 4MHz this gameboy runs at (very unlikely but let’s just take this as the worst case scenario), this would mean the fram could endure 289 days of torture…erm I mean continuous runtime before expected failure.
Probably quite a bit longer than that in fact – The game boy CPU runs at 4MHz internally, but all operations take a multiple of 4 cycles, so the cartridge bus actually operates at only 1MHz.
This too.
You can use FRAM in a project where you seldom access that data and keep a working copy in normal memory, like configuration data or really just savegames, but then you could also look into cheap SPI Flash that if push comes to shove for your (retro-)platform you simply bit-bang.
For the GB and GBC you would need some clever solution tough as in their eternal wisdom Big-N forgot the IO pin on the cartridge port. The original MBC1 just checked if you wrote to some ROM addresses and acted accordingly, but if i wrote my own game i would think of something myself, something that i can put into a CPLD as Microchip still produces 5v CPLDs. Check the ATF1502ASL as an example.
I didn’t know this about FeRAM. I found this: https://www.everspin.com/mram-replaces-fram-feram
That’s a valid concern. As others have pointed out, the endurance of FRAM is pretty good even with games that use it as scratch RAM, but it’s still something that could be improved.
The system uses swappable daughterboards for its memory options, so I’m currently working on a more traditional battery-backed SRAM module as an alternative.
Or you could get an Everdrive and not have a monstrous ridiculous brick hanging off the gameboy? No one is ever going to actually use this for longer than 5 minutes
Umm, it’s for development.