On 11/24/2013 09:23 PM, Matthias Trute wrote:
> I was a little surprised that he uses the amforth mailing list to
> place an advertisement for his system, but its ok.
> Matthias
I am sorry for that Matthias.
I was trying to send the mail directly to Wojtek, but the mail client
tricked me and it
Just as a reference, this is how it works in FF.
The DPs and LATEST is kept in ram during interpretation
of a line and during compilation state.
It also gives a nice undo effect if the compilation fails.
ABORT will restart QUIT and copy the old values from eeprom again.
No half compiled words are
Hi Wojtek,
Just to inform you that FlashForth buffers the DPs and LATEST in ram
during compilation.
This lessens the wear on the EEPROM and makes the compilation go faster !
BR Mikael
On 11/20/2013 12:31 AM, wzab wrote:
> Sorry, I've sent my message from another address, not registered to the
>
On Wed, 2013-02-27 at 22:01 +0100, Matthias Trute wrote:
> 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
>
On Wed, 2013-02-27 at 19:59 +0100, Matthias Trute wrote:
> You drive me crazy ;)
Well it was not my intention :-;
> >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.
I guess it can break but remarkably seldom. Everyt
Hi Enoch,
For your information, FlashForth has these robustness mechanisms built
in.
The aim has been to make it so robust that a reflash should never be
needed.
The Kernel is write protected, the memory allocation pointers in eeprom
are initialized from write protected flash with the EMPTY comma
