amforth-devel — Development discussion and user support

Re: [Amforth] Release 4.4 tagged and published

[Hannu V. <vu...@ms...>]

Hi!

Amforth is releasing quite fast. It was like yesterday when 4.2 came out :)
Big thank you everyone who has contributed.

Would it be good idea to change the 8k requirement from web page to something like Amforth takes about 8k Flash but doesn't fit out of box to 8k MCUs?

> - The reference card got a more compact layout, many bugs
> from the documentation headers in the source file are gone.

 rx rx? tx tx? +usart and also @e and !e are described several times. e words have mention about XMEGA but tx and rx have same description. This has probably something to do with the fact we have UART USART and USART0. 

Also numeric I/O part u words have maybe little bit too compact description. ud. ud.r u. u.r are double cell output. I'm still learning to do things with Amforth and that kind of documentation doesn't help much. It is probably huge task to do but someone should check out the descriptions of words. I would do that however I'm not familiar enough to do that.

Web page wordlist and refcard.pdf differs little bit but that isn't big problem. Bigger problem is that some words give error 404.

One nice feature would also be generation of refcard on compilation. Interactively added words can't be there but let's assume that one creates Amforth system and writes some frt files which defines words, they could be put to Application part of card. The more work requiring thing would be list not included words in the project. That would have save so much my time if I had some list which had included and excluded words. I have already written few words to do some tasks and usually start working with all words included and when system is working I'll take words out one by one until I have just working system :)

But I'll give 4.4 a try when I have more time. Now I have some thing called life to live :)

Best regards,
Hannu Vuolasaho
 		 	   		  

[Amforth] Release 4.4 tagged and published

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

Hi,

I've just tagged and published a new release named 4.4.

Noteworthy changes are

- The Game of Life with terminal output (requires controllers
  with at least many KB RAM, otherwise make the world small
  enough). A queens puzzle solver as well (more kind of a
  benchmark however).

- The reference card got a more compact layout, many bugs
  from the documentation headers in the source file are gone.

- new interrupt handling. The ideas are relativly old but
  now it works well. Many thanks to Wojciech and Al, I beg
  your pardon that it took such a long time to implement. But
  sometimes some active tests such as Erichs will speed up
  things ;=)

- The recognizer thing is now documented (to some degree);
  I sent an article to the German Forth FIG about it, that
  should be translated into plain English ASAP. Leons floating
  point library (a few patches are needed to work with it, just
  use the float.frt that is included) can now be included at
  runtime and the text interpreter can deal afterwards with
  the numbers nativly. Great stuff.

- internally there are even more source files and the
  amforth.asm file got smaller than ever. COLD is now
  WARM and the new COLD is what was in amforth.asm...

- not really my favorite: If you set WANT_IGNORECASE to
  1 and rebuild amforth you get a case insensive dictionary
  lookup. It took a few lines of code in icompare.asm, The
  discussion about it took more time than the implementation. Brr

Have fun, esp with Life

Matthias

[Amforth] amforth presentation at FOSDEM 2011 found online

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

Hello,

a friend of mine has found some videos of FOSDEM online at

  http://free-electrons.com/blog/fosdem-2011-videos/

including the presentation

   Arduino/AVR: interactive development on the controller with amforth
   http://fosdem.org/2011/schedule/event/arduino

Enjoy,
Erich

[Amforth] delister *.lst to *.asm

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

Hi.

Here is some gforth code to make a one-file amforth assembler source  
from your application.lst file.

Edit wowrd GO on line 76 in delister.fs to your needs.
   : go  s" my-application.lst" delist bye ;

Then on comand line do:
   gforth delister.fs -e go > my-application.asm

Befor you do so prepare your application:
- Deactivate all .nolist commands in amforth source.
- Exclude all words you do not want in your final application source.
- After my-application.lst has been generated by AVRA, change those  
few header and footer lines AVRA added into comments.

Finaly let AVRA assemble your application using your brand new  
source, check if result is ok by comparing my-application.hex with  
the orignal, may be with DIFFMERGE.


I am using amforth-3.6.

http://dl.dropbox.com/u/1170761/delister.fs

Hope it works fine. NO WARANTIES. Save your application befor you use  
delister!
Have fun. Michael

[Amforth] amforth & ATMega128

[David J. <dav...@ea...>]

Hello FORTH folk -

I have got amforth running on an ATMega128, using AVRStudio 4.18 and 
Hapsim, a peripheral emulator that supports serial communications. It 
displays the welcome message and you can run amforth on it, but real 
slow! Its main utility is confirming that the build functions correctly 
before programming the flash.

I've included a note showing the changes necessary to the amforth 4.2 files.

Cheers - David

[Amforth] amforth 4.3, atmega32, sleep

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

Hi,

for info:

atmega32

needs
   .equ SMCR   = MCUSR
to assemble
   .include "words/sleep.asm"
cleanly.
UNTESTED!

Cheers,
Erich

[Amforth] amforth 4.3, atmega32, watch dog timer

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

Hi,

for info:

atmega32 (old fashioned controller, me thinks)

needs
   .equ WDTCSR = WDTCR
   .equ WDCE   = WDTOE   \ bit 4
to assemble
   .include "words/no-wdt.asm"
cleanly.
Untested.

Cheers,
Erich

[Amforth] relister.fs

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

Hi


Here is a tool to convert your amforth application AVRA *.lst file  
into an assemler source.

http://dl.dropbox.com/u/1170761/relister.fs

I used gforth.
Open gforth, include relister.fs and type

s" <ApplicationName.lst>" relister

on gforth commandline.


To use shell command edit relister line 77 to name of your  
application.lst file. Then do:

gforth relister.fs > newsource.asm


Made it to have applications in ONE file independent of current  
amforth core, so versions may be followed with diffmerge tools. ;-)
Have fun. Michael

[Amforth] New version: 4.3

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

Hi all,

its been a long time since the last release, but you dont have to wait
any longer now.

The new release has two important changes: internally it works with
a new way to deal with the words (poorly documented however), more
important are naming changes for memory access words: e@ -> @e.

Many thanks to all who contributed with new docs and ideas

Matthias

Re: [Amforth] avra progress: .overlap/.nooverlap working

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

Hi Marcin!

On 04/28/2011 11:40 PM, Marcin Cieslak wrote:
> Hello,
>
> I have committed some changes to AVRA so that .overlap/.nooverlap
> directives are actually understood. This brings us closer
> to compile amforth with avra without any problems.
Good news!

>     git clone git://avra.git.sourceforge.net/gitroot/avra/avra

I have downloaded and built the program

$ avra --version
AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)
Copyright (C) 1998-2010. Check out README file for more info
...


I have renabled the .overlap directive in devices/$(MCU)/device.asm.

avra does not complain and build a .hex file. I have yet to test
the result.


Many thanks!
Erich

[Amforth] avra progress: .overlap/.nooverlap working

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

Hello,

I have committed some changes to AVRA so that .overlap/.nooverlap
directives are actually understood. This brings us closer
to compile amforth with avra without any problems.

Now you need to:

 - get the latest avra via:

   git clone git://avra.git.sourceforge.net/gitroot/avra/avra 

 - compile it

 - install "<cputype>.inc" files from AVR Studio (Appnotes folder)
   somewhere and point avra to it by using -I directive
   (edit appl/avr-build.xml).

//Marcin

[Amforth-devel] subscribe

[Carsten S. (private) <ca...@st...>]

Re: [Amforth-devel] Multitasking - details/demo

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

Pito,

> Hi, is there any reading for newbies how to start with amforth's
> multitasking, some explanation etc. E.g. 3 leds blinking at
> different rates and in parallel working with amforth..P.


http://amforth.sourceforge.net/howto.html

has an examples, the source code has some (poorly
documented) other example as lib/multitask-test.frt

HTH
Matthias

[Amforth-devel] Multitasking - details/demo

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

Hi, is there any reading for newbies how to start with amforth's
multitasking, some explanation etc. E.g. 3 leds blinking at
different rates and in parallel working with amforth..P.

Re: [Amforth-devel] icall

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

Hi Michael,
interesting, can you explain in detail? It is understood the icall
is a indirect call addressed by Z. So how to use it actually?
e.g. my_routine (written in .asm)
my_routine:
...
...
ret

So in the amforth I will call it like:

: my_test my_routine icall ;   ?????

P.




----- PŮVODNÍ ZPRÁVA -----
Od: "Kalus Michael" <mic...@on...>
Komu: "amforth mailing list list mailing"
<amf...@li...>
Předmět: [Amforth-devel] icall
Datum: 13.4.2011 - 10:58:45

> Hi.
> Recently someone asked how otherwise imported
> subroutines (c-code)  
> can be used by amforth.
> You may use icall of AVR instruction set to do so.
> Include icall.asm example in your application to
> test it.
> Add more stack to register moves if necessary for
> a given subroutine.
> 
> Michael
> 
> 
> 
> ; ( adr -- )
> ; R( -- )
> ; use icall to execute a code subroutine
> ; operation: PC <-- Z  and push PC+1 to
> returnstack.
> VE_ICALL:
> .dw $ff05
> .db "icall",0
> .dw VE_HEAD
> .set VE_HEAD = VE_ICALL
> XT_ICALL:
> .dw PFA_ICALL
> PFA_ICALL:
> movw zl,tosl
> loadtos
> icall
> jmp DO_NEXT
> 
> ; to test icall make a subroutine:
> subdup:
> savetos
> ret
> subdrop:
> loadtos
> ret
> 
> 
> ------------------------------------------------------------------------------
> > Forrester Wave Report - Recovery time is now
> measured in hours and minutes
> not days. Key insights are discussed in the 2010
> Forrester Wave Report as
> part of an in-depth evaluation of disaster
> recovery service providers.
> Forrester found the best-in-class provider in
> terms of services and vision.
> Read this report now! 
> http://p.sf.net/sfu/ibm-webcastpromo
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth-devel] icall

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

Hi.
Recently someone asked how otherwise imported subroutines (c-code)  
can be used by amforth.
You may use icall of AVR instruction set to do so.
Include icall.asm example in your application to test it.
Add more stack to register moves if necessary for a given subroutine.

Michael



; ( adr -- )
; R( -- )
; use icall to execute a code subroutine
; operation: PC <-- Z  and push PC+1 to returnstack.
VE_ICALL:
     .dw $ff05
     .db "icall",0
     .dw VE_HEAD
     .set VE_HEAD = VE_ICALL
XT_ICALL:
     .dw PFA_ICALL
PFA_ICALL:
     movw zl,tosl
     loadtos
     icall
     jmp DO_NEXT

; to test icall make a subroutine:
subdup:
     savetos
     ret
subdrop:
     loadtos
     ret

Re: [Amforth-devel] Starting amforth

[D N. <dny...@at...>]

On 4/12/2011 12:32 PM, Matthias Trute wrote:
> Am 10.04.2011 22:58, schrieb D Nyberg:
>> Long ago, I worked with forth extensively, but haven't for a while,  so
>> I have forgotten much. Also, that was work for an employer, so I don't
>> have copies of what I did back then. So I'll have to reinvent things I
>> remember doing.
>>
>> One of the things I did back then was I made a word called run_command"
>> Which compiled a literal string like ." does, but at run time it stuffed
>> the string into the command buffer and triggered the outer interpreter.
> Amforth does not (yet) provide the word EVALUATE that
> is needed to implement your idea verbatim, but
> its relativly easy to extend amforth to do what you want by
> duplicating the turnkey code and its use in QUIT.
I'll have to re-learn these parts of forth, but that's on my list of 
things to do.
>> That let us issue FORGET commands for words that didn't exist yet at
>> compile time,
> Funny.
>
>> etc. I've been thinking I'd like to do that again, but
>> this time maybe set up an amforth so that on cold boot it copies a
>> string (if it exists) from eeprom into the command buffer, then begins
>> execution.
> What is a cold boot? esp what makes it different from a warm boot? The
> atmega provide the reason of the reset in the status register and
> amforth copies this information into a register (R10). Your turnkey
> code may use that information to distinguish between e.g. a power on
> reset or a watchdog reset (details are in the datasheets for the
> MCUSR register).
Well I'm thinking in traditional mode; cold boot = power up or reset 
button, warm boot = software triggered, for instance by the ISR 
character check.
>> On warm boot, doesn't copy the string. It could be made even
>> a little more fancy, with maybe a few seconds count down before it runs
>> the buffer, and read ISR checks any received character for ^C and warm
>> boots if it sees one. I think that would make it very easy to develop
>> code in the field, set up automatic run if I think it's ready, break in
>> if it's not right. (I'd still want to incorporate Karl's eeprom loader,
>> or redevelop the same thing, though...)
> Do I understand it correctly: whenever a CTRL-C character is received,
> the currently executed word should be cancelled and the outer
> interpreter is activated? Just like a reset button but with keeping
> the stacks intact? Kinda of software interrupts.
I was actually thinking even reinitialize the stacks on warm boot; 
restart everything, except do not copy the string into the command 
buffer, since corrupted R stack or overflowed D stack could make it 
crash again. I suppose there might be some debug value in preserving the 
stacks, but I would have to think hard about side effects of trying to 
preserve them. Maybe spit out a stack dump to the console, then restart 
them from scratch? Again, I'd have to think about that.

But my first thought was cold boot = full init plus command string copy, 
warm boot = full init no command string copy. That would let me 
interrupt a hung program, or abort the command string before it started, 
if things were not as perfect  as I had hoped. One tool, two uses.

Re: [Amforth-devel] Starting amforth

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

Am 10.04.2011 22:58, schrieb D Nyberg:
> Long ago, I worked with forth extensively, but haven't for a while,  so 
> I have forgotten much. Also, that was work for an employer, so I don't 
> have copies of what I did back then. So I'll have to reinvent things I 
> remember doing.
> 
> One of the things I did back then was I made a word called run_command" 
> Which compiled a literal string like ." does, but at run time it stuffed 
> the string into the command buffer and triggered the outer interpreter.

Amforth does not (yet) provide the word EVALUATE that
is needed to implement your idea verbatim, but
its relativly easy to extend amforth to do what you want by
duplicating the turnkey code and its use in QUIT.


> That let us issue FORGET commands for words that didn't exist yet at 
> compile time,

Funny.

> etc. I've been thinking I'd like to do that again, but 
> this time maybe set up an amforth so that on cold boot it copies a 
> string (if it exists) from eeprom into the command buffer, then begins 
> execution.

What is a cold boot? esp what makes it different from a warm boot? The
atmega provide the reason of the reset in the status register and
amforth copies this information into a register (R10). Your turnkey
code may use that information to distinguish between e.g. a power on
reset or a watchdog reset (details are in the datasheets for the
MCUSR register).

> On warm boot, doesn't copy the string. It could be made even  
> a little more fancy, with maybe a few seconds count down before it runs 
> the buffer, and read ISR checks any received character for ^C and warm 
> boots if it sees one. I think that would make it very easy to develop 
> code in the field, set up automatic run if I think it's ready, break in 
> if it's not right. (I'd still want to incorporate Karl's eeprom loader, 
> or redevelop the same thing, though...)

Do I understand it correctly: whenever a CTRL-C character is received,
the currently executed word should be cancelled and the outer
interpreter is activated? Just like a reset button but with keeping
the stacks intact? Kinda of software interrupts.

Matthias

Re: [Amforth-devel] Starting amforth

[D N. <dny...@at...>]

Long ago, I worked with forth extensively, but haven't for a while,  so 
I have forgotten much. Also, that was work for an employer, so I don't 
have copies of what I did back then. So I'll have to reinvent things I 
remember doing.

One of the things I did back then was I made a word called run_command" 
Which compiled a literal string like ." does, but at run time it stuffed 
the string into the command buffer and triggered the outer interpreter. 
That let us issue FORGET commands for words that didn't exist yet at 
compile time, etc. I've been thinking I'd like to do that again, but 
this time maybe set up an amforth so that on cold boot it copies a 
string (if it exists) from eeprom into the command buffer, then begins 
execution. On warm boot, doesn't copy the string. It could be made even  
a little more fancy, with maybe a few seconds count down before it runs 
the buffer, and read ISR checks any received character for ^C and warm 
boots if it sees one. I think that would make it very easy to develop 
code in the field, set up automatic run if I think it's ready, break in 
if it's not right. (I'd still want to incorporate Karl's eeprom loader, 
or redevelop the same thing, though...)

Right now I'm working with freepcb to build a hardware target, but I'll 
get to those things in due course. I think I have a hardware fix for 
serial console timing problems, but I'll have to test it to be sure, first.

Re: [Amforth-devel] Starting amforth

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

Hi,

>>> Yes, UNTIL consumes a flag. IF consumes a flag too.
> 
>> OK. Does amforth's words page have then error in if (  -- addr  )
>> ? shouldn't that be ( f -- addr) Also until (  addr --  )
>> looks wrong. (f -- ) as it is making boolean decission.
> 
> You are right, that has to be fixed.

IF has multiple stack effects, its a compiler word. When
called as part of the compiler, it leaves an address on
the stack, when called at runtime it consumes a flag.
I have no good idea to document this yet.

btw: the sleep word takes now a parameter which contains
the actual sleep mode and I checked in the timer interrupt
in forth - democode. Nothing exciting but hopefully useful

Matthias

Re: [Amforth-devel] Starting amforth

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

Hi Hannu.


Am 10.04.2011 um 04:48 schrieb Hannu Vuolasaho:
..
>> Yes, UNTIL consumes a flag. IF consumes a flag too.

> OK. Does amforth's words page have then error in if (  -- addr  )
> ? shouldn't that be ( f -- addr) Also until (  addr --  )
> looks wrong. (f -- ) as it is making boolean decission.

You are right, that has to be fixed.

Maybe the "Forth Programmer's Handbook" is what you want, it is the  
de facto ANS Forth reference manual, regardless of which Forth  
implementation you use.
http://www.forth.com/forth/forth-books.html

Download a free copy of swiftForth evaluation version, the handbook  
is included as pdf file, a very fine piece of work. The ANS Forth  
Standard is included too.
http://www.forth.com/swiftforth/dl.html

The gforth user manual is a good reference as well.
http://www.jwdt.com/~paysan/gforth.html

Or look at dpans forth:
http://www.complang.tuwien.ac.at/forth/dpans-html/

Michael

Re: [Amforth-devel] Starting amforth

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

Hi Hannu,

>>> Q: Is somewhere simple LED blinker example? A: saw examples
>>> directory and studying those programs. But the workflow from
>>> forth code to standalone program is missing
>> 
>> \ example: : main ( -- ) begin led-on 1000 ms led-off 1000 ms key?
>> until ; ' main is turnkey
> Just to make sure that I understood this correctly, we define main
> word which has loop and executes led-on word, puts 1000 to stack,
> waits one second turns led off waits and reads from serial port. The
> key? word puts true if there is input. Second line makes main
> executed with turnkey word which is like autoexec.bat :)

Exactly. One side effect should be noted however: You loose the
command prompt.  Moreover: if you send a character and the loop
exits, the system will continue with QUIT. And QUIT is basically
the forth interpreter, which will operate on a not-working terminal
IO (no interrupts enabled, to usart line settings etc). May look
like a crash.

So the following definition is much better (note the port-init and
the again instead of the key? until).

: main ( -- ) port-init begin led-on 1000 ms led-off 1000 ms again ;

port-init has to setup the atemga ports for output.

>> 
>> My opinion: Never use (highlevel) forth on a embedded device to
>> serve an interrupt. Use the method that comes with the device. On
>> atmega: place a jump to code fragment that will set a variable. If
>> service may be slow, serve that variable in your forth task later.
> 
> True that. I need to check exsamples and study more. Right now I have
> questions in my mind. 1) Which registers I can use with ASM without
> pushing and popping them from stack.

You are save with all registers labeled tempx in the sources (r14 -
r21). Others should be saved with push/pop. For some registers it
may not strictly nessecairy, but I'd recommend it.

> 2) How do I create variable so
> that for exsample ISR can increment counter and I can use it in
> forth.

Just declare it as a variable.

variable counter

If you call counter afterwards, you get the RAM address of it
and can use with the assembler. Keep in mind that counter is
2 bytes, low byte first.

> 3) How to add portions of ASM and specify words for it.

you may want to examine the assembler-test.frt file and (probably
more interesting) the file keyboard.frt in

http://amforth.svn.sourceforge.net/viewvc/amforth/applications/lcd-ps2/blocks/

regarding the timer: this is one of the special cases which can be
implemented in forth without assembler. I have no idea what the
int0 part should do, but the timer part is fine in pure forth.
the file interrupt-test.frt is a (poorly documented) example

> 
> Last of my questions is there way to see how some word has been
> defined?

You have all the sources. Nothing is hidden. And almost every
word has its own source file. Why do you need SEE ??

> 
> And last I like to share this idea. in avr-libc documentation there
> is a the simple demo project. It is interrupt driven and makes PWM.

Work is in progress to write something beyond the user guide and some
example solutions. Maybe the author can be argued to reveal its
progress (no, its not me ;)

> But now I think I'll stop writing mail and start trying on that
> dimmer what I know about forth. ATMega88 is the victim this time.

Pick up an atmega168 or bigger, amforth is actually beyond the 8KB
flash size limits of that device... (some early versions will work
however, they are smaller in code size)


Matthias

Re: [Amforth-devel] Starting amforth

[Hannu V. <vu...@ms...>]

 
 
>>> Common constructs are:
>>> : main ( -- ) begin ... key? until ; \ test for any key
>>> : main ( -- ) begin ." ." 1000 ms key? dup if drop key $03 = then
>>> until ; \ test ctrl-c
>>
>> OK. Now I don't understand. ." is for printing like ." Hello
>> world!" If I've understood correct. What does two ." ." in row?
>
> You are right, the phrase ." xyz" in a definition outputs the string
> "xyz" to Terminal. The second " right after z is the delimmiter of
> the string definition. So if want a string of 5 stars I code ."
> *****" and if I want 3 dots I do ." ..." and if I want one dot only
> it is ." ." you see. You may use hex 2E emit as well.
 
Damn. You got me off guard. ofcourse it works like that. Those were such false friends so that I didn't saw the obvious.
 
>> wait a second check for input duplicate TOS (Why? does IF consume
>> one?) and if is true drop TOS, retrive the character and read from
>> memory address 03 ? Shouldn't that be just 03 when equality is
>> tested and passed to until after then word. So My current
>> understanding says that the duplicated key? is consumed only during
>> until?
>
> Yes, UNTIL consumes a flag. IF consumes a flag too. So you need two
> of them. If a key has been entered, check if it is ctrl-c ($03). This
> check gives the flag for UNTIL, so we better drop the underlying true
> flag. If there was no key we have a false flag, IF consumes the
> duplicated key? flag, an the false flag is passed on to UNTIL, so we
> get another run in the loop.
 
OK. Does amforth's words page have then error in if (  -- addr  )
? shouldn't that be ( f -- addr) Also until (  addr --  )
looks wrong. (f -- ) as it is making boolean decission.
 
<Good info only deleted from reply, not lost>
>
> Success!
Fail:
ATmega88 memory use summary [bytes]:
		Segment   Begin    End      Code   Data   Used    Size   Use%
		---------------------------------------------------------------
		[.cseg] 0x000000 0x001f96   1730   7696   9426    8192 115.1%
		[.dseg] 0x000100 0x000100      0      0      0    1024   0.0%
		[.eseg] 0x000000 0x000040      0     64     64     512  12.5%
		Assembly complete, 0 errors. 0 warnings
 
I need to wait for my new dev-board with ATMega 128 and get 328 for the dimmer.
I started trying copying template and commenting out everything from appl_dict and starting to add themback so it compiled without errors.
13+% optimization is required to run amforth with 8k devices.
Now it's time to sleep.
Hannu

 		 	   		  

Re: [Amforth-devel] Starting amforth

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

Hi Hannu.


Am 09.04.2011 um 21:57 schrieb Hannu Vuolasaho:

>
> Hi Michael and rest of you!
>
> Thanks for kind answers. Those were very enlightning. I'll bring  
> these new questions up so that beginners like myself doesn't need  
> to ask them over again (if they can search archives) and maybe give  
> some ideas what to put also getting started document. I have  
> confidense that I can find the answers from examples and trying  
> things. Even one fool can ask more questions than hundred wise men  
> can answer, I hope you don't feel I'm abusing this list.

You are welcome.



>> Am 08.04.2011 um 06:41 schrieb Hannu Vuolasaho:
>>
>>> Q: Is somewhere simple LED blinker example?
>>> A: saw examples directory and studying those programs. But the
>>> workflow from forth code to standalone program is missing
>>
>> \ example:
>> : main ( -- ) begin led-on 1000 ms led-off 1000 ms key? until ;
>> ' main is turnkey
> Just to make sure that I understood this correctly, we define main  
> word which has loop and executes led-on word, puts 1000 to stack,  
> waits one second turns led off waits and reads from serial port.  
> The key? word puts true if there is input.

Exactly. Number base has to be decimal to wait about a second. The  
led-on and led-off words have to be defined earlier of course,  
depending on which port pin LED is.


> Second line makes main executed with turnkey word which is like  
> autoexec.bat :)

Yes.




> I'm learning the language so I like to explain all code that I find  
> so I understand what I read.
>
>> 1. flash amforth into device
>> 2. develop your forth code on the device. Since it is in flash, is
>> permanent.
>> 3. set turnkey, Since it is in eeprom its permanent too.
>> 4. turn off power of device. Turn power on, it will run your
>> application.
> wow. It's like a Commorode 64 or picoBasic. (PIC chip with  
> interactive BASIC. Finnsh webpage only: www.picobasic.com)
> Anyway instant usable computer :)
>
>>
>> Step 2 can be very strenuous. amforth is very simple, it is for tiny
>> devices. I use gforth or some other "big" forth systems to develop
>> most of the forth code before it goes down the device and runs on
>> amforth. Since amforth is standard forth, this works nice. You have
>> to simulate features of the device. Fine tuning then is done
>> interactive on the device itself. So its kind of iteration using
>> gforth, test it in amforth on the device, continue this loop
>> modifying code until it does the job.
>
> MARKER word seems to be good for this.

Yes. That is its intended use.



>> Usually it takes a lot of re-flashing amforth till everything is
>> works well.
>
> During flash everything is resetted. First are lost the forth words  
> code and in EEPROM reset dictionary to them. So source file must be  
> on computer where it van be uploaded to system. Also using ASM  
> reguires reflashing.

Re-flashing gives a clean forth again. You must upload forth source  
too then. I hope your Terminal does handle this.



>> Common constructs are:
>> : main ( -- ) begin ... key? until ; \ test for any key
>> : main ( -- ) begin ." ." 1000 ms key? dup if drop key $03 = then
>> until ; \ test ctrl-c
>
> OK. Now I don't understand. ." is for printing like ." Hello  
> world!" If I've understood correct. What does two ." ." in row?

You are right, the phrase ." xyz" in a definition outputs the string  
"xyz" to Terminal. The second " right after z is the delimmiter of  
the string definition. So if want a string of 5 stars I code ."  
*****" and if I want 3 dots I do ." ..." and  if I want one dot only  
it is ." ." you see. You may use   hex 2E emit   as well.




> wait a second check for input  duplicate TOS (Why? does IF consume  
> one?) and if is true drop TOS, retrive the character and read from  
> memory address 03 ? Shouldn't that be just 03 when equality is  
> tested and passed to until after then word. So My current  
> understanding says that the duplicated key? is consumed only during  
> until?

Yes, UNTIL consumes a flag. IF consumes a flag too. So you need two  
of them. If a key has been entered, check if it is ctrl-c ($03). This  
check gives the flag for UNTIL, so we better drop the underlying true  
flag. If there was no key we have a false flag, IF consumes the  
duplicated key? flag, an the false flag is passed on to UNTIL, so we  
get another run in the loop.

...
>> My opinion: Never use (highlevel) forth on a embedded device to serve
>> an interrupt. Use the method that comes with the device. On atmega:
>> place a jump to code fragment that will set a variable. If service
>> may be slow, serve that variable in your forth task later.
>
> True that. I need to check exsamples and study more. Right now I  
> have questions in my mind.
> 1) Which registers I can use with ASM without pushing and popping  
> them from stack.

In asm code you may use all working registers named "temp" since  
amforth makes no use of them. Top of stack (TOS) is in the register  
pair named tosl and tosh. So you have access to TOS within register  
operations.


> 2) How do I create variable so that for exsample ISR can increment  
> counter and I can use it in forth.

There are two ways for this.

First one is: Add your variable to the source of amforth, then flash  
it. Add your code file in ASM too that increments second, minute,  
hour by interupt. While interupt is working in background, you may  
fetch variable with forth - see example "time".

time c@   gets the value stored at adr = hour on top of stack.
time 1+ c@ gives you the minute.
time 2 + c@ gives you the second.


; ( -- adr )
VE_TIME:
     .dw $ff04
     .db "time"
     .dw VE_HEAD
     .set VE_HEAD = VE_TIME
XT_TIME:
     .dw PFA_DOVARIABLE
PFA_TIME:
     .dw heap
.equ hour=heap
     .set heap = heap + 1
.equ minute=heap
     .set heap = heap + 1
.equ second=heap
     .set heap = heap + 1

The other way is to load the assembler.frt on top of amforth and code  
it there as a source file.


> 3) How to add portions of ASM and specify words for it.

Upload amforth-4.2/lib/assembler.frt (Lubos Pekny) to amforth.


> ...
> Last of my questions is there way to see how some word has been  
> defined?

There is no comfortable SEE yet as far as I know.

But you may inspect you code with a dump of flash memory
: myword   somecode ;
' myword 10 dump

you may look up all the execution tokens (xt) in the *.lst file that  
was created by your assembler (AVRA?) when generating amforth. Or  
include SEEWORD to you source to see name of given execution token:

; : seeword     xt>nfa icount $ff and itype ;
; ( xt -- )
; R( -- )
; type name of word.
VE_SEEWORD:
     .dw $FF07
     .db "seeword",0
     .dw VE_HEAD
     .set VE_HEAD = VE_SEEWORD
XT_SEEWORD:
     .dw DO_COLON
PFA_SEEWORD:        ; ( xt -- )
     .dw XT_XT_TO_NFA
     .dw XT_ICOUNT
     .dw XT_DOLITERAL
     .dw $FF
     .dw XT_AND
     .dw XT_ITYPE
     .dw XT_EXIT



Include SEEDEF to get name of word that a deferred definition is  
currently using.

; ( xt -- )
; R( -- )
; type name of deferd word in use.
VE_SEEDEF:
     .dw $FF06
     .db "seedef"
     .dw VE_HEAD
     .set VE_HEAD = VE_SEEDEF
XT_SEEDEF:
     .dw DO_COLON
PFA_SEEDEF:        ; ( xt -- )
     .dw XT_DEFERFETCH
     .dw XT_SEEWORD
     .dw XT_EXIT

Try  ' key seedef

:-)


>
> And last I like to share this idea. in avr-libc documentation there  
> is a the simple demo project. It is interrupt driven and makes PWM.  
> I think it could be nice if the demo project in getting starte page  
> had first single task non-sleeping non interrupt version of the  
> project and then shoved how to make as much as possible same  
> project with interrupts.
>
> So far I think that amforth may become the default environment for  
> my 8-bit AVR toys because forth as language thinks more like I do  
> in principle. Learning curve is quite steep however since there are  
> so many words and many look much a like and forth's postfix is  
> sometimes hard to understand.
>
> But now I think I'll stop writing mail and start trying on that  
> dimmer what I know about forth. ATMega88 is the victim this time.
>
> Best regards,
> Hannu Vuolasaho

Success!

Michael

Re: [Amforth-devel] Starting amforth

[Hannu V. <vu...@ms...>]

Hi Michael and rest of you!

Thanks for kind answers. Those were very enlightning. I'll bring these new questions up so that beginners like myself doesn't need to ask them over again (if they can search archives) and maybe give some ideas what to put also getting started document. I have confidense that I can find the answers from examples and trying things. Even one fool can ask more questions than hundred wise men can answer, I hope you don't feel I'm abusing this list.

>
> Am 08.04.2011 um 06:41 schrieb Hannu Vuolasaho:
>
>> Q: Is somewhere simple LED blinker example?
>> A: saw examples directory and studying those programs. But the
>> workflow from forth code to standalone program is missing
>
> \ example:
> : main ( -- ) begin led-on 1000 ms led-off 1000 ms key? until ;
> ' main is turnkey
Just to make sure that I understood this correctly, we define main word which has loop and executes led-on word, puts 1000 to stack, waits one second turns led off waits and reads from serial port. The key? word puts true if there is input.
Second line makes main executed with turnkey word which is like autoexec.bat :)

I'm learning the language so I like to explain all code that I find so I understand what I read.

> 1. flash amforth into device
> 2. develop your forth code on the device. Since it is in flash, is
> permanent.
> 3. set turnkey, Since it is in eeprom its permanent too.
> 4. turn off power of device. Turn power on, it will run your
> application.
wow. It's like a Commorode 64 or picoBasic. (PIC chip with interactive BASIC. Finnsh webpage only: www.picobasic.com)
Anyway instant usable computer :)

>
> Step 2 can be very strenuous. amforth is very simple, it is for tiny
> devices. I use gforth or some other "big" forth systems to develop
> most of the forth code before it goes down the device and runs on
> amforth. Since amforth is standard forth, this works nice. You have
> to simulate features of the device. Fine tuning then is done
> interactive on the device itself. So its kind of iteration using
> gforth, test it in amforth on the device, continue this loop
> modifying code until it does the job.

MARKER word seems to be good for this.
>
> Usually it takes a lot of re-flashing amforth till everything is
> works well.

During flash everything is resetted. First are lost the forth words code and in EEPROM reset dictionary to them. So source file must be on computer where it van be uploaded to system. Also using ASM reguires reflashing.

> Common constructs are:
> : main ( -- ) begin ... key? until ; \ test for any key
> : main ( -- ) begin ." ." 1000 ms key? dup if drop key $03 = then
> until ; \ test ctrl-c

OK. Now I don't understand. ." is for printing like ." Hello world!" If I've understood correct. What does two ." ." in row?
wait a second check for input  duplicate TOS (Why? does IF consume one?) and if is true drop TOS, retrive the character and read from memory address 03 ? Shouldn't that be just 03 when equality is tested and passed to until after then word. So My current understanding says that the duplicated key? is consumed only during until?

>> Q: Register read and write?
>> A: 1 PIN_NUMBER lshift REGISTER_NAME or! to set one bit. Are
>> registers normally included? ( in C #include "avr/io.h" is needed)
>
> No. (as far as I know)

Mathias trute wrote:
>> Just keep in mind: that WANT_something = 1 only
>> makes the register names available. There is no code associated
>> with.Which wasn't clear to me. I believe PORTA is just address for I/O space where I want to write the the data. However most registers are 8-bit long. This will need some studying.
>
>
>
>> Q: How interrupts are used?
>> A: First there has to be word for interrupt and it has to be told
>> to sytem so that it knows what to run on interrupt and then
>> registers are written to enable that interrupt.
>
> Religious content ;-)
>
> My opinion: Never use (highlevel) forth on a embedded device to serve
> an interrupt. Use the method that comes with the device. On atmega:
> place a jump to code fragment that will set a variable. If service
> may be slow, serve that variable in your forth task later.

True that. I need to check exsamples and study more. Right now I have questions in my mind.
1) Which registers I can use with ASM without pushing and popping them from stack.
2) How do I create variable so that for exsample ISR can increment counter and I can use it in forth.
3) How to add portions of ASM and specify words for it.

>
>> Q: Can Amforth used as calculator?
>> A: Instead of using dc to calculate time to next coffee break forth
>> prompt over serial cable could be used for that. Or can it?
>
> You will have to set up a real time clock in your device first I
> guess, using a timer interrupt to count down the seconds, minutes,
> hours.

Well this question before I was sure how the system worked. I think I'll give amforth a try in my light dimmer. I can't wait for my new toy anymore. The geek factor is that dimming lights you can also make calculations with it. My nerd frineds are so jealous when they see that I can ask how much is  2 5 + . 

I'm thinking something like two tasks. Two ASM helped interrupts. First is INT0 for sync and second is counter. First task fires triacs and second sleeps even there is no need for that and with some key drops to prompt so I can show off with the system in dimmed light :) There is no real need for sleeping in that project but maybe in some other project needs that and it is nice to learn things.

Last of my questions is there way to see how some word has been defined? 

And last I like to share this idea. in avr-libc documentation there is a the simple demo project. It is interrupt driven and makes PWM. I think it could be nice if the demo project in getting starte page had first single task non-sleeping non interrupt version of the project and then shoved how to make as much as possible same project with interrupts.

So far I think that amforth may become the default environment for my 8-bit AVR toys because forth as language thinks more like I do in principle. Learning curve is quite steep however since there are so many words and many look much a like and forth's postfix is sometimes hard to understand. 

But now I think I'll stop writing mail and start trying on that dimmer what I know about forth. ATMega88 is the victim this time.

Best regards,
Hannu Vuolasaho