amforth-devel — Development discussion and user support

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

Re: [Amforth-devel] ATmega103?

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

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

Hi,

Bernard Mentink wrote:

> Can someone tell me if the ATmega103 device is supported to run amforth? On
> initial inspection of the m103def.inc file, there doesn't seem to be a NRWW
> bootloader
> area, if this is the case does that mean amforth will not work with this
> part?

If a bootloader for in-system-programming exists for this device,
amforth should be able to run on it as well, but may require
some more work.

> 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. The files in
the device directory are (more or less) regularly tested and produced
at least one working system. Internally I use some other devices but
they are not well tested or do not work at all (e.g. at90usb on the
ATUSBKEY sample hardware).

If you want to use another controller, just create a device file
similiar to the existing ones. If you want it to be included with
amforth, send it to me and I'll happily put it in.

Basically amforth is only limited by the architecture (atmega cores with
hardware multiplier and some instructions) and the flash size. An
Atmega48  is too small (amforth needs around 7 KB flash for itself) and
everything with more than 128 KB is to big. Attinys lack some core
features (and flash size), atxmegas may work rsn. 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.

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

iD8DBQFIGXAD9bEHdGEMFjMRAokRAJ4wHGL7X4aVRwtREBGA/QmQU5OSHwCdEuQP
cHoQeSTbwCqI/VFUZsuzYAE=
=9FkE
-----END PGP SIGNATURE-----

Re: [Amforth-devel] Cannot get serial prompt on an Atmega128 device (STK500/501) development board

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

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

Bernard,

> My assemble looks ok, output:
> ----------------------------------------------------
> wine ~/amForth/AvrAssembler2/avrasm2.exe -I ~/amForth/AvrAssembler2/Appnotes
> -I ~/lib/avra -I ../../core -fI -v1 -W+iw  -e bf.eep.hex -l bf.lst bf.asm
> fixme:ntdll:find_reg_tz_info Can't find matching timezone information in the
> registry for bias -720, std (d/m/y): 6/04/2008, dlt (d/m/y): 28/09/2008
> /home/bmentink/amForth/AvrAssembler2/Appnotes\m128def.inc(1140): warning:
> Register r31 already defined by the .DEF directive
> /home/bmentink/amForth/AvrAssembler2/Appnotes\m128def.inc(1141): warning:
> Register r30 already defined by the .DEF directive
> 
> Assembly complete, 0 errors. 2 warnings
> --------------------------------------------------------

The warnings can be ignored, they do no harm.


> I have attached the makefile I used, the custom bf.asm, and the
> atmega128.asm file I created.

This maillinglist drops attachments. You could send them directly to
me, but I don't have access to a real atmega128, so I cannot test them.

> I can download the bf.hex file to the device fine, but on hooking up the
> RS232 to PE0,PE1 (Rd,Tx) I cannot see any prompt
> in minicom (set to 9600 8N1).

You may double check that you really use the usart0 port. When I got
my first atmega128 style controller board, I connected the usart1 and
programmed usart0. Took a few hours to find out and another one to roll
back the changes I made... :=(

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

iD8DBQFIGWyU9bEHdGEMFjMRAvKGAKDjoGpBO6FRHIt0Rk+mU5oJaMlVYwCgx906
Vs5YpYFmaj6/QNpqT0G9YDY=
=2u0P
-----END PGP SIGNATURE-----

[Amforth-devel] Cannot get serial prompt on an Atmega128 device (STK500/501) development board

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

Hi All,

I am having lots of problems trying to get amforth running on an ATmega128
on an stk500/501 combo devel board.

My assemble looks ok, output:
----------------------------------------------------
wine ~/amForth/AvrAssembler2/avrasm2.exe -I ~/amForth/AvrAssembler2/Appnotes
-I ~/lib/avra -I ../../core -fI -v1 -W+iw  -e bf.eep.hex -l bf.lst bf.asm
fixme:ntdll:find_reg_tz_info Can't find matching timezone information in the
registry for bias -720, std (d/m/y): 6/04/2008, dlt (d/m/y): 28/09/2008
/home/bmentink/amForth/AvrAssembler2/Appnotes\m128def.inc(1140): warning:
Register r31 already defined by the .DEF directive
/home/bmentink/amForth/AvrAssembler2/Appnotes\m128def.inc(1141): warning:
Register r30 already defined by the .DEF directive

Assembly complete, 0 errors. 2 warnings
--------------------------------------------------------

I have attached the makefile I used, the custom bf.asm, and the
atmega128.asm file I created.
I have set the fuses to use the internal osc at 8Mhz.

If anyone has the time, please have a look over those files to see if
anything is amis.

I can download the bf.hex file to the device fine, but on hooking up the
RS232 to PE0,PE1 (Rd,Tx) I cannot see any prompt
in minicom (set to 9600 8N1).

Any help much appreciated.

Cheers,
Bernard Mentink

[Amforth-devel] ATmega103?

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

Hi,

Can someone tell me if the ATmega103 device is supported to run amforth? On
initial inspection of the m103def.inc file, there doesn't seem to be a NRWW
bootloader
area, if this is the case does that mean amforth will not work with this
part?

On a similar vein, is there a list of devices published thatamforth "will"
be able to be run on given it's current architecture.

Thanks,
Bernard Mentink

Re: [Amforth-devel] XMEGA

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

Ok, so the existing assembler should work fine. On first glance I do see
some differences, the main one is that the interrupt vectors are 4 bytes
apart not two bytes apart as in the other devices.
Also, the names in ATxmega128A1.inc a quite a bit different so names in the
.asm files will have to change accordingly ..

On Tue, Apr 29, 2008 at 6:20 PM, Matthias Trute <mt...@we...> wrote:

>
> > Quick question: Does amforth support the XMEGA with just the addition of
> > the
> > .asm in the /devices folder and the appropriate .inc file from ATMEL
> > Studio?
>
> I hope so, but do not know it. The assembler code works with
> very little modifications (mostly regarding the serial interface).
>
> > Or is a bit harder than that?
>
> maybe, but Atmel mentioned that existing atmega code works for atxmega
> without modifications.
>
> bye
> Matthias
>
>
>
> -------------------------------------------------------------------------
> 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] avrdude error downloading image

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

Bernard,

debugging hardware remotly is difficult. Did you check google, there
was a short discussion around this with some possible reasons that cause
a serial line to not work, the most stupid one is probably keeping
the programmer connected (that may keep the reset line).

> I have a 16mhz crystal connected to an external oscillator which feeds the
> chip via XTAL1. Using the link you mentioned I get LFUSE = 0xC0 HFUSE=
> 0xD9
> nad EFUSE= 0xff, is this correct?

Cannot check, but the calculator works fine, usually.

> Not sure what to debug next.

just join on #forth-ev this evening

Bye
Matthias

Re: [Amforth-devel] avrdude error downloading image

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

Thanks Mathias,

I have a 16mhz crystal connected to an external oscillator which feeds the
chip via XTAL1. Using the link you mentioned I get LFUSE = 0xC0 HFUSE= 0xD9
nad EFUSE= 0xff, is this correct?

I then added these values to the sample makefile and did a "make write-fuse"
and then reset the device. I also have frequency=16000000 in the bf.asm
file.

I still have no activity out the serial port. I am using miniterm and a
loopback on the cable works fine at 9600 baud (what I have in bf.asm).

Not sure what to debug next.

Thanks again,
Bernard

On Tue, Apr 29, 2008 at 8:06 PM, Matthias Trute <mt...@we...> wrote:

>
> > 1. the line ".equ cpu_frequency = 8000000" in the bf.asm file, is that
> the
> > crystal frequency of the crystal frequency devided by two?
>
> That is the frequency, the controller runs with in Hz. which
> clock source is used and the possible clock modification depend
> on the fuse settings. http://palmavr.sf.net/cgi-bin/fc.cgi
> may be useful here.
>
> Keep in mind, that the usart interface has a 2x setting that doubles
> the baudrate, but this is unused in the default sources.
>
> btw: The template directory is a much better starting point since the
> relevant files are better documented.
>
> > 2. Which serial port of the mega128 device will I expect the forth to
> use?
>
> If you use the default sources, connect with usart0.
>
> Bye
> Matthias
>
>
> -------------------------------------------------------------------------
> 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] avrdude error downloading image

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

> 1. the line ".equ cpu_frequency = 8000000" in the bf.asm file, is that the
> crystal frequency of the crystal frequency devided by two?

That is the frequency, the controller runs with in Hz. which
clock source is used and the possible clock modification depend
on the fuse settings. http://palmavr.sf.net/cgi-bin/fc.cgi
may be useful here.

Keep in mind, that the usart interface has a 2x setting that doubles
the baudrate, but this is unused in the default sources.

btw: The template directory is a much better starting point since the
relevant files are better documented.

> 2. Which serial port of the mega128 device will I expect the forth to use?

If you use the default sources, connect with usart0.

Bye
Matthias

Re: [Amforth-devel] avrdude error downloading image

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

Hi Mathias,

Thanks but I found that setting the device flag to "-c stk200" solved the
issue and downloading and verification finished fine.

I am now trying to get a prompt out of the Forth via the serial port. I have
a couple of questions:

1. the line ".equ cpu_frequency = 8000000" in the bf.asm file, is that the
crystal frequency of the crystal frequency devided by two?

2. Which serial port of the mega128 device will I expect the forth to use?

Thanks,
Bernard

On Tue, Apr 29, 2008 at 6:18 PM, Matthias Trute <mt...@we...> wrote:

>
> > Hi All,
> >
> > I have an STK500/STK501 and am trying to load a forth image to the
> > atmega128
> > that is on the STK501.
> > I have modified the bf.asm file etc for this micro and everything
> > assembles
> > ok on a Linux host.
> >
> > The problem is communication to the parallel port doesn't seem to work,
> > anyone have any suggestions?
>
> Looks like a permission problem on the parport device. You may try
> running avrdude as root (sudo recommended). Otherwise you may need
> to contact the avrdude folks.
>
> Bye
> Matthias
>
>
>
> -------------------------------------------------------------------------
> 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] Deferred number?

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

> Matthias,
>
> Thanks for the personal reply.
>
>> emit/key and friends are deferred since they should easily
>> re-targettable from the serial to say can or I2C. For number
>> there was so such scenario. Why do you want to behave number
>> differently? A solution could be to CATCH conversion errors,
>> since number THROWs on them
>
>... or to allow entering double precision numbers.

That may be added into the main-stream code base sometimes. Feel
free to send a patch ;=) But note, that the number conversion in
amforth is only good enough and not fully standard compatible...

> Of course I am only playing, but when I used Forth as a sort of
> super-monitor on an embedded system controlling a lathe I did this to
> allow me to enter hex as $abcd whilst keeping BASE set to 10.

Ahh. There are ongoing standardization tasks running with the
forth2000x folks on this topic, and I remender a (short) discussion
in the usenet (clf) this year around this topic too. We'll see, what will
happen.

bye
Matthias

Re: [Amforth-devel] XMEGA

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

> Quick question: Does amforth support the XMEGA with just the addition of
> the
> .asm in the /devices folder and the appropriate .inc file from ATMEL
> Studio?

I hope so, but do not know it. The assembler code works with
very little modifications (mostly regarding the serial interface).

> Or is a bit harder than that?

maybe, but Atmel mentioned that existing atmega code works for atxmega
without modifications.

bye
Matthias

Re: [Amforth-devel] avrdude error downloading image

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

> Hi All,
>
> I have an STK500/STK501 and am trying to load a forth image to the
> atmega128
> that is on the STK501.
> I have modified the bf.asm file etc for this micro and everything
> assembles
> ok on a Linux host.
>
> The problem is communication to the parallel port doesn't seem to work,
> anyone have any suggestions?

Looks like a permission problem on the parport device. You may try
running avrdude as root (sudo recommended). Otherwise you may need
to contact the avrdude folks.

Bye
Matthias

[Amforth-devel] avrdude error downloading image

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

Hi All,

I have an STK500/STK501 and am trying to load a forth image to the atmega128
that is on the STK501.
I have modified the bf.asm file etc for this micro and everything assembles
ok on a Linux host.

The problem is communication to the parallel port doesn't seem to work,
anyone have any suggestions?

The error is:
-------------------------------------------------------------------
make: *** [bf] Error 1
bmentink@laptop:~/amForth/amforth-2.7/appl/avr-STK500$ make bf
avrdude -c stk500  -P /dev/parport0 -p atmega128 -e -U flash:w:bf.hex:i -U
eeprom:w:bf.eep.hex:i
avrdude: ser_open(): can't set attributes for device "/dev/parport0":
Inappropriate ioctl for device
make: *** [bf] Error 1

Thanks,
Bernard.

Re: [Amforth-devel] Deferred number?

[Tom H. <cel...@gm...>]

Matthias,

Thanks for the personal reply.

> emit/key and friends are deferred since they should easily
> re-targettable from the serial to say can or I2C. For number
> there was so such scenario. Why do you want to behave number
> differently? A solution could be to CATCH conversion errors,
> since number THROWs on them

One reason would be to allow the entering of different number bases
whatever BASE is set to, or to allow entering double precision
numbers.

Of course I am only playing, but when I used Forth as a sort of
super-monitor on an embedded system controlling a lathe I did this to
allow me to enter hex as $abcd whilst keeping BASE set to 10.

Regards

Tom Harris <cel...@gm...>

[Amforth-devel] XMEGA

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

Quick question: Does amforth support the XMEGA with just the addition of the
.asm in the /devices folder and the appropriate .inc file from ATMEL Studio?
Or is a bit harder than that?

Regards,
Bernard

Re: [Amforth-devel] AT90CAN128 Forth code

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

Thanks Mathias,

I may just do that. In the same vein, is there a mega128.asm around
somewhere?
If not I may create one using the at90can128.asm as a guide (I know there is
the associated m128def.inc file supplied by the atmel studio install).

Cheers,
Bernard.

On Mon, Apr 28, 2008 at 4:48 PM, Matthias Trute <mt...@we...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bernard Mentink wrote:
> > Hi All,
> >
> > Has anyone written and Forth code to support the CAN perpheral on this
> > device?
>
> The mcu core is supported, the perpheral to my knowledge not (yet).
>
> You are welcome to contribute it ;=)
>
> Matthias
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIFVcl9bEHdGEMFjMRAoWLAJoDw8ARTXxPA2QhqT3HOIFDXDh5rwCfRLcq
> 5nePEafyN1h6Q+VYtRKCb9w=
> =nQ3+
> -----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] Deferred number?

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

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

Tom Harris wrote:
> Greetings,
> 
> I am still trying to find my way around amforth, after a 20 year gap
> since I last used Forth. I have what I suspect is a stupid question.
> 
> On the Forth I last used I remember that the number word was vectored
> via a variable 'number, so that you could replace the number parser.
> Amforth does not use a deferred word for number, so it is not possible
> to replace number, is this correct? I can redefine number, but any
> previous usages of number, like the all-important quit word will still
> use the old definition. Is there a reason why number was not deferred
> like emit, key, pause, etc.?

emit/key and friends are deferred since they should easily
re-targettable from the serial to say can or I2C. For number
there was so such scenario. Why do you want to behave number
differently? A solution could be to CATCH conversion errors,
since number THROWs on them

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

iD8DBQFIFVfh9bEHdGEMFjMRAjClAKCJqDErXIVFGpUqXJf8f2OLfYy1mgCgpSQL
SZ+Rb2gJc+9XJiXPjG1gPB8=
=Xizt
-----END PGP SIGNATURE-----

Re: [Amforth-devel] AT90CAN128 Forth code

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

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

Bernard Mentink wrote:
> Hi All,
> 
> Has anyone written and Forth code to support the CAN perpheral on this
> device?

The mcu core is supported, the perpheral to my knowledge not (yet).

You are welcome to contribute it ;=)

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

iD8DBQFIFVcl9bEHdGEMFjMRAoWLAJoDw8ARTXxPA2QhqT3HOIFDXDh5rwCfRLcq
5nePEafyN1h6Q+VYtRKCb9w=
=nQ3+
-----END PGP SIGNATURE-----

[Amforth-devel] Deferred number?

[Tom H. <cel...@gm...>]

Greetings,

I am still trying to find my way around amforth, after a 20 year gap
since I last used Forth. I have what I suspect is a stupid question.

On the Forth I last used I remember that the number word was vectored
via a variable 'number, so that you could replace the number parser.
Amforth does not use a deferred word for number, so it is not possible
to replace number, is this correct? I can redefine number, but any
previous usages of number, like the all-important quit word will still
use the old definition. Is there a reason why number was not deferred
like emit, key, pause, etc.?


On the bright side, what other language allows you to have enough
knowledge to poke around in the internals after a few days spent
learning it?

TomH

[Amforth-devel] AT90CAN128 Forth code

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

Hi All,

Has anyone written and Forth code to support the CAN perpheral on this
device?

Thanks,
Bernard Mentink