Resetting the cart from the menu corrupts persistent RAM. Here's a minimal example:
--corruptor function _init() cartdata('corruptor_ram_test') -- dump persistent ram for i=0,63 do printh(dget(i)) end end function _draw() end |
Run this from the command-line and repeatedly do "reset cart" from the menu. It should print 64 zeros every time. But after a few iterations, it will start printing out non-zero numbers, demonstrating that persistent RAM has been corrupted. 😱
I think perhaps this was a regression introduced with the realistic glitching effects upon reset. Maybe a bit too realistic!
If it means anything, the HTML export doesn't seem to corrupt the memory when you keep clicking the reset button. (And the HTML export doesn't have the glitch effect...)
I can confirm this happens on pocketCHIP.
Very nasty bug. Happens about one in three times you press reset.
I am terribly sorry for joking about serious stuff that matters(tm) but who is the first to come up with useful error checking code?
Here's my attempt:
-- triple modular redundancy -- sacrifices 2/3rds of the persistent ram -- for redundancy so we can only use -- memory slots 0..19 (20..39 and 40..59 -- hold redundant copies of the data) -- only 20 slots used for code clarity, you -- can of course fit flr(64/3)=21 values --majority gate - if one of the three values --is different from the two, the majority value --is returned function errcheck(memslot) local x=dget(memslot) local y=dget(memslot+20) local z=dget(memslot+40) return bor(bor(band(x,y),band(y,z)),band(x,z)) end -- same as dget() except this also refreshes -- the other memory slots function edget(slot) local v=errcheck(slot) -- refresh value edset(slot,v) return v end -- set value in slot and the extra slots function edset(slot,v) dset(slot,v) dset(slot+20,v) dset(slot+40,v) end |
I made a test cart and this seems to work. Unless, of course, two of the redundant copies are corrupted at the same time. I think we can just increase redundancy in that case, depends what is the maximum numbers of corrupted slots.
I was just thinking of this! Would "mid" work instead of the bitwise operators? After all, if two out of three values are correct, then the middle value one must be correct. But I'm hoping we won't have to work around this for too long...
Oh, wow. Thanks for the report weeble. You are exactly right about the glitch effect being too realistic..
Fixed for 0.1.11, and bumped 0.1.11 forward as much as possible.
@kometbomb ha, that redundancy method is really nice, it's just too bad it might actually be useful.
p.s. I'm so terribly, terribly sorry.
[Please log in to post a comment]