amforth-devel — Development discussion and user support

Re: [Amforth-devel] see

[pito <pi...@vo...>]

Michael,
so I fired up ff and this is what I can see:

ok<$,ram>
see see
26ea eca0 f00c call  '
26ee eccf f00c call  cr
26f2 df20      rcall (see)
26f4 50ed
26f6 10ee
26f8 e1fc      bnz   26f2
26fa 50ed
26fc 50ed
26fe 0012      return
ok<$,ram>
see drop
0e4c 50ed
0e4e 50ed
0e50 0012      return
ok<$,ram>
see constant
0a64 ecda f00c call  create
0a68 d8e2      rcall cell
0a6a da9f      rcall negate
0a6c ec6c f00e call
0a70 efbd f003 goto  i,
ok<$,ram>

There is "seen" as well, so this is with "seen":
ok<$,ram>
see interpret
16f4 dff3      rcall 'source
16f6 ec6d f006 call  2!
16fa daf5      rcall false
16fc dfe8      rcall >in
16fe deeb      rcall !
1700 da1e      rcall bl
1702 deaf      rcall word
1704 dfef      rcall dup
1706 dd9b      rcall c@
1708 dd31      rcall ?0=
170a e04a      bz 17a0
170c df2b      rcall find
170e dd33      rcall d0=
1710 e033      bz 1778
1712 dc51      rcall 1+
1714 da1b      rcall state
1716 dc9a      rcall 0=
1718 dc29      rcall or
171a dd28      rcall ?0=
171c e013      bz 1744
171e a858
1720 d009      bra 1734
1722 da14      rcall state
1724 dd23      rcall ?0=
1726 e106      bnz 1734
1728 ecf5 f006 call  (s"
172c 4305
172e 4d4f
1730 3f50
1732 d0f4      bra 191c
1734 9c46
1736 ec15 f005 call  execute
173a bc46
173c d7e1      bra 1700
173e 9846
1740 9a46
1742 d7de      bra 1700
1744 9846
1746 dfce      rcall dup
1748 d86a      rcall lit
174a 104c
174c dc8f      rcall =
174e dd0e      rcall ?0=
1750 e002      bz 1756
1752 8846
1754 d008      bra 1766
1756 9a46
1758 dfc5      rcall dup
175a d861      rcall lit
175c 0ee8
175e dc86      rcall =
1760 dd05      rcall ?0=
1762 e006      bz 1770
1764 8a46
1766 d912      rcall cf,
1768 9055
176a b858
176c 8055
176e d7c8      bra 1700
1770 aa58
1772 d7f9      bra 1766
1774 dba6      rcall in,
1776 d7c4      bra 1700
1778 9846
177a 9a46
177c ec26 f007 call  drop
1780 df51      rcall number?
1782 dcf4      rcall ?0=
1784 e006      bz 1792
1786 d9e2      rcall state
1788 dcf1      rcall ?0=
178a e0ba      bz 1700
178c ec35 f002 call  literal
1790 d7b7      bra 1700
1792 d851      rcall dp>
1794 de8e      rcall c@+
1796 ecea f006 call  type
179a daa5      rcall false
179c d8b1      rcall ?abort?
179e d7b0      bra 1700
17a0 ef26 f007 goto  drop
ok<$,ram>

Pito

Re: [Amforth-devel] Minicom Uploader

[Matthias T. <mt...@we...>]

Al,

> I don't know how to turn word wrap on in the minirc.amforth file which is why 
> you need the -w flag (or ^AW when running). Anyone know how to turn that on in 
> the config file?

not really the config file but an environment variable

export MINICOM=-wC

(this part of by .profile)

Matthias

Re: [Amforth-devel] marker.asm for 4.1

[Al W. <al....@aw...>]

Haven't yet. I need to do a clean VM because I have production AVR code on 
this machine so I don't want to tamper with the assembler here. But I will.

Speaking of fun. My most recent Forth project previous to this one was a Forth 
compiler for my custom CPU done in an FPGA.

http://www.drdobbs.com/architecture-and-design/222000477

The CPU:
http://www.drdobbs.com/embedded-systems/221800122

and the Assembler:
http://www.drdobbs.com/embedded-
systems/222600279?queryText=Assembler+universal


On Saturday, September 18, 2010 02:37:48 am Marcin Cieslak wrote:
> >> Al Williams <al....@aw...> wrote:
> > Hand compile of marker from the ANS library. Note that this requires the
> > head version of 4.1 as discussed earlier.
> > 
> > http://dl.dropbox.com/u/360343/marker.asm
> 
> I think we should have a motto:
> 
> "Amforth - your computer is fun again"
> 
> :)
> 
> By the way, did you have a chance to test if avra works with my patches
> for you?
> 
> //Marcin
> 
> 
> ---------------------------------------------------------------------------
> --- Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] marker.asm for 4.1

[Marcin C. <sa...@sa...>]

>> Al Williams <al....@aw...> wrote:
> Hand compile of marker from the ANS library. Note that this requires the head 
> version of 4.1 as discussed earlier.
>
> http://dl.dropbox.com/u/360343/marker.asm

I think we should have a motto:

"Amforth - your computer is fun again"

:)

By the way, did you have a chance to test if avra works with my patches
for you?

//Marcin

Re: [Amforth-devel] see

[pito <pi...@vo...>]

Micheal, thanks!
> So replace here with dp if you use amforth-4.1
> please.
and update words definition on the amforths web as well..

> This flashforth SEE is interesting, but I cannot
> run it, no pic here.
> What is its output?
YES the ff is interesting, indeed. Maybe sharing ideas between them
might create synergies which will give both of them a bigger
momentum, ufff..
I will fire up my pic dev board, maybe there is ff flashed in it.
There is also "seen" in the folder. As I can remeber it does
dissassembling of a word, but I will check. I did play with ff
before I had found amforth. As ff is concerned, I am desperately
waiting on dspic33/24 port (promised this autumn).. a killer
combination...
> Its a nice study of a forth system if you make a
> SEE for it :-)
currently as the forth language is concerned I can say only "Ich bin
Berliner ein swap", so frankly, this wold be for me a too big sip..
But this capability is native to amforth as amforth is doing it
billion times per day.. So just to reverse it, somehow..
Pito

[Amforth-devel] marker.asm for 4.1

[Al W. <al....@aw...>]

Hand compile of marker from the ANS library. Note that this requires the head 
version of 4.1 as discussed earlier.

http://dl.dropbox.com/u/360343/marker.asm

[Amforth-devel] Rescue Mode

[Al W. <al....@aw...>]

Thanks to some help from people on the list, I have what seems to be a pretty 
interesting "rescue" mode that can recover from corrupt EEPROM as long as the 
basic flash portion and the bootloader flash are intact.

My development boards all have a MAX232 or a USB dongle attached so I assume 
that the RX pin will be high when we start up at least some of the time. If I 
isolate the RX pin and ground it on restart, I reload a pure copy of the 
EEPROM stuff that is built into the high part of flash.

This is on the 4.1 trunk

Here's inside my main file:
;;  enable Rescue mode
;;  These settings use the RS232 in port
.equ RESCUE_PIN = PIND
.equ RESCUE_PIN_NUM = 0
.equ RESCUE_PIN_SENSE = 0
;; .equ RESCUE_PULLUP = 1 

###

Next, are changes in amforth.asm:
    ; allocate space for User Area
    .set here = here + SYSUSERSIZE + APPUSERSIZE
; NEW CODE HERE
.ifdef RESCUE_PULLUP
.if RESCUE_PULLUP
	sbi RESCUE_PIN+1,RESCUE_PIN_NUM
.endif
.endif
.ifdef RESCUE_PIN
	clr temp1   		; 256 cycles of rescue sense or no rescue
rescue_check:
.ifndef RESCUE_PIN_SENSE
.equ RESCUE_PIN_SENSE = 0
.endif
.if RESCUE_PIN_SENSE == 0	
	sbic RESCUE_PIN,RESCUE_PIN_NUM
.else
	sbis RESCUE_PIN,RESCUE_PIN_NUM
.endif
	rjmp rescue_no
	dec temp1
	brne rescue_check
	ldi XL, low(PFA_RESCUE)
	ldi XH, high(PFA_RESCUE)
	jmp_ DO_NEXT
rescue_no:	
.endif	
; END OF NEW CODE
    ; load Forth IP with starting word
    ldi XL, low(PFA_COLD)
    ldi XH, high(PFA_COLD)
    ; its a far jump...
    jmp_ DO_NEXT

#### 
Then again at the end of asmforth:
; 1st free address in EEPROM.
edp:
.cseg
; NEW CODE FROM HERE DOWN TO END
.ifdef NEED_RESCUE_DATA		
RESCUE_DATA:
    .dw XT_APPLTURNKEY
    .dw UBRR_VAL
    .dw XT_DO_ISTORE 
    .dw lowflashlast ; DP
    .dw here         ; HERE
    .dw edp          ; EDP
    .dw VE_ENVHEAD   ; environmental queries
    .dw EE_FORTHWORDLIST; forth-wordlist
    .dw EE_FORTHWORDLIST
    .dw VE_HEAD      ; pre-defined (compiled in) wordlist
    .dw EE_FORTHWORDLIST      ; get/set-order
    .dw -1
    .dw -1
    .dw -1
    .dw -1
    .dw -1
    .dw -1
    .dw -1
    .dw -1 ; NUMWORDLISTS + 1 entry, this entry has to be -1
.set RESCUE_DATA_END = pc
.endif

#####

I have a new file: core/words/rescue.asm:
	;;  rescue logic - Williams
VE_RESCUE:
	.dw $ff07
	.db "_rescue"
	.dw VE_HEAD
	.set VE_HEAD = VE_RESCUE
	;; : _rescue baseadd size 0  do dup i + i@ i 2* e! loop drop ;
XT_RESCUE:
	.dw DO_COLON
PFA_RESCUE:
	.dw XT_DOLITERAL
	.dw RESCUE_DATA
	.dw XT_DOLITERAL
	.dw RESCUE_DATA_END-RESCUE_DATA
	.dw XT_ZERO
	.dw XT_DODO
	.dw PFA_RESCUE2
PFA_RESCUE1:	
	.dw XT_DUP
	.dw XT_I
	.dw XT_PLUS
	.dw XT_IFETCH
	.dw XT_I
	.dw XT_2STAR
	.dw XT_ESTORE
	.dw XT_DOLOOP
	.dw PFA_RESCUE1
PFA_RESCUE2:	
	.dw XT_DROP
	.dw XT_COLD
	.dw XT_EXIT   		; never reached?
.set NEED_RESCUE_DATA = 1

###

Then in dict_appl_core.inc I simply add in words/rescue.asm. That way the 
saved state and the _rescue word is in the bootloader area which can be 
locked. Of course, would be good to move the reset vector up there too and get 
all the code up in protected flash. Might do that yet.

Obvioiusly you can set the rescue pin to whatever you want, active high or 
low, and with or without pull up (default is low and no pull up). When the 
boot process sees an active rescue pin you lose everything back to the initial 
load.

This seems to work. You can put some words in and reboot all you like with no 
problems. Then if you ground the rescue pin, you lose your custom words. In 
addition I got one lock up crash and recovered from it. 

I'd be interested to hear any success or failures. Also, I'm really new at 
digging into amforth's internals so any suggestions on making this better are 
welcome too.

Re: [Amforth-devel] see

[Kalus M. <mic...@on...>]

Am 18.09.2010 um 01:05 schrieb pito:

> Hi Michael,
> few Q (sorry, I am an forth language illiterate):
> a) how the "here" knows what to deliver - next free address of flash
> or next free address from ram?

Oh, I'm sorry. Its in amforth-3.6.

amforth-3.6
here == next free address of flash
heap == next free address from ram

amforth-4.1 (ANS forth standard)
dp   == next free address of flash
here == next free address from ram

So replace here with dp if you use amforth-4.1 please.


> b) I saw see in flashforth and I did run it - it is very short, can
> that be ported to amforth (see ff36 folder) somehow?

This flashforth SEE is interesting, but I cannot run it, no pic here.
What is its output?


> c) would it be possible to modify the routine so that we may see a
> linked list of words from which the word under investigstion has
> been compiled?, e.g.:
> see d.
> : 0 d.r space exit ok
>>
> I think there is all the information available in flash (at least
> "words" shows a lot of words, maybe there are some hidden as well so
> the name can be extracted).
> Thanks Pito

Yes.

The code field holds all the xt of the words beeing used in the  
definition.
The main principle is to use xt>nfa on them to find their names and  
type them.
Then handle loops and conditional branching as well as literals and  
strings, and maybe disassemble inlined code.

Its a nice study of a forth system if you make a SEE for it :-)

Michael

Re: [Amforth-devel] see

[pito <pi...@vo...>]

Hi Michael,
few Q (sorry, I am an forth language illiterate):
a) how the "here" knows what to deliver - next free address of flash
or next free address from ram?
b) I saw see in flashforth and I did run it - it is very short, can
that be ported to amforth (see ff36 folder) somehow?
c) would it be possible to modify the routine so that we may see a
linked list of words from which the word under investigstion has
been compiled?, e.g.:
see d.  
: 0 d.r space exit ok
>
I think there is all the information available in flash (at least
"words" shows a lot of words, maybe there are some hidden as well so
the name can be extracted).
Thanks Pito

[Amforth-devel] see

[Kalus M. <mic...@on...>]

Hi.

If you like to see what has been compiled, gforth has comfortable
  SEE <word>
as a command. There is no see in amforth so far? So this may help a  
little.

<snip>
new
hex   ( source: amforth-4.1/lib/ans94/ans.frt)
\ go from the XT backwards to get the Name field
: xt>nfa ( xt -- nfa )
     1- \ link address
     \ tricky: we look for the flash cell whose address + it content  
& 0x00ff is
     \ this address
     dup 1- >r ( -- lfa)
     begin
	1- dup ( -- fla fla )
	i@ $00ff and 1+ 2/ ( -- fla len )
	over + ( fla lfa? )
	r@ = ( fla lfa? )
     until
     r> drop  ;

\ now create a lister
: lister ( xt -- )
	xt>nfa here swap - 0 do
	cr here 1- i - dup 4 u0.r space i@ 4 u0.r
         loop ;

here .
: dummy 1122 3344 5566 ;
here .
' dummy .
' lister .

' lister lister
.s

</snip>


This is what I got:

» here .
1524  ok
» : dummy 1122 3344 5566 ;
  ok
» here .
1531  ok
» ' dummy .
1529  ok
» ' lister .
150B  ok
»
  ok
» ' lister lister

1530 1C37
152F 5566
152E 1C54
152D 3344
152C 1C54
152B 1122
152A 1C54
1529 1C0A
1528 1506
1527 0079
1526 6D6D
1525 7564
1524 FF05
1523 1C37
1522 1513
1521 1EBF
1520 0FB5
151F 0004
151E 1C54
151D 1FEB
151C 03AD
151B 0FB5
151A 0004
1519 1C54
1518 1CA5
1517 1D95
1516 1EB7
1515 1E38
1514 0121
1513 03A0
1512 1523
1511 1E92
1510 1D36
150F 1D95
150E 1CB8
150D 0121
150C 14F0
150B 1C0A
150A 14EB
1509 7265
1508 7473
1507 696C
1506 FF06 ok
» .s
  ok
»

Then I looked up cfa in the <application>.lst file:

addr cfa  mnemonic
1530 1C37 XT_EXIT
152F 5566 $5566
152E 1C54 XT_DOLITERAL
152D 3344 $3344
152C 1C54 XT_DOLITERAL
152B 1122 $1122
152A 1C54 XT_DOLITERAL
1529 1C0A DO_COLON
1528 1506 link to precedence cell of previous word
1527 0079 0 y
1526 6D6D m m
1525 7564 u d
1524 FF05 FF == precedence bits, 05 == count byte of name.

Voilà.
So we see the latest words compiled this way.
Michael

Re: [Amforth-devel] Minicom Uploader

[Al W. <al....@aw...>]

I don't know how to turn word wrap on in the minirc.amforth file which is why 
you need the -w flag (or ^AW when running). Anyone know how to turn that on in 
the config file?


On Friday, September 17, 2010 14:09:46 pm Erich Waelde wrote:
> Hi Al,
> 
> On 09/17/2010 08:11 PM, Al Williams wrote:
> > http://dl.dropbox.com/u/360343/am4up.c
> 
> superb! Works for my arduino duemilanove, which is very
> resistive to amforth-upload.py.
> 
> Thanks for sharing this!
> 
> Erich
> 
> ---------------------------------------------------------------------------
> --- Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Minicom Uploader

[Erich W. <ew....@na...>]

Hi Al,

On 09/17/2010 08:11 PM, Al Williams wrote:
> http://dl.dropbox.com/u/360343/am4up.c

superb! Works for my arduino duemilanove, which is very
resistive to amforth-upload.py.

Thanks for sharing this!

Erich

Re: [Amforth-devel] Minicom Uploader

[pito <pi...@vo...>]

Al, few years back somebody offered to me the 1802.. I was not fast
enough, a pity. Pito

Re: [Amforth-devel] Minicom Uploader

[Al W. <al....@aw...>]

Ah the Python scripts are way more portable though. If you wish to include the 
uploader in the distribution tools, feel free.


On Friday, September 17, 2010 13:43:43 pm Matthias Trute wrote:
> Hi Al,
> 
> > I remembered that I wrote a simple upload program for the RCA 1802 a few
> > years back that had a lot of the same serial comm issues (handshaking,
> > etc). So I pulled the code out and ported it for amforth. Probably not
> > as useful for Windows users though since iti depends on minicom to
> > handle the serial I/O.
> > 
> > Very handy to be able to just be working at the terminal and upload a
> > word.
> > 
> > http://dl.dropbox.com/u/360343/am4up.c
> 
> Smart tool, cool. It simply works. Thank you. It makes the
> python-script(s) obsolete ;=)
> 
> Matthias
> 
> 
> 
> ---------------------------------------------------------------------------
> --- Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Minicom Uploader

[Matthias T. <mt...@we...>]

Hi Al,

> I remembered that I wrote a simple upload program for the RCA 1802 a few years 
> back that had a lot of the same serial comm issues (handshaking, etc). So I 
> pulled the code out and ported it for amforth. Probably not as useful for 
> Windows users though since iti depends on minicom to handle the serial I/O.
> 
> Very handy to be able to just be working at the terminal and upload a word.
> 
> http://dl.dropbox.com/u/360343/am4up.c

Smart tool, cool. It simply works. Thank you. It makes the 
python-script(s) obsolete ;=)

Matthias

[Amforth-devel] Minicom Uploader

[Al W. <al....@aw...>]

I remembered that I wrote a simple upload program for the RCA 1802 a few years 
back that had a lot of the same serial comm issues (handshaking, etc). So I 
pulled the code out and ported it for amforth. Probably not as useful for 
Windows users though since iti depends on minicom to handle the serial I/O.

Very handy to be able to just be working at the terminal and upload a word.

http://dl.dropbox.com/u/360343/am4up.c

Here's the instructions from the comments inside the file:
// Filter to upload files to amforth from minicom
 // Al Williams http://www.hotsolder.com
// Originally for the elf (if you were wondering about the names)
// 17 Sept 2010 -- Public Domain

 // Minicom uploader has stdin connected to serial input,
 // stdout connected to serial output
 // stderr connects back to minicom
 // exit code 0 for success or non zero for fail
 
 // To set this up, use Control+AO and configure file transfer 
 // protcols. Set a name and the program file name 
 // Set Name=Y, U/D to U, FullScrn to N, IO-Red to Y, and Multi to N

// OR you can put this in /etc/minicom/minirc.amforth

/****************  Start file on line below
# Machine-generated file - use setup menu in minicom to change parameters.
pu pname10          YUNYNamforth
pu pprog10          am4up
pu baudrate         9600
pu bits             8
pu parity           N
pu stopbits         1
pu minit            
pu mreset           
pu backspace        BS
pu rtscts           No

 **************** Line above was the last line of the file */
// Then start minicom like this:
// minicom -w -D /dev/ttyUSB1 amforth
// This presumes you have am4up (this file compiled with gcc) on your path
// and you are using /dev/ttyUSB1.
// 
// To compile this file:
// gcc -o am4up am4up.c 
// Then copy the am4up executable to your path somewhere 
 
 // The character pacing is handled by waiting for the echo
 // The line pacing is handled by waiting for > or k
 // A ? in the prompt output indicates an error
 // Note you might still be in a defining word so 
 // when you get an error you might have to enter a ; to get back
 // to a normal prompt.


Al W.
 

Re: [Amforth-devel] Word header in asm

[Matthias T. <mt...@we...>]

Pito,

> Hi,
> is there any expalnation available on what these 
> .dw $ff03    ;
> 
> ff02 ff05 in the header of a ams word definition means?

This is the combination of the string length (the lower half)
and some flag information. $ff means: no special flag is set,
$00 means immediate. Strictly speaking only  one bit of
the $00 is the immediate flag. This "strange" behavior
comes from the flash character: it does not cost anything
to set a bit to 0 but you need to erase a whole page when
turning it to 1. But since there are no other flags currently
in use, it does not matter at all. (maybe (again: MAYBE)
one other bit may be used for case insensitive dictionary 
search).

A side effect is, that amforth can use word with up
to 255 characters length. Which is absolutly theoretical
since the terminal input buffer has only 80 bytes and
the ram area the word WORD uses as its scratch buffer has
only 100 bytes. But it makes the code more compact.

> And if
> important, how is the implication when writing words in asm? Thanks,

standard words should use the $ff<length> information.
That should fit almost all cases (immediate words are
rare)

Matthias

Re: [Amforth-devel] Some nitpicking

[Matthias T. <mt...@we...>]

Marcin,

while checking all the old mails, i came across yours
(and sorry for the delay, better late than never...)

> Small tidbits from 4.1:

all of them are now fixed. Thank you


> .include "words/2literal.asm"
> .include "words/2to_r.asm"
> .include "words/2r_from.asm"
> could go into some separate dict file for easy inclusion 
> ("dict_2x.inc" ?). They use rjmp, so I include them in
> my high memory (dict_appl_core.inc)

the rjmp can be changed easily, the dict_2x is worth a try?
maybe.... 

> I tried to add "tibsize.asm", but it complains that we
> have no EE_TIBSIZE. It seems that there is no such thing.

The size of the terminal input buffer is a compile time constant,
it should go to an environment? query.. deleted for now, no-one could
have used it anyway

Matthias

Re: [Amforth-devel] Floating point - f* f/ in asm .. calculate execution times

[pito <pi...@vo...>]

Michael,
here is a little bit more precise function duration measurement tool
(FDMT):

\
*******************************************************************
\ Precise measurement of duration of a FUNCTION
\ Pito 17-9-2010
\ based on the idea on FUNCTION separation by Michael Kalus
\ Pito's 4 primitives flib used
\ Pito's stopwatch used
\ atmega 1284p @25MHz


2000000. 2constant Nloop  \ 2mil measurements
fvariable t_fdrop
fvariable t_empty
fvariable t_empty1
fvariable t_function

: m1
\ measure empty loop1
_pi     100 0 timer-start do 20000 0
do sp@ >r r> sp! loop
loop timer-stop Nloop d>f f/ fdup t_empty1 f! 
cr fs. ." secs elapsed - empty1 loop" fdrop ;

: m2
\ measure fdrop
_pi     100 0 timer-start do 20000 0 
do sp@ >r fdrop r> sp! loop
loop timer-stop Nloop d>f f/ fdup t_fdrop f! 
cr fs. ." secs elapsed - fdrop loop" fdrop 

t_fdrop f@ t_empty1 f@ f- t_fdrop f!
cr t_fdrop f@ fs. ." secs duration of fdrop" ;

: m3
\ measure empty measurement loop
_pi _1e3 f* _e
100 0 timer-start do 20000 0
do fdup fdup fdrop fdrop loop
loop timer-stop Nloop d>f f/  fdup t_empty f! 
cr fs. ." secs elapsed - fdrop fdrop loop" fdrop fdrop ;

: fmeasure
\ did you run m1 m2 m3 already?

\ measure FUNCTION in measurement loop
_pi _1e3 f* _e 

100 0 timer-start do 20000 0
\
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
do fdup fdup f/ fdrop loop    \ <<<<< replaced one fdrop with
FUNCTION
\
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
loop timer-stop Nloop d>f f/ fdup t_function f! 

cr fs. ." secs elapsed - function fdrop loop"  fdrop fdrop

\ calculate clean FUNCTION duration
t_function f@ t_empty f@ f- t_fdrop f@ f+ t_function f!  \
t_function-(t_empty-t_fdrop)

cr t_function f@ fs. ." secs duration of f/ FUNCTION" ;


\
****************************************************************************************

Ex: (@25MHz f_cpu)

> m1

8.9653244E-6 secs elapsed - empty1 loop ok

> m2

1.4795408E-5 secs elapsed - fdrop loop
5.830083E-6 secs duration of fdrop ok

> m3

2.6738689E-5 secs elapsed - fdrop fdrop loop ok 

> fmeasure

2.9554117E-5 secs elapsed - function fdrop loop
8.6455116E-6 secs duration of f+ FUNCTION ok 

> fmeasure

2.858418E-5 secs elapsed - function fdrop loop
7.6755762E-6 secs duration of f- FUNCTION ok

> fmeasure

3.3853273E-5 secs elapsed - function fdrop loop
1.2944672E-5 secs duration of f* FUNCTION ok

> fmeasure

5.3068438E-5 secs elapsed - function fdrop loop
3.2159829E-5 secs duration of f/ FUNCTION ok


Thanks and have a nice weekend! Pito 

Re: [Amforth-devel] Marker etc.

[Al W. <al....@aw...>]

Yes, grabbing the head and building for ATMEGA32 marker now works! 

Great!


On Thursday, September 16, 2010 16:46:44 pm Marcin Cieslak wrote:
> Al Williams <al....@aw...> wrote:
> > Not sure why, but I tried running the 8MHz internal RC again and now its
> > fine. Granted, before I was on the 4.1 and now I'm on 3.8 -- doubt
> > that's the difference though. Probably operator error!
> 
> There seems to be a bug in i@ introduced in 4.1 (see other postings). Can
> you try trunk now?
> 
> //Marcin
> 
> 
> ---------------------------------------------------------------------------
> --- Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Marker etc.

[Marcin C. <sa...@sa...>]

Al Williams <al....@aw...> wrote:
> Not sure why, but I tried running the 8MHz internal RC again and now its fine. 
> Granted, before I was on the 4.1 and now I'm on 3.8 -- doubt that's the 
> difference though. Probably operator error!

There seems to be a bug in i@ introduced in 4.1 (see other postings). Can you 
try trunk now?

//Marcin

Re: [Amforth-devel] Marker etc.

[Al W. <al....@aw...>]

Not sure why, but I tried running the 8MHz internal RC again and now its fine. 
Granted, before I was on the 4.1 and now I'm on 3.8 -- doubt that's the 
difference though. Probably operator error!

Re: [Amforth-devel] Marker etc.

[Al W. <al....@aw...>]

> 
> Ok, but it is already mentioned ;=)
> 
Whoops I see that.

> Your complaints are welcome, but what could I do? Others complain that
> the scripts do not work at all due to <whatever>. I use the scripts on
> my systems and they work good enough. Maybe I intuitivly circumvent all
> the bugs and deficits already ;=)
> 
Please don't take anything as a complaint! I'm very impressed and I'm enjoying 
exploring. 


> > So as it stands now I must use a crystal or resonator
> 
> Most people who work with atmegas strongly recommend to use a quartz
> when it comes to serial communication (even at low speed such as 9600
> characters per second). The internal oscillator works at 8MHz which is
> cut down to 1MHz and it is known to be very unstable.

The default is 8 with an 8:1 prescaler, but you can pick 1:1 which I did. It 
all worked except for the write to flash.

> 
> And again: marker is currently broken, sorry for that. But it will
> come back. Sooner or later.

I've reverted to an older version and hacked it up with some of the newer 
device stuff and it works great! Thanks.

Re: [Amforth-devel] Marker etc.

[pito <pi...@vo...>]

> Most people who work with atmegas strongly
> recommend to use a quartz 
> when it comes to serial communication (even at low
> speed such as 9600
> characters per second). The internal oscillator
> works at 8MHz which is
> cut down to 1MHz and it is known to be very
> unstable.
> 
Hi,
some points I've gathered with serial i/o and terminals with amforth
(I am using XP, usb connectivity, atmega32 @11.0592MHz, atmega1284p
@25Mhz):
1. there are only 2 terminals which work reliable to me - Forfiter
and Mosaic Serial Terminal, the later I am using now.
2. the speeds - I run Mosaic up to 256kbits - absolutely no problem
3. you CANNOT use terminals which do not commit "ok" or each
character, amforth will not work - it will corrupt when writing new
words !!!!
Amforth needs a lot of time (sometimes fraction of seconds) in order
to compile and flash the word - when not commiting 'ok' terminal
will shoot characters to amforth and amforth will loose them!!
therefore you must wait until ready again. There is none handshaking
except this one!
4. amforth is very demanding as the baudrate precision is concerned,
the 8n1 communication can have +/- 4.5% baudrate precision, but
amforth will not compile with such spread. It means in practise
unless you have so called any_baud crystals (e.g. 11.0592 etc.) you
can compile only for specific speeds!!!
5. baudrate - you may change it in amforth session by: Num UBRR0L c!
where Num is the baudrate_constant - you may see the atmega guide
table 17.9-17.10 or you may calculate it for a given resonator or
crystal (!! with known frequency!!). When reset the amforth reverts
to default baudrate burned in.
Finetuning: you may try to change the constant a little bit until
the serial works reliable (do not forget to change the baudrate in
terminal as well when you change to next baudrate step)
6. crystals, resonators, internal RC - you will not have any issues
with standard crystals, but pls mind the 2 capacitors must have a
specific value as well (15-22pf). Be carefull with higher
frequences, crystals higher than 25MHz are so called overtone
crystals, they oscillate on 1/3 of the frequency depicted on its
body.
Resonators easily have 10-20% deviation from depicted frequency, so
it may not work with serial at given baudrate, however you may
measure its frequency and adjust baudrate constant accordingly. The
stability is good for serial. 
Internal RC - the chip makers claim up to 3% precision, so-so
usable, but it is voltage (! the chip voltage - pls mind very good
decoupling caps near the chip Vcc, Avcc) dependand so you may go out
of baudrate easily as well when voltage fluctuates (mind BOD
Brown-out Detector - when enabled (fuses!) a small drop in voltage
causes an reset (2ns impuls can trigger it), also EEPROM and FLASH
WRITE does not work properly when voltage fluctuates). You may
measure the frequency on a pin, then udjust baudrate accordingly,
or, some chips have internal udjustment (register value) for
finetuning (+/- 10%) of the internal frequency. I would recommend
internal oscillator up to 2400baud to be safe.
7. for amforth the finetuned serial communication with appropriate
terminal supporting 'ok' commit is absolutely vital!! It flashes in
its flash directly from serial, there are no large buffers (as far
as I know) with checksums, so any instability means corruption of
data.
8. From my other experience - electronics - the 97% of instabilities
and corruptions in sw area comes from hardware issues - wrong
capacitors, crystals, decoupling, voltage source instability,
interference between PC and development board, grounding, unreliable
sockets, connectors, cables too long, mobile phones laying near the
testbed, statics, etc.etc.)
Pito

Re: [Amforth-devel] Floating point library - 4 primitives f/ f* f+ f-

[Matthias T. <mt...@we...>]

Marcin,

> Dnia 16.09.2010 Matthias Trute <mt...@we...> napisał/a:
> >
> > btw: I'm still working on the marker issue. strange case....
> 
> Matthias,
> 
> Reverting change 918 to istore_nrww.asm fixes the marker issue.

indeed. fixed. thank you.

Matthias