amforth-devel — Development discussion and user support

[Amforth-devel] For - next vs Do - Loop

[D W. <dou...@ya...>]

> I've tried FlashForth recently (have a
look on it - a lot of ineresting features you may utilise), however
the creator does insist on FOR NEXT instead of DO LOOP. Frankly, I
do not understand that..Pito

The creator of forth feels that FOR - NEXT is significantly more efficient than DO - LOOP.  Unfortunately, I have no luck google-ing the exact page I wish to reference, but here is a page that quotes Moore

<chipChuck> FOR NEXT is much simpler than DO LOOP, especially for hardware implementation

http://tom.bespin.org/src/old/Chuck%20Moore%205-4-02.txt

Since forth is Moore's personal tool, he does whatever he wishes, and others chose to follow or not.  All implementations are considered simultaneously 'correct' if they do what they are intended, and 'incorrect' if they differ from Chuck.  And Chuck tends change his mind as he sees fit, and doesn't always tell anyone, so nobody really worries. The result is many different 'flavors' of forth. 

Doug Williams CSQE



      

Re: [Amforth-devel] amforth - how to make him case insensitive

[<an...@ki...>]

Umm I prefer languages and OS's to be case sensitive.

(I guess being a unix/linux type of guy)

In forths case the case sensitivity gives you more scope to create words
that are named meaningfuly.

If you are operating case insensitive you have less combinations
available to you when making words and are more likely to end up naming
your forth functions and subroutines with soemthing that is meaningless.
just because you are running out of options (particularly when trying to
think of a new word name on the fly, without digging out a dictionary).

It's arithmetic really, this is why passwords that use upper and lower
case on case sensitive systems are far more secure. (combinatorial
explosion)

However....

There is perhaps an argument for adopting a case styling convention for
word names that differs from say variable names to help code readability.

What that stylistic convention could be I am not going to get into. It
is a very easy way to promote a mass brawl as firmly held preferences
vary so widely. Casing though is one of many options.

Thoughts for what they are worth...



On 29/07/10 18:16, Matthias Trute wrote:
> Pito,
> 
> 
>> when you do insist on case sensitivness than do make the forth words
>> uppercase...
> 
> Why do you think I insist on case sensitivness? Case sensitivness
> is simpler to implement (take it as an axiom if you do not believe
> it). Its very easy do write a converter in any language on the PC 
> side, even windows VBS can do that:
> 
> Dim upper as String = "converted from lowercase" 
> Console.WriteLine(upper.ToUpper())
>     Console.WriteLine(UCase(upper))
>     Console.WriteLine(StrConv(upper,VbStrConv.UpperCase))
> 
> not to mention the many unix tools like tr...
> 
>> Who actually needs case sensitive forth?? 
> 
> I do and will do so for the next few months, at least.
> 
>> PS: It is interesting how the creators of such
>> nice sw implementations do insist on something, which an average
>> user does not understand.. I've tried FlashForth recently (have a
>> look on it - a lot of ineresting features you may utilise), however
>> the creator does insist on FOR NEXT instead of DO LOOP. Frankly, I
>> do not understand that..
> 
> Thats life. And FF is interesting, indeed.
> 
> 
> Matthias
> 
> PS: If _you_ insist on case insensitivness, feel free to send a 
> patch, that I can consider to include into amforth. Thats the way Open
> Source Software works and thats the reason why I share amforth with 
> other people
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> 
> 
> 
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] amforth - how to make him case insensitive

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

Pito,


> when you do insist on case sensitivness than do make the forth words
> uppercase...

Why do you think I insist on case sensitivness? Case sensitivness
is simpler to implement (take it as an axiom if you do not believe
it). Its very easy do write a converter in any language on the PC 
side, even windows VBS can do that:

Dim upper as String = "converted from lowercase" 
Console.WriteLine(upper.ToUpper())
    Console.WriteLine(UCase(upper))
    Console.WriteLine(StrConv(upper,VbStrConv.UpperCase))

not to mention the many unix tools like tr...

> Who actually needs case sensitive forth?? 

I do and will do so for the next few months, at least.

> PS: It is interesting how the creators of such
> nice sw implementations do insist on something, which an average
> user does not understand.. I've tried FlashForth recently (have a
> look on it - a lot of ineresting features you may utilise), however
> the creator does insist on FOR NEXT instead of DO LOOP. Frankly, I
> do not understand that..

Thats life. And FF is interesting, indeed.


Matthias

PS: If _you_ insist on case insensitivness, feel free to send a 
patch, that I can consider to include into amforth. Thats the way Open
Source Software works and thats the reason why I share amforth with 
other people

Re: [Amforth-devel] amforth - how to make him case insensitive

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

Matthias,
when you do insist on case sensitivness than do make the forth words
uppercase... There are tons of sw and libraries on the web you
cannot run easily as they are uppercase... Who actually needs case
sensitive forth?? PS: It is interesting how the creators of such
nice sw implementations do insist on something, which an average
user does not understand.. I've tried FlashForth recently (have a
look on it - a lot of ineresting features you may utilise), however
the creator does insist on FOR NEXT instead of DO LOOP. Frankly, I
do not understand that..Pito
----- PŮVODNÍ ZPRÁVA -----
Od: "Matthias Trute" <mt...@we...>
Komu: "Everything around amforth"
<amf...@li...>Předmět: Re: [Amforth-devel] amforth - how to make him case
Datum: 28.7.2010 - 20:26:22

> Hi,
> 
> > Hi friends,
> > is there any trick how to make him Case
> > insensitive?
> amforth is case sensitive, I may change that
> sometimes,but now. A quick fix is a simple case converter,
> like perl or tr, but I do not know about such
> toolsfor Windows ;=)
> 
> PS: the python scripts could do the job as well,
> there are python build-in functions to convert
> case, but see above not for Windows...
> 
> maybe VBS or javascript could be used as well...
> 
> Matthias
> 

Re: [Amforth-devel] Variable and 2variable space in ram, .res info

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

Am Montag, den 26.07.2010, 18:05 +0200 schrieb pito: 
> Hi, 
> why a variable xxx occupies 2 cells? (when observing with ".res"
> word) and 2variable 4 cells? (with the definition -> : 2variable
> here 2 cells allot constant ; ).OR: does .res returns # of Bytes instead of cells?

.res prints usually bytes, the cells are misleading at all. Will fix
ASAP

Matthias

Re: [Amforth-devel] amforth - how to make him case insensitive

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

Hi,

> Hi friends,
> is there any trick how to make him Case insensitive?

amforth is case sensitive, I may change that sometimes,
but now. A quick fix is a simple case converter,
like perl or tr, but I do not know about such tools
for Windows ;=)

PS: the python scripts could do the job as well,
there are python build-in functions to convert
case, but see above not for Windows...

maybe VBS or javascript could be used as well...

Matthias

[Amforth-devel] Variable and 2variable space in ram, .res info

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

Hi, 
why a variable xxx occupies 2 cells? (when observing with ".res"
word) and 2variable 4 cells? (with the definition -> : 2variable
here 2 cells allot constant ; ).OR: does .res returns # of Bytes instead of cells?

> .res
free FLASH cells      9628 
free RAM cells        1754 
used EEPROM cells     62 
used data stack cells 0 
used return stack     10 
free return stack     70 
ok
> 2variable diameter
ok
> .res
free FLASH cells      9620 
free RAM cells        1750 
used EEPROM cells     62 
used data stack cells 0 
used return stack     10 
free return stack     70 
ok
>  variable aaa
ok
> .res
free FLASH cells      9614 
free RAM cells        1748 
used EEPROM cells     62 
used data stack cells 0 
used return stack     10 
free return stack     70 
ok

Thanks, pito.

[Amforth-devel] amforth - how to make him case insensitive

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

Hi friends,
is there any trick how to make him Case insensitive? There is a lot
of examples with uppercase words, however amforth rejects such
sources..Thanks, Pito.

[Amforth-devel] Forfiter 1.4 - still a speed issue, Mosaic Terminal

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

Hi, I've tried the new Forfiter 1.4. Unfortunately it still does not
work at 115200. I'am using the MosaicTerminal v1.27 now. It supports
Forth upload and does work fine at 115200. Pito

Re: [Amforth-devel] Beginner's experience

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

Pito,

At first: Thank you ver much for sharing your experience with us (me).
I highly appreciate it!

> I got a dev system which is fully stable (usb usart and usb programmer,
> Avr Studio, Avrdude, XP SP3). So I am a win user who does not fit into
> the community (:-)..

Hey, despite the fact that I prefer Linux does not mean its unusual to
use different program starting environments ;=)

> I found Forfiter, which enabled me to upload (however it works with 
> 19k2 max) as it has ok commit. 

Lubos told recently me that he has published a new version of his tool. 
And that he does not use high speed transfers ;=)

> I do not have access to python and pearl scripts (XP Python incompatibility)so
> the only way is to upload the required frts (marker, 2x, atmega32 reg
> def, etc)each time again. Then marker - dev and I tried again. When
> happy and none crash I used -dev to start again without a reflash.

You can not only upload a hex file to the controller but also download
the flash/eeprom from the controller. That I do so from time to time..


> The biggest problem for me (a beginner) is the "OS" ruggedness and support.
> The new words might be available on net, but the OS is hardwired. Words
> like .s and .res did not help me much, so I did mostly "try and error"
> wise, with frequent reflashing the rom. Many times the systems stoped
> response after running the new word and I lost the acces to the system.
> Even hardware reset did not help.

Sounds familiar :=( Any idea for a debugger? It has to be small, and
minimal invasive and fool proof..

> The ctrl-C for return to interpreter, or ctrl-Q for a soft reset would
> be
> really necessary. Also some stack overflow exception with a return to
> prompt would be a nice feature.

I usually press a reset button. Works almost all of the time. But see
above: any ideas (and code of course) for a debugger are welcome.

> Maybe the current linux toolchain is more advanced, however the development
> process with amforth and my XP tools is a challenge for a beginner (not
> speaking about a good simulator..)

The linux toolchain is absolutly mine, I think I'm the only one who
uses ant for calling a windows assembler with it. Feel free to send
patches/documentation/howtos to do it better. I just hacked
an ugly screenshot series to document the avr studion usage, but I'd not
really recommend it.

> PS: Any plans for amforth 32bit with float??

Not currently. Maybe someone want to volonteer?

Matthias

Re: [Amforth-devel] devices

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

Ian,

> For devices does AVRA only need to support the following in order to
> support AMForth?
>
> at90can128	atmega168	atmega32	atmega644	atmega88
> atmega1280	atmega169	atmega328p	atmega644p	atxmega128a1
> atmega16	atmega2561	atmega640	atmega8
>
> This is just a listing from the amforth-cur/releases/4.0/core/devices
> directory.

Well this is a list of known-good devices. amforth should run on any
Atmega with at least 8KB flash memory.

Matthias

[Amforth-devel] devices

[Ian J. <ij...@sa...>]

OK,

I think this is a dumb question but ... I once met a Rhodes Scholar that asked similar questions... just before she became a Rhodes Scholar.  Anyway here goes.

For devices does AVRA only need to support the following in order to support AMForth?

at90can128	atmega168	atmega32	atmega644	atmega88
atmega1280	atmega169	atmega328p	atmega644p	atxmega128a1
atmega16	atmega2561	atmega640	atmega8

This is just a listing from the amforth-cur/releases/4.0/core/devices directory.

Ian
ij...@sa...

Re: [Amforth-devel] My issue with 2variable in int_isr

[<an...@ki...>]

I don't know about the tronics but I certainly loose the urge to try.

On 09/07/10 19:58, pito wrote:
> Does your dev system stop working when outside 30degC? (:-))). P.
> 
> ----- PŮVODNÍ ZPRÁVA -----
> Od: "Matthias Trute" <mt...@we...>
> Komu: "Everything around amforth" <amf...@li...>
> Předmět: Re: [Amforth-devel] My issue with 2variable in int_isr
> Datum: 9.7.2010 - 20:26:08
> 
>> Hi Pito,
>>
>>
>>> it crashes in such a way I have to reflash rom to
>>> get access to system.
>>>> What is the trick here?
>>
>> Well, it crashes outside of any interrupt as well.
>> I've got
>> no idea why so far. And it's way too hot outside...
>>
>> Sorry
>> Matthias
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth-devel] My issue with 2variable in int_isr

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

Does your dev system stop working when outside 30degC? (:-))). P.

----- PŮVODNÍ ZPRÁVA -----
Od: "Matthias Trute" <mt...@we...>
Komu: "Everything around amforth" <amf...@li...>
Předmět: Re: [Amforth-devel] My issue with 2variable in int_isr
Datum: 9.7.2010 - 20:26:08

> Hi Pito,
> 
> 
> > it crashes in such a way I have to reflash rom to
> > get access to system.
> > > What is the trick here?
> 
> Well, it crashes outside of any interrupt as well.
> I've got
> no idea why so far. And it's way too hot outside...
> 
> Sorry
> Matthias
> 

Re: [Amforth-devel] My issue with 2variable in int_isr

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

Hi Pito,


> it crashes in such a way I have to reflash rom to get access to system.
> What is the trick here?

Well, it crashes outside of any interrupt as well. I've got
no idea why so far. And it's way too hot outside...

Sorry
Matthias

[Amforth-devel] My issue with 2variable in int_isr

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

Hi dear friends,
when I enable interrupt this works well:

decimal
2variable ticker
variable seconds
262144. 2constant clkpi    ( clks per interrupt = 256*prescaler )
1. ticker 2!
0 seconds !
\ overflow2 interupt service routine
\ ! not optimised yet
: tick_isr
ticker 2@ clkpi d- ticker 2!
ticker 2@ clkpi d< if  f_cpu ticker 2@ d+ ticker 2!
1 seconds +!
then ;

However with 2variable "seconds" definition:

decimal
2variable ticker
2variable seconds
262144. 2constant clkpi    ( clk per interrupt = 256*prescaler )
1. ticker 2!
0. seconds 2!
\ overflow2 interupt service routine
\ ! not optimised yet
: tick_isr
ticker 2@ clkpi d- ticker 2!
ticker 2@ clkpi d< if  f_cpu ticker 2@ d+ ticker 2!
1. seconds 2@ d+ seconds 2!
then ;

it crashes in such a way I have to reflash rom to get access to system.
What is the trick here?
I've tried
: 2variable create 0 , 0 , ;
as well as
: 2variable here 2 cells allot constant ;
Thanks a lot,
Pito

[Amforth-devel] Beginner's experience

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

Hi dear friends,
as the amforth is a nice gadget worth of consideration, let me summarise

my beginner's first impression I've got after few evenings with it (and
forth). It is my second attempt to learn and utilise it, the first I
did was in '82 as I had built my first ucomputer (8085 based).

I got a dev system which is fully stable (usb usart and usb programmer,
Avr Studio, Avrdude, XP SP3). So I am a win user who does not fit into

the community (:-)..

The install of the fresh amforth from the template was easy, some editing
of template was required (see my earlier posts). Then I started my
learning process by trying the examples. None .py tools used.

Here I learned the dict* files needs to be enhanced by several words

in .asm, in order to start with. The upload of .frt for atmega32 and

other words needed was not easy as of the delay required. Hyperterminal
is of no use. After long tweaking and 20 reflashes (because of hangs)
I found Forfiter, which enabled me to upload (however it works with 
19k2 max) as it has ok commit. 

It seems there is no check whether a word has been uploaded correctly,
so it happened the words were uploaded partially because of a missing

definition following an abort of the upload. However the word
appeared in wordlist. So I had many new words. And sometimes I had
to reflash because of a hang. 

When I tried a small routine within an interrupt routine I need to 
reflash at least 15 times to get it stable (I think because
of stackoverun and resulting crashes - no prompt, thus reflash). So the
development cycle was longer as with C or asm.

I do not have access to python and pearl scripts (XP Python incompatibility)so
the only way is to upload the required frts (marker, 2x, atmega32 reg
def, etc)each time again. Then marker - dev and I tried again. When
happy and none crash I used -dev to start again without a reflash.

The biggest problem for me (a beginner) is the "OS" ruggedness and support.
The new words might be available on net, but the OS is hardwired. Words
like .s and .res did not help me much, so I did mostly "try and error"
wise, with frequent reflashing the rom. Many times the systems stoped
response after running the new word and I lost the acces to the system.
Even hardware reset did not help.

The ctrl-C for return to interpreter, or ctrl-Q for a soft reset would
be
really necessary. Also some stack overflow exception with a return to
prompt would be a nice feature.

Simple an ability to run a word and interrupt it anytime with a return

to prompt is higly required. So the main differentiator against others
shall be the blackbox is bullet proof and always responsive. I do not
know
how to achieve that (maybe an OS interrupt with highest priority always
checking the incoming RX escape sequences.. e.g. every system tick..).
The amforth, from my understanding, will never be used by someone for
extreme time critical applications, so more such OS features in its
kernel/interpreter would be an andvatage.

My trigger to spend some time with forth is basicly a) with my interest
in
FPGA, simple hw implementation of many forth processors in today's high
density arrays, and b) that I do like such small black boxes (e.g. parallax
stamps, 51 basics, etc) to play with between football matches..

Maybe the current linux toolchain is more advanced, however the development
process with amforth and my XP tools is a challenge for a beginner (not
speaking about a good simulator..)

PS: Any plans for amforth 32bit with float??

Cheers,
Pito

Re: [Amforth-devel] USART.asm driver - U2X and baud error

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

all atmels use U2x, it is a part of calculus of the baudrate... Yes we
can adapt, of course..Pito

----- PŮVODNÍ ZPRÁVA -----
Od: "Matthias Trute" <mt...@we...>
Komu: "Everything around amforth" <amf...@li...>
Předmět: Re: [Amforth-devel] USART.asm driver - U2X and baud error
Datum: 8.7.2010 - 12:22:03

> Hi Pito,
> 
> > I see in usart.asm driver you are not considering
> > U2X (which may improve
> > > baudrate precision for certain combinations). Also
> > error is set to +/-
> > > 1% max. So when compiling one gets "systematic baud
> > errors .." even
> > > when the combination may work properly. It is not
> > so important and probaly
> > > your intention, however I did some experiments with
> > baudrates and Xtals
> > > and I saw that message even I know that a combination
> > is correct.
> > 
> I picked up the settings based upon readings I found
> in various sites of
> teh internet and they work most of the time well. The
> error range is
> based upon the same basis. remember that amforth runs
> on a wide variety
> of controllers with different usart module versions.
> feel free to adapt
> the code to whatever suits you, it's easy.
> 
> Matthias
> 

Re: [Amforth-devel] Thanks

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

Hi Leon,
the accuracy of an internal RC oscillator according to atmel is +/- 3%.
You may calibrate it (see atmega docs) to get better. There is also
a dependency on voltage and temperature, what can be another few percent
with RC. The recomended precision for 8N1 communication is +/- 4.5%
for a given baudrate. So you may get problems. It does not matter whether
you use 1,4,or 8MHz internal RC oscillator.
As a rule of thumb the RC oscilator stability is 10^-2, cheapo Xtals
10^-5, good Xtals 10^-6, thermostated (ovenised) 10^-7, rubidum source
10^-10, cesium 10^-13. Short time stability 10x better (e.g. for 10sec).
However, there is "aging" factor as well. With cheapo Xtals 100ppm per
annum. So you have the choice...
Pito

----- PŮVODNÍ ZPRÁVA -----
Od: "Leon Nathaniel Maurer" <leo...@gm...>
Komu: amf...@li...
Předmět: [Amforth-devel] Thanks
Datum: 8.7.2010 - 6:33:35

> It looks like I've got amforth working (photographic
> evidence:
> http://tinyurl.com/2d7cddx) -- thanks for your help!
> 
> To avoid future problems, I do have a couple related
> quick questions. The FAQ
> notes the default 1MHz clock (8 MHz internal RC clock
> divided by 8) can be
> unreliable and suggests: "Try to maximize the CPU frequency."
> What are the
> symptoms of this problem? Just not being able to get
> the serial communication
> to work? Does it help to use the internal clock but
> not divide by 8 (giving an
> 8MHz clock), or is inaccuracy with the internal clock
> part of the problem?
> 
> Thanks.
> -Leon
> 
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Thanks

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

Hi.
..
> Funnily enough 16Mhz the frequency that the arduino's use was found to
> be a good match.
>
> I have had acceptable results with 20Mhz xtals as well.

I'm running boards with atmega168 using 8, 16 and 20 Mhz with no  
problems.
Michael 

Re: [Amforth-devel] Avra 1.3 released

[Ian J. <ij...@sa...>]

I will try.

My FreeBSD box has been down for a year :-( mainly because it's owner was pre-occupied with relocation but also from some shipping damage.  Now I'm updating my ports to get "git" then avra1.3 and amforth 4.0.

Jerry wrote back to me and was very positive about adding additional devices to avra.  This time around I'll attempt to create diff patches for amforth sources and also provide feedback to the avra project.  You are right about avra/avrasm2 I forgot most of the difficulties related to compatibility.

I'm anxious to try out the butterfly application with the changes Michael mentioned.

Ian

On 2010-07-08, at 6:28 AM, Matthias Trute wrote:

> Ian,
> 
>> 
>> Avra 1.3 was released.  I have asked one of the project managers Jerry 
>> Jacobs how to contribute additional device support to the official 
>> release.
> 
> It would be cool if avra could compile the whole amforth system (again).
> There are not only the devices missing but also some features of the
> assembler itself (esp avrasm2 compatability).
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

It's not worth it without T.B.
ij...@sa...

Re: [Amforth-devel] Thanks

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

Leon,

> To avoid future problems, I do have a couple related quick questions. The FAQ 
> notes the default 1MHz clock (8 MHz internal RC clock divided by 8) can be 
> unreliable and suggests: "Try to maximize the CPU frequency." What are the 
> symptoms of this problem?

You get no terminal prompt or (too much) garbage there.

> Just not being able to get the serial communication 
> to work? Does it help to use the internal clock but not divide by 8 (giving an 
> 8MHz clock), or is inaccuracy with the internal clock part of the problem?

Using the full 8MHz may solve some or most of the problems, the better
solution is a so called baud rate quartz (e.g. 14,... MHz)

Matthias

PS: What terminal app do use use on you Mac? looks funny

Re: [Amforth-devel] Avra 1.3 released

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

Ian,

> 
> Avra 1.3 was released.  I have asked one of the project managers Jerry 
> Jacobs how to contribute additional device support to the official 
> release.

It would be cool if avra could compile the whole amforth system (again).
There are not only the devices missing but also some features of the
assembler itself (esp avrasm2 compatability).

Matthias

Re: [Amforth-devel] Help with word definition- redef

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

Hi Pito,

> Hi dear friends,
> as I am a newbie in forth I would kindly ask you for a minor help with
> a definition of a new word - "redef"
> 
> : redef ( string"word" -- n1 )
> 
> 1. n1 = 0, it finds the address ADDR_LAST of "word" (from the newest
> side - lefthandside)and memorise it; if not n1=-1 and exit
> 2. it finds the address of the next "word" (the next olderer in the word
> list) and replaces its address with the address in ADDR_LAST; n1++
> 3. repeats till the end of the wordlist (to the very righthandside word)


That's definitly not a task for a forth "beginner" and goes very deep
into the code of amforth. Sorry, but I cannot provide any assistance
here and now.

Matthias

Re: [Amforth-devel] USART.asm driver - U2X and baud error

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

Hi Pito,

> I see in usart.asm driver you are not considering U2X (which may improve
> baudrate precision for certain combinations). Also error is set to +/-
> 1% max. So when compiling one gets "systematic baud errors .." even
> when the combination may work properly. It is not so important and probaly
> your intention, however I did some experiments with baudrates and Xtals
> and I saw that message even I know that a combination is correct.

I picked up the settings based upon readings I found in various sites of
teh internet and they work most of the time well. The error range is
based upon the same basis. remember that amforth runs on a wide variety
of controllers with different usart module versions. feel free to adapt
the code to whatever suits you, it's easy.

Matthias