But @ThaddeusSM you have 115 more levels of Lode Runner to complete before you can risk upsetting your EEPROM settings.
BTW … that link look to be a place holder. There is not code or .HEX file there.
But @ThaddeusSM you have 115 more levels of Lode Runner to complete before you can risk upsetting your EEPROM settings.
BTW … that link look to be a place holder. There is not code or .HEX file there.
Yeah I know about Lode Runner XD. I should have looked at the github page closer I guess. In my excitement I went too fast
I looked a little deeper in the Team Arg website/github page and it looks like they just claimed all the necessary sites, but haven’t put up any actual files yet.
Peaked too early. It will be interesting to see what EEPROM settings they are saving - would be lovely if there is no clash!
What level are you on now?
I am on 49 I think?? Level 43 or 44 might be broken btw. I remember having to skip either one of them or both due to some abnormality in the level design, but I forgot to report it right away sigh hopefully we can find it again.
I am working on a level designer that makes it easy to pick errors and design new levels. The above pic is from that designer.
Can anyone else see the stormtrooper?
Unfortunately there will always be a 1/65535 chance that your chosen sentry value is going to clash.
But on top of that there’s the possibility that the sentry isn’t overwritten but the other data is.
A better solution would be to use a cyclic redundancy check.
That would tell you if any of the data had been overwritten and not just the sentry value.
(Unfortunately every time I go to read about the maths behind CRC they loose me at ‘long division’. Xor being addition modulo two makes perfect sense, as does treating a string of bits as a polynomial, but long division is just weird, even when done with regular numbers instead of polynomials.)