Re: [Flashforth-devel] minor bugs in 328-16MHz-38400?

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

Hi Stefan.
Thanks for your nice feedback.

See my inline comments below.

Great to hear about OptiForth. Is it on github ?

BR Mikael

On 2020-11-16 10:21, Stefan wrote:
> a) '<', '>', 'min', 'max', 'd<' and 'd>' deliver wrong results, when 
> the
> (signed) space overflows e.g.
>    20.000 -20.000 <  ok<#,ram> 65535

Do you have working code for this to share ?

> b) 'digit?' accepts : ; < = > ? X Y Z [ \ ] ^ _ ` as regular digits 
> e.g.
>    1[ ^ `  ok<#,ram> 14 7 9

Yes. I simplfied digit? a bit too much.
In practice it works for legal number conversion.

> c) 'ms' (u -- ) is counting u+1 milliseconds, e.g. 100 loops of 1 ms
> last 200 ms
>    : testms ticks #100 begin 1 ms 1- dup 0= until drop ticks swap - ;
>    testms  ok<#,ram> 200

Seems like a bug. I will check this.

> 
> d) it's not a bug, but ...
>    by initializing all registers and RAM to zero the internal
> oscillator (as the time basis
>    for FLASH and EEPROM programming) is set to the slowest possible
> frequency, thereby almost
>    doubling the programming time, this can be avoided by saving the
> value of OSCCAL
> 

This was actually changed in the commit 4.11.2020. Now it only 
initializes RAM.
Not the registers.

> e) also not a bug, but ...
>    DP_TO_EEPROM is done wordwise, in many cases half the EEPROM writes
> could be saved by
>    doing it bytewise, because the hi-bytes of the pointers are 
> unchanged
> 

Good catch. I will change that.

> with best regards
> bitflipser
> 
> PS: If you want to test my OptiForth328 called version, please let me 
> know.
> 
> 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael