amforth-devel — Development discussion and user support

[Amforth-devel] New release: 2.7

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

Hi,

I just made a new release of amforth.

The most notable changes are a better ans94
conformance (stack order of double cell values)
and the assembler from Lubos Pekny (www.forth.cz).
The assembler may emit a warning like

Appnotes\m169def.inc(1199): warning: Register r31 (and r30) already 
defined by the .DEF directive

this is harmless and can be ignored.

The downloadable package contains now every
file to make it easier to use.

Have fun with it
Matthias

Re: [Amforth-devel] Atmega8 UART issues

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

Klaus Zerbe wrote:

> @Matt: If possible, try also another controller since Atmega8 ist a 
> little bit small for amforth anyway.

For the records: I just put an amforth from repository trunk on an
atmega8 with an external 12MHz quartz and everything worked as expected.

   amforth 2.7 ATmega8
 > unused cells decimal u.
  2298 ok
 >


The fuses are as follows

MCU=atmega168
LFUSE=0xee
HFUSE=0xdf
EFUSE=0xf9

MCU=atmega8
LFUSE=0xee
HFUSE=0xd9

Bye
Matthias

Re: [Amforth-devel] Block commands

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

Hi,

> are there yet any ideas on how the Block commands will be done? I guess
> the
> biggest problem is memory as the normal 1024 byte block size would be far
> to big.

I've implemented some words for the I2C EEPROM with the native block sizes
of the chips (around 32 or 64 bytes per block).

One approach to implement full block buffers could be a virtualization.
But this will be difficult since the normal memory access words have
to be used to access the block buffer. A word set like b@/b! to
access (virtual) block memory would certainly work, but does not help
porting code from other forth's .

In older forth version a word b/blk was defined to give the size of
a block buffer in bytes. The value can be different for each block
device (EEPROM, SD-Card etc).

A total different solution would be: full block buffer sizes but only on
systems that have enough memory (internal or external).

All solution should provide some kind of an abstraction layer, since
there are far too many different block devices available. That
layer can work with native block sizes.

Bye
Matthias

[Amforth-devel] Block commands

[Christian B. <cas...@ca...>]

Servus, (=bavarian for hello and goodbye)

are there yet any ideas on how the Block commands will be done? I guess the 
biggest problem is memory as the normal 1024 byte block size would be far to 
big.

Servus
  Casandro

Re: [Amforth-devel] Adding own code to amforth: reserving heap space

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

Christian Berger wrote:

> Ohh I was able to get it from therw. It seems like you did preety much what I 
> did. I think from what I have seen the only point where I could claim my code 
> to be better is in the vsync area, but that's largely irrelevant. Ohh and my 
> clock doesn't need an additional quartz.
> 
> Anyhow, are you interrested in getting some FM-Synthesis sound routines for 
> your application?

I'm collecting everything and publish all I'm allowed to do.
But the TV application is not mine.

Bye
Matthias

Re: [Amforth-devel] Adding own code to amforth: reserving heap space

[Christian B. <cas...@ca...>]

Am Donnerstag 13 März 2008 20:57:57 schrieb Matthias Trute:
> Erich Waelde wrote:
> > Hello,
> >
> > Christian Berger wrote:
> >> Am Mittwoch 12 März 2008 20:43:16 schrieb Erich Waelde:
> >>> not sure whether this helps: You did look at the application
> >>> in amforth/appl/tv, did you?
> >>
> >> No, but that sounds interresting. What is it and where do I find it? I
> >> don't have an appl directory.
> >
> > You need to look at the svn sources directly:
> > http://amforth.svn.sourceforge.net/viewvc/amforth/appl/tv/
>
> I'm sorry to tell, that the link does not work any more...

Ohh I was able to get it from therw. It seems like you did preety much what I 
did. I think from what I have seen the only point where I could claim my code 
to be better is in the vsync area, but that's largely irrelevant. Ohh and my 
clock doesn't need an additional quartz.

Anyhow, are you interrested in getting some FM-Synthesis sound routines for 
your application?

Servus
  Casandro

Re: [Amforth-devel] Adding own code to amforth: reserving heap space

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

Erich Waelde wrote:
> Hello,
> 
> Christian Berger wrote:
>> Am Mittwoch 12 März 2008 20:43:16 schrieb Erich Waelde:
>>> not sure whether this helps: You did look at the application
>>> in amforth/appl/tv, did you?
>> No, but that sounds interresting. What is it and where do I find it? I don't 
>> have an appl directory.
> 
> You need to look at the svn sources directly:
> http://amforth.svn.sourceforge.net/viewvc/amforth/appl/tv/

I'm sorry to tell, that the link does not work any more...

The reason is simple: a reorganization of the repository
structure. It is not yet fully finished but I think it won't change
a lot again, since I use the new structure internally for quite some
time. The only thing thats left is around applications that I cannot
work with, like the tv application. The actual link for them is

http://amforth.svn.sourceforge.net/viewvc/amforth/applications/

All new code is now in trunk, regardless of core or library or
(my) applications.

Matthias

Re: [Amforth-devel] Adding own code to amforth: reserving heap space

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

Hello,

Christian Berger wrote:
> Am Mittwoch 12 März 2008 20:43:16 schrieb Erich Waelde:
> > not sure whether this helps: You did look at the application
> > in amforth/appl/tv, did you?
> 
> No, but that sounds interresting. What is it and where do I find it? I don't 
> have an appl directory.

You need to look at the svn sources directly:
http://amforth.svn.sourceforge.net/viewvc/amforth/appl/tv/


Cheers,
Erich

[Amforth-devel] Forth-Computer first release

[Christian B. <cas...@ca...>]

Servus,

I just made the first release of the Forth-Computer, a modified version of 
amforth with video output and keyboard input.

Here's the release note:
http://www.mikrocontroller.net/topic/94193

Servus
  Casandro

Re: [Amforth-devel] Adding own code to amforth: reserving heap space

[Christian B. <cas...@ca...>]

Am Mittwoch 12 März 2008 20:43:16 schrieb Erich Waelde:
> Hi,
>
> not sure whether this helps: You did look at the application
> in amforth/appl/tv, did you?

No, but that sounds interresting. What is it and where do I find it? I don't 
have an appl directory.

I found the bug now, insteadt of writing
.set heap=heap+XSize*YSize+...
I wrote
.set heap=XSize+YSize+...

I am now almoust done, BTW. The only thing missing is shift on the keyboard.

> Good luck,
> Erich


Thank you
  Christian Berger

Re: [Amforth-devel] Adding own code to amforth: reserving heap space

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

Hi,

not sure whether this helps: You did look at the application 
in amforth/appl/tv, did you?

Good luck,
Erich

Christian Berger wrote:
> Servus, (=bavarian for hello and goodbye)
> 
> I am trying to add video-terminal code to amforth, and currently it only kinda 
> works.
> 
> I can enter text and it gets displayed, but whenever I press the enter key it 
> mostly crashes.
> 
> I suspect that my software and amforth use the same memory areas.
> 
> I am currently using a code like this to allocate space on the heap:
> 
> .dseg
> .org heap
> keyboard_buffer: .byte 1
> keyboard_shift: .byte 1
> .set heap = heap + 2
> .cseg
> 
> I am not sure if this is correct, but if it is I will also check if I'm not 
> messing with registers in a way I shouldn't.
> 
> Servus
>   Casandro
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth-devel] Adding own code to amforth: reserving heap space

[Christian B. <cas...@ca...>]

Servus, (=bavarian for hello and goodbye)

I am trying to add video-terminal code to amforth, and currently it only kinda 
works.

I can enter text and it gets displayed, but whenever I press the enter key it 
mostly crashes.

I suspect that my software and amforth use the same memory areas.

I am currently using a code like this to allocate space on the heap:

.dseg
.org heap
keyboard_buffer: .byte 1
keyboard_shift: .byte 1
.set heap = heap + 2
.cseg

I am not sure if this is correct, but if it is I will also check if I'm not 
messing with registers in a way I shouldn't.

Servus
  Casandro

Re: [Amforth-devel] Changing the word used for output and input

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

Christian Berger wrote:
> Am Freitag 07 März 2008 17:22:08 schrieb Matthias Trute:
>> Hi,
>>
>>> Now my big question is, how do I redirect the output of the forth system
>>> to the emit_tv word?
>> just do
>>
>> ' your-emit is emit
> 
> Thanks, that works fine, but how can I change that permanently?

similiar: amforth defines a deferred word named turnkey which is
executed whever the controller starts up. The default turnkey is
defined in the application/words/turnkey.asm file and sets up the
serial line, turns the interrupts on and prints the version number.

You turnkey action may look like

--------------
: my-turnkey ( now your code goes here ) ;

' my-turnkey is turnkey
---------------

And the default turnkey action is changed to yours. Be aware that
the default turnkey action is not saved, you may need to re-flash
the eeprom (turnkey is a EEPROM based DEFER word).

>> The IS/DEFER is based upon a forth200x standard see
>>
>> http://www.forth200x.org/deferred.html for the
>> details.
> 
> Unfortunately I know far to little about Forth to understand that.

Its a elegant way to do vectored execution. Traditional forth
would express it like the first amforth versions: A variable named
'<something> and a word named <something> that reads the content of
the variable '<something> and executes the XT stored there.

------ old

variable 'something
: something 'something @ execute ;
' a-word 'someting !
something

------- new

RDEFER something
' a-word IS something
something
---------

afterwards something will execute a-word when called. The RDEFER is
used to express that the XT vector is stored in RAM. Other possibilities
are EDEFER (for EEPROM) and UDEFER (for the user area). An IDEFER would
use a flash cell. The IS is always the same, for all deferred words.

Note that the DEFER/IS words are almost lowercase and need to
be loaded from the file lib/defer.fs since the core system contains the
runtime words only ;=)

Bye
Matthias

Re: [Amforth-devel] Changing the word used for output and input

[Christian B. <cas...@ca...>]

Am Freitag 07 März 2008 17:22:08 schrieb Matthias Trute:
> Hi,
>
> > Now my big question is, how do I redirect the output of the forth system
> > to the emit_tv word?
>
> just do
>
> ' your-emit is emit

Thanks, that works fine, but how can I change that permanently? In the next 
step of my project I will loose the serial line, but gain a keyboard, so I'd 
like to change input and output to those new devices.

> The IS/DEFER is based upon a forth200x standard see
>
> http://www.forth200x.org/deferred.html for the
> details.

Unfortunately I know far to little about Forth to understand that.

> Bye
> Matthias

Servus
  Casandro

Re: [Amforth-devel] Changing the word used for output and input

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

Hi,

> Now my big question is, how do I redirect the output of the forth system to 
> the emit_tv word?

just do

' your-emit is emit

at the prompt or inside a colon definition

: 2tv ['] your-emit is emit ;

The IS/DEFER is based upon a forth200x standard see

http://www.forth200x.org/deferred.html for the
details.

Bye
Matthias

[Amforth-devel] Changing the word used for output and input

[Christian B. <cas...@ca...>]

Servus, (=bavarian for hello and goodbye)

I want to make a forth-based home computer. And I already got so far as to 
write accompanying video routines for it.

So I can currently enter something like emit_tv and a character will appear on 
the monitor. The hardware actually just consists of 2 resistors. :) If you 
are interested I can upload pictures of the current system somewhere.

Now my big question is, how do I redirect the output of the forth system to 
the emit_tv word?

Servus
  Casandro

Re: [Amforth-devel] Version 2.6: case ... endcase broken?

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

Hello,

Matthias Trute wrote:
> Hi Erich,
> 
> better late than never
> 
> Erich Waelde wrote:
> 
>> In release 2.6 "case" "encase" "of" "endof" were moved into
>> lib/case.frt
> 
>> Any ideas? 
> 
> I took the code from the usenet and did not test it. mea culpa.
> Another forth-project named flashforth has a different implementation
> for it, maybe you can test theirs?
> 

After downloading "flashforth" (for PIC controllers, GPL v3) 
from flashforth.sourceforge.net, I stole "case.fth" from 
their code base. With a minimum of changes (change "for ... 
next" to "?do ... loop") it did work for my tests. In 
particular, case did work, and the argument is cleaned up 
properly. I found this implementation easily readable. Kudos 
to Mikael Nordman and the flashforth folks.

Please find below the files I used.


Cheers,
Erich

-------------------------------------------------------------------
flash_case.fs
-------------------------------------------------------------------
\ 
*********************************************************************
\    Case for FlashForth 
           *
\    Filename:      case.fth 
           *
\    Date:          15.1.2008 
           *
\    FF Version:    3.2 
           *
\    Copyright:     Mikael Nordman 
           *
\    Author:        Mikael Nordman 
           *
\ 
*********************************************************************
\    FlashForth is licensed acording to the GNU General 
Public License*
\ 
*********************************************************************
\ A case implementation posted by Jenny Brien on c.l.f.
\ Modified to use for..next instead of do..loop

\ Modified for use in amforth, changed for..next back
\ to do..loop; Erich Waelde

\ -case
\ marker -case
\ hex ram

variable #of
: case  (  x -- x #of )
   #of @  0 #of !  \ allow nesting
; immediate


: of  ( -- orig)
     postpone over  postpone = ( copy and test case value)
     postpone if    ( add orig to control flow stack )
     postpone drop  ( discards case value if = )
; immediate

: endof ( orig1  -- orig2 )
    postpone else 1 #of +!
; immediate

: endcase  ( #of  orig1..orign  -- )
     postpone drop  ( discard case value )
     #of @ 0 do
       postpone then
     loop
     #of !
; immediate

-------------------------------------------------------------------
test_case.fs

\ 2008-02-02 Erich Waelde


#include lib/ans94/postpone.frt
#include flash_case.fs

: checkout ( n -- )
   case
     0 of ." none" endof
     1 of ." once" endof
     2 of ." twice" endof
     ." unknown"
   endcase
;

-------------------------------------------------------------------

Re: [Amforth-devel] Version 2.6: case ... endcase broken?

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

Hi Erich,

better late than never

Erich Waelde wrote:

> In release 2.6 "case" "encase" "of" "endof" were moved into
> lib/case.frt

> 
> Any ideas? 

I took the code from the usenet and did not test it. mea culpa.
Another forth-project named flashforth has a different implementation
for it, maybe you can test theirs?

Matthias

Re: [Amforth-devel] Atmega8 UART issues

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

Klaus Zerbe wrote:
> Hi,
> i probably got into the same problems like Matt Eastburn.
> 
> I also used AVStudio 4.13 to compile & link and burned the HEX and EEP 
> files with AVR Prog 1.4 into an Atmega8L with an external Xtal with 
> 36864 Mhz.
> 
> I fused for Highsped external Xtal and 2.7V BOD, leaving all other fuses 
> alone.

I found the following website useful when it comes to fuses:

http://palmavr.sourceforge.net/cgi-bin/fc.cgi

> Like for Matt the resulting controller did not communicate via USART. 
> Reducing the baudrate didn't help. So I added some Assembler code for 
> trace output and that worked. I could follow the inner interpreter and 
> found this running all the time, but seemed not reaching the 
> "applturnkey" ever.

Strange. Did you find out in which  word the inner interpreter kept
so busy? I've observed this behavior only when I forgot to upload
the eeprom bytes.

> Finally I stopped this and used an ATmega168 instead. After correcting a 
> Typo in "atmega168.asm" (The label ADCCaddr was written as ADCaddr) that 
> compiled and linked fine and after burning that output amforth started 
> without a problem.

It's not exactly a typo but a different name for the same address in
different tools. And I prefer the linux based ones ;=)

> So maybe something is wrong in "atmega8.asm" when using the Atmega8L ?

This and/or the fuses.

> @Matt: If possible, try also another controller since Atmega8 ist a 
> little bit small for amforth anyway. There are only 17% memory free for 
> your applications. Atmega168 is pincompatible but has 16kb instead 8kb 
> FlashROM and a built-in far-distance JMP-instruction too ;)

at a very deep internal level, amforth uses the far-call instruction
even on systems which do not officially support the mnemomic. All
my atmega8 run fine with it and have no trouble with it, but maybe
not all are such tolerant. Can you please send me a picture of your
atmega directly? (the mailling list does not accept attachements)
together with your application definition file.

Matthias

[Amforth-devel] Atmega8 UART issues

[Klaus Z. <kl...@ze...>]

Hi,
i probably got into the same problems like Matt Eastburn.

I also used AVStudio 4.13 to compile & link and burned the HEX and EEP 
files with AVR Prog 1.4 into an Atmega8L with an external Xtal with 
36864 Mhz.

I fused for Highsped external Xtal and 2.7V BOD, leaving all other fuses 
alone.
@Matt: click on the "Advanced settings button" in AVR prog to access the 
fuses.

Like for Matt the resulting controller did not communicate via USART. 
Reducing the baudrate didn't help. So I added some Assembler code for 
trace output and that worked. I could follow the inner interpreter and 
found this running all the time, but seemed not reaching the 
"applturnkey" ever.

Finally I stopped this and used an ATmega168 instead. After correcting a 
Typo in "atmega168.asm" (The label ADCCaddr was written as ADCaddr) that 
compiled and linked fine and after burning that output amforth started 
without a problem.

So maybe something is wrong in "atmega8.asm" when using the Atmega8L ?

@developers: Keep up your great work!
I've not used Forth since 1986 on Z80 and 8088- systems but remember how 
much fun that was.
Now its even greater being able to explore those cool microcontrollers 
in direct interaction !

@Matt: If possible, try also another controller since Atmega8 ist a 
little bit small for amforth anyway. There are only 17% memory free for 
your applications. Atmega168 is pincompatible but has 16kb instead 8kb 
FlashROM and a built-in far-distance JMP-instruction too ;)

Kind regards

Klaus Zerbe

Re: [Amforth-devel] Atmega8 uart issues.

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

Hi Matt,


Matt Eastburn wrote:
> 
> I am using a atmega8L (at 5volts). 8MHz Crystal. 9600baud.
> 
> As mentioned in my first post i get the exact same hardware to work when
> compiling C to it.

To summarize:
1. you can transfer a program to the controller. I suppose, you
use the same tools/programmer for
a. the compiled C Programm and
b. the "compiled" amforth system.

Can you reread the program from the compiler and compare
that to the original file?

2. The amforth system depends on a small second file
(*.eep.hex). This file is only 12 byte, but it must be
transfered into the controllers eeprom. It stores a few
important things for internal use of the amforth system.
Just to make sure, you did transfer that as well, right? If
you did not, the amforth system cannot start.

3. fuse bits. The fact, that you can successfully transfer
and run a compiled C program, seems to suggest, that it is
not a problem with the fuse bits. I do not use AVR Studio,
but I expect that there is some "menu", which says something
like "set fuses" or "set fuses/locks". Then I expect a panel
with a list of "bits" to select, with strange names like
BODLEVEL, BODEN (brown out detection enabled), CKSEL0..3 to
select the exact clock source.

In theory, a brandnew controller runs on its internal RC
oscillator at something like 125 kHz, but again, the fact
that your C program works, seems to suggest that the fuses
are set ok.

> I do unplug the programmer - but it does not help.
> 
> Now as for the fuse bits - this is where i could be going wrong. because I
> dont really know how or what to set them to.
> 
> I just use AVR Studio to compile the asm files then program the chip. but
> dont know what to set the fuse bits to - or where i can set them.
see above.


4. Again, let me recommend to test lower baud rates.


Good luck,
Erich

Re: [Amforth-devel] Atmega8 uart issues.

[Matt E. <mat...@me...>]

Hi Erich,

thanks for your help.

I will give you some more info on the setup I have.

I am using a atmega8L (at 5volts). 8MHz Crystal. 9600baud.

As mentioned in my first post i get the exact same hardware to work when
compiling C to it.

I do unplug the programmer - but it does not help.

Now as for the fuse bits - this is where i could be going wrong. because I
dont really know how or what to set them to.

I just use AVR Studio to compile the asm files then program the chip. but
dont know what to set the fuse bits to - or where i can set them.


Matt Eastburn

Re: [Amforth-devel] Atmega8 uart issues.

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

Hello,
and "welcome" :-)

Matt Eastburn wrote:

> I have just set up a basic project to see if I can get something out  
> of the serial port.
> 
> At this stage can't get it to do anything on the serial port.

This could unfortunately be any number of things ... so 
without more details (exact controller, crystal or internal 
oscillator, at what speed ...) this is hard to "debug".

My suggestions:

1. go to very low speeds on the serial port, maybe 1200 
baud, just to see, if bits go across the line. Use an LED 
with a resistor as a "probe". Just to make sure there are 
pulses on the cable connections.

2. I had similar problems with an atmega32. They were fixed 
by using a "baud rate crystal" (11.0592 MHz) and better fuse 
settings (I had to dig deep in the datasheet: hfuse=0x89, 
lfuse=0xee). This setting now works reliably with 115200 baud.

3. To make things a little more "obscure", the programmer I 
used initially, did not release the /Reset line properly. So 
unplugging the damn thing made much of a difference :-)


Good luck!
Erich


Good luck!

[Amforth-devel] Atmega8 uart issues.

[Matt E. <mat...@me...>]

Hi guys,

Just found amforth and am pretty excited by it.

I have just set up a basic project to see if I can get something out  
of the serial port.

At this stage can't get it to do anything on the serial port.

Is there something I am doing wrong. Avr assembler compiles fine. Then  
programs to the chip fine.

I know the hardware works because I can get C to talk on the serial  
port.

Please help me out if you can.


Matt Eastburn

[Amforth-devel] Version 2.6: case ... endcase broken?

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

Hello,

In release 2.6 "case" "encase" "of" "endof" were moved into
lib/case.frt

I loaded a small amforth (no case) on an atmega32.

using the following file
-----------------------------------------
#include lib/ans94/postpone.frt
#include lib/case.frt

: checkout ( n -- )
   case
     0 of ." none" endof
     1 of ." once" endof
     2 of ." twice" endof
     ." unknown"
   endcase
;
-----------------------------------------
for upload with amforth-upload.py produces a reset or hang
(!) of the controller after "endcase".

Any ideas? The above example used to work with Version 2.5
and included case.asm endcase.asm of.asm endof.asm files,
except for a leftover argument.

Cheers,
Erich

--- the gory details --------------------
$ amforth-upload.py -t /dev/ttyUSB0 zz.fs
: postpone
  ok    bl word find dup 0<
  ok    if
  ok drop compile compile , exit
  ok    then
  ok    if
  ok , exit
  ok    then
  ok    drop
  ok    [ base @ decimal ] -13 [ base ! ] throw
  ok; immediate
  ok
> 0 constant case
  ok
> : of
  ok    1+
  ok    >r
  ok    postpone over postpone =
  ok    postpone if
  ok    postpone drop
  ok    r> ;
  ok
>  immediate
  ok
> : endof
  ok    >r
  ok    postpone else
  ok    r> ;
  ok
>  immediate
  ok
> : endcase
  ok    postpone drop
  ok    0 ?do
  ok      postpone then
  ok    loop ;
  ok
>  immediate
  ok
> : checkout
  ok  case
  ok    0 of ." none" endof
  ok    1 of ." once" endof
  ok    2 of ." twice" endof
  ok    ." unknown"
  ok  endcase
amforth 2.6 ATmega32
>
  ok
> ;
amforth 2.6 ATmega32
> Traceback (most recent call last):
   File "/home/ew/bin/amforth-upload.py", line 232, in ?
     main(sys.argv[1:])
   File "/home/ew/bin/amforth-upload.py", line 228, in main
     write_file_flow(in_file,tty_dev)
   File "/home/ew/bin/amforth-upload.py", line 169, in
write_file_flow
     write_line_flow(line,dest)
   File "/home/ew/bin/amforth-upload.py", line 121, in
write_line_flow
     i = dest.read(1)
KeyboardInterrupt
$