Log In  

Resetting the cart from the menu corrupts persistent RAM. Here's a minimal example:

function _init()
 -- dump persistent ram
 for i=0,63 do

function _draw()

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!

P#42920 2017-07-30 13:16 ( Edited 2017-08-01 11:30)

ouch!! that's a heavy one!

P#42922 2017-07-30 14:06 ( Edited 2017-07-30 18:06)

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...)

P#42950 2017-07-31 06:44 ( Edited 2017-07-31 10:44)

I can confirm this happens on pocketCHIP.

Very nasty bug. Happens about one in three times you press reset.

P#42975 2017-07-31 21:33 ( Edited 2017-08-01 01:33)

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))

-- same as dget() except this also refreshes
-- the other memory slots
function edget(slot)
 local v=errcheck(slot)
 -- refresh value
 return v

-- set value in slot and the extra slots
function edset(slot,v)

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.

P#42983 2017-08-01 03:26 ( Edited 2017-08-01 07:49)

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...

P#42987 2017-08-01 06:34 ( Edited 2017-08-01 10:34)

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.

P#42988 2017-08-01 06:38 ( Edited 2017-08-01 10:38)

All I can hear is

[quote]bumped 0.1.11 forward[/quote]


@weeble: Yes it would. Good thinking!

P#42989 2017-08-01 07:30 ( Edited 2017-08-01 11:42)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2023-12-05 00:51:48 | 0.017s | Q:23