I posted the most recent version with EEPROM-saved highscores. I also posted a gameplay gif, which I converted with imagemagick, but even with a delay of zero between frames, it seems to play the animation back too slowly. Anyway, I’m done with this for now. There are perhaps a few small changes I could make, but I’m leaving them to later.

In the meantime, I present a highscore challenge: my highscore on the game is currently 10630. Post a photo if you get a higher score, and I might put a little leaderboard in the first post.


Nothing to brag about : 3405 at first try :slight_smile:

1 Like

Nice job for a first attempt!


It has become an excellent game @wuuff … now we will try to get the sound working better. I think I might know what the problem is. The same volume affects output now in two ways: 1) it affects the digital potentiometer that controls the overall volume. But in Gamebuino sound, the same master volume is also used as a multiplier when the sound output byte is calculated.

1 Like

7495, on second attempt :slight_smile: (sound is ok btw)

1 Like

3 posts were split to a new topic: [Troubleshooting] Battery issues

2 posts were merged into an existing topic: [Troubleshooting] Battery issues

well…its only a little higher but still counts ?


Yeah, it counts! I added a highscore list to the first post. I probably should have done so earlier but at least I have enough scores now that I can have 5.

I noticed that you also encountered the bug with the highscore table where the loader overwrites data over Armageddon’s highscore table. I should have chosen a different EEPROM location other than starting from zero. I would have preferred the loader data to be at the end of EEPROM but that’s just a personal preference.

I probably should update the game to save at a different place in EEPROM, but nobody has complained about it so it was low priority. I’m pretty busy for the next two weeks or so, but if anybody finds it bothersome I can patch it easily after that, or they could patch it themselves! Open source!


We could do with a ‘save/load EEPROM to/from SD file’ program.

The reason for picking a different spot isn’t just to avoid overwriting other game’s saves, it’s also because if everyone writes to the start then the early areas of EEPROM wear out faster than the rest (depending on how good the wear levelling is).

(It would be neat if chip manufacturers took that into account and gave earlier areas a better lifespan.)

the max write cycles is something like >100k.

If you wear out EEPROM by playing Armageddon, I will bring a new Pokitto to your door! :wink:

Edit:1M cycles at 25C (source: Microchip)

1 Like

Why would you use a Microchip specification for an NXP part?

From the NXP LPC11U6x datasheet section 12.1 table 11:
EEPROM endurance: 100000 min, 1000000 typical cycles
(Tamb = -40℃ to +85℃; VDD = 2.7 V to 3.6 V. Based on JEDEC NVM qualification. Failure rate < 10 ppm)

Lazyness. I guessed they’d be similar, both being ARM Cortex-M0’s

1 Like

Laziness is a a virtue.

1 Like

Here a new Highscore (Nr… 3)


Fear not, for I have appeased the angry noodles.

(Ignore the weird top score, that was there when I started. Obviously two games writing to the same block of EEPROM.)


:open_mouth: insane

1 Like

@Rakkachi still has the highest score though - 10695.


Highscore table updated! Keep the scores coming. If we get enough I may expand the table to 10 slots.

I really need to fix the EEPROM issue by saving the highscores at a different place from any other game, but I really have other things I need to be working on… Maybe I can make an update this weekend.

Maybe we also need the loader to start saving and restoring EEPROM from the SD card to prevent conflicting saves from corrupting EEPROM, but that would only work when games are loaded by the loader. Data would still be corrupted if games are loaded directly from a computer. Would such an addition still be useful if flashing directly would still cause problems?


A better fix would be to use a checksum algorithm to verify the data.
That helps you know if another game has overwritten anything.

Then if it doesn’t match up warn the user “either the current save data is corrupted or there is no game save for this game, would you like to make a new save?” and then wipe the data if they say yes.

Not necessarily.

If we built a function into the library that could handle that so that there was a common interface for it then every game could voluntarily offer the ability to store the previous EEPROM to SD or create a backup of the game.

The difficult part is finding an arrangement that suits everyone and does what’s intended.
This also ties in with the idea of coming up with an SD arrangement that gives each game or author their own folder.

Yes, because people would be aware of the issue and chose when to backup their EEPROM.

(Also my suggestion of a function/class in the API helps to mitigate that.)

1 Like