Good thoughts! Thank you very much!
Actually, editing hex images was one of our tricks back in the day (for a while I could sight-read 6502 hex). I REALLY like flash because I don't need a UV lamp to reprogram it. I've long kept a chip from every project with no read protection in case both the source code and the hex image for programming get lost.
I'll go looking for STARTV, play around a bit and see what I can come up with.
Thanks again!
craig
--------------------------------------------
On Wed, 9/20/17, Mikael Nordman <mik...@fl...> wrote:
Subject: Re: [Flashforth-devel] Pic18 change system protection addresses?
To: fla...@li...
Date: Wednesday, September 20, 2017, 2:16 PM
I think your analysis is fine,
but what to do about it ?
The protect system is hardcoded so you cannot
circumvent it without
changing the FF
kernel.
I have never tried
dumping FF from a chip an reprogramming the image.
I quess you can poke in the numbers to the hex
image after the dumping
it out.
Look for STARTV: in the
source. There you have 6 words that is used by
EMPTY.
;;;
EMPTY dictionary data
STARTV: dw
h'0000'
DPC: dw
dpcode ; dp_user_dictionary
DPE:
dw dpeeprom
DPD: dw
dpdata+h'f000'
LW: dw
lastword
STAT: dw DOTSTATUS
I quess you can get a map or
listing file to tell you the addresses.
The
data you need to move there is the first 6 words in
eeprom.
Or a kernel word
SNAP could be contructed to set the pointers used by
EMPTY.
Those could also be
stored in eeprom. (Just because I dont like to write
to kernel flash.
And have another word TRULYEMPTY that works
like the EMPTY of today.
Or
make a word ALMOSTEMPTY that gets you back to the SNAP
status.
Actually it not
that simple... The kernel and the user words are in
separate lists.
So FORGET would
anyway be able to forget all user dictionary words.
FORGET would need to check that does not forget
below the SNAPped
dictionary pointer.
------------
But the above is almost the same as defining
marker
eeprom 0 value
bla
marker calibration
: blu
. ... ;
marker basicwords
:
asdf ;
marker appwords
:
akajshdk ;
59 to bla
except it requires some
discipline, that you don't actually use EMPTY.
Changing EMPTY to some random string would fix
that :-)
Since the values
already exist in the dictionary,
reinitialization of the values will be skipped
if you send a file
to FF.
So the fast solution is to
have the special values defined in the start
of the dictionary
+ marker,
just as you suggest.
No
need to mess with forget. Using forget will always mess up
the
system.
-----------
You could create another type
of defining word called
cal: ( address 'name' -- ) // define a
uninitialized value at address.
: cal: flash
create -2 dp +! i, ram does> @ ;
Modify this row in the FF source code
DPE: dw dpeeprom
by increasing the number
protected EEPROM words (dpeeprom + EXTRA)
There you can use as EXTRA number of bytes
starting at $ec0c for
unforgettable
calibration data :-)
Or
just use adresses at end of eeprom or end of flash, and hope
no one
ever allots that far.
hex
ok<$,ram>
ec50 cal: cal1
ok<$,ram>
cal1
ok<$,ram>ffff
45 to cal1
ok<$,ram>ffff
cal1
ok<$,ram>ffff 45
ec50 @
ok<$,ram>ffff 45 45
So now your cal: values always uses TO to
init the values.
BR
Mikael
------------------------------------------------------------------------------
Check out the vibrant tech community on one of
the world's most
engaging tech sites,
Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel
|
