amforth-devel — Development discussion and user support

Re: [Amforth-devel] Amforth(9600), ZTerm(19200) why?

[avr f. <avr...@gm...>]

ok. thanks. :)Now I have a harder question.
1. Why is my Arduino losing memory after turning it off. It could also be
that the internal state is damage.
When I try to connect second time. It's not answering or garbage appear in
the terminal. I'm using default fuses. With baudrate 9600.


Background:
This forth image is based on the svn repository.
And uses AVRMacPack to compile.


On Sun, Jun 15, 2008 at 8:40 PM, Christian Berger <
cas...@ca...> wrote:

> On Sunday 15 June 2008 20:26:19 avr feedback wrote:
> > When Amforth it set to 9600 and ZTerm to 19200. It works. why?
>
> I guess your Arduino runs at 16 MHz but you told the assembler that your
> controller is running at 8MHz.
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] Heap pointer in EEPROM, Why?

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

hi,

> why is the heap pointer stored in EEPROM?

It is the pointer to the first unused ram address. There
may be words in the dictionary that uses ram below it and they
depend on the absolute address.

> I probably miss something, but wouldn't it be more logical to store that
> in
> RAM as its contents are irrelevant after the RAM has been deleted?

No, the content of the RAM is lost, but not it's structure.

The words that allocated RAM will use it again at the same addresses
(that those words need to store somewhere, e.g. as a variable entry
in the dictonary).

bye
Matthias

Re: [Amforth-devel] Amforth(9600), ZTerm(19200) why?

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

On Sunday 15 June 2008 20:26:19 avr feedback wrote:
> When Amforth it set to 9600 and ZTerm to 19200. It works. why?

I guess your Arduino runs at 16 MHz but you told the assembler that your 
controller is running at 8MHz.

[Amforth-devel] Amforth(9600), ZTerm(19200) why?

[avr f. <avr...@gm...>]

Hello.

I just got it working. But I can't understand one thing.

Why do I need faster baud rate in ZTerm compared to Amforth baud rate
settings?

When Amforth it set to 9600 and ZTerm to 19200. It works. why?

I just got my Arduino this week. So I'm learning..

---
Background: This is how I got it working
Tools: Mac, VMware Fusion, Studio4.14(589) in WindowsXP, ZTerm on mac

Amforth
1. Get amforth compiling clean. (change temp6->zl and temp7->zh)
2. Change ADCaddr -> ADCCaddr
3. Comment out r30 and r31 in macros.asm.
3. Set Baud rate = 9600
4. Change .include to device/atmega168.asm
5. Compile, f7.

Uploading hex and eep files.
1. Arduino have a extern crystal. (CKSEL=1111,SUT=00)
2. LFUSE=0xCF, HFUSE=0xDF, EFUSE=0xF8 (
http://palmavr.sourceforge.net/cgi-bin/fc.cgi)
3. LockBit=0xCF

Connecting with ZTerm
1. Connect USB cable direct to Arduino
2. Disconnect AVRISP mkII from Arduino
3. ZTerm 19200N81, no local echo, no Xon/Xoff, no Hardware handshake
   vt100, ZModem protocol for send and receive.

[Amforth-devel] Heap pointer in EEPROM, Why?

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

Servus,

why is the heap pointer stored in EEPROM?
I probably miss something, but wouldn't it be more logical to store that in 
RAM as its contents are irrelevant after the RAM has been deleted?

Servus
  Casandro

Re: [Amforth-devel] Heap?

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

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

Hi

Christian Berger wrote:
> Servus,
> 
> are there any plans to have a heap like in C?

Simple and short answer: No.

The longer answer is, that a heap management needs both code size
and RAM size which is both (sometimes very) limited. Therefore I
do not wrote a sophisticated memory management subsystem. ALLOT
is all that exists.

But feel free to implement it.

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

iD8DBQFIU6219bEHdGEMFjMRAmR/AKCuMnvhA7JSm455iOHHtVK7nEYOPgCfZaXm
4WjSti6e2q8jcdu39nlWihM=
=ZFSr
-----END PGP SIGNATURE-----

[Amforth-devel] Heap?

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

Servus,

are there any plans to have a heap like in C?

Maybe the simplest way would be to do it like most C implementations do it:

  v            v
YZ0123456....YZ0123456...

The pointers point at the start of the memory region the programm uses. 
(0123...) Just before that point, there is a word (YZ) which is there for 
memory management. That word contains the size of the memory region and a 
flag indicating wether it's in use or not.

So we would need 3 words:
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Heap-Allocation.html

In short:
allocate       u -- a-addr wior
This word should search through the heap for free memory. It starts by the 
first pointer, which is somewhere stored in the system. It follows the size 
information until it found a free block which is large enought for the size 
requested. If the block is larger than the requested size it will be split 
into two. If there are not enought bytes to make a new block, the current one 
will be made bigger. If an error occurs, it will be reported in wior.

free       a-addr -- wior
This word looks for the next blocks, if those are free, it merges them with 
the current block. The current block is then set to be unused.
This simple routine will run into problems if memory is freed in the wrong 
direction. Then it will not be able to merge free blocks as it is unable to 
look towards low memory regions. Maybe a special word "clean-up" might be 
good. Or we could have an allocate which checks for successive free blocks.
Free will fail on blocks which are marked unused.

resize       a-addr1 u -- a-addr2 wior
This word would essentially allocate a new block of size u, copy the data from 
the old block and free the old block. Maybe optimisations could be done to 
expand the block towards lower memory regions even if the conventional 
allocate/free combination would not work.

Another word we should have, which is not included in gforth is:
sizeof	 	a-addr1 -- u
This word checks the pointer and returns the size of the block at its 
position. 
This would help us prevent many buffer overrun problems of C.



Dynamic memory would enable us to do lots of things. For example the video 
output could save on space. For example it could have a line pointer table 
which stores pointers for each (text) line of the display. Empty lines could 
just have a 0-entry in that table. Double width lines could just take up half 
the memory. Graphic lines could use more memory, etc. Overall we might save 
quite a bit of memory.

Servus
  Casandro

Re: [Amforth-devel] Video quod vadis

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

Am Samstag 24 Mai 2008 21:50:35 schrieb Matthias Trute:
> Christian Berger wrote:

> It would be nice if the keyboard words would work with EKEY from
> the forth200x words. That would make code page changes very easy too.

I should look into that. As I mentioned before, I'm not really that fluently 
with Forth.

> > Hmm, maybe we could have block read and write commands. But for that we'd
> > need memory allocation words.
>
> ALLOT exists ;=)

I also need to look into that. It would be great if one had something simmilar 
to the memory handling C does, only working.

> 800 bytes is less than a single ANS block, and power is not essential as
> long as a tv device is concerned ;=)

Well if you have 2048 bytes of RAM on your device total, it is a problem. 
Besides for the ethernet interface you'd still need the SPI, which is already 
used by the video. And Ethernet is _really_ expensive. It costs more than the 
rest of the system, including an additional large screen television set for 
output to larger crowds.
And a normal large TV-set only takes about 10 watts peak, probably a lot less 
with white text on black background. Small non-direct view screens even take 
less power.

> btw: On tuxgraphics there is an atmega88 with an ethernet interface and
> a webserver running on it.

Of course, there have been many projects involving ethernet and TCP/IP. So far 
most only support IPv4.

Well I'll need to look into it. Maybe there's a way to implement Ethernet with 
very little external hardware. Yes, I know there are single chip Ethernet 
interfaces around.

> > My idea would be to have a
> > tiny stripped down networking protocoll which can work with tiny buffers.
>
> Sound like you are looking for CAN.

CAN is so bloated and expensive. I2C on the contrary is widely availiable in 
microcontrollers and easy to implement in software.
Well OK, I admit it, I don't really like CAN. :)

> Bye
> Matthias

Servus
  Casandro

Re: [Amforth-devel] Video quod vadis

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

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

Christian Berger wrote:

> Well there is nothing new other what is on here. Yes, it now supports the 
> @-key. I'm still not very happy about the keyboard routines.
> http://www.mikrocontroller.net/topic/94193

It would be nice if the keyboard words would work with EKEY from
the forth200x words. That would make code page changes very easy too.

> Hmm, maybe we could have block read and write commands. But for that we'd need 
> memory allocation words.

ALLOT exists ;=)

>>> If you add some kind of networking via I2C you can send a kind of e-mail.
>> There is even a ethernet connection possible (with IP etc). Hardware
>> exists.
> 
> TCP/IP needs a _lot_ of memory (800 bytes) and ethernet is not only rather 
> expensive, but it also takes quite a lot of power.

800 bytes is less than a single ANS block, and power is not essential as
long as a tv device is concerned ;=)

btw: On tuxgraphics there is an atmega88 with an ethernet interface and
a webserver running on it.

> My idea would be to have a 
> tiny stripped down networking protocoll which can work with tiny buffers.

Sound like you are looking for CAN.

Bye
Matthias

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

iD8DBQFIOHGL9bEHdGEMFjMRAtCUAJ9jWqJnp6UIflbDuqfELTrKLVYATQCeKrE1
VSp4HYEFfwBQ1xKEdlgrkvs=
=o9/d
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Video quod vadis

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

Am Freitag 23 Mai 2008 21:12:04 schrieb Matthias Trute:
> Hi Christian,

> If you have any updates, you can send them to me (directly).

Well there is nothing new other what is on here. Yes, it now supports the 
@-key. I'm still not very happy about the keyboard routines.
http://www.mikrocontroller.net/topic/94193

> I'm happy to sit-and-wait and nitpick the cherries ;=)

Good :)

> (Standard-) blocks are somewhat difficult since they need a lot of RAM
> for the buffer(s). IMHO blocks can only be used with external RAM and/or
> a modified RAM - Fetch/Store to emulate a MMU with paging.

Hmm, maybe we could have block read and write commands. But for that we'd need 
memory allocation words.

With memory allocation, it would also be possible to have a more dynamic video 
display. For example we could have an empty image to need less memory than a 
full one. Just like the popular ZX80 homecomputer does.

> > Seriously if you can edit blocks, and send them to a printer
>
> I doubt that a windows el-cheapo GDI printer will ever work ;=)

I doubt GDI printers are still around. Most now have either PCL or Postscript 
or some Linux-only stuff.

> Postscript OTOH may work well, esp for a forth system ...

True, we could have parallel processing. :)

> > If you add some kind of networking via I2C you can send a kind of e-mail.
>
> There is even a ethernet connection possible (with IP etc). Hardware
> exists.

TCP/IP needs a _lot_ of memory (800 bytes) and ethernet is not only rather 
expensive, but it also takes quite a lot of power. My idea would be to have a 
tiny stripped down networking protocoll which can work with tiny buffers. I2C 
can already do quite a bit of what we want. For example it already forces the 
slave to acknownledge the bytes. A master could just send bytes until the 
slave doesn't acknownledge anymore.
As I2C is multi-master we can essentially use it like Ethernet.
We can still define a "gateway-protocoll" in which you can contact 
a "router-node" and tell it to forward your connection.

> Bye
> Matthias

Servus
  Casandro

Re: [Amforth-devel] Video quod vadis

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

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

Hi Christian,

Christian Berger wrote:
> Servus, (=bavarian for hello and goodbye)
> 
> as you may know I have written some video routines for amforth (currently 
> seperate).

If you have any updates, you can send them to me (directly).

> I now wonder what direction we should go with them. There are already some 
> routines hidden in the repository.

I'm happy to sit-and-wait and nitpick the cherries ;=)

> If we would then also have the block commands, amforth would be on its way 
> towards a fully functional desktop operating system. :)

(Standard-) blocks are somewhat difficult since they need a lot of RAM
for the buffer(s). IMHO blocks can only be used with external RAM and/or
a modified RAM - Fetch/Store to emulate a MMU with paging.

> Seriously if you can edit blocks, and send them to a printer

I doubt that a windows el-cheapo GDI printer will ever work ;=)
Postscript OTOH may work well, esp for a forth system ...

> If you add some kind of networking via I2C you can send a kind of e-mail.

There is even a ethernet connection possible (with IP etc). Hardware
exists.

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

iD8DBQFINxcE9bEHdGEMFjMRAjVzAJ4hVFUPKL/pxMlssrkC/A3iTuSdOwCgw+UJ
VW/FLwsl5w3B5IFLQ7rnbFQ=
=qUM2
-----END PGP SIGNATURE-----

[Amforth-devel] Video quod vadis

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

Servus, (=bavarian for hello and goodbye)

as you may know I have written some video routines for amforth (currently 
seperate).
I now wonder what direction we should go with them. There are already some 
routines hidden in the repository.
My personal vision is to have video output at 64x16 plus a status line 
(technically possible) so we can display forth blocks directly. This would 
save a lot of memory. 
If we would then also have the block commands, amforth would be on its way 
towards a fully functional desktop operating system. :)
Seriously if you can edit blocks, and send them to a printer, you can already 
write letters with your system. Now add a simple database, and you can do 
mass-mailings.
If you add some kind of networking via I2C you can send a kind of e-mail.

What do you think?

Servus
  Casandro

Re: [Amforth-devel] amforth-uptload.py tool

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

Hi,

just for the records:
> I'd recommend setserial. minicom IIRC resets the serial settings when
> shutting down.

You can prevent minicom from "initializing the modem" by 
using the "-o" Option. Check the documentation for details.

You can exit from minicom without resetting the serial 
interface with "C-A Q".


Cheers,
Erich

Re: [Amforth-devel] amforth-uptload.py tool

[Bernard M. <bme...@gm...>]

Hi Mathias,

Thanks for that. I used stty to set the serial baud rate, as it is not very
apparent how to do that with setserial reading the manpage.

The atmega128 system works great now, I have used the macros.asm file that
you checked in the other day to sort out the temp7 issue. I will email the
atmega128.asm file to your address for inclusion in future releases.

Cheers,
Bernard

On Fri, May 9, 2008 at 6:02 PM, Matthias Trute <mt...@we...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bernard,
>
> > 1. I use the utility as "amforth-upload.py filename.frt" (where
> filename.frt
> > is the forth code), is this correct,  the -h help returned indicates this
> is
> > all you do.
>
> I add the -t parameter for the port every time (even for ttyS0) to be
> sure to send the files to the correct port.
>
> > 2. If this utility  uses the serial device /dev/ttyS0, how  does it set
> up
> > the baud rate, there is no facility in the script to do that.
> > (I tried using minicom to set up the baud rate for the port, then use the
> > -f(force) option with the script, but still nothing ....
>
> I'd recommend setserial. minicom IIRC resets the serial settings when
> shutting down. The upload utility itself does not change the serial
> settings.
>
> Bye
> Matthias
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFII+jr9bEHdGEMFjMRAjxOAKDIETGZdp4hxaoiBXoI7vhAiHtnmwCgm30k
> IOrxEI69rcSU9q9ai7VKPj8=
> =+WO8
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] amforth-uptload.py tool

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

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

Bernard,

> 1. I use the utility as "amforth-upload.py filename.frt" (where filename.frt
> is the forth code), is this correct,  the -h help returned indicates this is
> all you do.

I add the -t parameter for the port every time (even for ttyS0) to be
sure to send the files to the correct port.

> 2. If this utility  uses the serial device /dev/ttyS0, how  does it set up
> the baud rate, there is no facility in the script to do that.
> (I tried using minicom to set up the baud rate for the port, then use the
> -f(force) option with the script, but still nothing ....

I'd recommend setserial. minicom IIRC resets the serial settings when
shutting down. The upload utility itself does not change the serial
settings.

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

iD8DBQFII+jr9bEHdGEMFjMRAjxOAKDIETGZdp4hxaoiBXoI7vhAiHtnmwCgm30k
IOrxEI69rcSU9q9ai7VKPj8=
=+WO8
-----END PGP SIGNATURE-----

[Amforth-devel] amforth-uptload.py tool

[Bernard M. <bme...@gm...>]

Hi All,

I am trying to use the above tool to download some forth (.frt) files to my
target atmel128  based board.

When I try to use this utility (Linux box, standard port /dev/ttyS0) it just
does nothing, no error messages .. nothing, have to CTL-C to get out.

Some questions:

1. I use the utility as "amforth-upload.py filename.frt" (where filename.frt
is the forth code), is this correct,  the -h help returned indicates this is
all you do.
2. If this utility  uses the serial device /dev/ttyS0, how  does it set up
the baud rate, there is no facility in the script to do that.
(I tried using minicom to set up the baud rate for the port, then use the
-f(force) option with the script, but still nothing ....

Hopefully someone has used this utility can tell me what I am doing wrong ..


Thanks,
Bernard

Re: [Amforth-devel] at90can128

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

Hi all,

> I'm currently trying to set up Amforth on an AT90CAN128 evaluation board,
> and was very thankful for your input yesterday.

That was helpful indeed. Thanks to all that found it out. The reason
that amforth does not work on 128KB flash controllers is that
temp7 is mapped to zl. My strong believe that the warning the
assembler produces can be ignored was based upon the fact
that amforth works fine on smaller atmegas. This and that I did not
tested the final release on the atmega128 but a intermediate version
with the 2.7 version prompt led to the confusion. Sorry about that.


> Changing temp7 to temp5 in the macro definitions only does part of the
> trick.

Well, it does not really solves the problem. This evening I'll
commit a change into the repository that solves the problem (hopefully,
I'll _do_ the test on my can128).

> compile a definition as simple as this:
>
>    : test 1 2 + . ;

This particular problem is in the division routines. They use
all the tempx registers, so mixing temp5 with temp7 disruptes the
division completly. And division is used in number conversion...

> I'm a bit perplexed on why the colon compiler code should work on an
> ATmega32.

The problem is not related with the colon compiler.


Bye
Matthias

Re: [Amforth-devel] at90can128

[Stefan H. <ste...@ya...>]

Oops. Have to correct myself.

The ATMega32 and the AT90CAN32 are different in a number of ways, judging from a diff I made between the device definitions in the AVRA library. So, as a working model I hazard to guess that the AT90CAN32 will not work with amforth, too, but the ATmega32 should be.

Can anyone confirm whether the ATmega128 works?

Have a nice day,

Stefan


      E-Mails jetzt auf Ihrem Handy.
www.yahoo.de/go

Re: [Amforth-devel] at90can128

[Stefan H. <ste...@ya...>]

Hello, Lars and Bernard, and hi rest,

I'm currently trying to set up Amforth on an AT90CAN128 evaluation board, and was very thankful for your input yesterday.

Changing temp7 to temp5 in the macro definitions only does part of the trick. While it /does/ provide for a pleasant command prompt which works normally, the colon compiler does hang or not terminate when trying to compile a definition as simple as this:

   : test 1 2 + . ;

I tried to increase the delay between characters, inter-line-delay does not come into account as its only one line. Perhaps there's still a problem with temp6 or further registers that are already mapped to different purposes for the AT90CANxxx and ATmega128 (and probably the ATmega64).

I'm a bit perplexed on why the colon compiler code should work on an ATmega32. As far as I understood, the AT90CANxxx are the same as the corresponding ATmegaxxx, with the CAN hardware added. And that the ATmega{32,64,128} differ only in Flash, EPROM and RAM size. For an AVR Butterfly, everything works like a charm.

Have a nice day,

Stefan



      Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: 
http://de.yahoo.com/set

Re: [Amforth-devel] Amforth-devel Digest, Vol 10, Issue 1 / ATmega256

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

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

Guten Morgen Matthias.

Am 06.05.2008 um 22:11 schrieb amforth-devel- 
re...@li...:
...
> The 128KB boundary may
> fall too, but currently I have only some vague ideas how to do it and
> (more important) no hardware to play with.

Hm, hast du ein Board um einen ATmega2560 oder ATmega2561 zu stecken?  
Oder müsste auch ein Board her?

Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFIIUgwJ3DLQCvSXtcRAsP9AJ9/FgNYEKopUKz17cjIHkwLczi4WACffdqQ
1GQdmbWAdQlhxWO3kTHW+gw=
=dlrB
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Amforth-devel Digest, Vol 10, Issue 1

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

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

Hi.

Am 06.05.2008 um 22:11 schrieb amforth-devel- 
re...@li...:
> ...
>> On a similar vein, is there a list of devices published  
>> thatamforth "will"
>> be able to be run on given it's current architecture.
>
> There is no official list since I don't have access to every type
> of controller and cannot test each and every version.

Maybe you like forth-ev wiki and use it for a lineup?:
http://www.forth-ev.de/wiki/doku.php/projects:avr:lineup

Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFIIURaJ3DLQCvSXtcRApceAKCfCnKlugXypyd0CEfFCVcvSq3nUgCeKKJ7
LTO1pLBXXAjSH42BtjsLJnM=
=LZA0
-----END PGP SIGNATURE-----

Re: [Amforth-devel] at90can128

[Bernard M. <bme...@gm...>]

Thanks heaps Lars,

I thought I had done something wrong in my porting of the at9can128.asm to
my atmega128.asm file, you are correct temp7 is trashing the zh register, I
confirmed that by
running AVR studio and debugging the code in the simulator. The device
resets each time after DO_EXECUTE, changing to temp5 makes the code run
normal.

I will try it on the mega128 hardware when I get home tonight.

I notice that both temp6 and temp7 overlap r30/r31 so maybe we need to get
rid of both temp6 and temp7.....

Regards,
Bernard.

On Tue, May 6, 2008 at 11:28 PM, Lars Jonsson <la...@ze...> wrote:

> Hi,
> Maybe this is some regression (it must have worked some time I guess): I
> had
> a look the at at90can128.asm file and the readflashcell and writeflashcell
> will not work, they trash the zh register since temp7 is the same as zh.
> Maybe just change to e.g. temp5.
>  /Lars Jonsson
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth-devel] at90can128

[Lars J. <la...@ze...>]

Hi,
Maybe this is some regression (it must have worked some time I guess): I had
a look the at at90can128.asm file and the readflashcell and writeflashcell
will not work, they trash the zh register since temp7 is the same as zh.
Maybe just change to e.g. temp5.
  /Lars Jonsson

Re: [Amforth-devel] do_next

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

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

Kalus Michael schrieb:
> Moin.
>
> Ich versuche gerade das DO_NEXT des amforth zuverstehen. Suchen in 
> der mailing list ergab dazu "no result". Gibt es da ein link zu einer 
> Erklärung?
Das ist exakt genauso wie in Ron Minkes Beschreibung in
der VD.

>
> Kommentiert (aber nicht unbedingt verstanden) habe ich das bisher so:
>
>
>            DO_NEXT: ; 24 CPU cycles to ijmp
> C:001c0e f06e          brts DO_INTERRUPT
> C:001c0f 01fd          movw zl, XL        ; READ IP:   Z <-- IP
...

Der Generierte Code ist schwerer lesbar als der eigentliche Quelltext
mit den Makros.
>
> IP ist ein 16Bit Zähler.
> - Warum wird der x2 genommen um von der so ermittelten Addresse im 
> Flash den Wert für W zu holen?
AVR 8Bit Microcontrollerbesonderheit. Der Flash besteht
aus 16bit Zellen, die zugehörige lpm (load program memory)
liest aber 8bit weise.
> - Der Wert in W ist nun ein Zeiger dorthin, wo der ausführbare Code 
> beginnt, oder?
Siehe Ron Minkes Artikel

> Irgendwie blicke ich gerade nicht durch. Ist das nicht eine Stufe 
> zuviel "indirect threading code" ?
Da es funktioniert, müsste eigentlich stimmen ;=)

Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIGgpx9bEHdGEMFjMRAl2gAKCYKCUCyX7biiygAO0Pm4ptcfs63ACfbDhw
tTBiWyHoND/wBwNNx6fQlOk=
=Q+Fa
-----END PGP SIGNATURE-----

[Amforth-devel] do_next

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

Moin.

Ich versuche gerade das DO_NEXT des amforth zuverstehen. Suchen in  
der mailing list ergab dazu "no result". Gibt es da ein link zu einer  
Erklärung?

Kommentiert (aber nicht unbedingt verstanden) habe ich das bisher so:


           DO_NEXT: ; 24 CPU cycles to ijmp
C:001c0e f06e          brts DO_INTERRUPT
C:001c0f 01fd          movw zl, XL        ; READ IP:   Z <-- IP
C:001c10   +      readflashcell wl, wh
C:001c10 0fee      lsl zl		  ; Z*2
C:001c11 1fff      rol zh
C:001c12 9185      lpm wl, Z+		  ; w <-- (Z)
C:001c13 9195      lpm wh, Z+
C:001c14 9611          adiw XL, 1        ; INC IP

           DO_EXECUTE: ; 12 cpu cycles to ijmp
C:001c15 01fc          movw zl, wl		; Z <-- W
C:001c16   +      readflashcell temp0,temp1
C:001c16 0fee      lsl zl			; Z*2
C:001c17 1fff      rol zh
C:001c18 9105      lpm temp0, Z+		; temp <-- (Z)
C:001c19 9115      lpm temp1, Z+
C:001c1a 01f8          movw zl, temp0		; Z <-- temp
C:001c1b 9409          ijmp			; jump (Z)


Da gibt es also 3 indirekte Ladevorgäng und gleich 2x die  
Multiplikation mit 2.

IP ist ein 16Bit Zähler.
- Warum wird der x2 genommen um von der so ermittelten Addresse im  
Flash den Wert für W zu holen?
- Der Wert in W ist nun ein Zeiger dorthin, wo der ausführbare Code  
beginnt, oder?
Warum muss der wiederum erst noch x2 genommen werden, um dann über  
diesen Zeiger einen Zeiger zu holen von dort den PC zu laden?

Irgendwie blicke ich gerade nicht durch. Ist das nicht eine Stufe  
zuviel "indirect threading code" ?


Michael