amforth-devel — Development discussion and user support

[Amforth-devel] Major redesign of the repository

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

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

Hi,

Today I've changed the repository structure. There are two new
directories at the top level: appl and lib. The directories blocks and
target within trunk are gone together with the makefile there.

Why these changes? amforth itself is basically useless. It needs
a few information about the environment it will run. I call this
an "appl(ication)". In this directory you can find a collection of
targets: AVR Butterfly, the Evaluation Boards and (new!) thanks to
Alexander Haucks impressive work an application to use a tv with
minimal hardware (2 resistors!).

These applications have all that's needed to build and burn the hex
files: a makefile, speed definition files (the former target/xy.asm)
and some useful forthcode specific for this environment. The build
process includes the amforth source tree like a library. It is up
to the developer to decide which version is be used. trunk
is always the lastest and newest, maybe useless version. release/x.y
is stable in a sense that it is never changed.

The lib directory contains forth code snippets that may be useful
across applications. Currently it contains some definitions for
an ANS system and some other more or less trivial words.

These changes should make life easier, feedback is
welcome!

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

iD8DBQFGUDEI9bEHdGEMFjMRAr0jAJ9/GQOL7P8k8LEoxng6hZ7fJH8YWQCdEx2j
MeVL1UZI6P/iL7nCzqT1p3g=
=rLw7
-----END PGP SIGNATURE-----

[Amforth-devel] =?iso-2022-jp?b?GyRCJDMkcyRLJEEkTxsoQiheXiA=?= =?iso-2022-jp?b?GyRCInYbKEI=?=

[<bao...@ya...>]

はじめまして美樹です。
掲示板で見て趣味合うかなって思ってメールしちゃいました。
 
イキナリでゴメンなさいm(__)m
こういう感じで知り合えるのに憧れてて初挑戦しちゃいました。
お返事もらえたら簡単な自己紹介しますネ(^_-)-☆
もしそんな気なかったらそう言ってもらえれば諦めますので。
もちろん仲良くなれた方が嬉しいけど。
お返事気長に待ってま〜す(^_^)/~
http://www.star-lightz.com/m-box

[Amforth-devel] pal tv output for amforth 2.x

[Alexander H. <ale...@gm...>]

Hello !!!
If you dont speak german please reply in english and i answer in english=20
only...

Ich denke aber, da=DF du Deusch kannst (wenn du Forth, von der Pieke auf ge=
lesen=20
hast).

Zun=E4chst mal ein gro=DFes lob !!! das amforth klappt wirklich sehr gut be=
i mir.=20
(ich benutze den Mega32 und fr=FCher den Mega8)=20
Deswegen habe ich gedacht ich lasse dir die folgenden Dateien einfach mal
zukommen.
Mit nur 2 zus=E4tzlichen Widerst=E4nden ist der Mega32 in der Lage ein TV-S=
ignal=20
zu erzeugen. (siehe info.asm in anhang ) Das Programm habe ich im Internet=
=20
gefunden und f=FCr amforth ver=E4ndert. Es muss nur in amforth.asm die=20
include-Zeile und die initialisierung rein. (siehe amforth.asm in anhang) e=
s=20
sind zwar noch ein paar Bugs drinn, aber man kann sehen, da=DF es n=FCtzlic=
h sein=20
k=F6nnte.  Wenn du Interesse hast, kann ich dir die folgenden Versionen=20
schicken... Ich weiss nicht wie lange ich noch Zeit habe=20
damit 'rumzuspielen', aber ich hoffe das ganze auf jeden Fall stabil und=20
absturz-sicher hinzukriegen... ;-)

Ein Nachteil hat die Routine:
Sollte der Baustein gerade ins Flash schreiben, wird des TV_Bild aber flack=
ern=20
(da IRQ's aus). Das wird sich wohl kaum vermeiden lassen.

Aber schau's dir doch einfach mal an...

Tsch=FCss,=20
Alexander Hauck -- ale...@gm...


P.S. kann es sein, dass in DO ... LOOP ein Bug ist ??
Immer wenn der Stack leer ist, macht mein avr kein TV_CLS kommando (Definit=
ion=20
s. TV_TTY.frt) also:
  > TV_CLS --> FEHLER
  > 42 TV_CLS --> OK
Kann aber auch ein Bug in meinen Routinen sein, den ich bisher einfach noch=
=20
nicht gefunden habe...

[Amforth-devel] Creative Suite 2 Version Xavier

[Norma B. <df...@vi...>]

MICROSOFT OFFICE 2007 ENTERPRISE $79.95 ADOBE CREATIVE SUITE 2 PREMIUM=20=
$149.95 CORELDRAW GRAPHICS SUITE X3 $59.95 MICROSOFT WINDOWS XP=20=
PROFESSIONAL SP2 $49.95 ADOBE DREAMWEAVER CS3 $59.95 ADOBE PHOTOSHOP CS3=20=
EXTENDED $89.95 ADOBE ACROBAT 8.0 PROFESSIONAL $79.95 MICROSOFT WINDOWS=20=
VISTA BUSINESS $79.95 AUTODESK AUTOCAD 2007 $129.95=20=
http://nadaujebejat.comSTART DOWNLOADING 

Re: [Amforth-devel] Interrupt handling question

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

2007/5/1, Matthias Trute <mt...@we...>:
> I'd suspect your refresh-display code...

... and rightfully so.  I had put a drop into it as I suspected that
there would be something on the stack to drop and forgot to remove
that.  Things run fine now, thanks for the fix!

-Hans

Re: [Amforth-devel] Interrupt handling question

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

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

Hans,

Hans H=FCbner wrote:

> I tried my display stuff with the trunk version, but it still crashes
> once I unmask the interrupt.  I am using an atmega32 on an STK500,
> maybe something is wrong with the definitions for that CPU?  What CPU
> type do you test with?

atmega32 @ 16 MHz

variable cnt0
0 cnt0 !
: inccnt0 1 cnt0 +! ;
' inccnt0 0B int!

works fine even for TCCR0 set to 1 (prescaler 64).
> 1 TIMSK c!
 ok
> TCCR0 c@ .
 4 ok
> : s1 10 0 do cnt0 @ . loop ;
 ok
> s1
 39AA 39AB 39AC 39AD 39AE 39B0 39B1 39B2 39B4 39B5 39B6 39B7 39B9 39BA
39BB 39BC
 ok
> 1 TCCR0 c!
 ok
> s1
 -106D -D1B -A53 -78C -4C5 -1FE CA 28E 4DA 728 973 BBE E0E 105C 1334 160A=
 ok

At that speed even the compiler works for a hello-world word..

I'd suspect your refresh-display code...

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

iD8DBQFGNuK29bEHdGEMFjMRAlY9AKDZCjlX7Ax1fbDj/J1Uh8kfSSqmwACcCSRT
+NlR4ZJsjw3pWWfLTCLKtME=3D
=3DrARo
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Interrupt handling question

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

2007/4/30, Matthias Trute <mt...@we...>:
> [1] I found a stupid error in the interrupt system. For my atmegas
> timer0 now increases a variable with your settings for an
> hout by now... See svn trunk.

I tried my display stuff with the trunk version, but it still crashes
once I unmask the interrupt.  I am using an atmega32 on an STK500,
maybe something is wrong with the definitions for that CPU?  What CPU
type do you test with?

Thanks!
Hans

Re: [Amforth-devel] Interrupt handling question

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

Hi Matthias,

2007/4/30, Matthias Trute <mt...@we...>:
> > Together with my scripting mechanics (and the Forth file translated to
> > assembler), it will be possible to build a complete amforth system
> > from source without having to go round-trip to the target.
>
> That would be a host based compiler. Do you know the avr assembler
> from Daniel Kryzcena? (krue.net). It is written for gforth and he
> makes his avrforth with it.

I have not looked at it, and the one thing I love most about amforth
is the fact that it is completely target-based.  Being able to hack
through a system interactively and to try out things and redefine
words on the fly is just great.  I don't want a host-target
configuration.

My mechanism is more useful for automatic deployment.  I usually put
the Forth source I work with into an open editor and then cut and
paste between my editor and the terminal program connected to the AVR.
 At some point in time, I decide that I need to start with a fresh
amforth (either because there is a new version, because my flash is
full or because I want to move from one AVR to another).  In that
case, I want to use my source file and replicate the installation on
another AVR, from scratch, with as little manual interaction as
possible.

> You drive the idea of a "stand-alone" system to it's limit, don't you?

Yeah, maybe.  Also the idea of "Open Source" makes most sense if the
source is always delivered with the system.  :)

> > For my FPGA application, I will propably put the source into the
> > serial flash and compile from there, but I first want to have this
> > running on a real AVR.
>
> What's wrong with your io redirect? Put the base system into whatever
> the flash is and let KEY read from eeprom

Exactly that!  It is just the missing link from *.asm + *.frt to a hex
file that automatically starts when I switch on the power of the AVR
that bothers me :)

> btw: do you want to publish this module?

You mean the compile-from-rom stuff?  Sure, if anyone wants to use it,
take it.  If someone asks, I'll also put some more comments and
options into the perl and makefile stuff.  Just let me know.

> [1] I found a stupid error in the interrupt system. For my atmegas
> timer0 now increases a variable with your settings for an
> hout by now... See svn trunk.

Thanks!  I'll check it out later on!

Cheers,
Hans

Re: [Amforth-devel] Interrupt handling question

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

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

Hi Hans,
>> > Do you have a tool that aids in translating Forth to Assembler,
>>
>> I don't _have_ such a tool, I _am_ that tool ;=)
> 
> Given that the routines I need are really simple, maybe I can use you
> as the tool?

I wont recommend me for routine tasks. I'm buggy[1] and my overhead
is pretty high since I tend to write scripts to assist me ;)

> My mechanism may also fill the needs of others:  I have
> set up the necessary scripting that converts one or more forth files
> (using "\ include" as syntax) to a hex file that can be flashed.  The
> source is flashed so that the last adress is right below the boot
> block.  Comments and while space are stripped.  The compile-from-rom
> forth program changes the input vectors so that characters are read
> from ROM until the last byte below the boot block has been hit.  Then,
> the input vectors are set back to rx0/rx0?.

I had quite a few uses for this io redirect, but yours is ingenious.

> Together with my scripting mechanics (and the Forth file translated to
> assembler), it will be possible to build a complete amforth system
> from source without having to go round-trip to the target.

That would be a host based compiler. Do you know the avr assembler
from Daniel Kryzcena? (krue.net). It is written for gforth and he
makes his avrforth with it.

> It may even be good to add some more code so that the source can be
> viewed on the target (in the tradition of making the source code
> available to the "customer").

You drive the idea of a "stand-alone" system to it's limit, don't you?

> For my FPGA application, I will propably put the source into the
> serial flash and compile from there, but I first want to have this
> running on a real AVR.

What's wrong with your io redirect? Put the base system into whatever
the flash is and let KEY read from eeprom, btw: do you want to publish
this module?

Bye
Matthias

[1] I found a stupid error in the interrupt system. For my atmegas
timer0 now increases a variable with your settings for an
hout by now... See svn trunk.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGNeEd9bEHdGEMFjMRAvWmAKDs1a68VzFdUc5/jwz5wg3CbPCKWwCgsQh3
w1LUgL67WNgR5j7rdjxiLco=
=AKs+
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Interrupt handling question

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

Hi Matthias,

2007/4/29, Matthias Trute <mt...@we...>:
> >> What's a flashless AVR??? Sounds like sodium free salt ;=)
> >
> > It is one that uses the AVR_Core of OpenCores.
>
> Cool stuff. What hardware do you use for it? Not that
> I want to work with it, but to get a feeling for it...

I am using the Spartan 3E Starter Kit
(http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_47&products_id=92&language=en),
which is pretty cheap and has all sorts of peripheral chips.

> > Do you have a tool that aids in translating Forth to Assembler,
>
> I don't _have_ such a tool, I _am_ that tool ;=)

Given that the routines I need are really simple, maybe I can use you
as the tool?  My mechanism may also fill the needs of others:  I have
set up the necessary scripting that converts one or more forth files
(using "\ include" as syntax) to a hex file that can be flashed.  The
source is flashed so that the last adress is right below the boot
block.  Comments and while space are stripped.  The compile-from-rom
forth program changes the input vectors so that characters are read
from ROM until the last byte below the boot block has been hit.  Then,
the input vectors are set back to rx0/rx0?.

Together with my scripting mechanics (and the Forth file translated to
assembler), it will be possible to build a complete amforth system
from source without having to go round-trip to the target.  Presently,
my automatism stops after having compiled amforth and sent both
amforth and the source to be compiled to the target, because I first
need to upload the compile-from-rom stuff through the serial port.

It may even be good to add some more code so that the source can be
viewed on the target (in the tradition of making the source code
available to the "customer").

For my FPGA application, I will propably put the source into the
serial flash and compile from there, but I first want to have this
running on a real AVR.

Thanks for your support,
Hans

Re: [Amforth-devel] Interrupt handling question

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

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

Hi Hans,

> I take this as encouragment: 

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

looks innocent but crashes here too :=(
I'll look at it very closly ASAP..

>> What's a flashless AVR??? Sounds like sodium free salt ;=)
> 
> It is one that uses the AVR_Core of OpenCores.

Cool stuff. What hardware do you use for it? Not that
I want to work with it, but to get a feeling for it...

> Having an interactive environment would be much preferable.

Forth has its advantages ;=)

> BTW:  For that project, I will also reanimate my "compile from ROM" 
> idea from months ago.

I think about the change from INTERPRET to EVALUATE. But it would work
with RAM strings, not FLASH strings...

> Do you have a tool that aids in translating Forth to Assembler,

I don't _have_ such a tool, I _am_ that tool ;=)

> or to disassemble or some such?

A kind of disassembler creates the html pages of
http://amforth.sf.net/words/ . It is written in
poor write-only perl, but drop me a line if you
want it.

> It would not be too hard to do it by hand, but it would still require
> some experience which I do not have.

It's not that difficult to convert forth -> ASM/XT_* by hand. esp when
the code already works ... I know that at least 2 members of this list
can do it ;=)) But they asked for such a tool too, there seems to be a
real demand for it...

Matthias

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

iD8DBQFGNPYY9bEHdGEMFjMRAn7aAJ9ak3ea7PFpfrCyMrlDPyOBfecR/ACgx/Jz
vWyF/UIFoy2VQnAirVtYz+w=
=tUum
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Interrupt handling question

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

Hi Matthias,

2007/4/29, Matthias Trute <mt...@we...>:
> > I am asking because my code crashes - If I leave the stack as it was
> > before entering the interrupt handler, I see periodic reboots (once a
> > second) when I enable the interrupt handler.
>
> without your code it is difficult to analyze.

I take this as encouragment:

: start-display ( -- )
    init-display \ sets up port directions, globals
    0 display-number \ display a number

    ['] refresh-display 11 int! \ set up interrupt handler (we're in decimal)

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

> >  I am asking because I want to give amforth on a flashless AVR a try.
>
> What's a flashless AVR??? Sounds like sodium free salt ;=)

It is one that uses the AVR_Core of OpenCores.  I am working on a FPGA
based CPU, and I need a simple controller environment in order to boot
the real CPU, inspect memory and the like.  I was using an 6809 until
now, but I have not been able to find a Forth interpreter for that, so
I had to use GCC.  It worked, but having to recompile and download the
debug monitor was kind of tedious.  Having an interactive environment
would be much preferable.

BTW:  For that project, I will also reanimate my "compile from ROM"
idea from months ago.  I got that mechanism working fine, but one
thing that is kind of burdensome is the fact that, after compiling
amforth I have to upload my compile-from-rom module before I can
actually compile.  Do you have a tool that aids in translating Forth
to Assembler, or to disassemble or some such?  It would not be too
hard to do it by hand, but it would still require some experience
which I do not have.

Cheers,
Hans

Re: [Amforth-devel] Interrupt handling question

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

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

Hans,

Hans H=FCbner schrieb:

> I am trying to port my timer interrupt driven display code to
> amforth-1.9 and have some problems with that.
>=20
> On the documentation page
> (http://amforth.sourceforge.net/interrupts.php), an example interrupt
> handler is printed:
>=20
> : doint1
>     . ( <-- this is dangerous in interrupts )
> ;
>=20
> The danger set aside (I guess the dangerous part is the fact that the
> UART will generate another interrupt that may not be properly
> handled), it seems that this example has a stack effect.

Ok, you are right. The example is a non-example. An interrupt
word must not have any stack effect.

>  Is this intended?

not really, sorry.

> Is there something on the stack that the interrupt handler
> must remove?

no. All the low level interrupt stuff is handled by amforth (namely
the reti instruction). On forth level there is no state to keep other
than the stacks.

> I am asking because my code crashes - If I leave the stack as it was
> before entering the interrupt handler, I see periodic reboots (once a
> second) when I enable the interrupt handler.

without your code it is difficult to analyze.

> If I pop the topmost
> item, amforth plain crashes with trash characters written to the
> console.

Well, that is most likly, see above.

> It could be that the new interrupt handler code is too slow
> to work with the timer interrupt,

The new code is faster then the old one.

> but before getting into debugging
> that, I'd like to know if there is something fundamentally wrong with
> my code.

you could try using a semaphore like flag to detect an interrupt
overrun.

> BTW:  Is there anything in amforth except ISTORE that writes to flash?

No, all words which write to flash call i! to do the "real work".

>  I am asking because I want to give amforth on a flashless AVR a try.

What's a flashless AVR??? Sounds like sodium free salt ;=3D)

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

iD8DBQFGNHVz9bEHdGEMFjMRAricAKCM3peY2gh0WLnTUqXK76nQHmws8gCgovch
DQ2roL6T+z0PnyYfNQdKBNM=3D
=3D+/GU
-----END PGP SIGNATURE-----

[Amforth-devel] Interrupt handling question

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

Hi,

I am trying to port my timer interrupt driven display code to
amforth-1.9 and have some problems with that.

On the documentation page
(http://amforth.sourceforge.net/interrupts.php), an example interrupt
handler is printed:

: doint1
    . ( <-- this is dangerous in interrupts )
;

The danger set aside (I guess the dangerous part is the fact that the
UART will generate another interrupt that may not be properly
handled), it seems that this example has a stack effect.  Is this
intended?  Is there something on the stack that the interrupt handler
must remove?

I am asking because my code crashes - If I leave the stack as it was
before entering the interrupt handler, I see periodic reboots (once a
second) when I enable the interrupt handler.  If I pop the topmost
item, amforth plain crashes with trash characters written to the
console.  It could be that the new interrupt handler code is too slow
to work with the timer interrupt, but before getting into debugging
that, I'd like to know if there is something fundamentally wrong with
my code.

BTW:  Is there anything in amforth except ISTORE that writes to flash?
 I am asking because I want to give amforth on a flashless AVR a try.

Thanks!
-Hans

[Amforth-devel] Show("A download does not appear to be in progress.

[Joy <zd...@pr...>]

CHFR continues its Steady Climb, UP Another 23% Since Monday!

China Fruits Corporation
Symbol: CHFR
Price: $0.42

CHFR is climbing steady all week. UP over 23% since Monday, investors
are enjoying the solid climb. Read CHFR's recent news, and get on it
Thursday!

Because when the user presses Download, the download is always started
from the beginning (unlike when he presses Resume), the parameter passed
is 0, and you can see that on the next line. Now that we know its size,
we know from what point to move on with the downloading. ", "Could not
resume", MessageBoxButtons. If there's no existing file, there's no
resume, so we start from 0. It if has, we break out of the loop because
this variable is set to true only when we wish to stop (pause) the
download. This will go on until the last picture is displayed, then the
timer will be cleared and the function will not be called again;
finished will become true and running will become false.
thank you :)Sorin Sodolescu - Apr 18 2007 - 09:44hello ct. Therefore,
even though the  button is named Pause, what it actually does is to stop
the download completely, not leave it in a hanging state. However, if
it's not, we specify a different parameter when creating the FileStream
object: FileMode.
Just go to the pictures The Observer, UK -The Met used to undertake a
cumbrous tour of the hinterland each spring, shoehorning corpulent
tenors on to trains and unloading them to sing in . We will make the ULs
become visible and invisible with ":hover". First we have to check what
value was entered.
It's also important to notice that from the application's point of view
there are two types of palindromes: odd in length and even in length. We
also want to avoid calling the function when the page loads (refreshes)
and the n fields is empty. 4 will be a winter break holiday, and March
14 also will be a holiday, Spring break moves to March 17-24, and the
last day of school moves to May 23. For as long as a character that's
not identical is found, the function keeps calling itself. This means
the file on the hard drive now has 314,159 bytes.
It will allow you to split files into as many output files as you want
and then reconstruct the file from the splitted output files.
Just go to the pictures The Observer, UK -The Met used to undertake a
cumbrous tour of the hinterland each spring, shoehorning corpulent
tenors on to trains and unloading them to sing in . Greatest common
divisor - The largest number that divides evenly into each of a given
set of numbers. You can change the values in the last line of the matrix
for a different color or try equal values at each value for other
effects.
To make this work in Internet Explorer and Firefox we'll need 2 separate
CSS files, one for each browser.
com Nome Search Powered by :: Free RSS news Add RSS news to your web
site holiday news vertical portal can now be syndicated quickly and
easily using our new  Really Simple Syndication feeds.
4 will be a winter break holiday, and March 14 also will be a holiday,
Spring break moves to March 17-24, and the last day of school moves to
May 23.
It will feature next, previous, play, pause and resume buttons along
with transition effects between pictures. If a slideshow is running, it
checks if it has been paused or not. We'll use a DIV and some ULs to
create our menu since this is not only the most appropriate method but
it's also optimizes it for search engines.
Write(bytePart, 0, bytePart. Tech killings Home :: Web Directory ::
holiday News :: Free RSS news :: Free Newsletter :: Tell a Friend
Clientfinder.
This way all of the  ULs will fit next to eachother. A palindrome is a
sequence that reads the same in either direction. That filter will
create the transition effect using DirectX; unfortunately browsers other
than Internet Explorer do not support the DirectX filters applied here.
First we have to check what value was entered.
The slideshow will still work, however there will be no transition
effect between pictures. Also called greatest common factor, highest
common factor.
These functions are used to make the page look more user-friendly, and
go in the head of the document.
Like in the factorial function, we first have to check the variables'
values.

[Amforth-devel] We accepted your loan request

[Kristin C. <tr...@ti...>]

Thank you for your loan request, which we recieved 
yesterdayWe'd like to inform you that we are accepting your application.
We are ready to give you a $272,000 loan (Approved refinance) for a 
low month payment. Approval process will take only 1 minute. Please=20=
visit the 
confirmation link below and fill-out our short 30 second form.=20=
http://gkkzngresullts.com

Re: [Amforth-devel] Extra code in R237

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

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

Christoph Bayer schrieb:
> Hello list,
> 
> I found an probably unwanted line of code introduced in R237 in file p16.asm:
> "call device_init" seems to be included by accident.

... and is removed intentionally ;=)

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

iD8DBQFGHSoTLo3irIddFw4RAlADAJ9UsyZGdqhWmpCRA9urFRW3pTVK4wCeIkyx
Sd6JhbQhHsS/eqkrk8v6/Uk=
=FXbi
-----END PGP SIGNATURE-----

[Amforth-devel] Extra code in R237

[Christoph B. <chr...@we...>]

Hello list,

I found an probably unwanted line of code introduced in R237 in file p16.asm:
"call device_init" seems to be included by accident.

Thank you very much for your software!

Best regards,

Christoph Bayer

_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Re: [Amforth-devel] Data stack pointer problem?

[Maciej W. <mwi...@gm...>]

2007/4/5, Matthias Trute <mt...@we...>:
> There is a much simpler bugfix, that does not need any additional
> code: Move the code block for the data stack pointer in
> amforth.asm to the proper postion (at the end). Just fixed in svn..

Now, that was FAST reaction :). Thank you!

Best regards,
Maciej

Re: [Amforth-devel] Data stack pointer problem?

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

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

Hello Maciej,

> I have narrowed the problem to the start of COLD codeword that first
> calls SP0 to fetch the address of the stack (that should be
> stackstart) and then SP! to store the top of stack value to Y
> register.
>
> The problem is that SP0 returns its value on the stack while Y
> register is still uninitialized and contains XT_NOOP address (from
> reset routine). In the SVN this problem may be a bit hidden because
> top of stack is kept in a register pair, but the execution will start
> with savetos macro that uses Y register anyway and might corrupt the
> RAM anyway.
> 
> I think that this could be solved by adding word SP0! that just loads
> Y with stackstart value or by moving in amsforth.asm, reset routine
> the parameter stack pointer initialization just before the jump to
> Forth machine so that Y register will have the value of stackstart.

There is a much simpler bugfix, that does not need any additional
code: Move the code block for the data stack pointer in
amforth.asm to the proper postion (at the end). Just fixed in svn..

Thank you!

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

iD8DBQFGFK9vLo3irIddFw4RAsnJAJ42OeMDdBgrNLT75tyikwmlQ56bQgCfRKi6
CpWrXWIcHC1HkKOBMzOMz4I=
=uTW4
-----END PGP SIGNATURE-----

[Amforth-devel] Data stack pointer problem?

[Maciej W. <mwi...@gm...>]

Hello

I'm a beginner with AVR assembler and Forth in general, but it seems
to me that there is a problem with parameter stack pointer (Y
register) initialization in amforth.

I tried to run amforth in AVR Studio simulator, maybe there are some
differences with real hardware that I'm not aware of. Anyway, amforth
1.6 crashed in the simulator.

I have narrowed the problem to the start of COLD codeword that first
calls SP0 to fetch the address of the stack (that should be
stackstart) and then SP! to store the top of stack value to Y
register.

The problem is that SP0 returns its value on the stack while Y
register is still uninitialized and contains XT_NOOP address (from
reset routine). In the SVN this problem may be a bit hidden because
top of stack is kept in a register pair, but the execution will start
with savetos macro that uses Y register anyway and might corrupt the
RAM anyway.

I think that this could be solved by adding word SP0! that just loads
Y with stackstart value or by moving in amsforth.asm, reset routine
the parameter stack pointer initialization just before the jump to
Forth machine so that Y register will have the value of stackstart.

Best regards,
Maciej

Re: [Amforth-devel] benchmarks ;=)

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

2007/4/2, Matthias Trute <mt...@we...>:
> Hans H=FCbner schrieb:
> > Joh,
> >
> > if you meant to write 1/100s (10 ms), using Timer0 will work just
> > fine!  I had no problems running it at higher speeds, too, with my
> > interrupt handler written in Forth.
>
> Which frequencies did you use?

I used Timer0 with clock prescaling set to 256 and interrupting on
overflow, on an ATMEGA16 at 16 Mhz.  This results in interrupts at
roughly 240 Hz.  Looking the other way, it leaves 256 256 * AVR
instructions per interrupt.

-Hans

Re: [Amforth-devel] benchmarks ;=)

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

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

Hans H=FCbner schrieb:
> Joh,
>=20
> if you meant to write 1/100s (10 ms), using Timer0 will work just
> fine!  I had no problems running it at higher speeds, too, with my
> interrupt handler written in Forth.

Which frequencies did you use?

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

iD8DBQFGETDcLo3irIddFw4RAv9HAJwPPyFIBN44+re2DW1x9MEAMAwEbACgn2vo
Ka7qyu4oLf5Wri8RqKJv2jY=3D
=3D+wqr
-----END PGP SIGNATURE-----

Re: [Amforth-devel] benchmarks ;=)

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

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

Joh,

joe...@t-... schrieb:

> what is your proposal to generate a (1/100us) clock (for e.g. the
> output of a bit pattern ) in amforth? (as you wrote, the timer int.
> isn't usable for such speed)

I only wrote that the timer interrupt may cause strange effects, since I
had/have problems with a 72KHz timer on an atmega8. But I did not re-do
these tests for several month by now due to some hardware problems.
Maybe the problem is solved en-passant...

And as Hans wrote, I doubt, that amforth will _ever_ reach a clock cycle
of 10ns (==100 MHz). You should consider the *very* new atmegas
(paperware) with high-resolution timers.

> What speed can I expect when I use the word pause? Is there a
> guarantee how often the word is called per ms?

How could this be done? The inner interpreter (NEXT) is called
every few cpu cycles: an EXIT needs no (additional) time, an
division may need several hundreds of cycles. An EMIT/KEY
may need _very_ long time. amforth is not designed to generate
a time-slice based hard real-time system for sub-millisecond
requirement.

> Because the pulses
> should come in a certain time distance.

You can use the timer/counter of the atmegas without genereating an
interrupt. That gives the pulses very accurate and basically without
amforth.

Bye
Matthias

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

iD8DBQFGETCxLo3irIddFw4RAlU8AJ9Mzo82Cf1K97B6JE5PLxwihkn1OACcDI7P
9SUI+0GyCiSuu7QFO0numgE=
=gAG3
-----END PGP SIGNATURE-----

Re: [Amforth-devel] benchmarks ;=)

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

-----Original Message-----
> Date: Mon, 02 Apr 2007 16:21:47 +0200
> Subject: Re: [Amforth-devel] benchmarks ;=)
> From: "Hans Hübner" 
> To: "Everything around amforth" 

> Joh,
> 
> if you meant to write 1/100s (10 ms), 

No, sorry I mean 1 pulse every 100 mikroseconds.

> using Timer0 will work just
> fine!  I had no problems running it at higher speeds, too, with my
> interrupt handler written in Forth.

it is possible to have a look at this handler...?

> 
> -Hans
> 
> 2007/4/2, joe...@t-... :
> > Hi Matthias,
> > 
> > what is your proposal to generate a (1/100us) clock (for e.g. the
> > output of a bit pattern ) in amforth? (as you wrote, the timer int.
> > isn't usable for such speed)
> > What speed can I expect when I use the word pause? Is there a
> > guarantee how often the word
> > is called per ms? Because the pulses should come in a certain time
> > distance.
> > 
> > Best regards
> > joh
> > 
> > 
> > -----Original Message-----
> > 
> > > Date: Sun, 01 Apr 2007 11:06:59 +0200
> > > Subject: [Amforth-devel] benchmarks ;=)
> > > From: Matthias Trute
> > > To: Everything around amforth
> > 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > Hi,
> > > 
> > > I just run a stupid benchmark with the fib word from the blocks
> > > directory. 24 fib gives the biggest usable number (46368) on
> > > amforth.
> > > 
> > > Running a loop with 100 iterations took roughly 3'30 on an
> > > atmega32 at 16MHz. The sparring partner I choose is gforth (0.6.2,
> > > comes with ubuntu) on my 2GHz P4 system. To balance the frequency
> > > difference, gforth had to run 125 times the 100 loop. That took
> > > around 1'30.
> > > 
> > > What does it tell us? Well, nothing perhaps. Or that amforth
> > > executes 1 forth "instruction" where gforth has 2, scaled with cpu
> > > cycle clock.
> > > 
> > > Matthias
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.3 (GNU/Linux)
> > > 
> > > iD8DBQFGD3YzLo3irIddFw4RAibBAKDBc2whzaOQcV33T4GpkI/H0/PGiwCgoSrq
> > > HLmj7z4xtPYDCrQ9bl0Ps8Q=
> > > =RK8F
> > > -----END PGP SIGNATURE-----
> > > 
> > > 
> > > 
> >
-------------------------------------------------------------------------
> > 
> > > 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
> > > 
> > > 
> > 
> > 
> > 
> > 
> >
-------------------------------------------------------------------------
> > 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
> > 
> > 
> 
>
-------------------------------------------------------------------------
> 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
> 
>