Re: [Flashforth-devel] Pic18 change system protection addresses?

[Mikael N. <mik...@fl...>]

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