Log In  


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!



ouch!! that's a heavy one!


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

Cart #42985 | 2017-08-01 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

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.


All I can hear is

[quote]bumped 0.1.11 forward[/quote]

\o/

@weeble: Yes it would. Good thinking!



[Please log in to post a comment]