EEPROM Crusade - Fixing the games that overwrite reserved EEPROM

Following the conversation that started here:

I’m going to attempt to fix some of the games that are overwritting the reserved EEPROM bytes - i.e. bytes 0 through 15, the first 16 EEPROM bytes.

I have no idea how long this ‘crusade’ will last.
(Probably either until I get bored of it or my help is needed elsewhere.)

Hopefully others will help out by reporting other broken games, helping to track down source code or (for Gamebuino ports) providing replacements.

Games that need fixing

  • Crabator
  • TinyDepth
  • CalenderApp
    • Note: problem is due to logic error
  • Armageddon
  • Evade
  • Fanboat
  • Harambe’s Revenge
    • Note: problem is due to logic error/issues
  • Jezzball
  • WHG
  • Arduloop
  • Big Black Box
  • Digger
  • Solitaire
  • Tiny Sokoban
  • Tiny NS Tower
  • Uforace
  • 101Starships
  • Starduino
  • Tiny Asteroids
  • Tiny Digital Invader

All taken from @Mr.Blinky’s spreadsheet.

Games that have been fixed


Current status

I can’t actually find a forum post or source code for Crabator, TinyDepth, Armageddon, Jezzball, WHG, Big Black Box, Digger, Solitaire, Uforace.

(I’m beginning to question who actually ported all these Gamebuino games - the all have the bug and they’re all missing source code and forum entries.)

Fanboat has code, but doesn’t really specify a proper licence and there’s no GitHub page, which means I’m going to have to try to contact the author to negotiate a fix.

Calender’s problem seems to be that it’s actually trying to write too much to EERPOM rather than explicitly overwriting the reserved area.
Although looking at the source, I only count 114 bytes being used.

I’ve had a quick look at Harambe’s Revenge.
Figuring out if there’s an actual error or not is not a clear cut task - the logic has to be unpicked first.

Evade seems fixable.
I’ve raised an issue on the GitHub,
but if they don’t reply within the next few days I’ll make a fork with a fix or something.

Arduloop seems fixable.
I’ve raised an issue on the GitHub,
but if there’s no reply it’s going to take a while to fix the logic.

The ‘Tiny’ series of games by Akkera102 all seem fixable.
I’m going to wait until I have time to compose an explanation in the author’s native language (Japanese) before raising an issue or contacting them.

Starduino is completely closed source, so only the author can fix it (and may already have done so? I seem to recall a conversation about it).


This was one game I adapted. I’ve forked and adapted it on my GitHub

1 Like

I got a fix for it & the hold Up&Down for reset thing.

Waiting on confirmation if we want to move the save area to some other offset to fit better with other games before I repackage it.

1 Like

A few of the gamebuino games were adapted by @Electro-l.i.b

@Pharap once you make the changes could you make a pull request to

Team work - FTW ! :grin:

I’ve put quite a bit of effort in compiling a game list primarily focussed on authors (see my 3rd point below) and @Mr.Blinky has focussed on directly collating EEPROM address usage (wonderful work!).

There’s 3 reasons I resisted jumping in and fixing up these games immediately:

  1. Until we have mapped all of the <350 games, we may just be moving from one crowded area of EEPROM to another. I’d love there to be some discussion on best practice (yes, “again ?!”… I know)… but at the very least, let’s try to ensure the address only needs to be shuffled once. I’m hoping to visually represent density of address usage.
  2. Beyond the obviously wrong reserved 16 bytes, documenting usage shows other bugs and fragmentation (multiple address ranges used, perhaps due to a typo!). Less urgent, but still good to compact and remove bugs here, benefitting point 1.
  3. Community! My preference is reaching out to the authors (as I have been!) to fix their own bugs. My hope is that authors may be able to achieve better efficiency gains but considering what data really needs to be stored, using the smallest data types. Most importantly of all, I hope to bring the long tail of solo contributors and lapsed members back in to the community and excited for the FX magic! We may even attract some first time contributors who want to fix-up there fave game. I really think the task is better if more inclusive and immersive - focussed on the community.

All that being said… of course I couldn’t resist starting to tweak some games… :innocent:
I actually created a GitHub Org for this purpose, generating PR’s to upstream in due course ~ Golden Cartridge - FX collection · GitHub

I’m happy to rename the Org and invite team members if other’s want to contribute… or be active on an official @bateske Github Org … but still think my points above are worth considering… Cheers

Edit - To prove point (3): from @obono’s contribution on his own code, exposed some misunderstanding. The more eyes reviewing this, the better!


I’m already in touch with the author @fanboat via email and will point him here too.

I’m also encouraging @Electro-l.i.b to join the community via Twitter

It was @akkera102 Gamebuino Library for Arduboy

Details also here:

The problem with some of the converted games is that they using copyright or trademarked materials.

@bateske I was hoping the GoldCart would exclude ported (e.g. Gambuino) and emulated (e.g. VMS) games, unless they use the full 128x64 screen…

Yeah for the most part, you can check the current games:

Super Crate Buino is kind of on the edge because its for gamebuino, but @uxe did a pretty full port of it, and it’s nice game to play…

If you make the changes to EEPROM games listed then can you please issue pull request to the hex files of that repo?

(Also, I’m considering bringing all of the files into one folder for hexes as the categories is being determined by the CSV file, it’s not needed and since then I’ve moved some around but not their file location)

Circuit Dude (with custom levels) and Micro City use a lot of EEPROM. Should those be considered when moving things around? Otherwise, I’d expect users to just know that they are overwriting other game saves. UNLESS, we come up with a solution. Maybe an FX-specific version for saving data to the FX chip could be done? I could make that change with Circuit Dude, but I didn’t take a look at the code for Micro City, though.

If he needs any advice or information about licensing,
feel free to point him in my direction or ask for some resources to pass on.

Even if he isn’t open to licensing, as long as he agrees to provide a version of the source code with the problem fixed then we should be fine.
(Though of course, not having the code licensed causes issues for distributing it.)

As I said, I’ll try to find some time to contact Akkera.

I intend to provide both an explanation in English and an attempt at an explanation in Japanese.
Akkera does understand English, but I think they would appreciate having both, and having someone who will be (probably) able to make sense of a response in Japanese.

That said, if there’s someone whose Japanese is better than mine, I’m happy to let them negotiate in my stead.


That’s an entirely separate issue to the EEPROM issue,
and the appropriate response would have to be determined on a case-by-case basis.

Typically the answer will either be drop the game or edit out the copyrighted/trademarked materials.

If you’re going to do that, try to also bring the licence file along with the .hex.
That’s something we really haven’t been doing enough of.

Also be wary of GPL-licenced code - by distributing a precompiled copy of anything under the GPL licence you also have to provide access to the source code in one of several officially sanctioned means (the exact terms are quite long and confusing - see section 6 of the licence).

1 Like

And if you end up having a mechanism for doing this for GPL, it wouldn’t hurt to do it for all licences.

1 Like

The cart github has the source code in zip files. I’ll probably put them in source folder, and the license is contained within there. If anyone wants to write 200 license files then I’ll add them too.

Though given the amount of hassle doing that entails,
another option is to not redistribute code released under the GPL and just stick to the more forgiving licences. :P


Assuming the source is being taken from GitHub repos,
the licence files should already be provided with the source code in most cases.
Some people might specify the licence as part of the source code but not provide a licence file.

If the licence isn’t part of the source code and there’s no licence file then technically you probably aren’t allowed to redistribute the game or the code.

The zip files are in the same folders as the .png and .hex

1 Like

I’m already retired from homebrew developer.
but @Pharap summon me. ‘:)’

First, I fixed the gamebuino games.
eeprom writting offset: 0 -> 16.

Thank you @Mr.Blinky. I used your list and game source code.
@bateske I requested pullup(ArduFXTest github). please if it is no problem, marge hex files.


1.Crabator          60     name + score(MSB+LSB)
2.Armageddon        80     score + name
3.Jezzball           4     id + score
4.WHG               22     levels
5.Big Black Box      1     level unlock
6.Digger            10     game mode, score, etc. fixed eeprom init 1024 -> 10 byte
7.Solitaire      0x120     c++ object added. simbuino debug(rough 0x120 byte)
8.Uforace           60     name + score(MSB+LSB)
9.101Starships       2     score(MSB+LSB)

source code


Hi @akkera102 -that’s awesome!
Welcome back :smiley:
Could you look over some of your other nice games ? ~

Many thanks, Andrew



A post was split to a new topic: Storing EEPROM data on the FX chip