amforth-devel — Development discussion and user support

[Amforth-devel] Wordlist online

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I've made a small tool to generate some html from the assembly
code. The result  against the svn trunk can be read at
amforth.sf.net/words.

What does it do?

It scans all the assembly files and creates a html file
for every definition found. This includes most of the "hidden"
words too. If a given word looks like from a colon defintion
the tokens are reverse compiled to there name and a link to them
is generated. This does not very well work for branches however. Please
ignore the last exit too. General formatting is, well, not very
nice...

The last step is a list, by which other words the current word
is used.


Have fun with it

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF+p2XLo3irIddFw4RAmE+AKDNMcPhNy61mB4jEqUIWatuLLZOpwCdGlau
DC7W6OBp7AN77+58mr0CbpQ=
=fKSC
-----END PGP SIGNATURE-----

Re: [Amforth-devel] formated output

[Ulrich H. <uh...@xl...>]

Hi Joh,

amforth's <# # #> do not work with double cell numbers
but only with single cell numbers. gforth's work with double
cell numbers.

So for gforth you either define

\ gforth
: u.r ( u w -- )  >r       0       <# #s #>  r> over - 0 max spaces  
type ;
5  10 u.r           5 ok

or you use the original definition with double precision numbers:

\ gforth
: ud.r  ( d w -- )   >r  <# #s #>  r> over - 0 max spaces type ;
5. 10 ud.r          5 ok

amforth slightly diverges from Standard Forth behavior here.

Regards,
		Ulli



Am Mar 15, 2007 um 11:38 PM schrieb joe...@t-...:

>
> -----Original Message-----
>> Date: Thu, 15 Mar 2007 20:34:08 +0100
>> Subject: Re: [Amforth-devel] formated output
>> From: Ulrich Hoffmann
>> To: Everything around amforth
>
>>> Is there a possibility in amforth or do I have to make it all
>>> by myself (with <# # #> ....)
>>
>> Hi,
>> for right adjusted number output you often find the words .r or u.r
>> as in:
>>
>> \ amforth
>> : spaces ( u -- ) ?dup if 0 do space loop then ;
>>
>> : u.r ( u w -- )
>>> r  <# #s #>  r> over - 0 max spaces type ;
>
> That leads to a stack underflow (as tested  in gforth)
>
>
>> w specifies the width of the field, where the number is
>> displayed right aligned, like this:
>>
>>> 100 12 u.r
>> 100 ok
>>> 10 12 u.r
>> 10 ok
>>> 1 12 u.r
>> 1 ok
>>>
>>
>
> Thanks for your ideas.
> Greetings
> joh
>
>
>
> ----------------------------------------------------------------------- 
> --
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] formated output

[<joe...@t-...>]

-----Original Message-----
> Date: Thu, 15 Mar 2007 20:34:08 +0100
> Subject: Re: [Amforth-devel] formated output
> From: Ulrich Hoffmann 
> To: Everything around amforth 

> > Is there a possibility in amforth or do I have to make it all
> > by myself (with <# # #> ....)
> 
> Hi,
> for right adjusted number output you often find the words .r or u.r
> as in:
> 
> \ amforth
> : spaces ( u -- ) ?dup if 0 do space loop then ;
> 
> : u.r ( u w -- )
> > r  <# #s #>  r> over - 0 max spaces type ;

That leads to a stack underflow (as tested  in gforth)


> w specifies the width of the field, where the number is
> displayed right aligned, like this:
> 
> > 100 12 u.r
> 100 ok
> > 10 12 u.r
> 10 ok
> > 1 12 u.r
> 1 ok
> > 
> 

Thanks for your ideas.
Greetings
joh

Re: [Amforth-devel] formated output

[<joe...@t-...>]

Hi all,
-----Original Message-----
> Date: Thu, 15 Mar 2007 17:05:49 +0100
> Subject: Re: [Amforth-devel] formated output
> From: Matthias Trute 
> To: Everything around amforth 

> emit sends a single character only. Probably you mean  . (dot).
> This uses the free number format which indeed does not provide
> a field width.

Yes (dot) was the thing I struggle with. Emit only for the right side of
the
dump - the ASCII print.

> 
> > Is there a possibility in amforth or do I have to make it all
> > by myself (with <# # #> ....)
> 
> What's wrong with " : my. hex <# # # # # #> type" ?

should work, I'll try it this weekend.
Thank you
joh

Re: [Amforth-devel] formated output

[Ulrich H. <uh...@xl...>]

> Is there a possibility in amforth or do I have to make it all
> by myself (with <# # #> ....)

Hi,
	for right adjusted number output you often find the words .r or u.r
as in:

\ amforth
: spaces ( u -- ) ?dup if 0 do space loop then ;

: u.r ( u w -- )
      >r  <# #s #>  r> over - 0 max spaces type ;

w specifies the width of the field, where the number is
displayed right aligned, like this:

 > 100 12 u.r
                100 ok
 >  10 12 u.r
                 10 ok
 > 1 12 u.r
                  1 ok
 >


Regards,
		Ulli

Re: [Amforth-devel] formated output

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joerg,

> fact that we have not the possibility to EMIT all the numbers
> with equal amounts of decimals...

emit sends a single character only. Probably you mean  . (dot).
This uses the free number format which indeed does not provide
a field width.

> Is there a possibility in amforth or do I have to make it all 
> by myself (with <# # #> ....)

What's wrong with " : my. hex <# # # # # #> type" ?

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF+W7dLo3irIddFw4RAjsqAJ9GRKdeaJPHBap/w+piiCvQOT0CnQCfTq7H
FDWDJU7hn0Iy7rEouUwKdkY=
=6DKV
-----END PGP SIGNATURE-----

[Amforth-devel] formated output

[<joe...@t-...>]

Hi all,

I wrote a word dump, to look around in the memory (s).
Unfortunately the output is not column by column due the
fact that we have not the possibility to EMIT all the numbers
with equal amounts of decimals...
Is there a possibility in amforth or do I have to make it all 
by myself (with <# # #> ....)

greetings
joh

Re: [Amforth-devel] LEAVE?

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans,

Hans H=FCbner schrieb:
>=20
> will LEAVE be implemented?

will: yes. when: sometimes....

leave has the problem that it will need
more work in [+]loop to resolve the (possibly
many) jump references it causes.

> Or is there a different way to leave a
> loop in amforth?

not directly.

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF96q5Lo3irIddFw4RAgydAJsGDXKqR2oHZkv1K+wH+MrLpM/6KACgqYqc
X1dyfyyTdYnzgwDxHL/MLqU=3D
=3DONdP
-----END PGP SIGNATURE-----

[Amforth-devel] LEAVE?

[<ha...@hu...>]

Hi,

will LEAVE be implemented?  Or is there a different way to leave a
loop in amforth?

-Hans

Re: [Amforth-devel] Set hook from word / Timers / Praise!

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Hans,

Hans H=FCbner schrieb:
> Am 13.03.07 schrieb Hans H=FCbner <ha...@hu...>:
>> For fun, I have connected a four digit 7 segment display to my
>> ATMEGA32 running at 16 Mhz.  The display is multiplexed in two pairs,
>> so I need to refresh fast enough to get a stable display.  To do so, I
>> use TIMER0 with the overflow interrupt mapped to vector three.  I
>> prescale the timer by 256, thus my interrupt handler is called at
>> about 240 Hz.  It just works.  Also, I have observed no anomalies
>> working in immediate mode while my display refresh was active, so I
>> could still compile works.  What a gas!  Great stuff :)
>=20
> Just an observation:  While compiling, the display flickers.  It seems
> that IRQs are being disabled during flash programming, which is a good
> thing.

This is really a good news. In my tests the controller always
freezes when the flash gets written. I should re-do the tests...

Thanks+Bye
Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF9wR5Lo3irIddFw4RAn0AAJ4n9ysiK35Hr5tRC3/lanaG05PRRwCZAX6E
PDMTYIEDg/N43uA/0bI2Cnc=3D
=3DJSRh
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Set hook from word / Timers / Praise!

[<ha...@hu...>]

Am 13.03.07 schrieb Hans H=FCbner <ha...@hu...>:
> For fun, I have connected a four digit 7 segment display to my
> ATMEGA32 running at 16 Mhz.  The display is multiplexed in two pairs,
> so I need to refresh fast enough to get a stable display.  To do so, I
> use TIMER0 with the overflow interrupt mapped to vector three.  I
> prescale the timer by 256, thus my interrupt handler is called at
> about 240 Hz.  It just works.  Also, I have observed no anomalies
> working in immediate mode while my display refresh was active, so I
> could still compile works.  What a gas!  Great stuff :)

Just an observation:  While compiling, the display flickers.  It seems
that IRQs are being disabled during flash programming, which is a good
thing.  Other than that, the timer driven refresh code has now been
running for several hours without a hitch.

-Hans

Re: [Amforth-devel] Set hook from word / Timers / Praise!

[<ha...@hu...>]

2007/3/13, Matthias Trute <mt...@we...>:
> Hans H=FCbner wrote:
> > Also, on the home page under Bugs, "Using timer interrupt may cause
> > strange effects." is mentioned.  I would like to use a timer to
> > refresh my multiplexed LED display, can you let me know what the
> > "strange effects" are?
>
> If the frequency is too high (say 100Hz on a 16MHz controller) the
> controller stops responding. And regardless of the frequency you are not
> able to use the flash write operation i! and all words using it. I have
> no idea why it happens...

For fun, I have connected a four digit 7 segment display to my
ATMEGA32 running at 16 Mhz.  The display is multiplexed in two pairs,
so I need to refresh fast enough to get a stable display.  To do so, I
use TIMER0 with the overflow interrupt mapped to vector three.  I
prescale the timer by 256, thus my interrupt handler is called at
about 240 Hz.  It just works.  Also, I have observed no anomalies
working in immediate mode while my display refresh was active, so I
could still compile works.  What a gas!  Great stuff :)

-Hans

If anyone's interested:

I had to patch devices/atmega32.asm:

.org=09OVF0addr ; Overflow0 Interrupt Vector Address
    rjmp int3_isr

\ Ansteuerung der vierstelligen 7-Segment-Anzeige

\ Port A =3D> 1. und 3. Stelle
\ Port B =3D> 2. und 4. Stelle
\ Port C =3D> Bit 0: 1. und 2. Stelle ausw=E4hlen
\           Bit 1: 3. und 4. Stelle ausw=E4hlen
\           Bit 1 und 3 d=FCrfen nicht gleichzeitig auf 1 gesetzt werden!

decimal

\ Tabelle f=FCr die Umsetzung von Ziffern in Bits f=FCr die 7-Segment-Anzei=
ge

create 7seg-digit-map
 63 invert ,   6 invert ,  91 invert ,  79 invert ,
102 invert , 109 invert , 125 invert ,   7 invert ,
127 invert , 111 invert ,

\ Umrechnen einer Ziffer in Bits f=FCr die 7-Segment-Anzeige

: 7seg-digit ( n -- m )
    7seg-digit-map 1+ + i@
;

\ Variable f=FCr die aktuell angezeigten Display-Bits

0 variable display 3 allot

\ Eine Zahl ins Display-Register schreiben
: set-display ( n -- )
    4 0 do
        10 /mod
    loop
    drop
    7seg-digit display 3 + c!
    7seg-digit display 2 + c!
    7seg-digit display 1 + c!
    7seg-digit display     c!
;

\ Initialisieren der Schnittstelle zum Display
: init-display

    \ Erst mal die Bits so einstellen, da=DF alle LEDs aus sind
    255 PORTA c!
    255 PORTB c!
    0 PORTC c!
    \ Jetzt die Datenrichtungsregister setzen, so da=DF die
entsprechenden Bits alle
    \ als Ausgang konfiguriert sind.
    255 DDRA c!
    255 DDRB c!
    7 DDRC c!
;

\ Aktuell aktive Display-H=E4lfte
0 variable field

\ Wechseln der Display-H=E4lfte und anzeigen der passenden Ziffern.  Jedes
\ Mal, wenn das Wort refresh-display aufgerufen wird, wird wird das Display
\ umgeschaltet.  Wenn man refresh-display schnell genug hintereinander aufr=
uft,
\ ergibt sich ein stehendes Bild.
: refresh-display ( -- )
    0 PORTC c!
    field c@
    dup if
        display     c@ PORTA c!
        display 1 + c@ PORTB c!
        2 PORTC c!
    else
        display 2 + c@ PORTA c!
        display 3 + c@ PORTB c!
        1 PORTC c!
    then
    not field c!
;

\ Demo f=FCr refresh-display
: refresh-display-demo ( -- )
    begin
        refresh-display
        1ms
    key? until
    key drop
;

\ Anzeige aller vier Ziffern im Hintergrund.  Die Umschaltung erfolgt
\ durch den Timer-Interrupt.
: start-display ( -- )
    init-display
    0 set-display

    ['] refresh-display 3 intvector !

    \ Timer clock =3D> sysclk / 256
    4 TCCR0 c!
    \ Timer0 einschalten
    1 TIMSK c!
;

: count ( -- )
    10000 0 do
        i set-display
        1ms
    loop
;

Re: [Amforth-devel] Set hook from word / Timers / Praise!

[<ha...@hu...>]

2007/3/13, Hans H=FCbner <ha...@hu...>:
> On the web page, it is descibed that
>
> ' mypause 'pause !
>
> sets the pause hook to the word mypause.  That works just fine from
> immediate mode, but not from within another word.  How would I achieve
> the same thing from within another word?

I checked the ANS specification
(http://www.taygeta.com/forth/dpans.htm) and found the answer myself,
['] in a word definition does what ' does in immediate mode, so my
code now reads

: start-display ( -- )
    init-display
    0 set-display
    ['] refresh-display 'pause !
;

-Hans

[Amforth-devel] Set hook from word / Timers / Praise!

[<ha...@hu...>]

Hi Matthias,

I have a forth and an amforth question:

On the web page, it is descibed that

' mypause 'pause !

sets the pause hook to the word mypause.  That works just fine from
immediate mode, but not from within another word.  How would I achieve
the same thing from within another word?

Also, on the home page under Bugs, "Using timer interrupt may cause
strange effects." is mentioned.  I would like to use a timer to
refresh my multiplexed LED display, can you let me know what the
"strange effects" are?

I love amforth!  Being able to iteratively develop on the AVR is so much fun!

Thanks!
Hans

Re: [Amforth-devel] Constant array?

[<ha...@hu...>]

2007/3/12, Matthias Trute <mt...@we...>:
> > I need to create a lookup table in Flash which will be used to
> > translate decimal digits to 7 segment display digits.
> >
> > In a RAM-based forth, I could write something like
> >
> > table constant -2 allot

Oops, I guess I really meant to write

0 constant table -2 allot

> a quick solution would be
>
> > create table
>  ok
> > 1 , 2  , 3 , 4 , 5 , 6 ,
>  ok
> > 1 table + i@ .
>  1 ok
> > 2 table + i@ .
>  2 ok
> > 6 table + i@ .
>  6 ok

So your example creates an array with indices starting at 1 instead of
0, but that will do.  Thanks a lot!

-Hans

Re: [Amforth-devel] Constant array?

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans,

> I need to create a lookup table in Flash which will be used to
> translate decimal digits to 7 segment display digits.
>=20
> In a RAM-based forth, I could write something like
>=20
> table constant -2 allot
> 63 , 6 , 91 , 79 , 102 , 109 , 125 , 7 , 127 , 111 ,
>=20
> This would (as far as I understand) a base pointer table that pointed
> to the 63, with the other values following.

Your code initializes a constant named -2 with the value the word table
leaves (or your base value is at least char T). After that it will
allocate an unknown amount of space in RAM and finally compiles the
values into the dictionary

> How would I do this with amforth?  As far as I can read from the
> source code, allot acts on the heap (RAM) pointer.  Is there something
> equivalent to allot that acts on the current dictionary pointer?

You have to set the dp manually (with e@ and e!)

> I would be willing to waste one byte for each entry in the table and us=
e
> 16 bits for each, but i=B4d like to easily access the base pointer of
> the table.

a quick solution would be

> create table
 ok
> 1 , 2  , 3 , 4 , 5 , 6 ,
 ok
> 1 table + i@ .
 1 ok
> 2 table + i@ .
 2 ok
> 6 table + i@ .
 6 ok
>

Bye
Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF9QgVLo3irIddFw4RAg7LAKCRsRMkSPkQPUhc20tbS6TDhj9OvgCgvAO7
+AdlHdBspr32EXMw7NRXYBs=3D
=3Dikw9
-----END PGP SIGNATURE-----

[Amforth-devel] Constant array?

[<ha...@hu...>]

Hi,

(I am a beginner in Forth, so please excuse me if the question is stupid).

I need to create a lookup table in Flash which will be used to
translate decimal digits to 7 segment display digits.

In a RAM-based forth, I could write something like

table constant -2 allot
63 , 6 , 91 , 79 , 102 , 109 , 125 , 7 , 127 , 111 ,

This would (as far as I understand) a base pointer table that pointed
to the 63, with the other values following.

How would I do this with amforth?  As far as I can read from the
source code, allot acts on the heap (RAM) pointer.  Is there something
equivalent to allot that acts on the current dictionary pointer?  I
would be willing to waste one byte for each entry in the table and use
16 bits for each, but i=B4d like to easily access the base pointer of
the table.

Thanks!
Hans

Re: [Amforth-devel] python uploading script

[pix <pi...@te...>]

On Fri, Mar 09, 2007 at 09:01:24AM +0100, Matthias Trute wrote:
> Limit the number of characters sent per second to some adjustable
> value

actually, why would this be necessary? has anyone encountered the
buffers getting overloaded with the echo-tracking flow control scheme?

if you just want to send characters slowly, there is pv, and ascii-xfr
(comes with minicom, alows separate character/line delays).

the idea of amforth-upload was to upload as fast as possible without
overloading amforth.

.. and timing is a pain to implement ;)

pix.

Re: [Amforth-devel] python uploading script

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pix schrieb:
> On Fri, Mar 09, 2007 at 09:01:24AM +0100, Matthias Trute wrote:
>> Limit the number of characters sent per second to some adjustable
>> value
> 
> actually, why would this be necessary? has anyone encountered the
> buffers getting overloaded with the echo-tracking flow control scheme?

As I wrote: Those are wishes other users wrote to me, maybe not related
directly with your tool. personally I think that your scheme is quit
good, I cannot imagine how it can overload the amforth buffers (I do
hope that someday a "real" flow control will work).

Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF8VGQLo3irIddFw4RAtK5AJ9x5Gm1J8D0o8OYwQSZbR3DOR3qIQCfSUHz
rAdiWuJH9SbKcLS6ddNf4NA=
=Tu15
-----END PGP SIGNATURE-----

Re: [Amforth-devel] python uploading script

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Pix,

> would it be to ugly to have the script implement "INCLUDE" and
> "INCLUDE?" on it's side?

I see no other place to implement it. If amforth sees these instructions
it will abort.

>> If amforth signals an abort instead of the ok the script should stop
>> uploading.
> 
> do you mean, any of the error messages starting with "??" ?

Yes.

>> Limit the number of characters sent per second to some adjustable value
> 
> hmmm. doable i guess. 
> 
> i was wondering, would there be any value in sending a few more
> characters than have been echoed back? is there any kind of buffer?

there are two buffers: usart receive buffer (16 characters long) and the
forth TIB (80 characters). Only the characters in the TIB had echos
back to the serial line (except some control characters). The usart
buffer keeps the "unread" characters that wait for the next execution
of key. I'm not fully satisfied with it but it works "good enough",
at least for me....

> i was thinking the script at the moment might be too cautious.

That's impossible ;=)

Bye
Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF8RRULo3irIddFw4RAhGlAJwMSYRYj410g+2M/zfsLqC6HI93eQCgyc9c
6Tg4X0S92vVOpRa7r2sESSg=
=comk
-----END PGP SIGNATURE-----

Re: [Amforth-devel] python uploading script

[pix <pi...@te...>]

On Thu, Mar 08, 2007 at 09:21:45PM +0100, Matthias Trute wrote:
> Hi Pix,
> 
> > is there any kind of accepted standard for forth
> > pre-processor syntax?
> 
> None I'm aware, but a few users wrote me in PM some wishes:

would it be to ugly to have the script implement "INCLUDE" and
"INCLUDE?" on it's side?

> If amforth signals an abort instead of the ok the script should stop
> uploading.

do you mean, any of the error messages starting with "??" ?

> Limit the number of characters sent per second to some adjustable value

hmmm. doable i guess. 

i was wondering, would there be any value in sending a few more
characters than have been echoed back? is there any kind of buffer? i
was thinking the script at the moment might be too cautious.

i noticed it's also possible to add the script as an upload protocol in
minicom. you need to set the -f option so that it doesn't check to see
who else has the tty open.

> I've added a link to your site in the FAQ.

oh, thanks.

pix.

Re: [Amforth-devel] python uploading script

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Pix,

> is there any kind of accepted standard for forth
> pre-processor syntax?

None I'm aware, but a few users wrote me in PM some wishes:

If amforth signals an abort instead of the ok the script should stop
uploading.

Limit the number of characters sent per second to some adjustable value


I've added a link to your site in the FAQ.

Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF8HBZLo3irIddFw4RAu7VAKDApeaPBKVWL22fNKwiUPTT/0X/KgCggG+U
iIHA90f9sYGN3PdiGCZmyNM=
=6UCu
-----END PGP SIGNATURE-----

[Amforth-devel] Windows Terminal for amForth

[Marcel D. <mde...@my...>]

Hi Windows users,
Assembling amForth 1.3 with AVRStudio under Windows

Since I own a test board with an atmega32, all the following hints refer to this controller and its
related source files. They should be usable to the other controllers too, by replacing 'mega32'
files with 'megaxx' where applicable. As for the moment I have not tested any of them.

Assembling original source files with AVRASM2 in Atmel AvrStudio 4.12 yields the following errors:
(numbered 1. to 5.)

1. Invalid redifinition of 'RWWSRE'   in atmega32.asm (line 16)
2. Invalid redifinition of 'UDR0'     in atmega32.asm (line 22)

   These values are defined in m32def.inc in the first place (file comes with AVRStudio);

   Resolved by commenting out line 16 in atmega32.asm, by commenting out line 22 in atmega32.asm
   and by replacing UDR0 with UDR in uasrt.asm source file. (m32def.inc is a system file and must
   not be altered).

      A fix should replace UDR0 in atmega32.asm with a new definition (e.g. UDR_0)
      or replace UDR0 with UDR in amForth sources.
      References to UDR0 are in:
        atmega8.asm
        atmega16.asm
        atmega32.asm
        atmega168.frt
        usart.asm
      I replaced UDR0 by UDR (24feb07)!

3. Undefined label TWSIaddr in atmega32.asm (line 68)

   Resolved by changing TWSIaddr into TWIaddr in line 68

4. Overlapping of object code in cseg in usart.asm (line 10)
5. Overlapping of object code in cseg in usart.asm (line 12)

   Atmels assembler does not accept different code sequences for the same address range (imho this
   is bad practice anyway).

   Resolved by commenting out several lines in usart.asm (lines 6..14) like this:

    /* .set pc_ = pc

    .org URXCaddr
      rjmp usart0_rx_isr
    .org UDREaddr
      rjmp usart0_udre_isr

    .org pc_ */

   and by modifying interrupt vectors in atmega32.asm:
    .org        URXCaddr ; USART Receive Complete Interrupt Vector Address
        rjmp usart0_rx_isr
    .org        UDREaddr ; USART Data Register Empty Interrupt Vector Address
        rjmp usart0_udre_isr

   I modestly think the interrrupt vectors belong in atmega32.asm rather than in usart.asm.


The resulting code assembles with no error and runs on my test board.

Note: in AvrStudio you must manually save any changed files before a new build!

Corrections above yield the following values (e.a.):

EQU  URXCaddr     0000001a
EQU  UDREaddr     0000001c
EQU  RWWSRE       00000004
EQU  UDR          0000000c
EQU  UDR0         00000000 ; These seem to be correct.

Any feedback welcome!

md 24feb07, 03mar07

-- 
derri

Re: [Amforth-devel] Windows Terminal for amForth

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Marcel Derrmann wrote:

> AmForth is not limited to Linux users. Although the sources are
> written for the avra assembler, you can build amForth with Atmels
> AVRStudio, after half a dozen of minor changes. If there is interest,
> I can mail or post my approach.

Please do so.

Most (all?) of the changes are due the fact that avra (the linux
assember I use) does not understand the avrasm2 syntax. The include
files from avrasm1 and avrasm2 do not contain the same definitions.
For whatever reason...


> What about including the hex target files in the amForth download?

They can only be used for a very limited range of hardware platforms.
Even such an trivial change as the oszillator frequency needs a
rebuild. For this reason I do not publish hexfiles. Future versions
for specific target may have hexfiles, the AVR butterfly or "my"
little robots are candidates for this.

Bye
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF6+StLo3irIddFw4RAhvHAKCLPsmjNGeI9pdNypZzmnRELd+v0QCfaRP4
Jtj0f35u/50nsbGcf7GtSn0=
=W9Gg
-----END PGP SIGNATURE-----

[Amforth-devel] New release 1.4

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I've just compiled release 1.4 of amforth before the changelog
is getting too long ;=)

It contains a few new words..

abort" ( f -- ) prints the string and aborts if flag permits
unused ( -- n)  returns the number of unsed flash cells
                  (multiply with 2 and you get the number of
                   bytes)

.. some words changed ..

pad does no longer have it's own ram space. It is now located
at and above heap. please note, that word uses pad too.

case & co are now in an optional compile-time dictionary. This
dictionary is intended to be used for "bigger" atmegas and
contains some other words like d+ d- etc.

quit has some internal changes (see abort") and any thrown
exception will do abort too.

/mod is changed from usigned division to signed (symmetric)
/ and mod depend on it and have changed therefore too. The
old /mod may re-appear as u/mod in the optional dictionary
if needed.

serial flow control (xonxoff) still does not work, it is not
included in this release.



Have fun with it

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF6+DILo3irIddFw4RAuddAJ4yN4feuhKwsitWCQmWxO5j4wF67wCguFV/
TCnsvbExWprrDLjueyr/OdM=
=ZkTm
-----END PGP SIGNATURE-----