amforth-devel — Development discussion and user support

Re: [Amforth] error uploading ports-standard.frt

[J. B. <jpu...@gm...>]

Thanks, Martin + Tristan.

After reading »synonym is available since amforth 5.0« I did expect that it
is included already.

so I've tried ports-standard.frt . Worked after \-ing analog.6 and analog.7
.
Perhaps a somewhat more explicit comment would help.

PS: the PDF from Trute is very nice, because I have a lot of info in 1
document.
PS2: 'drop' is not(?) for removing defined words, it's forget → marker
empty (?)
PS3: it's ports-standard.frt, not ports-arduino.frt as per documentation.
PS4: perhaps we could add the library path to amforth-shell.py - making it
easier for beginners(?)

Kind regards, Jochen





Am Sa., 9. Aug. 2025 um 15:03 Uhr schrieb Martin Nicholas via Amforth-devel
<amf...@li...>:

> On Sat, 9 Aug 2025 13:57:33 +0200
> "J. Barth" <jpu...@gm...> wrote:
>
> > Hi, my name is Jochen,
> > I've tried to upload ports-standard.frt to my (arduino) uno to access
> > the adc.
> >
> > Did use amforth-6.9 with uno.hex and uno.eep.hex (manually, done
> > before reading the manual).
> >
> > (Had to add -I /home/user_xyz/.../amforth-6.9/common/lib , without it
> > did not find some #require files)
> >
> > see below:
> >
> > ./amforth-shell-upload.sh $(./amforth-dependencies.pl
> > ports-standard.frt)
> > + ../amforth-6.9/tools/amforth-shell.py -p /dev/ttyUSB0 -I
> > /home/jb/forth/amforth-6.9/common/lib
> > ../amforth-6.9/appl/arduino/blocks/ports-standard.frt
> > |I=appl_defs: 0 loaded
> > |I=getting filenames on the host
> > |I=  Reading .
> > |I=  Reading /home/jb/forth/amforth-6.9/common/lib
> > |I=using ../amforth-6.9/appl/arduino/blocks/ports-standard.frt
> > verbatim **** /home/jb/forth/my-amforth
> > |I=getting MCU name..
> > |I=successfully loaded register definitions for atmega328p
> > |I=getting filenames on the host
> > |I=  Reading /home/jb/forth/amforth-6.9/avr8/devices/atmega328p
> > |I=  Reading /home/jb/forth/amforth-6.9/avr8/lib
> > |I=  Reading .
> > |I=  Reading /home/jb/forth/amforth-6.9/common/lib
> > |F=../amforth-6.9/appl/arduino/blocks/ports-standard.frt
> > |C|    1|\
> > |C|    2|\ port definitions for Atmegas as found on the Arduino
> > Standard |C|    3|\ Atmega168, Atmega328p
> > |C|    4|\
> > |S|    5|decimal
> > |W|    6|
> > |S|    7|PORTD 0 portpin: digital.0
> > |S|    8|PORTD 1 portpin: digital.1
> > |S|    9|PORTD 2 portpin: digital.2
> > |S|   10|PORTD 3 portpin: digital.3
> > |S|   11|PORTD 4 portpin: digital.4
> > |S|   12|PORTD 5 portpin: digital.5
> > |S|   13|PORTD 6 portpin: digital.6
> > |S|   14|PORTD 7 portpin: digital.7
> > |W|   15|
> > |S|   16|PORTB 0 portpin: digital.8
> > |S|   17|PORTB 1 portpin: digital.9
> > |S|   18|PORTB 2 portpin: digital.10
> > |S|   19|PORTB 3 portpin: digital.11
> > |S|   20|PORTB 4 portpin: digital.12
> > |S|   21|PORTB 5 portpin: digital.13
> > |W|   22|
> > |S|   23|PORTC 0 portpin: digital.14
> > |S|   24|PORTC 1 portpin: digital.15
> > |S|   25|PORTC 2 portpin: digital.16
> > |S|   26|PORTC 3 portpin: digital.17
> > |S|   27|PORTC 4 portpin: digital.18
> > |S|   28|PORTC 5 portpin: digital.19
> > |W|   29|
> > |C|   30|\ some digital ports have an alternative use
> > |C|   31|\ synonym is available since amforth 5.0
> > |S|   32|synonym SPI:SS   digital.10
> > |E= ?? -13 7
> > **** /home/jb/forth/amforth-6.9/appl/arduino/blocks
> >
> > Kind regards, Jochen
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
> >
>
> Have a look at:
> https://amforth.sourceforge.net/faq.html#what-means
> https://forth-standard.org/standard/tools/SYNONYM
>
> Error -13 means "Word not found". You need to load:
> ./common/lib/forth2012/tools/synonym.frt
>
> You can faultfind this sort of thing
> by typing the following:
> " ' synonym drop"
> An error means synonym isn't found. The above snippet avoids executing
> synonym should it actually be present.
>
> Hope this helps.
>
> --
> Regards,
>
> Martin Nicholas.
>
> E-mail: rep...@mg... (Address will be valid throughout 2025).
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] error uploading ports-standard.frt

[Martin N. <amf...@mg...>]

For a numerical list of exceptions:
https://forth-standard.org/standard/exception

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg... (Address will be valid throughout 2025).

Re: [Amforth] error uploading ports-standard.frt

[<ho...@tj...>]

Hi Jochen and welcome.

AmForth is complaining when you upload ports-standard.frt because it 
cannot find the word synonym. This is not a built-in word and so needs 
to be uploaded before trying to upload ports-standard.frt
synonym can be found in this file

./common/lib/forth2012/tools/synonym.frt

To use the ADC will require some additional Forth words. Below is a link 
in the AmForth documentation (if you have not already found it)

https://amforth.sourceforge.net/TG/recipes/Arduino-Analog.html?highlight=adc

The ADC unit on the ATmega328P, the mcu which powers the UNO, does have 
more to offer than is made available in the above words. Whether that is 
important to you depends upon what you want to do and your appetite for 
reading the datasheet and modifying this set of Forth words.

> (Had to add -I /home/user_xyz/.../amforth-6.9/common/lib , without it 
> did
> not find some #require files)

tools/amforth-shell.py --help

amforth-shell.py can use the environment variable AMFORTH_LIB which 
helps with this.

Let us know how you get on.

Kind regards,
Tristan


On 2025-08-09 12:57, J. Barth wrote:
> Hi, my name is Jochen,
> I've tried to upload ports-standard.frt to my (arduino) uno to access 
> the
> adc.
> 
> Did use amforth-6.9 with uno.hex and uno.eep.hex (manually, done before
> reading the manual).
> 
> (Had to add -I /home/user_xyz/.../amforth-6.9/common/lib , without it 
> did
> not find some #require files)
> 
> see below:
> 
> ./amforth-shell-upload.sh $(./amforth-dependencies.pl 
> ports-standard.frt)
> + ../amforth-6.9/tools/amforth-shell.py -p /dev/ttyUSB0 -I
> /home/jb/forth/amforth-6.9/common/lib
> ../amforth-6.9/appl/arduino/blocks/ports-standard.frt
> |I=appl_defs: 0 loaded
> |I=getting filenames on the host
> |I=  Reading .
> |I=  Reading /home/jb/forth/amforth-6.9/common/lib
> |I=using ../amforth-6.9/appl/arduino/blocks/ports-standard.frt verbatim
> **** /home/jb/forth/my-amforth
> |I=getting MCU name..
> |I=successfully loaded register definitions for atmega328p
> |I=getting filenames on the host
> |I=  Reading /home/jb/forth/amforth-6.9/avr8/devices/atmega328p
> |I=  Reading /home/jb/forth/amforth-6.9/avr8/lib
> |I=  Reading .
> |I=  Reading /home/jb/forth/amforth-6.9/common/lib
> |F=../amforth-6.9/appl/arduino/blocks/ports-standard.frt
> |C|    1|\
> |C|    2|\ port definitions for Atmegas as found on the Arduino 
> Standard
> |C|    3|\ Atmega168, Atmega328p
> |C|    4|\
> |S|    5|decimal
> |W|    6|
> |S|    7|PORTD 0 portpin: digital.0
> |S|    8|PORTD 1 portpin: digital.1
> |S|    9|PORTD 2 portpin: digital.2
> |S|   10|PORTD 3 portpin: digital.3
> |S|   11|PORTD 4 portpin: digital.4
> |S|   12|PORTD 5 portpin: digital.5
> |S|   13|PORTD 6 portpin: digital.6
> |S|   14|PORTD 7 portpin: digital.7
> |W|   15|
> |S|   16|PORTB 0 portpin: digital.8
> |S|   17|PORTB 1 portpin: digital.9
> |S|   18|PORTB 2 portpin: digital.10
> |S|   19|PORTB 3 portpin: digital.11
> |S|   20|PORTB 4 portpin: digital.12
> |S|   21|PORTB 5 portpin: digital.13
> |W|   22|
> |S|   23|PORTC 0 portpin: digital.14
> |S|   24|PORTC 1 portpin: digital.15
> |S|   25|PORTC 2 portpin: digital.16
> |S|   26|PORTC 3 portpin: digital.17
> |S|   27|PORTC 4 portpin: digital.18
> |S|   28|PORTC 5 portpin: digital.19
> |W|   29|
> |C|   30|\ some digital ports have an alternative use
> |C|   31|\ synonym is available since amforth 5.0
> |S|   32|synonym SPI:SS   digital.10
> |E= ?? -13 7
> **** /home/jb/forth/amforth-6.9/appl/arduino/blocks
> 
> Kind regards, Jochen
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] error uploading ports-standard.frt

[Martin N. <amf...@mg...>]

On Sat, 9 Aug 2025 13:57:33 +0200
"J. Barth" <jpu...@gm...> wrote:

> Hi, my name is Jochen,
> I've tried to upload ports-standard.frt to my (arduino) uno to access
> the adc.
> 
> Did use amforth-6.9 with uno.hex and uno.eep.hex (manually, done
> before reading the manual).
> 
> (Had to add -I /home/user_xyz/.../amforth-6.9/common/lib , without it
> did not find some #require files)
> 
> see below:
> 
> ./amforth-shell-upload.sh $(./amforth-dependencies.pl
> ports-standard.frt)
> + ../amforth-6.9/tools/amforth-shell.py -p /dev/ttyUSB0 -I
> /home/jb/forth/amforth-6.9/common/lib
> ../amforth-6.9/appl/arduino/blocks/ports-standard.frt
> |I=appl_defs: 0 loaded
> |I=getting filenames on the host
> |I=  Reading .
> |I=  Reading /home/jb/forth/amforth-6.9/common/lib
> |I=using ../amforth-6.9/appl/arduino/blocks/ports-standard.frt
> verbatim **** /home/jb/forth/my-amforth
> |I=getting MCU name..
> |I=successfully loaded register definitions for atmega328p
> |I=getting filenames on the host
> |I=  Reading /home/jb/forth/amforth-6.9/avr8/devices/atmega328p
> |I=  Reading /home/jb/forth/amforth-6.9/avr8/lib
> |I=  Reading .
> |I=  Reading /home/jb/forth/amforth-6.9/common/lib
> |F=../amforth-6.9/appl/arduino/blocks/ports-standard.frt
> |C|    1|\
> |C|    2|\ port definitions for Atmegas as found on the Arduino
> Standard |C|    3|\ Atmega168, Atmega328p
> |C|    4|\
> |S|    5|decimal
> |W|    6|
> |S|    7|PORTD 0 portpin: digital.0
> |S|    8|PORTD 1 portpin: digital.1
> |S|    9|PORTD 2 portpin: digital.2
> |S|   10|PORTD 3 portpin: digital.3
> |S|   11|PORTD 4 portpin: digital.4
> |S|   12|PORTD 5 portpin: digital.5
> |S|   13|PORTD 6 portpin: digital.6
> |S|   14|PORTD 7 portpin: digital.7
> |W|   15|
> |S|   16|PORTB 0 portpin: digital.8
> |S|   17|PORTB 1 portpin: digital.9
> |S|   18|PORTB 2 portpin: digital.10
> |S|   19|PORTB 3 portpin: digital.11
> |S|   20|PORTB 4 portpin: digital.12
> |S|   21|PORTB 5 portpin: digital.13
> |W|   22|
> |S|   23|PORTC 0 portpin: digital.14
> |S|   24|PORTC 1 portpin: digital.15
> |S|   25|PORTC 2 portpin: digital.16
> |S|   26|PORTC 3 portpin: digital.17
> |S|   27|PORTC 4 portpin: digital.18
> |S|   28|PORTC 5 portpin: digital.19
> |W|   29|
> |C|   30|\ some digital ports have an alternative use
> |C|   31|\ synonym is available since amforth 5.0
> |S|   32|synonym SPI:SS   digital.10
> |E= ?? -13 7
> **** /home/jb/forth/amforth-6.9/appl/arduino/blocks
> 
> Kind regards, Jochen
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 

Have a look at:
https://amforth.sourceforge.net/faq.html#what-means
https://forth-standard.org/standard/tools/SYNONYM

Error -13 means "Word not found". You need to load:
./common/lib/forth2012/tools/synonym.frt

You can faultfind this sort of thing
by typing the following:
" ' synonym drop"
An error means synonym isn't found. The above snippet avoids executing
synonym should it actually be present.

Hope this helps.

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg... (Address will be valid throughout 2025).

[Amforth] error uploading ports-standard.frt

[J. B. <jpu...@gm...>]

Hi, my name is Jochen,
I've tried to upload ports-standard.frt to my (arduino) uno to access the
adc.

Did use amforth-6.9 with uno.hex and uno.eep.hex (manually, done before
reading the manual).

(Had to add -I /home/user_xyz/.../amforth-6.9/common/lib , without it did
not find some #require files)

see below:

./amforth-shell-upload.sh $(./amforth-dependencies.pl ports-standard.frt)
+ ../amforth-6.9/tools/amforth-shell.py -p /dev/ttyUSB0 -I
/home/jb/forth/amforth-6.9/common/lib
../amforth-6.9/appl/arduino/blocks/ports-standard.frt
|I=appl_defs: 0 loaded
|I=getting filenames on the host
|I=  Reading .
|I=  Reading /home/jb/forth/amforth-6.9/common/lib
|I=using ../amforth-6.9/appl/arduino/blocks/ports-standard.frt verbatim
**** /home/jb/forth/my-amforth
|I=getting MCU name..
|I=successfully loaded register definitions for atmega328p
|I=getting filenames on the host
|I=  Reading /home/jb/forth/amforth-6.9/avr8/devices/atmega328p
|I=  Reading /home/jb/forth/amforth-6.9/avr8/lib
|I=  Reading .
|I=  Reading /home/jb/forth/amforth-6.9/common/lib
|F=../amforth-6.9/appl/arduino/blocks/ports-standard.frt
|C|    1|\
|C|    2|\ port definitions for Atmegas as found on the Arduino Standard
|C|    3|\ Atmega168, Atmega328p
|C|    4|\
|S|    5|decimal
|W|    6|
|S|    7|PORTD 0 portpin: digital.0
|S|    8|PORTD 1 portpin: digital.1
|S|    9|PORTD 2 portpin: digital.2
|S|   10|PORTD 3 portpin: digital.3
|S|   11|PORTD 4 portpin: digital.4
|S|   12|PORTD 5 portpin: digital.5
|S|   13|PORTD 6 portpin: digital.6
|S|   14|PORTD 7 portpin: digital.7
|W|   15|
|S|   16|PORTB 0 portpin: digital.8
|S|   17|PORTB 1 portpin: digital.9
|S|   18|PORTB 2 portpin: digital.10
|S|   19|PORTB 3 portpin: digital.11
|S|   20|PORTB 4 portpin: digital.12
|S|   21|PORTB 5 portpin: digital.13
|W|   22|
|S|   23|PORTC 0 portpin: digital.14
|S|   24|PORTC 1 portpin: digital.15
|S|   25|PORTC 2 portpin: digital.16
|S|   26|PORTC 3 portpin: digital.17
|S|   27|PORTC 4 portpin: digital.18
|S|   28|PORTC 5 portpin: digital.19
|W|   29|
|C|   30|\ some digital ports have an alternative use
|C|   31|\ synonym is available since amforth 5.0
|S|   32|synonym SPI:SS   digital.10
|E= ?? -13 7
**** /home/jb/forth/amforth-6.9/appl/arduino/blocks

Kind regards, Jochen

[Amforth] A RISC-V update

[<ho...@tj...>]

A risc-v update for CH32V307

AmForth-RV can now compile to flash directly rather than saving a word 
already compiled in ram as before. This is better and much more like the 
approach taken by the AVR code base. However, it does need an mcu that 
is able to do this. The flag field in the dictionary is used more, which 
simplifies and optionally declutters word listings. I think this was 
something that was intended, but not fully implemented. Being able to 
call C library functions from Forth has helped with beginning to add 
IEEE-754 floating point to AmForth-RV. There is a link to a pre-built 
hex file on [1] and the development board seems to be available in the 
EU from [2]. More details in the project logs [3].

Best wishes,
Tristan

[1] https://tjnw.co.uk/amforth-rv/pages/building.html
[2] 
https://www.elektor.com/products/wch-ch32v307v-evt-r1-risc-v-development-board
[3] https://tjnw.co.uk/amforth-rv/pages/logs.html

[Amforth] A RISC-V update - USB

[<ho...@tj...>]

A RISC-V update - USB

AmForth-RV now has a USB operator prompt. I've put a small video of it
working on YouTube (link below).

https://www.youtube.com/watch?v=JRXCS4dm84U

Best wishes,
Tristan

Re: [Amforth] A RISC-V update

[Martin N. <amf...@mg...>]

On Tue, 16 Apr 2024 19:34:13 +0100
ho...@tj... wrote:

> Thoughts/fixes very much welcomed. Currently struggling with USB.


There is a library for flashforth, see below. It's for an Atmega
32u4, However I quickly came to the conclusion that it had some flaws
and shelved attempts to get it working.

https://sourceforge.net/p/flashforth/code/ci/master/tree/avr/forth/usbcdc.fs

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg... (Address will be valid throughout 2024).

Re: [Amforth] A RISC-V update

[Mark R. <cab...@gm...>]

This is really great to see Tristan. Bravo to your efforts getting this
going!

On Sat, Apr 13, 2024 at 7:24 PM <ho...@tj...> wrote:

> A RISC-V update.
>
> AmForth-RV is now self-supporting (no C libraries required) for the
> WCH CH32V307. Source and a pre-built hex file are here [0]
>
> Best wishes,
> Tristan
>
> [0] https://tjnw.co.uk/amforth-rv
>
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] A RISC-V update

[<ho...@tj...>]

Thoughts/fixes very much welcomed. Currently struggling with USB.

Best wishes,
Tristan



On 2024-04-13 18:25, Martin Nicholas via Amforth-devel wrote:
> Thanks for your work. I've just ordered a development board.
> 
> M.
> 
> On Sat, 13 Apr 2024 17:08:53 +0100
> ho...@tj... wrote:
> 
>> A RISC-V update.
>> 
>> AmForth-RV is now self-supporting (no C libraries required) for the
>> WCH CH32V307. Source and a pre-built hex file are here [0]
>> 
>> Best wishes,
>> Tristan
>> 
>> [0] https://tjnw.co.uk/amforth-rv
>> 
>> 
>> 
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> 
>> 

Re: [Amforth] A RISC-V update

[Martin N. <amf...@mg...>]

Thanks for your work. I've just ordered a development board.

M.

On Sat, 13 Apr 2024 17:08:53 +0100
ho...@tj... wrote:

> A RISC-V update.
> 
> AmForth-RV is now self-supporting (no C libraries required) for the
> WCH CH32V307. Source and a pre-built hex file are here [0]
> 
> Best wishes,
> Tristan
> 
> [0] https://tjnw.co.uk/amforth-rv
> 
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 



-- 
Regards,

Martin Nicholas.

E-mail: mg...@mg....

[Amforth] A RISC-V update

[<ho...@tj...>]

A RISC-V update.

AmForth-RV is now self-supporting (no C libraries required) for the
WCH CH32V307. Source and a pre-built hex file are here [0]

Best wishes,
Tristan

[0] https://tjnw.co.uk/amforth-rv

[Amforth] A RISC-V update

[<ho...@tj...>]

A risc-v update.

Getting there [0]

It can run ISRs written in both (almost pure) Forth and C [1]. There is 
has an evolving transpiler from Forth to ITC speak and the save and see 
words are now more robust. Some toolchain and building documentation has 
been added [2], and the beginnings of a cookbook.

I'm still tidying up the latest archive, but in the meantime, if anyone 
has a WCH development board and wants to try it, drop me a message off 
list.

Best wishes,
Tristan

[0] http://tjnw.co.uk/amforth-rv/pages/logs.html
[1] https://tjnw.co.uk/amforth-rv/pages/interrupts.html (with video!)
[2] http://tjnw.co.uk/amforth-rv/pages/building.html

Re: [Amforth] OFFLIST Re: A RISC-V update

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

so, it's not offlist at all, sigh.
Oh, well.
E.

Erich Wälde <ew....@na...> writes:

> [[PGP Signed Part:Undecided]]
> Hello Tristan,
>

-- 
May the Forth be with you ...

[Amforth] OFFLIST Re: A RISC-V update

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

Hello Tristan,

I'm quite impressed by the progress you make. And I think it's
high time to at least answer: "I read your mails" :)

That being said, I don't know, how much of my health stuff I
mentioned to you. So I'll let you know this much:

1. Last July my right eye suffered an ablatio retinae. This in
itself is bad already, but not entirely unexpected, since I am
myopic since the age of 10. So it got fixed by surgery, I'll
spare you all the interesting details. The repair didn't last
and it came off again TWO more times! And just because, in
November my left eye suffered the same problem. So from November
10.th to the end of the year I was not seeing much and somewhat
depressed over all. In January the final step for the right eye
was done and I start to see a lot better now. But even reading
on the screen was close to impossible for two months. Sigh. I
have not been to work since July, and with some luck I can start
going there again (reduced time initially) in March.

2. About 6 years ago I acquired a thing called "chronic fatigue
syndrom". This term is for lack of better understanding, what's
going on. The symptoms are similar or maybe the same as in Long
Covid, but the phenomenon has existed before. I readily admit,
that I have only a very mild version of this. But I can feel the
lack of power (physically and mentally) every day. The whole
thing is not understood, let alone any root causes. Anyway. This
has forced me to let go of several things, including the amforth
projekt.


With that now out of the way, I would suggest, that you receive
the login credentials for the source forge repository. Unless of
course, you have different plans. It's up to you. If you are
interested, do you have some sort of pgp key or so, where I can
send the magic spells hidden from prying eyes?


Along other lines: I have started to play with my avr/atmega
boards again, and I am currently working to get a much newer
radio chip connected and working: the hopeRF rfm69. In
comparison to the old rfm12 this is a wizzard module. It can
handle packet radio on it's own, while the rfm12 could only
handle one byte transmit/receive, one byte in the fifo. Plus the
rfm69 will handle aes encryption, automatic checksumming and
other useful tricks on its own. However, that means that I need
to read a lot of documentation and other projects' code to
understand, how to tame the beast. I can currently send
something, but I have not tried to receive the datagram yet. I
can "see" the transmission in gnuradio with an DVB-T stick used
as receiver. The whole thing is fun, but I am very slow.

Let me know, what you think.
Cheers,
Erich

I'll attach my public key:
pub   rsa4096 2020-12-12 [SC]
      03D05884448B9F17B9EC536ADBA0681A2AFE4FE1
uid           [ultimate] Erich Wälde (AmForth project) <ew....@na...>

-------------- next part --------------




ho...@tj... writes:

> A risc-v update.
>
> AmForth-RV update
>
> Good progress made with the CH32V307 [0]
>
> Words defined in the RAM dictionary can now be appended to the FLASH
> dictionary so user defined words (individual words or the entire RAM
> dictionary) are able to survive a reset. This was one of my major
> milestones and (in my mind) a requirement for a self-hosted Forth. I
> was not able to achieve this with the FE310 based red v board.
>
> Additionally, something new to AmForth. Compiled C objects can be linked
> into AmForth-RV and called from within CODEWORDs. This is a build
> level modification and arguments are passed to the C function using
> assembly according to the risc-v calling convention.
>
> The CH32V307 makes a very good target mcu for AmForth-RV and for
> experimenting with embedded RISC-V in general.
>
> - The development board is inexpensive and available [1] [2]
> - There is official documentation and many 3rd party resources
> - The mcu can program its own flash whilst executing from flash
> - AmForth-RV can be built with an open source toolchain (build in < 3s, flash in
>  < 6s )
>
> If you are interested in trying some risc-v hardware I think it is a
> good choice.
>
> AmForth-RV is still experimental, but has made a step in the direction
> of being less so. There are quite a few decisions to be made, so any
> thoughts on what AmForth-RV might look like in the future are very much
> welcomed.
>
> Best wishes,
> Tristan
>
> [0] https://github.com/openwch/ch32v307
> [1] https://wchofficialstore.aliexpress.com/store/1100367542
> [2] https://www.aliexpress.com/item/1005004329125620.html
> (and many other suppliers)
>
> A brief annotated/edited session showing saving a RAM dictionary word.
>
> // see if a word 3+ has been defined //
>
>  ok
>> show 3+
> LFA..... (LFA)... FFA..... (FFA)... NFA..... XT...... (XT).... word....
>  ok
>
> // no it has not, so define it in the RAM dictionary //
>
>> : 3+ 1+ 1+ 1+ ;
>  ok
>
> // and see that it exists //
>
>> show 3+
> LFA..... (LFA)... FFA..... (FFA)... NFA..... XT...... (XT).... word....
> 20003A54 200039B4 20003A58 00000000 20003A5C 20003A60 COLON    3+ (in RAM)
>  ok
>
> // now append the word 3+ to the FLASH dictionary //
>
>> save 3+
> 3+ HHHHBBBB 3+
>  ok
>
> // and see that it exists //
>
>> show 3+
> LFA..... (LFA)... FFA..... (FFA)... NFA..... XT...... (XT).... word....
> 0000D200 0000D094 0000D204 00000000 0000D208 0000D20C COLON    3+ (in FLASH)
> 20003A54 200039B4 20003A58 00000000 20003A5C 20003A60 COLON    3+ (in ROM)
>  ok
>
> // it does, twice, once in RAM and once in FLASH //
>
> // reset the board //
>
> AmForth-RV 7.0 RV32IMAFC WCH CH32V307
> Fri 19 Jan 2024 16:46:34 GMT
>
> // see if 3+ exists //
>
>> words
> 3+ forth-wordlist environment riscv-wordlist @cycle type0
> hifive-turnkey rev-info build-info mtimecmp mtime led.init -led +led
>> forth-wordlist >flash.p ram>flash flash>ram ram>rom rom>ram
>
> // see if it works //
>
>> 100 3+
>  ok
>> u.
> 103  ok
>> 
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...

Re: [Amforth] A RISC-V update

[Keith A. <ca...@pi...>]

Thanks for the update! Both the board and the experimental AmForth-RV 
implementation look really interesting. I'm curious how you're planning 
to use the compiled C object support. I can see that being helpful to 
access existing high-level building blocks for things like USB. Is it 
possible to give a walk-through of how it works?

Cheers!  Keith

On 2/6/24 02:23, ho...@tj... wrote:
> A risc-v update.
>
> AmForth-RV update
>
> Good progress made with the CH32V307 [0]
>
> Words defined in the RAM dictionary can now be appended to the FLASH
> dictionary so user defined words (individual words or the entire RAM
> dictionary) are able to survive a reset. This was one of my major
> milestones and (in my mind) a requirement for a self-hosted Forth. I
> was not able to achieve this with the FE310 based red v board.
>
> Additionally, something new to AmForth. Compiled C objects can be linked
> into AmForth-RV and called from within CODEWORDs. This is a build
> level modification and arguments are passed to the C function using
> assembly according to the risc-v calling convention.
>
> The CH32V307 makes a very good target mcu for AmForth-RV and for
> experimenting with embedded RISC-V in general.
>
> - The development board is inexpensive and available [1] [2]
> - There is official documentation and many 3rd party resources
> - The mcu can program its own flash whilst executing from flash
> - AmForth-RV can be built with an open source toolchain (build in < 
> 3s, flash in < 6s )
>
> If you are interested in trying some risc-v hardware I think it is a
> good choice.
>
> AmForth-RV is still experimental, but has made a step in the direction
> of being less so. There are quite a few decisions to be made, so any
> thoughts on what AmForth-RV might look like in the future are very 
> much welcomed.
>
> Best wishes,
> Tristan
>
> [0] https://github.com/openwch/ch32v307
> [1] https://wchofficialstore.aliexpress.com/store/1100367542
> [2] https://www.aliexpress.com/item/1005004329125620.html
> (and many other suppliers)
>
> A brief annotated/edited session showing saving a RAM dictionary word.
>
> // see if a word 3+ has been defined //
>
>  ok
>> show 3+
> LFA..... (LFA)... FFA..... (FFA)... NFA..... XT...... (XT).... word....
>  ok
>
> // no it has not, so define it in the RAM dictionary //
>
>> : 3+ 1+ 1+ 1+ ;
>  ok
>
> // and see that it exists //
>
>> show 3+
> LFA..... (LFA)... FFA..... (FFA)... NFA..... XT...... (XT).... word....
> 20003A54 200039B4 20003A58 00000000 20003A5C 20003A60 COLON    3+ (in 
> RAM)
>  ok
>
> // now append the word 3+ to the FLASH dictionary //
>
>> save 3+
> 3+ HHHHBBBB 3+
>  ok
>
> // and see that it exists //
>
>> show 3+
> LFA..... (LFA)... FFA..... (FFA)... NFA..... XT...... (XT).... word....
> 0000D200 0000D094 0000D204 00000000 0000D208 0000D20C COLON    3+ (in 
> FLASH)
> 20003A54 200039B4 20003A58 00000000 20003A5C 20003A60 COLON    3+ (in 
> ROM)
>  ok
>
> // it does, twice, once in RAM and once in FLASH //
>
> // reset the board //
>
> AmForth-RV 7.0 RV32IMAFC WCH CH32V307
> Fri 19 Jan 2024 16:46:34 GMT
>
> // see if 3+ exists //
>
>> words
> 3+ forth-wordlist environment riscv-wordlist @cycle type0
> hifive-turnkey rev-info build-info mtimecmp mtime led.init -led +led
>> forth-wordlist >flash.p ram>flash flash>ram ram>rom rom>ram
>
> // see if it works //
>
>> 100 3+
>  ok
>> u.
> 103  ok
>>
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] A RISC-V update

[<ho...@tj...>]

A risc-v update.

AmForth-RV update

Good progress made with the CH32V307 [0]

Words defined in the RAM dictionary can now be appended to the FLASH
dictionary so user defined words (individual words or the entire RAM
dictionary) are able to survive a reset. This was one of my major
milestones and (in my mind) a requirement for a self-hosted Forth. I
was not able to achieve this with the FE310 based red v board.

Additionally, something new to AmForth. Compiled C objects can be linked
into AmForth-RV and called from within CODEWORDs. This is a build
level modification and arguments are passed to the C function using
assembly according to the risc-v calling convention.

The CH32V307 makes a very good target mcu for AmForth-RV and for
experimenting with embedded RISC-V in general.

- The development board is inexpensive and available [1] [2]
- There is official documentation and many 3rd party resources
- The mcu can program its own flash whilst executing from flash
- AmForth-RV can be built with an open source toolchain (build in < 3s, 
flash in < 6s )

If you are interested in trying some risc-v hardware I think it is a
good choice.

AmForth-RV is still experimental, but has made a step in the direction
of being less so. There are quite a few decisions to be made, so any
thoughts on what AmForth-RV might look like in the future are very much 
welcomed.

Best wishes,
Tristan

[0] https://github.com/openwch/ch32v307
[1] https://wchofficialstore.aliexpress.com/store/1100367542
[2] https://www.aliexpress.com/item/1005004329125620.html
(and many other suppliers)

A brief annotated/edited session showing saving a RAM dictionary word.

// see if a word 3+ has been defined //

  ok
> show 3+
LFA..... (LFA)... FFA..... (FFA)... NFA..... XT...... (XT).... word....
  ok

// no it has not, so define it in the RAM dictionary //

> : 3+ 1+ 1+ 1+ ;
  ok

// and see that it exists //

> show 3+
LFA..... (LFA)... FFA..... (FFA)... NFA..... XT...... (XT).... word....
20003A54 200039B4 20003A58 00000000 20003A5C 20003A60 COLON    3+ (in 
RAM)
  ok

// now append the word 3+ to the FLASH dictionary //

> save 3+
3+ HHHHBBBB 3+
  ok

// and see that it exists //

> show 3+
LFA..... (LFA)... FFA..... (FFA)... NFA..... XT...... (XT).... word....
0000D200 0000D094 0000D204 00000000 0000D208 0000D20C COLON    3+ (in 
FLASH)
20003A54 200039B4 20003A58 00000000 20003A5C 20003A60 COLON    3+ (in 
ROM)
  ok

// it does, twice, once in RAM and once in FLASH //

// reset the board //

AmForth-RV 7.0 RV32IMAFC WCH CH32V307
Fri 19 Jan 2024 16:46:34 GMT

// see if 3+ exists //

> words
3+ forth-wordlist environment riscv-wordlist @cycle type0
hifive-turnkey rev-info build-info mtimecmp mtime led.init -led +led
> forth-wordlist >flash.p ram>flash flash>ram ram>rom rom>ram

// see if it works //

> 100 3+
  ok
> u.
103  ok
> 

[Amforth] RISC-V update

[<ho...@tj...>]

A risc-v update.

I managed to get AmForth RISC-V running on the CH32V307 [1] made by
WCH [2] using a "CH32V307V-EVT-R1 CH32V307 Evaluation Board RISC-V MCU" 
[3].

It still is experimental and still has the issue that upon reset all
words from the ram-wordlist are erased [5]. There are no words written
for the CH32V307's peripherals besides the USART. The unscientific
benchmark of the time taken to load tester-amforth.frt via
amforth-shell.py [4] comes in at about 1.2 seconds, beaten only by
running AmForth RISC-V under qemu [6] at 0.67 seconds. Early days but
I like both the CH32V307 and the dev board.

Best wishes,
Tristan

[1] https://www.wch-ic.com/products/CH32V307.html
[2] https://www.wch-ic.com/about_us.html
[3] https://www.aliexpress.us/item/3256805636827823.html
[4] https://tjnw.co.uk/amforth-rv/20231104/20231104.html
[5] https://amforth.sourceforge.net/TG/RISC-V.html#risc-v
[6] https://tjnw.co.uk/amforth-rv/20231222/20231222.html

A quick interactive session below

AmForth-RV 7.0 RV32IMAFC WCH C32V307
Fri 19 Jan 2024 16:46:34 GMT
> words
forth-wordlist environment riscv-wordlist dog cat @cycle type0 
hifive-turnkey rev-info build-info mtimecmp mtime led.init -led +led 
qspidiv serial-emit? serial-emit serial-key? serial-key pll sysclock 
dump r. 8x. 2x. x. .8hex .4hex .2hex ?ascii bee bong ram-wordlist 
wordlist Udefer! Udefer@ dp >in 0> get-current >body wlscope variable to 
; : ] reveal recurse ?abort postpone +loop newest loop latest header 
endloop do (create) defer! defer@ create constant :noname char ['] 
[compile] [char] \ abort" abort ' turnkey immediate leave >l l> lp lp0 
repeat again else if while until then begin ahead words sliteral s, ." 
s" itype type count ver init-ram ?do map-stack interpret recognize 
cfg-recognizer forth-recognizer split rectype-split rec-split rec-num 
rectype-dnum rectype-num rectype-xt rec-find rectype-null set-base bases 
number >number digit? toupper within ud* m+ name>flags name>string 
search-wordlist current show-wordlist traverse-wordlist nfa2cfa nfa>lfa 
find-xt cfg-order c, , compile literal 2literal /string parse parse-name 
cskip cscan ?stack source-tib source throw catch handler .ready .ok 
.input .error ?crlf bs accept refill-tib refill .s ud.r ud. u. d. d.r . 
sign #> #s # <# hold hld allot here pad hex decimal ( [ spaces space bl 
cr ms warm REGITC REGABI REGNUM value? variable? condbranch? exit? 
codeword? colon? PFA.DOUSER PFA.DODATA XT.DONEXT XT.DOCONDBRANCH 
PFA.VALUE PFA.DEFER XT.EXIT XT.VARIABLE XT.COLON cell false true -1 4 2 
1 0 bounds pause emit? emit key? key quit state base dabs a-- a++ a> >a 
cell- ashift nr> n>r compare (DOLITERAL) (DOCONDBRANCH) (DOBRANCH) 1ms 
up! up@ (DODOES) (DOUSER) (DODEFER) (DOVALUE) (DODATA) (DOVARIABLE) 
aligned j i unloop (DOPLUSLOOP) (DOLOOP) (DODO) nop execute cold #tib 
tib cells cell+ 2/ 2* 2- 2+ 1- 1+ - + d0= d0< ud/mod um/mod s>d 2dup d- 
d+ dnegate d2/ d2* 2r> 2>r 2r@ 2over 2drop 2nip 2swap umax umin max min 
= <> u> u< u<= u>= > < <= >= 0< 0<> 0= c! c@ +! fill move lshift rshift 
invert not xor or and rdrop rdepth depth /mod u/mod mod / m* um* * abs 
negate ! @ sp0 sp sp! sp@ rp rp! rp@ r@ r> >r pick -rot tuck ?dup rot 
over nip dup swap drop exit   ok
> : cat 1+ ;
  ok
> 100 cat . cr
101
  ok
> : ant 5 begin 1- dup . dup 0= until drop ;
  ok
> ant
4 3 2 1 0  ok
> here 10 dump

-------- 00--------- 04--------- 08--------- 0C---------
200022D0 40 69 00 00 40 CD 82 9B 03 66 47 31 34 36 33 35     
@i..@....fG14635
200022E0 2E 06 4D C4 DC 47 EE 30 AB 43 DD 3A FB 97 56 69     
..M..G.0.C.:..Vi
200022F0 38 0F F8 6F 32 30 30 30 32 32 33 33 0A 21 94 66     
8..o20002266.!.f
20002300 F2 73 EA CB C5 49 77 34 8E 88 FE 9C F9 57 2C 11     
.s...Iw4.....W,.
20002310 18 4A EC DB 16 94 A6 D2 02 0E A5 F4 91 16 1E 12     
.J..............
20002320 55 57 38 23 18 73 E1 E2 15 1A E0 05 28 75 A6 CF     
UW8#.s......(u..
20002330 B5 28 BC E1 7E BE 76 44 20 E2 CB 04 53 8B 81 44     .(..~.vD 
...S..D
20002340 82 F3 68 49 8B 5D 15 C8 10 4F 55 B0 20 8B F1 06     
..hI.]...OU. ...
20002350 FE 59 48 17 64 F4 02 8F 14 B8 F2 0C 98 83 62 6C     
.YH.d.........bl
20002360 45 ED 46 DE DB 1B FE 44 3A E9 A0 96 FC 24 59 38     
E.F....D:....$Y8
  ok
> 

[Amforth] RISC-V update

[<ho...@tj...>]

A risc-v update.

Some progress made, but mostly tools for my education. Details can be 
found here [0] Perhaps the most important decision has been to find an 
additional hardware target for 2024, the esp32-c3 [1]

Best wishes,
Tristan

[0] https://tjnw.co.uk/amforth-rv
[1] https://www.espressif.com/en/products/socs/esp32-c3

[Amforth] AmForth RISC-V update

[<ho...@tj...>]

Hello AmForth'ers,

A quick update on my efforts with AmForth RISC-V.

I've put the amended source distribution here[0]. I have added some 
history in case anybody not on the mailing list wanders across the page 
by chance.

The zip file contains RISC-V related source code, a pre-built hex file 
for the redv and the tools directory. The latter only for ease as I 
reference it from the makefile. Delighted to know if anyone tries the 
hex file out or if anyone is doing anything RISC-V related.

The system clock has been updated to 256MHz and an issue with variables 
in the RAM dictionary addressed. Details in the logs.

Best wishes,
Tristan

[0] https://tjnw.co.uk/amforth-rv/

[Amforth] AmForth RISC-V

[Tristan W. <ho...@tj...>]

Hi,

I managed to get AmForth RISC-V running on a SparkFun RED-V Thing Plus [1]
which is based on the same/similar SiFive RISC-V FE310 SoC as on the now
discontinued HiFive1 board [2]   

amforth 7.0 RV32IM RED-V Thing Plus
 Wed Oct 11 21:25:54 BST 2023 
> words
forth-wordlist environment riscv-wordlist @cycle dump .8hex .4hex
.2hex ?ascii type0 hifive-turnkey rev-info build-info mtimecmp mtime
black magenta cyan yellow white blue green red led-init cacheflush
inflash? c!i !i serial-emit? serial-emit serial-key? serial-key
serial-lastchar +usart ram-wordlist wordlist Udefer! Udefer@ dp >in 0>
get-current >body wlscope variable to ; : ] reveal recurse ?abort
postpone +loop newest loop latest header endloop do (create) defer!
defer@ create constant :noname char ['] [compile] [char] \ abort"
abort ' turnkey immediate leave >l l> lp lp0 repeat again else if
while until then begin ahead words sliteral s, ." s" itype type count
ver init-ram ?do map-stack interpret recognize cfg-recognizer
forth-recognizer split rectype-split rec-split rec-num rectype-dnum
rectype-num rectype-xt rec-find rectype-null set-base bases number
>number digit? toupper within ud* m+ name>flags name>string
search-wordlist current show-wordlist traverse-wordlist nfa2cfa
nfa>lfa find-xt cfg-order c, , compile literal 2literal /string parse
parse-name cskip cscan ?stack source-tib source throw catch handler
.ready .ok .input .error ?crlf bs accept refill-tib refill .s ud.r
ud. u. d. d.r . sign #> #s # <# hold hld allot here pad hex decimal (
[ spaces space bl cr ms warm false true -1 4 2 1 0 nr> n>r compare 1ms
up! up@ aligned j i unloop bounds nop pause emit? emit key? key
execute quit cold #tib tib state cells cell+ 2/ 2* 2- 2+ 1- 1+ - +
base d0= d0< ud/mod um/mod s>d 2dup d- d+ dnegate dabs d2/ d2* 2r> 2>r
2r@ 2over 2drop 2nip 2swap umax umin max min = <> u> u< u<= u>= > < <=
>= 0< 0<> 0= c! c@ +! fill move lshift rshift invert not xor or and
rdrop rdepth depth /mod u/mod mod / m* um* * abs negate ! @ sp0 sp sp!
sp@ rp rp! rp@ r@ r> >r pick -rot tuck ?dup rot over nip dup swap drop
exit ok >

I needed to make a few changes to the existing code to get it to
run. Flashing AmForth to the SparkFun RED-V Thing Plus is simple, as
when plugged in it presents itself as a drive. Copy the hex file to
the drive and it flashes itself.

On reset a bootloader runs the copied and flashed AmForth hex file,
but it sends some AT commands over the usart prior to running the
flashed program. It may do other things too. A search suggests this
might be related to a WiFi/BT chip on the HiFive1 Rev B. [3] Remaking
AmForth for a 115200 uart shows this nicely.

ATE0--> Send Flag error: #0 #0 #0 #0 AT+BLEINIT=0--> Send Flag error: #255 #255 #255 #255 AT+CWMODE=0--> Send Flag error: #255 #248 #0 #0 
amforth 7.0 RV32IM RED-V Thing Plus
 Thu Oct 12 21:48:35 BST 2023 
> 

I know next to nothing about risc-v assembly, but Matthias' code/macros look
super elegant to me.   

COLON "hifive-turnkey", APPLTURNKEY

  .word XT_LED_INIT
  .word XT_DECIMAL
  .word XT_INIT_USART

  .word XT_DOT_VER, XT_SPACE
  .word XT_ENV_BOARD,XT_TYPE, XT_CR

  .word XT_BUILD_INFO,XT_TYPE
  .word XT_SPACE, XT_REV_INFO, XT_TYPE

.word XT_EXIT

The SparkFun RED-V Thing Plus has a different LED arrangement and
location but it was easy enough to cobble together some assembler
words to make a proof of blinky. 

CODEWORD  "led-init", LED_INIT
  li x20, 1 << 5 
  li x21, GPIO_OUTPUT_EN
  sw x20, 0(x21)
  li x20, 1 << 5 
  li x21, GPIO_PORT
  sw x20, 0(x21)
NEXT

CODEWORD  "+led", PLUSLED
    li x20, 1 << 5 
    li x21, GPIO_PORT
    sw x20, 0(x21)
NEXT

CODEWORD  "-led", MINUSLED
    li x20, 1 << 5 
    li x21, GPIO_PORT
    sw zero, 0(x21)
NEXT

I'm glad I started with the SparkFun RED-V Thing Plus board. Whilst
it's more expensive than some other offerings, having something close to
the board AmForth RISC-V was originally written for, definitely helps a
lot. RISC-V is not an "open-source processor" [4] and I'm not able to
cope with the variety yet, if ever.

Despite the product page "backorder" status, there are quite a few of
the SparkFun RED-V Thing Plus still available from the usual sources.

Well a lot of fun, plenty to study for the winter, and with a blinky
up-and-running there is always the hope of progress.

Best wishes,
Tristan


[1] https://www.sparkfun.com/products/15799
[2] https://www.sifive.com/boards/hifive1
[3] https://www.sifive.com/boards/hifive1-rev-b
[4] https://riscv.org/blog/2020/02/risc-v-is-not-an-open-source-processor-krste-asanovic-chairman-of-the-board-risc-v/

Re: [Amforth] avra on a raspi zero v1

[Mark R. <cab...@gm...>]

On Wed, Oct 4, 2023 at 2:37 PM Tristan Williams wrote:

> Hello Mark,
>
> I took a local clone of your repo and the new template built for an uno
> without issue. Thank you.
>
> Are you open to a pull request?
>

Of course. I do believe that last night I fixed the last of the little bits
that were giving me trouble after trying to take care of the zero byte
padding issues. For some odd reason one of them played havoc with Evalue in
so that it just didn't work. It was in the word list, but was just hanging.
That is fine now as far as I can tell. I tested quite a bit with my word
list that is pretty extensive.


>
> Seeing that we are dealing with makefiles, it seemed a good time to
> address prebuilt binaries. I have blended/amended your template with
> the existing makefile in appl/arduino to output hex files for the m328
> based UNO and the 2561 based mega.


I agree. Any of the projects in appl should be able to be built and/or have
a prebuilt hex in them. Since today was the first day I was able to stop
looking at the repo and look at my own project to clean up the next thing I
did want to do is to cull and clean those. I have an uno or three and a
mega from an old disassembled  3D printer around here so I can try those
next. I also have a few other atmegas to work with from various interests
over the years. I need to look and see if any of them (atmega8, 16 etc) are
even able to take AmForth. So yes, any info put up at the repo will most
certainly be seen and considered by me for now unless something else
happens to move that focus.


> Separately, I have written a script to produce a simple html build
> specific reference-card that lists the words built into the respective
> pre-built hex files. It searches the .lst file produced by the
> assembler (in this case avra) for the assembler source files used and
> then searches them for the documentation. This has been discussed [1]
> on the mailing list before. However, if there are going to be prebuilt
> hex files in the repo, then a reference-card for those builds will be
> helpful for the person trying them out. It is not intended to be a
> substitute for the reference-card for AmForth as a whole.
>
> I have put up the html here as an idea.
>
> https://www.mostlymostly.uk/amforthdocs/prebuilt.html
>
> The page uses material from the existing site. It is not plumbed
> into the rst source (but it could be).


This looks great. A few times after you put up the link I accidentally
ended up there and wondered why the SF site was so snappy. I see you have
kept up with the refcard thing over the years from when we played around
with it. It's done with python I'm guessing. I really like your idea of
making them from the .lst files. It's something I've always thought would
be a great addition inside of the project directories if someone so
desired.


> Best wishes,
> Tristan
>
> [1] https://sourceforge.net/p/amforth/mailman/message/37112236/


All the best to you as well. It feels good to be polishing up the tools to
polish up the Forth that was starting to bit rot in my brain.
Mark


>
>
> On 30Sep23 22:30, Mark Roth wrote:
> > On Sat, Sep 30, 2023 at 9:46 PM Keith Amidon wrote:
> >
> > > On 9/30/23 03:17, Mark Roth wrote:
> > > > Hello weekend AmForth'ers
> > > >
> > > > So, while waiting to see what will happen with the repo I have
> continued
> > > to
> > > > play with a git version for my own use. I have reworked the makefile
> and
> > > > made some changes to the repo structure to accommodate for the new
> avra
> > > > code (which is still only a placeholder until I get that repository
> in
> > > > properly). I think that the new makefile should make it very easy to
> get
> > > > started and there is a bit of a long winded readme to explain
> anything
> > > that
> > > > has changed. If anyone wants to take a look and give feedback that
> would
> > > be
> > > > great.
> > > >
> > > > https://github.com/CableGuy67/AmForth
> > >
> > > I took a quick look at the makefile and related fines in the
> > > appl/template directory, which I believe is what you're referring to
> > > here. I have two minor suggestions:
> > >
> > >  1. How about renaming "template.asm" as "app.asm" and making the
> > >     corresponding changes to the makefile? I think this would make a
> > >     workflow of copying the template directory to one named for a new
> > >     application without updating names within the template directory
> > >     very natural. I would feel weird leaving around a file called
> > >     "template.asm" because that doesn't communicate well the purpose of
> > >     the file in the ultimate project. But "app.asm" seems like it could
> > >     usually fit. Having a consistent name like this could also simplify
> > >     documentation.
> > >
> >
> > Yeah, that does sound like a good idea. I like the way it implies intent.
> >
> >
> > >  2. This is really just a template for an avr8 project, right? Perhaps
> > >     the directory containing this sub-tree should be named
> > >     "avr8-template" instead of "template"? It seems to me that really
> > >     all the directories under "/appl" are currently templates for
> > >     different targets? Is that right?
> > >
> > > Note that I haven't tried anything here, these all come from code
> > > inspection and may be due to misunderstandings on my part.
> > >
> > > Cheers!  Keith
> > >
> >
> > You're not wrong in that. Since I only use the avr-8 chips I only
> recently
> > even looked into those other appl directories. It seems that it just sort
> > of grew like mushrooms (appl that is) and never had any cohesiveness.
> > Indicating that it is the appl template for avr8 is a no brainer. I have
> to
> > wonder if the makefile at one point in time was supposed to be more
> > inclusive with the other platforms but just never got there.
> >
> > Thanks for the suggestions. Different eyes and all.
> >
> > All the best,
> > Mark
> >
> >
> > >
> > > _______________________________________________
> > > Amforth-devel mailing list for http://amforth.sf.net/
> > > Amf...@li...
> > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > >
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] avra on a raspi zero v1

[Tristan W. <ho...@tj...>]

Hello Mark,

I took a local clone of your repo and the new template built for an uno
without issue. Thank you.

Are you open to a pull request?

Seeing that we are dealing with makefiles, it seemed a good time to
address prebuilt binaries. I have blended/amended your template with
the existing makefile in appl/arduino to output hex files for the m328
based UNO and the 2561 based mega.

Separately, I have written a script to produce a simple html build
specific reference-card that lists the words built into the respective
pre-built hex files. It searches the .lst file produced by the
assembler (in this case avra) for the assembler source files used and
then searches them for the documentation. This has been discussed [1]
on the mailing list before. However, if there are going to be prebuilt
hex files in the repo, then a reference-card for those builds will be
helpful for the person trying them out. It is not intended to be a
substitute for the reference-card for AmForth as a whole. 

I have put up the html here as an idea.

https://www.mostlymostly.uk/amforthdocs/prebuilt.html

The page uses material from the existing site. It is not plumbed
into the rst source (but it could be).

Best wishes,
Tristan

[1] https://sourceforge.net/p/amforth/mailman/message/37112236/

On 30Sep23 22:30, Mark Roth wrote:
> On Sat, Sep 30, 2023 at 9:46 PM Keith Amidon wrote:
> 
> > On 9/30/23 03:17, Mark Roth wrote:
> > > Hello weekend AmForth'ers
> > >
> > > So, while waiting to see what will happen with the repo I have continued
> > to
> > > play with a git version for my own use. I have reworked the makefile and
> > > made some changes to the repo structure to accommodate for the new avra
> > > code (which is still only a placeholder until I get that repository in
> > > properly). I think that the new makefile should make it very easy to get
> > > started and there is a bit of a long winded readme to explain anything
> > that
> > > has changed. If anyone wants to take a look and give feedback that would
> > be
> > > great.
> > >
> > > https://github.com/CableGuy67/AmForth
> >
> > I took a quick look at the makefile and related fines in the
> > appl/template directory, which I believe is what you're referring to
> > here. I have two minor suggestions:
> >
> >  1. How about renaming "template.asm" as "app.asm" and making the
> >     corresponding changes to the makefile? I think this would make a
> >     workflow of copying the template directory to one named for a new
> >     application without updating names within the template directory
> >     very natural. I would feel weird leaving around a file called
> >     "template.asm" because that doesn't communicate well the purpose of
> >     the file in the ultimate project. But "app.asm" seems like it could
> >     usually fit. Having a consistent name like this could also simplify
> >     documentation.
> >
> 
> Yeah, that does sound like a good idea. I like the way it implies intent.
> 
> 
> >  2. This is really just a template for an avr8 project, right? Perhaps
> >     the directory containing this sub-tree should be named
> >     "avr8-template" instead of "template"? It seems to me that really
> >     all the directories under "/appl" are currently templates for
> >     different targets? Is that right?
> >
> > Note that I haven't tried anything here, these all come from code
> > inspection and may be due to misunderstandings on my part.
> >
> > Cheers!  Keith
> >
> 
> You're not wrong in that. Since I only use the avr-8 chips I only recently
> even looked into those other appl directories. It seems that it just sort
> of grew like mushrooms (appl that is) and never had any cohesiveness.
> Indicating that it is the appl template for avr8 is a no brainer. I have to
> wonder if the makefile at one point in time was supposed to be more
> inclusive with the other platforms but just never got there.
> 
> Thanks for the suggestions. Different eyes and all.
> 
> All the best,
> Mark
> 
> 
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Maintainer(s) for AmForth

[Keith A. <ca...@pi...>]

> Thank you for writing amforth-shell. For me it has been a core part of
> AmForth and a key part of many of my projects. The combination of its
> reliability and AmForth recognizers meant I could automate sending
> both commands and data as Forth words over to an mcu running
> AmForth. Human readable and with no additional effort on my part
> to deal with pc-mcu communications :)

Thanks Tristan for this update that amforth-shell remains a reliable and 
useful tool for your applications. I always aim to build things that 
have lasting value and it makes me very happy to hear that has been your 
experience with this little tool. Hopefully all of us can work together 
to ensure that is the case for the overall amforth ecosystem well into 
the future.  :-)

-- Keith

Re: [Amforth] Maintainer(s) for AmForth

[Tristan W. <ho...@tj...>]

On 30Sep23 11:35, Keith Amidon wrote:
> On 9/30/23 05:25, Mark Roth wrote:
> > Hello Keith. I'm glad you mentioned the shell (and that you wrote it in the
> > way back when) because it had slipped my mind to get back to trying it.
> > I've gotten so used to using e4thcom that the tool in the repo is just
> > collecting figurative dust for me. Tristan W brought it up into the python3
> > realm some time back and I think sorted some bug or another after that.
> > I get the feeling there are a number of the back in the old days folks
> > doing the same and glancing at the mailing list. One would hope anyway.
> > Seeing the dates on the really old commits this past week really drove it
> > home just how long this project has been around. :)
> 
> Thanks! I'm not familiar with e4thcom. It looks interesting.
> 
> I'm curious if it also solves the primary reason I had for writing
> amforth-shell.py in the first place, which had to do with making higher baud
> rates work reliably without overrunning the very small serial input buffer
> amforth uses. When using a terminal emulator file transfer that just sent at
> maximum baud rate I frequently had problems with this on ATMega 328 based
> arduinos if the baud rate was greater than 19200 because amforth would fall
> behind as it was storing new words. amforth-shell.py solves this problem by
> waiting for a positive echo of the character it sent before sending the next
> which let me run at 115k and greatly sped up larger file transfers while
> ensuring they were reliable. For my project I had 12+ microcontrollers I had
> to regularly reprogram with a fairly large forth program and this was
> necessary to keep myself going crazy while waiting during updates.  :-)
> 
> --- Keith
> 

Hello Keith,

Thank you for writing amforth-shell. For me it has been a core part of
AmForth and a key part of many of my projects. The combination of its
reliability and AmForth recognizers meant I could automate sending
both commands and data as Forth words over to an mcu running
AmForth. Human readable and with no additional effort on my part
to deal with pc-mcu communications :)

Kind regards and thanks,
Tristan