Mikael,
>> >From checking your code, I can imagine a few things that would break
>> FF as well. ;)
> I am interested to know what that could be.
In flashforth.asm I found the following lines
rcall DOLIT
.dw dp_start
rcall FETCH
rcall TRUE_
call EQUAL
call ZEROSENSE
breq WARM_3
rcall EMPTY
WARM_3:
I read them as "if dp_start is -1, call EMPTY, otherwise
skip to WARM_3". This checks if the EEPROM got erased. Fine
so far (a common error if you forgot to flash the eeprom
hex file). But what if dp_start is something else?
I did not analyze (or even tested) this, but an invalid
turnkey action (e.g. assigning not an XT to turnkey) may be
sufficient (dp_start seems to be the turnkey vector). Than
you have no chance to recover the system automatically. (or
you have some more lines of defence...)
> I guess it can break but remarkably seldom.
Well, seldom is a relative number ;)
You check for errors, that already happened or are
possible. Its the same with security: You can do a lot
of things but someone will break in nevertheless. That
doesn't make your work bad, absolutly not!! I'm the one
who is lazy and ignorant I put all the burden to the
user ;)
Matthias
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
[email protected]
https://lists.sourceforge.net/lists/listinfo/amforth-devel
