Eeprom collision

Just to double-check, is Harambe’s Revenge accurate there?
Last I checked it used a system that consumed more or less all of EEPROM.

I remember there being an intent to change it to use just what it needed, but I don’t remember if that actually happened.
I had a quick look and I think perhaps Akkera might have produced a .hex with some kind of fix, which might be the one that ended up on the cart.

I must say, I’m surprised at how many titles take up such huge chunks of EEPROM. Just goes to show how futile it would be to try to prevent clashes. All we can truly do is detect and manage them.

Ultimately levelling out the wear is more important than trying to prevent clashes anyway.

It occurs to me that the rest of the world probably don’t realise you meant a vegetable and not someone from Sweden. :P

I agree with Filmote here.
It’s not worth worrying about problems that don’t exist in practice.

(At least, not when this is our spare time we’re giving up. Start paying me a wage and I’ll gladly consider every last ridiculous edge case. :P)

I said more or less the same thing to @acedent the day before:

Though I think I remember Tuxinator telling me that he was intending the player to bring their character across from the first game. I might be misremembering though.

Either way, it was never finished, and even if it were that’s still only two games. I think you’d need at least a handful to justify the additional legwork.

Yeah, there’s probably a better option than a tooltip.
I’d say some kind of pop-up window with an actual list, and then maybe make the tooltip say ‘click to see clashes’ or something?

As far as I can tell, as long as it’s red and blue instead of red and green, making the red more yellowish wouldn’t be necessary because red and blue are distinct for all three forms (tritanopia, deuteranopia and protanopia).

I’m going by the images I found here.

GitHub changed the closed marker from red to purple for a similar reason - ‘closed’ is not a bad thing.

Though I agree with Filmote that a hash is better than no hash because it lets you know when a clash has occurred, so in that respect it’s still ‘good’.

If it’s important to keep the green, then green and yellow is another pairing that would seem to be acceptable from a colourblind point of view.

You forgot to specify that the heatmap shouldn’t use red and green to indicate ‘heat’. :P

(Though actually, blue and red makes more sense for ‘heat’ anyway. Blue = cold, yellow = warm, red = hot.)

If I had all the data I and an hour or two to do it in, I could probably make a desktop tool to do something like that in Haskell, C++, C#, or Lua (take your pick). (Well, as long as that’s all you’d want it to do. No ‘one more thing…’ features.)

But doing it in JavaScript and HTML…
No thanks - getting the algorithm working would be only half the battle, manipulating the UI would be a separate battle entirely.

I really don’t envy @filmote being the one to have to do all this web UI stuff, he’s done more than I’d have patience for.

As accurate as @acedent’s keying :slight_smile:

I get that some (like the coder’s toolbox) are storing large objects in there but some of the other games really surprised me too.

Ah, sorry. I must have missed that.

I think highlighting the rows might be better as then you can visually see the clashes.

If you looked under the covers you would see that my JS and jQuery is very basic. This is a bit of a mess. I hate web work as a rule.

1 Like

I’m going to presume the one acedent used was the one @akkera102 modified somehow, though I’m not sure Akkera made the source public.

I half understand some of the software ones using a fair bit of EEPROM, though others I wonder why they’d need it. E.g. I wonder why Calendar needs so much.

The BrainFuck one worries me slightly because I wonder if it’s using EEPROM like RAM or something.

I’m not quite sure what Chie Magari Ita is doing either.
Looking at the code, I think it might be saving entire board configurations?
I’d need some time to pick it apart, and that’s time I can’t spare this morning.
Though, based on a quick skim, if I’m reading this right, its start address should actually be 864?

Nothing to apologise for, my point was just that if we’ve both said it then it’s probably accurate. (My memory isn’t always the best.)

Possibly, though that sounds like a fair bit more effort.

Also, it depends on how many of the games are actually on-screen at the moment. Highlighting rows may not be useful if one of the games is currently on an off-screen row, whereas a popup window with a list would show only the relevant information.

Unless instead of highlighting the clashing games it hid all the non-clashing games, leaving the user with a list of clashing games? Though that sounds like it might be more difficult.

My knowledge of jQuery extends to the fact they decided to declare a global variable named $ (which seems a bit self-important to me), and that a fair bit of what it does can be done with JavaScript’s DOM API. I’ve never actually used it for anything, just skimmed sample code (and frowned).

Me too. I started trying to design myself a website once and gave up shortly after figuring out how to make a ‘theme’ feature. It’s a far cry from using a desktop GUI API.

Half the problem, as far as I see it, is that the technology underlying the web is being required to do things it was never originally designed for. As far as I understand web history, HTML was really designed for things that would have originally been books or print (e.g. encyclopaedias, newspapers), not for so-called ‘web apps’. More or less everything else was bolted on top as an afterthought.

It allows you to add calendar entries- but obviously not many :grinning:

Everything can be done. It’s just a helper library.

At this stage, I’d like to share the glory (and blame!) with @Mr.Blinky who did the vast majority of the analysis used to produce the original spreadsheet. :sweat_smile:
It’s very possible there are mistakes – and this data is 2yrs old now…

@Pharap - please feel free to modify the original spreadsheet with any errors, or just post here and I will try to maintain it and post fixes for the CartBuilder.

Some original discussion with the author starts here.

1 Like

Presumably a calendar entry is a large blob of text or something?

I mean in a less cumbersome way than used to be the case.
From what I’ve skimmed, jQuery used to be used a lot because the JavaScript DOM API used to be quite crap, but it vastly improved sometime around the EcmaScript 6 standard.

(I wonder how many people realise that JavaScript is actually an implementation of the EcmaScript standard…)

The thing is I’m still not entirely sure if it is an error. I’m kind of confused about what’s what in regards to Harambe’s Revenge and need a second pair of eyes to confirm what I’m seeing.

So far I’ve managed to establish that Akkera made a version of Harambe’s Revenge (which I struggled to find because it wasn’t in a proper fork), and I’m presuming it’s that version that’s ended up being accounted for because the original was never updated.

However, if Akkera’s version is what’s in use, I count 11 bytes of progmem in use, from addresses 16 to 26 (inclusive). Three bytes here and 8 bytes worth of HighScoreEntry. (I mentioned this in my comment on the other thread.)

(That possibly suggests some of the other entries in the chart using the range 16-16 might not be accurate? I.e. that these entries haven’t actually had their range counted, and that 16-16 range was a placeholder?)

Also, I’ve suddenly realised Akkera’s version of Harambe’s Revenge is using EEPROM.write, not EEPROM.update.

I checked the rest and so are Evade, and Arduloop.

(For the record, this is exactly why I was against having both a write and an update on the Arduboy2EEPROM API - programmers who don’t deal with EEPROM expect to have a read and a write, they don’t expect an update function. If they don’t know any better, they’ll instinctively use write because it’s what all the other APIs have, so it’s better for that to be the right choice, or indeed for there to be no choice to make.)

Fanboat’s safe because it’s using put, and Calendar is actually using update.

Not quite as useful as you were expecting I’m afraid.

It just says that Mr Blinky accidentally overlooked that bitfields were in use, and that Obono was using a checksum (and me being pleased/impressed that someone else had attempted a checksum/hash to protect their game).

Upon a second look at the actual code I’m fairly certain that 864 is the start address, though I’ll have to sit down and calculate the size in a minute, I need to dash off for a moment.

1 Like

So it works …


That is flipping awesome!! Love it! :smiley:

Edit: How are the titles sorted? I presume not alphabetic – ok, it’s by start address. Would it be possible to sort by start address and then also by end address? e.g. the many collisions at 16 will the cascade better.
I also presume you have a very wide monitor! It may be worth putting the Close window ‘X’ to the left of the title… there was a moment of confusion before I scrolled to find it…

The popup is only about 1300px wide and should be visible on most normal monitors.

I do have a 4K monitor (3840px wide) so it looks quite narrow for me :slight_smile:

Mmm … I guess so.

Yep Have done that now.

I cannot control that as its done by the jQuery library. How small is your screen?

1 Like

1152 px wide… first time I’ve been screen shamed… :sweat:


Yep … sorry. How do you call yourself a lover of technology and have such a small monitor.

You are supposed to respond with a ‘its not the size but what you do with it’ sort of joke.

1 Like


… would you consider ~900px width and a horizontal scroll bar?
Edit: using it a bit more, works fine. It would be nice to add back the text box for the selected game, showing just its start/end/hash details. Bonus feature: Add a tick box to ‘hide whales’ – anything over 256(?) bytes in size gets hidden. Currently everything seems to clash because of a few large titles.

Assume you mean the tool tip / alt text?

You can see that by hovering over the bar itself … but I can put it over the text as well.

This is true.

I am open to PRs :slight_smile:

And only because I had a go at you, go and try the cart site now (you may need to refresh the browser).

1 Like

Out of interest, is that a tablet or just a really old laptop?

My old laptop had that awkward 1366×768 resolution that would have only just fit a 1300px box.

As things currently stand I have a single 1920x1080 monitor, but I like to have my browser windows snapped to one half of the screen, making them portrait, which tends to confuse some websites.

Either way the moral of the story is that developers are hilariously prone to false assumptions (e.g. “clocks always move forward”, “people always have a forename and a surname”, “nobody uses 32-bit computers anymore”).

Can you try it now @pharap? Are you seeing the large or small version of the popup? I have also added a scroll bar (up / down) as it was very tall.

I already tried it, hence the like on the post above.

If I look at it with a maximised window I get a horizontal scrollbar as well, and the names are a tad squashed.

(Not that that matters to me, since I probably won’t be using a maximised view anyway.)

Ah … I thought you had done that before I added the scroll bar. I had only added it moments before you posted.

Its an interesting problem with jQuery dialogues or - more likely - my understanding of them and how best to handle sizing.

I check the window’s width as I initialize the dialogues (onDocReady) but when I render the content of the dialogue (on clicking of the button), I check the window size again to see whether to use the narrow or wide rulers. If you had refreshed the page (or come into it full sized) then the second version would have worked - its a result of you resizing the window after the initial onDocReady(). Not sure best way to fix that …

I could always store the initial width away somewhere and use it when rendering the content but that seems a little backwards. Would be better to re-initialise the dialogue on clicking the button.