I mean the subdivisions… you could have half as many and have each subdivision = 1byte.
Perhaps a visual representation would help? Like dimming rows, and highlighting just those that clash?
Is it possible to change colours: red → reddish-orange (more yellow) and green → blue. This helps with colour blindness and also removes the misunderstanding that the hash is green for ‘good’ (it doesn’t actually fix a a collision).
1 Like
Yes, that’s what I am thinking.
Yep.
No but it is good in the sense that the user will not have weird results - like ridiculously high scores when they have never actually played the game and so on. It would reinforce the ‘please look after your EEPROM use’.
Each tick is actually four bytes, not four bits. Removing every second tick results in 8 bytes - which is as meaningless as 4 bytes I guess.
1 Like
Sorry… my mistake!
So your scale runs 1 to 1024 (not 0 to 1023), and each number is the decimal address in bytes +1 (max is 1024 bytes - but some bugs might exceed the available EEPROM).
This will be really useful when understanding interactions of existing games.
Would it be possible to provide a different view for developers planning to use EEPROM? Something like a heat map? Even better, the facility to enter the number of bytes to store- and be given a start address to minimise byte collisions, and ensure the address and the length, won’t collide.
I haven’t shown it here but those that start at 0 are on the left hand margin (so its really 0 - 1023).
Version 2.0
Fark … I will let someone else contribute a PR for that.
1 Like
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 
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 
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. 
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
That is flipping awesome!! Love it! 
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
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… 
2 Likes
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
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