amforth-devel — Development discussion and user support

[Amforth] Code copied to sourcehut.org

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

Dear AmForthers,

I have just now converted r2457 of
svn://svn.code.sf.net/p/amforth/code

via svn2git and pushed it to

https://git.sr.ht/~amforth/code/tree

If you would please be so kind as to give it a try.
Test your usual workflow.
Are all files in the expected places?
Can you assemle your favourite .hex files?
Can you create patches (email form)?

Play with it.

Do you see something odd or unexpected?


Cheers,
Erich



-- 
May the Forth be with you ...

[Amforth] git question/moving to sourchut

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

Dear AmForthers,

long time no hear. Yes I know. All I can say is: I was very un-motivated to do
anything involving atmega microcontrollers or AmForth. When I packed
everything away in September 2020, I was very frustrated. I wanted to
implement a new version of my data collector stuff, and it kept failing on me
for no apparent reason. This went on for several months until I decided to put
everything out of sight.

Beginning of February 2021 I started to play with this stuff again. Just for
my own pleasure, not telling anyone. So currently I have this working (again):

- TX -- a atmega644pa microcontroller, running AmForth-6.9
  using a 434MHz radio to transmit sensor data
  using a mightyohm geiger counter as sensor (it reports about 20
  events/minute :)

- RX -- a atmega644pa microcontroller, running AmForth-6.9
  using a 434MHz radio to receive said data

- a Raspberry Pi connected to the serial interface of RX requesting data every
  10 Minutes, sending that data off via mqtt. MQTT relays the datagrams via
  telegraf into an influxdb, grafana makes the collected data visible to a web
  browser. This part I had set up over winter to replace my outdated and
  somewhat dodgy pgplot/perl driven visualization.

This setup is quite stable. I see occasional outliers, so transport is not as
robust as it could be.

Sounds like full success? Well. Maybe. I also spent countless hours on the
let's say intriguing interface of the Bosch Sensortec BME280 sensor
(temperature, relative humidity, pressure). While the sensor may be top notch,
I did not grok the imho complicated calculations, which are neccessary to
convert the Bits into a human readable value. Working in C is much simpler,
bacause C code is available, and because the compiler will do all sorts of
signed/unsigned acrobatics for me. Yes there is Forth code available as well,
e.g. from our nice neighbours in Netherlands, as published in Vierte Dimension
2020-01:
https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2020-01.pdf

I have given up on this for now, and I have ordered some (expensive!)
Sensirion STH85 sensors (temperature, rel. humidity). I have some SHT71, but I
broke the last one.


So, all of this is to say, I am hopefully out of hibernation.


Regarding the AmForth Project:

1.
I have registered an account at sourcehut.org:
https://git.sr.ht/~amforth

The repository is currently empty, but that should change.


2.
I have experimented a little with svn2git. Thanks for your experiments and
various hints on the mailing list.

There is one thing I am still very undecided:

When I try to understand a problem in the AmForth code, I often do something
like:

find or grep -rl $something in ./releases/*/avr8/...
pipe this through md5sum to see what changed when
Then do diffs between specific releases.
A more complete example is given below.

IFF I convert the ./releases/ directories to git branches, then this will not
be possible any more, I think. The I have to use git blame and git diff
between branches.

Currently I think having all files unfolded in a directory tree has its
merits. At least in the sense that I know, how to deal with this.

But this is highly against the git way, as I understand it. So I am inclined
to create branches, but I would highly appreciate hints on how to efficiently
find out about changes of a given file during its history. How are you doing
this? Ah, web interface ... how about the command line?


3.
During a completely different experiment that you find here
https://ew.srht.site/
I think I have understood, how to create static html content in such a way
that it will be served by sourcehut. Currently "not found"
https://amforth.srht.site/
but that shall change as well.


4.
I intent to give admin privileges to at least two more people. Carsten
Strotmann has given me a key already. So if anyone else is interested, please
get in touch with me.


Cheers,
Erich



----------------------------------------------------------------------
> example for find/grep diff workflow:
> 
> $ md5sum ~/bin/amforth-upload.py releases/*/tools/amforth-upload.py trunk/tools/amforth-upload.py
> c0a6266c243a724da85074fc6a7bc315  /home/ew/bin/amforth-upload.py
> a6e355913f567148d6129638d1979dd0  releases/2.7/tools/amforth-upload.py
> 5e7458e0382bf29d4820c4f1f720222c  releases/2.8/tools/amforth-upload.py
> 5e7458e0382bf29d4820c4f1f720222c  releases/2.9/tools/amforth-upload.py
> 5e7458e0382bf29d4820c4f1f720222c  releases/3.0/tools/amforth-upload.py
> 5e7458e0382bf29d4820c4f1f720222c  releases/3.1/tools/amforth-upload.py
> 5e7458e0382bf29d4820c4f1f720222c  releases/3.2/tools/amforth-upload.py
> 5e7458e0382bf29d4820c4f1f720222c  releases/3.3/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.4/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.5/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.6/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.7/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.8/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.9/tools/amforth-upload.py
> c0a6266c243a724da85074fc6a7bc315  releases/4.0/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.1/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.2/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.3/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.4/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.5/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.6/tools/amforth-upload.py
> 7bee7d2eb669aad5c4b77c93c74d1941  releases/4.7/tools/amforth-upload.py
> 7bee7d2eb669aad5c4b77c93c74d1941  releases/4.8/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/4.9/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.0/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.1/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.2/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.3/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.4/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.5/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/5.6/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/5.7/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/5.8/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/5.9/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.0/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.1/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.2/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.3/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.4/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.5/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.6/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.7/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/6.8/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  trunk/tools/amforth-upload.py
>        #+end_example
> 
>        I'm using amforth-upload.py from release 4.0. This version /works/ for
>        me. Changes occured in these releases:
> 
>        #+begin_example
> a6e355913f567148d6129638d1979dd0  releases/2.7/tools/amforth-upload.py
> d98ce0c817fd19cba4474e13b56f566f  releases/3.4/tools/amforth-upload.py
> c0a6266c243a724da85074fc6a7bc315  releases/4.0/tools/amforth-upload.py
> 3f6c0a9b8616e4636a2cc9f06d1ede10  releases/4.1/tools/amforth-upload.py
> 7bee7d2eb669aad5c4b77c93c74d1941  releases/4.7/tools/amforth-upload.py
> e8f55df9f17ceb38228ba68270ca019d  releases/4.9/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  releases/5.7/tools/amforth-upload.py
> faf3f05fbb4126a290d435e83e3e90ee  trunk/tools/amforth-upload.py
>        #+end_example
> 
>        #+begin_example
> for R in 2.7 3.4 4.0 4.1 4.7 4.9 5.7
> do
>     ls -l releases/$R/tools/amforth-upload.py
>     #wc -l releases/$R/tools/amforth-upload.py
> done
> 
> -rwxr-x--- 1 ew ew 6201 2020-04-05 12:27 releases/2.7/tools/amforth-upload.py*
> -rwxr-x--- 1 ew ew 6921 2020-04-05 12:27 releases/3.4/tools/amforth-upload.py*
> -rwxr-x--- 1 ew ew 7408 2020-04-05 12:27 releases/4.0/tools/amforth-upload.py*
> -rwxr-x--- 1 ew ew 7409 2020-04-05 12:27 releases/4.1/tools/amforth-upload.py*
> -rwxr-x--- 1 ew ew 7414 2020-04-05 12:27 releases/4.7/tools/amforth-upload.py*
> -rwxr-x--- 1 ew ew 7541 2020-04-05 12:27 releases/4.9/tools/amforth-upload.py*
> -rwxr-x--- 1 ew ew 7978 2020-04-05 12:27 releases/5.7/tools/amforth-upload.py*
> 
> 232 releases/2.7/tools/amforth-upload.py
> 253 releases/3.4/tools/amforth-upload.py
> 264 releases/4.0/tools/amforth-upload.py
> 264 releases/4.1/tools/amforth-upload.py
> 261 releases/4.7/tools/amforth-upload.py
> 261 releases/4.9/tools/amforth-upload.py
> 269 releases/5.7/tools/amforth-upload.py
> 
>      ... and so on. Similar game with no-jtag.asm led to recognize that the
>      active file was essentially empty at the time.


-- 
May the Forth be with you ...

[Amforth] patch for amforth-shell.py

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

amforth-shell.py replaces known mcu register names with their
values. This makes it very easy to create a file like this and upload
it to the mcu (in this case avr8)

#include ms.frt

: low     ( mask port --   ) dup c@ rot invert and swap c! ;
: high    ( mask port --   ) dup c@ rot or swap c! ;

: blink ( -- )
    #32 DDRB high
    begin
        #32 PORTB low 
        1000 ms
        #32 PORTB high
        1000 ms
    key? until
;

connecting via serial and typing blink makes the led on pin 13 of an
uno blink until a key is pressed. However, the Forth system knows
nothing about DDRB or PORTB as these were substituted on-the-fly by
amforth-shell.py during the upload. This does save some flash memory
and does simplify writing code, but it is not always what you want. If
you wanted to use PORTB at the interpreter prompt, you can't as it
does not exist as a constant. Adding

#37 constant PORTB

will not help either, as amforth-shell.py still substitutes on-the-fly
creating a new word $25, as

' $25 execute .

will show. I looked to see if I could turn this behaviour off, but
I couldn't find an option to do this. The patch below changes this,
adding the option

  --no-regsub, -X       Do NOT replace mcu registers with their values.

The default behaviour remains unchanged, with register names
substituted on-the-fly.

--- ../amforth-6.93/tools/amforth-shell.py	2020-12-03 15:29:07.000000000 +0000
+++ ../amforth-6.93/tools/new-shell.py	2020-12-16 17:42:48.000000000 +0000
@@ -648,9 +648,12 @@
             help="Add Include directory")
         parser.add_argument("--uploaded-wl", "-U", action="store_true", default=False,
             help="Keep the list of uploaded filenames in the dictionary.")
+        parser.add_argument("--no-regsub", "-X", action="store_true", default=False,
+            help="Do NOT replace mcu registers with their values.")
 
         parser.add_argument("files", nargs="*", help="may be found via the environment variable AMFORTH_LIB")
         arg = parser.parse_args()
+        self.noregsub = arg.no_regsub 
         self.debug = arg.debug_serial
         self.max_line_length = arg.line_length
         self._serial_port = arg.port
@@ -917,7 +920,7 @@
                 continue
             if w in self._appl_defs:
                 w = self._appl_defs[w]
-            elif w in self._amforth_regs:
+            elif w in self._amforth_regs and not self.noregsub :
                 w = self._amforth_regs[w]
             elif w.upper() in self.stdwords:
                 w = w.lower()

[Amforth] [PATCH] Update to "Arduino-HelloWorld.rst.txt" recipe

[Carsten S. <ca...@st...>]

Hi AmForth List,

on the weekend I've run the "Arduino Hello World" recipe and found 
two
issues:

a) the recipe jumps from pin 5 to pin 7 of Port B in the middle of 
the
recipe, that was confusing

b) modern AmForth does not seem to include the word "ms" in the 
kernel

Attached is a patch that changes to Port to use Digital-13 on the
Arduino all the time (to be consistent) and gives information 
where to
find the word "ms" (or how to quickly define it).


<https://git.sr.ht/~cstrotm/AmForth/commit/a2a968b7c02aff5afd622f842aeda9a21ddcdc92.patch>

Greetings

Carsten


>From a2a968b7c02aff5afd622f842aeda9a21ddcdc92 Mon Sep 17 00:00:00 
2001
From: Carsten Strotmann <ca...@st...>
Date: Mon, 1 Mar 2021 13:55:20 +0100
Subject: [PATCH] Fix port number in example and add information on 
word "ms"

---
 .../TG/recipes/Arduino-HelloWorld.rst.txt     | 52 
 +++++++++++--------
 1 file changed, 29 insertions(+), 23 deletions(-)

diff --git 
a/doc/htdocs/_sources/TG/recipes/Arduino-HelloWorld.rst.txt 
b/doc/htdocs/_sources/TG/recipes/Arduino-HelloWorld.rst.txt
index 7de8045..93bb471 100644
--- a/doc/htdocs/_sources/TG/recipes/Arduino-HelloWorld.rst.txt
+++ b/doc/htdocs/_sources/TG/recipes/Arduino-HelloWorld.rst.txt
@@ -9,7 +9,7 @@ attached to the port Digital-13. For this recipe, 
the amforth system
 is already loaded onto the ardiuno. Instructions to do it are in 
 the
 :ref:`User Guide`.
 
-To quickly test the hardware start a terminal (e.g. screen 
 /dev/ttyACM0 38400) 
+To quickly test the hardware start a terminal (e.g. screen 
/dev/ttyACM0 38400)
 and enter the following commands (assuming an Arduino Uno)
 
 .. code-block:: forth
@@ -19,12 +19,12 @@ and enter the following commands (assuming an 
Arduino Uno)
    > $00 $25 c!
 
 The LED turned on until the last command is executed. The 
 character
-:command:`>` is the command prompt, if you see it, you can enter 
-any commands. You'll never enter that character yourselves. A 
+:command:`>` is the command prompt, if you see it, you can enter
+any commands. You'll never enter that character yourselves. A
 command line can be up to 80 characters long.
 
 The commands above are pretty obscure. To make them easier to
-understand we define labels for some numbers, so called 
+understand we define labels for some numbers, so called
 constants:
 
 .. code-block:: forth
@@ -35,24 +35,24 @@ constants:
 The arduino uses its own numbering schema for pins, but
 for now we use the atmega one: digial-13 is the same as
 bit 7 of port B. Port B has 8 pins and three registers to
-configure them. we need two of them: The Data Direction 
-Register (DDR) and the PORT (Output) Register. The third 
+configure them. we need two of them: The Data Direction
+Register (DDR) and the PORT (Output) Register. The third
 register is used for reading from the port (PIN).
 
 The above commands can now be written as
 
 .. code-block:: forth
 
-  > $20 DDRB c! 
+  > $20 DDRB c!
   > $20 PORTB c!
   > $00 PORTB c!
 
 Technically the same but easier to read.
 
 Next we do not want to enter all commands interactively. Forth
-has the reputation of an extendible command set. 
+has the reputation of an extendible command set.
 
-Good forth coding style means to have many small words which do 
 exactly 
+Good forth coding style means to have many small words which do 
exactly
 one thing. Most forth commands are built with only a handful 
 other commands.
 
 The first command in this example sets up the Data Direction 
 Register DDR
@@ -68,7 +68,7 @@ The same in Forth is:
 
 .. code-block:: forth
 
-   > : led-init  $80 DDRB c! ;
+   > : led-init  $20 DDRB c! ;
     ok
    >
 
@@ -81,17 +81,17 @@ With this command line the interpreter learns 
a new command:
     ok
    >
 
-It writes the number 128 (hex 80) to the register DDRB (hex 24)
-as defined above. This makes the 7th bit of PORTB an Output pin.
+It writes the number 32 (hex 20) to the register DDRB (hex 24)
+as defined above. This makes the 5th bit of PORTB an Output pin.
 
 Calling our newly defined word does not change anything
 visible. But with the next word, the LED will turn on:
 
 .. code-block:: forth
 
-  : led-on $80 PORTB c! ;
+  : led-on $20 PORTB c! ;
 
-Here the 7th bit will be set to 1, and that makes the led to be 
 connected
+Here the 5th bit will be set to 1, and that makes the led to be 
connected
 to VCC (5V) and it will turn on (the LED is connected to ground 
 already).
 
 If the led-on command does not turn on the LED just call the
@@ -123,9 +123,15 @@ Our next word will simplify this and gives 
the real blink experience:
 
   : led-blink led-on 500 ms led-off 500 ms ;
 
-Calling this command will turn on the led, waits for half a 
 second, turn it
-off again and waits another half a second before returning to the 
 command
-prompt.
+Calling this command will turn on the led, waits for half a 
second,
+turn it off again and waits another half a second before 
returning to
+the command prompt. If the word `ms` is not found, it can be 
loaded
+from `<AmForth>/common/lib/forth2012/facility/ms.frt` or defined
+assembler
+
+.. code-block:: forth
+
+  : ms 0 ?do 1ms loop ;
 
 With this command you can blink the led a few times
 
@@ -148,11 +154,11 @@ To make it blink "forever", we define 
another command word:
         led-blink
         key?
      until
-     key drop 
+     key drop
    ;
 
-Since this is our first command which needs more than 1 line, the 
-interpreter acts more complex. It changes the command prompt 
 until 
+Since this is our first command which needs more than 1 line, the
+interpreter acts more complex. It changes the command prompt 
until
 the end of the command definition is reached (the command ``;``)
 The ouput in the terminal window looks like
 
@@ -167,7 +173,7 @@ The ouput in the terminal window looks like
     okkey drop
     ok;
     ok
-   > 
+   >
 
 This word first prints some text ("press any key to stop") and 
 starts a loop.
 This loop lets the led blink once and checks for a keystroke. If 
 no key
@@ -185,7 +191,7 @@ Where to go next
 ................
 
 This example is very basic. Next steps may involve library code
-like :ref:`Digital Ports`. Related to it are the :ref:`Upload` 
 for 
+like :ref:`Digital Ports`. Related to it are the :ref:`Upload` 
for
 files with forth code.
 
-More Arduino related stuff is in :ref:`Arduino Analog`. 
+More Arduino related stuff is in :ref:`Arduino Analog`.
-- 
2.30.1

[Amforth] wordlist tools

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

I have been using wordlists to store and catalogue information for a
different project and found I needed some more tools in addition to
those in the distribution

Source and more details below

https://tjnw.co.uk/wlt/

Kind regards,

Tristan

Re: [Amforth] A project using an AmForth recogniser

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

I have added parts two and three of the project.

https://tjnw.co.uk/limpicprog/

Best wishes,
Tristan

On 06Jan21 18:56, Tristan Williams wrote:
> First part of project to make tinkering in the shed easier.
> 
> https://tjnw.co.uk/limpicprog/
> 
> Best wishes,
> Tristan
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth] Useful additions to the "Extended VM"

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

It's a handy way of using the A & B variables as local variables when
needed.

    .dw $ff03
    .db "a>r"
    .dw VE_HEAD
    .set VE_HEAD = VE_ATOR
XT_ATOR:
    .dw PFA_ATOR
PFA_ATOR:
      push ah
      push al
    jmp_ DO_NEXT

    .dw $ff03
    .db "r>a"
    .dw VE_HEAD
    .set VE_HEAD = VE_AFROMR
XT_AFROMR:
    .dw PFA_AFROMR
PFA_AFROMR:
      pop al
      pop ah
    jmp_ DO_NEXT


Quick and simple definitions which allow you to do stuff like this:
: workwitha
	a>r
		use a with impunity
	r>a
;

I've translated these from my own version, so I hope it's survived.

--
Regards,

Martin Nicholas.

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

[Amforth] A project using an AmForth recogniser

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

First part of project to make tinkering in the shed easier.

https://tjnw.co.uk/limpicprog/

Best wishes,
Tristan

[Amforth] AVR-Dx Port

[Stephen D <au....@gm...>]

Hi all,
now that Erich has provided the Python source I've taken time to
investigate generating the device control files.

Microchip have made changes to the device files between Studio 6.2 and 7.0.

In 6.2:
- filename is <device>.xml
- schema version 0.3
- no support for AVR-Dx parts

In 7.0
- filename is <device>.atdf
- inconsistent schema versions 0.3 (old parts), 4.4 (new parts)
- module names change e.g. ANALOG_COMPARATOR becomes AC (mega128)
- xml module element nesting changes e.g. USART0/USART1 now nested under
USART (mega128)

I should be able to tweak the existing python scripts to generate the
required device.asm, device.py and .frt code but the module and register
name changes are likely to cause a great deal of inconsistency between the
AVR-Dx parts and the earlier AVR models.

An alternative option would be to regenerate the entire avr8/devices tree.
A lot of work and a lot of potential breakage. It would however mean that
the new style register and module names would be applied consistently to
all devices.

I imagine there are other options.

Regards,
S

Re: [Amforth] Added tools/partdescription to svn

[Stephen D <au....@gm...>]

Thanks Erich. I’ve completed the first step. With the help of the kind
folks over at avrfreaks.net I have been able to integrate the latest Atmel
Assembler (2.2.8) and AVR-Dx .inc files into the amforth tools download. I
have an updated Atmel-Assembler.tgz file ready to upload.

I will send you a link to the file personally.

Regards,
Stephen

On Thu, 31 Dec 2020 at 03:23, Erich Wälde <ew....@na...> wrote:

>
> Hello,
>
> as promised, I added the script "pd2amforth" to the source tree,
> see amforth/trunk/tools/partdescription/...
>
> > $ svn commit . -m 'added tools/partdescription'
> > Password:
> > Sending        doc/source/index.rst
> > Adding         tools/partdescription
> > Adding         tools/partdescription/00README
> > Adding         tools/partdescription/ATmega16.xml
> > Adding         tools/partdescription/ATmega32.xml
> > Adding         tools/partdescription/ATmega328P.xml
> > Adding         tools/partdescription/pd
> > Adding         tools/partdescription/pd/__init__.py
> > Adding         tools/partdescription/pd/convert_number.py
> > Adding         tools/partdescription/pd/device.py
> > Adding         tools/partdescription/pd/interrupts.py
> > Adding         tools/partdescription/pd/make_path.py
> > Adding         tools/partdescription/pd/register.py
> > Adding         tools/partdescription/pd/sleep.py
> > Adding         tools/partdescription/pd/wdt.py
> > Adding         tools/partdescription/pd2amforth
> > Transmitting file data ..............done
> > Committing transaction...
> > Committed revision 2457.
>
> I have written what little I know into a 00README file in that
> directory. May it be of help.
>
> Cheers,
> Erich
>
> PS: the website is not yet updated
>
>
> --
> May the Forth be with you ...
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] Added tools/partdescription to svn

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

Hello,

as promised, I added the script "pd2amforth" to the source tree,
see amforth/trunk/tools/partdescription/...

> $ svn commit . -m 'added tools/partdescription'
> Password: 
> Sending        doc/source/index.rst
> Adding         tools/partdescription
> Adding         tools/partdescription/00README
> Adding         tools/partdescription/ATmega16.xml
> Adding         tools/partdescription/ATmega32.xml
> Adding         tools/partdescription/ATmega328P.xml
> Adding         tools/partdescription/pd
> Adding         tools/partdescription/pd/__init__.py
> Adding         tools/partdescription/pd/convert_number.py
> Adding         tools/partdescription/pd/device.py
> Adding         tools/partdescription/pd/interrupts.py
> Adding         tools/partdescription/pd/make_path.py
> Adding         tools/partdescription/pd/register.py
> Adding         tools/partdescription/pd/sleep.py
> Adding         tools/partdescription/pd/wdt.py
> Adding         tools/partdescription/pd2amforth
> Transmitting file data ..............done
> Committing transaction...
> Committed revision 2457.

I have written what little I know into a 00README file in that
directory. May it be of help.

Cheers,
Erich

PS: the website is not yet updated


-- 
May the Forth be with you ...

Re: [Amforth] Newbie getting started with AVR128DA48

[George H. <jac...@gm...>]

Both 328eForth and FlashForth wpuld be easier starting points for a newbie.

If one must use AmForth, studying the directory structure and content is
key to finding out how to compile to a specific target.

On Tue, Dec 29, 2020, 11:22 PM Brian <bkn...@gm...> wrote:

> Perhaps the Arduino controlled by Eforth would be a good help. It has
> the full assembly code explained for eforth might be a good jumping off
> point its available at
>
> http://www.forth.org/OffeteStore/OffeteStore.html. A good read no matter
> what.
>
> Brian-in-ohio
>
> On 12/29/20 4:05 AM, Stephen D wrote:
> > Hi all,
> > would like to try running amforth on one of the new AVR processors, the
> > AVR128DA48 to be exact. A Curiosity Nano board turned up this week and
> I'm
> > keen to give it a try.
> >
> > Am a total newb with regards to amforth and forth in general but have
> > plenty of AVR programming experience, both in C and assembler. Have
> looked
> > through the User and Technical Guides but not found an answer to my
> > question:
> >
> > How do you define a new AVR8 chip within amforth?
> >
> > I have looked through the files under /avr8/devices/atmega* e.g.
> > device.asm, device.inc etc. They all claim to be "generated
> automatically".
> > I have not been able to find where the automatic generation is performed.
> > Is anyone able to point me in the right direction please?
> >
> > Thanks,
> > Stephen
> >
> > _______________________________________________
> > 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] Newbie getting started with AVR128DA48

[Brian <bkn...@gm...>]

Perhaps the Arduino controlled by Eforth would be a good help. It has 
the full assembly code explained for eforth might be a good jumping off 
point its available at

http://www.forth.org/OffeteStore/OffeteStore.html. A good read no matter 
what.

Brian-in-ohio

On 12/29/20 4:05 AM, Stephen D wrote:
> Hi all,
> would like to try running amforth on one of the new AVR processors, the
> AVR128DA48 to be exact. A Curiosity Nano board turned up this week and I'm
> keen to give it a try.
>
> Am a total newb with regards to amforth and forth in general but have
> plenty of AVR programming experience, both in C and assembler. Have looked
> through the User and Technical Guides but not found an answer to my
> question:
>
> How do you define a new AVR8 chip within amforth?
>
> I have looked through the files under /avr8/devices/atmega* e.g.
> device.asm, device.inc etc. They all claim to be "generated automatically".
> I have not been able to find where the automatic generation is performed.
> Is anyone able to point me in the right direction please?
>
> Thanks,
> Stephen
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Newbie getting started with AVR128DA48

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

Hello Stephen,

I wanted to do something similar with the ATmega4809 on a Curiosity Nano last
year but ran out of time/skill.

https://sourceforge.net/p/amforth/mailman/search/?q=4809

> There appear to be a number of changes at the C macro and register level
> from the previous mega generation. I have not dug deep enough into the
> AmForth code yet but it may require a fair bit of rework.

That was what I found also, and would agree that it may require a fair
bit of rework - both in terms of the AmForth code, but also the tool
chain more generally. All that being said, to have AmForth able to run
on this newer generation of mcu would be fantastic.

Best wishes,
Tristan

On 29Dec20 23:02, Stephen D wrote:
> Hi Erich,
> thank you for getting back to me so quickly.
> 
> On Tue, 29 Dec 2020 at 22:30, Erich Wälde <ew....@na...> wrote:
> 
> > Well, well. This is one of the secrets that I have not yet
> > uncovered from the files I have. You might not know that the
> > author of AmForth has left this planet earlier this year. So we
> > have to make due with some code archeology :)
> >
> 
> I saw with surprise and sadness the news of Matthias' passing. I imagine
> this has caused a great deal of disruption for this project. If I can help
> in any way I will.
> 
> AVR128DA48. What a beast. I skimmed the datasheet only briefly
> > https://www.microchip.com/wwwproducts/en/AVR128DA48
> >
> > If you want to work your way to support this chip, I suggest to
> > make a twofold approach:
> >
> > 1. Have a controller, which is supported by AmForth already,
> > like the venerable atmega328p. Use this to set up the whole tool
> > chain and verify, that you can build and upload it, and that the
> > result is actually working. Unless, of course, you have done
> > this already.
> >
> 
> I have access to an STK600 and several devices in the atmega family.
> Haven't programmed one with AmForth yet but based on what I've read in the
> documentation I am not expecting too many problems.
> 
> 
> > 2. Then try to fill in pieces for the new controller. Start with
> > the files of a supported controller with the same size flash/ram
> > /eeprom.
> >
> > You have to make sure, that the new controller uses the exakt
> > same set of assembly instructions --- it probably does not,
> > because I read the word "hardware multiplier"
> >
> > > The AVR128DA48 microcontroller is part of the AVR DA family
> > > featuring the AVR processor with hardware multiplier - running
> > > at up to 24 MHz and with 128 KB Flash, 16 KB SRAM and 512
> > > bytes of EEPROM in 48-pin packages.
> >
> 
> I don't think it's going to be straight forward -
> https://ww1.microchip.com/downloads/en/Appnotes/Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdf
> There appear to be a number of changes at the C macro and register level
> from the previous mega generation. I have not dug deep enough into the
> AmForth code yet but it may require a fair bit of rework.
> 
> Meanwhile I will have a look whether I can uncover the generator
> > scripts from some dusty corner ...
> >
> > Ok, I think I found them:
> > > $ ls -l pd2amforth ./pd/*
> > > -rw-r----- 1 ew ew  122 2015-09-03 18:09 ./pd/__init__.py
> > > -rw-r----- 1 ew ew  226 2015-09-03 18:09 ./pd/convert_number.py
> > > -rw-r----- 1 ew ew 2183 2016-10-18 20:40 ./pd/device.py
> > > -rw-r----- 1 ew ew 1187 2016-10-18 20:40 ./pd/interrupts.py
> > > -rw-r----- 1 ew ew  200 2015-09-03 18:09 ./pd/make_path.py
> > > -rw-r----- 1 ew ew 1618 2016-10-18 20:40 ./pd/register.py
> > > -rw-r----- 1 ew ew 1509 2016-10-18 20:40 ./pd/sleep.py
> > > -rw-r----- 1 ew ew 1065 2016-10-18 20:40 ./pd/wdt.py
> > > -rwxr-x--- 1 ew ew 1840 2016-10-18 20:40 pd2amforth*
> >
> >
> > I do not know really, how they work, but I can certainly add
> > them to the repository ...
> >
> 
> Thanks, please let me know when you have had a chance to add the scripts,
> device.py looks interesting.
> 
> 
> > Cheers,
> > Erich
> >
> 
> Cheers,
> Stephen
> 
> 
> >
> > --
> > May the Forth be with you ...
> 
> 
> And also with you ;)
> 
> _______________________________________________
> > 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] Newbie getting started with AVR128DA48

[Stephen D <au....@gm...>]

Hi Erich,
thank you for getting back to me so quickly.

On Tue, 29 Dec 2020 at 22:30, Erich Wälde <ew....@na...> wrote:

> Well, well. This is one of the secrets that I have not yet
> uncovered from the files I have. You might not know that the
> author of AmForth has left this planet earlier this year. So we
> have to make due with some code archeology :)
>

I saw with surprise and sadness the news of Matthias' passing. I imagine
this has caused a great deal of disruption for this project. If I can help
in any way I will.

AVR128DA48. What a beast. I skimmed the datasheet only briefly
> https://www.microchip.com/wwwproducts/en/AVR128DA48
>
> If you want to work your way to support this chip, I suggest to
> make a twofold approach:
>
> 1. Have a controller, which is supported by AmForth already,
> like the venerable atmega328p. Use this to set up the whole tool
> chain and verify, that you can build and upload it, and that the
> result is actually working. Unless, of course, you have done
> this already.
>

I have access to an STK600 and several devices in the atmega family.
Haven't programmed one with AmForth yet but based on what I've read in the
documentation I am not expecting too many problems.


> 2. Then try to fill in pieces for the new controller. Start with
> the files of a supported controller with the same size flash/ram
> /eeprom.
>
> You have to make sure, that the new controller uses the exakt
> same set of assembly instructions --- it probably does not,
> because I read the word "hardware multiplier"
>
> > The AVR128DA48 microcontroller is part of the AVR DA family
> > featuring the AVR processor with hardware multiplier - running
> > at up to 24 MHz and with 128 KB Flash, 16 KB SRAM and 512
> > bytes of EEPROM in 48-pin packages.
>

I don't think it's going to be straight forward -
https://ww1.microchip.com/downloads/en/Appnotes/Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdf
There appear to be a number of changes at the C macro and register level
from the previous mega generation. I have not dug deep enough into the
AmForth code yet but it may require a fair bit of rework.

Meanwhile I will have a look whether I can uncover the generator
> scripts from some dusty corner ...
>
> Ok, I think I found them:
> > $ ls -l pd2amforth ./pd/*
> > -rw-r----- 1 ew ew  122 2015-09-03 18:09 ./pd/__init__.py
> > -rw-r----- 1 ew ew  226 2015-09-03 18:09 ./pd/convert_number.py
> > -rw-r----- 1 ew ew 2183 2016-10-18 20:40 ./pd/device.py
> > -rw-r----- 1 ew ew 1187 2016-10-18 20:40 ./pd/interrupts.py
> > -rw-r----- 1 ew ew  200 2015-09-03 18:09 ./pd/make_path.py
> > -rw-r----- 1 ew ew 1618 2016-10-18 20:40 ./pd/register.py
> > -rw-r----- 1 ew ew 1509 2016-10-18 20:40 ./pd/sleep.py
> > -rw-r----- 1 ew ew 1065 2016-10-18 20:40 ./pd/wdt.py
> > -rwxr-x--- 1 ew ew 1840 2016-10-18 20:40 pd2amforth*
>
>
> I do not know really, how they work, but I can certainly add
> them to the repository ...
>

Thanks, please let me know when you have had a chance to add the scripts,
device.py looks interesting.


> Cheers,
> Erich
>

Cheers,
Stephen


>
> --
> May the Forth be with you ...


And also with you ;)

_______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Newbie getting started with AVR128DA48

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

Hello Stephen,

welcome to the list!

Stephen D writes:

> Hi all,
> would like to try running amforth on one of the new AVR processors, the
> AVR128DA48 to be exact. A Curiosity Nano board turned up this week and I'm
> keen to give it a try.
>
> Am a total newb with regards to amforth and forth in general but have
> plenty of AVR programming experience, both in C and assembler. Have looked
> through the User and Technical Guides but not found an answer to my
> question:
>
> How do you define a new AVR8 chip within amforth?
>
> I have looked through the files under /avr8/devices/atmega* e.g.
> device.asm, device.inc etc. They all claim to be "generated automatically".
> I have not been able to find where the automatic generation is performed.
> Is anyone able to point me in the right direction please?

Well, well. This is one of the secrets that I have not yet
uncovered from the files I have. You might not know that the
author of AmForth has left this planet earlier this year. So we
have to make due with some code archeology :)

AVR128DA48. What a beast. I skimmed the datasheet only briefly
https://www.microchip.com/wwwproducts/en/AVR128DA48

If you want to work your way to support this chip, I suggest to
make a twofold approach:

1. Have a controller, which is supported by AmForth already,
like the venerable atmega328p. Use this to set up the whole tool
chain and verify, that you can build and upload it, and that the
result is actually working. Unless, of course, you have done
this already.

2. Then try to fill in pieces for the new controller. Start with
the files of a supported controller with the same size flash/ram
/eeprom.

You have to make sure, that the new controller uses the exakt
same set of assembly instructions --- it probably does not,
because I read the word "hardware multiplier"

> The AVR128DA48 microcontroller is part of the AVR DA family
> featuring the AVR processor with hardware multiplier - running
> at up to 24 MHz and with 128 KB Flash, 16 KB SRAM and 512
> bytes of EEPROM in 48-pin packages.


Meanwhile I will have a look whether I can uncover the generator
scripts from some dusty corner ...

Ok, I think I found them:
> $ ls -l pd2amforth ./pd/*
> -rw-r----- 1 ew ew  122 2015-09-03 18:09 ./pd/__init__.py
> -rw-r----- 1 ew ew  226 2015-09-03 18:09 ./pd/convert_number.py
> -rw-r----- 1 ew ew 2183 2016-10-18 20:40 ./pd/device.py
> -rw-r----- 1 ew ew 1187 2016-10-18 20:40 ./pd/interrupts.py
> -rw-r----- 1 ew ew  200 2015-09-03 18:09 ./pd/make_path.py
> -rw-r----- 1 ew ew 1618 2016-10-18 20:40 ./pd/register.py
> -rw-r----- 1 ew ew 1509 2016-10-18 20:40 ./pd/sleep.py
> -rw-r----- 1 ew ew 1065 2016-10-18 20:40 ./pd/wdt.py
> -rwxr-x--- 1 ew ew 1840 2016-10-18 20:40 pd2amforth*


I do not know really, how they work, but I can certainly add
them to the repository ...

Cheers,
Erich



-- 
May the Forth be with you ...

[Amforth] Newbie getting started with AVR128DA48

[Stephen D <au....@gm...>]

Hi all,
would like to try running amforth on one of the new AVR processors, the
AVR128DA48 to be exact. A Curiosity Nano board turned up this week and I'm
keen to give it a try.

Am a total newb with regards to amforth and forth in general but have
plenty of AVR programming experience, both in C and assembler. Have looked
through the User and Technical Guides but not found an answer to my
question:

How do you define a new AVR8 chip within amforth?

I have looked through the files under /avr8/devices/atmega* e.g.
device.asm, device.inc etc. They all claim to be "generated automatically".
I have not been able to find where the automatic generation is performed.
Is anyone able to point me in the right direction please?

Thanks,
Stephen

[Amforth] First release of ./test subdir

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

Dear AmForthers,

2020-11-02 I wrote:

> 3. Add testing scripts --- I have a set of scripts for that, but I
>    have not run this stuff yet. However, in my opinion adding a
>    working test suite is far more important at the moment, than
>    anything else.
>
>    This includes preparing some hardware with 4 relevant target boards
>    in order to simplify the process.
>

I have committed r2456 with an added ./test tree.
It features one board (avr8-at644p) and a handful of test cases:
> ./bin/grok-test-log.pl tmp/unit-test.log
> TESTING addition
> INCORRECT RESULT: t{ 1 1 + -> 10 }t
>       2/3 ok, (1 failed)
> TESTING subtraction
> INCORRECT RESULT: t{ 21 4 - -> 16 }t
>       4/5 ok, (1 failed)
> TESTING multiplication
> INCORRECT RESULT: t{ $ffff -1 * -> $efff }t
>       3/4 ok, (1 failed)
> Summary:
>       9/12 ok, (3 failed)


Feel free to experiment. This is by no means ready for primetime
or complete. I add the text of the Howto below. Yes its lengthy.
But it wouldn't be worth your time if it was much shorter.


I am awaiting you comments, ideas, contributions.


Thank you for your patience and time!

Stay healthy!
Norhtern winter solstice upcoming in less than 3 days!

Cheers,
Erich




--- ./trunk/test/Howto.txt -------------------------------------------

* test

  How to run this stuff?

** prolog

   This new "test" tree is a "release early" thing. I can run "make
   test" on exactly my specific target board. I have written only a
   handful of tests in order to demonstrate the tree structure and the
   scripts. It probably needs a few more scripts and iterations to get
   this all into a clean state.


   While preparing this I realized that I probably do things quite a
   bit different. Here is why:

   Firstly, when I started with AmForth (version 2.1) neither
   "amforth-upload.py" let alone "amforth-shell.py" existed. They came
   in version 2.7 and 3.2 respectively. I remember using
   "tools/am4up.c" from within minicom and maybe other exiting hacks.

   Secondly, since sending comments to the controller were clearly a
   waste of time, I did, what any "good (tm)" Unix citizen would do: I
   wrote a few (perl) scripts as filters to make this more pleasant.
   "fs.unfold" and "fs.trim" --- they are included in
   : trunk/test/bin
   These scripts are quite simple.

   - fs.unfold :: will read the given input line by line. If a line
     starts with the pattern '^[#]*include\s+' then the next word is
     used as a file name (no spaces allowed). The file name is
     expected to be relative to the current directory. There is no
     searching and thus no error-multiple-files-found to handle. If
     the path/name does not exist, too bad, the script will bail out!

     To make the tree structure look identical in all projects, I use
     symlinks to point into the relevant source tree.

     If the file is found, its content will be added verbatim to the
     output stream, of course resolving any new include statements if
     present (recursively call the script itself again).

     The output is annotated with text markers, the resulting output
     is there to be read by human eyes.

   - fs.trim :: is removing comments, trailing whitespace, empty
     lines. It compresses whitespace after the first word (I like the
     indentation to be kept, it makes reading more pleasant while the
     code is uploading.

   And in the Makefile I will unfold by program.fs file, trim it and
   then uplaod it. Any error makes the pipeline "Fail early!"

   I switched to amforth-upload.py when it became available for the
   upload part. However, I stayed with an old version (4.0), because I
   did not like something about the newer version.

   Then along came "amforth-shell.py". It is spectacularly useful for
   newcomers. However: it needs a nicely populated tree and it changes
   the uploaded source code behind my neck (e.g. replacing PORTA by
   the appropriate value). While I do agree that this is nice for
   others, I hate it. I will not learn, that I forgot to define
   something. This will bite me when "away from home" without the
   nicely populated tree of useful files, of course.

   After that the "#require" thing came along. for similar reasons I
   don't like it, and therefore I wrote another script to delete
   these lines: "fs.del_require".

   The astute reader may have noticed, that in my little world
   comments are comments:
   : \ #include
   : \ #require
   are just comments. They are ignored.


   So, this is why things are set up like they are:
   - no searching
   - bail out on the slightest error
   - be strict to make this experiment /reproducible/

   In the interactive world, by all means use amforth-shell.py if you
   like!


** preparations

   As usual you will need all external software, to make this run. In
   my case this is at least (you hopefully get the idea):

   : bash perl python make wine/AvrAsm2 avrdude minicom

   Then there are a few /important/ symlinks.

   1.
   : trunk/avr8/Atmel -> your/local/path/to/AvrAssembler2
   This is referenced in
   : trunk/test/firmware/avr8-at644p/Makefile
   to find the Atmel assembler (run with wine)

   2.
   : trunk/test/firmware/avr8-at644p/lib
   : trunk/test/firmware/avr8-at644p/lib-avr8
   which point back into the source code tree. This is my way to find
   files like the Hayes tester
   : include lib/forth2012/tester/tester-amforth.frt
   or any other loadable forth code.
   These symlinks are currently checked in, so nothing to do.


   And there are a number of variables in
   : trunk/test/Makefile
   : trunk/firmware/avr8-at644p/Makefile
   describing the programmer and the serial interface. These should
   maybe go into separate files to be included ...



** directory tree explained

   : trunk
   :     +-- avr8
   :     |   +-- Atmel -> .local.path.to/AvrAssembler2
   :     |
   :     +-- test
   :     |   +-- Makefile
   :     |   +-- bin
   :     |   |   +-- amforth-upload-4.0.py
   :     |   |   +-- fs.del_require
   :     |   |   +-- fs.trim
   :     |   |   +-- fs.unfold
   :     |   |   +-- grok-test-log.pl
   :     |   |
   :     |   +-- cases
   :     |   |   +-- common
   :     |   |   |   +-- double
   :     |   |   |   |   +-- t_2over.frt
   :     |   |   |   +-- t_arithmetic.fs
   :     |   |   +-- avr8
   :     |   |
   :     |   +-- firmware
   :     |       +-- avr8-at644p
   :     |           +-- Makefile
   :     |           +-- dict_appl.inc
   :     |           +-- dict_appl_core.inc
   :     |           +-- first.fs
   :     |           +-- lib      -> ../../../common/lib
   :     |           +-- lib-avr8 -> ../../../avr8/lib
   :     |           +-- testfirmware.asm
   :     |           +-- testfirmware.fs
   :     |           +-- words
   :     |               +-- applturnkey.asm
   :     |               +-- qmark.asm

   - "test" is the new subdirectory.
   - "test/bin" holds hopefully all needed scripts.
   - "test/firmware" holds subdirectories for specific
     "architecture"-"target board" combinations. An obvious new
     candidate would be "avr8-duemilanove" or similar.
   - "test/cases" holds a tree of test case files.


** prepare a given target board

   : make firmware TARGET=avr8-at644p
   : make firmware-install TARGET=avr8-at644p

   Please note that the exact configuration of your target boards need
   possibly new subdirectories, specific values for cpu speed, baud
   rate, and serial interface, maybe much more.

   This would also be the place to include more .asm functions.

   "firmware" and "firmware-install" are make targets in
   : firmware/$arch-$target/Makefile
   They are called from the top level Makefile.

   I resisted the urge to create a superfancy single session make.
   While modern and sexy it is close to unpenetrable if you have not
   used this before.

** run tests

   : make upload-tester TARGET=avr8-at644p
   : make test TARGET=avr8-at644p

   Uploading the hayes tester is a separate step. The relevant file
   can be amended to include any desired .frt files, of course.

** write new tests

   Well, this is hopefully simple, get inspired by the few examples
   available.



** Epilog

   As said, this is "minimal art work".

   Don't be afraid to experiment with it.

   My goal is to make it simple for anyone to actually run the test
   suite.

   It should be simple to add more test cases. The structure should
   maybe follow the structure in the lib source directories.

   It should be possible to add a new board for any supported
   architecture with modest effort.


-- 
May the Forth be with you ...

Re: [Amforth] 2020 festive paper exchange

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

Hello David and Erich,

Thank you very much for your links. I will certainly have plenty to
keep me occupied and away from the TV over the holidays.

> Finite State Machines in Forth (J.V. Noble 1995)

Perhaps J.V. Noble's Finite State Machines in Forth and Erich's Vierte
Dimension article could be referenced on the AmForth website? For a
newcomer to Forth like me, it is too useful a paper to have to rely on
finding it by chance!

Best wishes,
Tristan

On 10Dec20 18:23, Erich Wälde wrote:
> Hello Tristan,
> 
> Tristan Williams writes:
> 
> > Hello AmForthers,
> >
> > With the season's TV not to everybody's taste and ownership of the
> > remote control contested, having an alternative activity is a good
> > idea. Over the decades there have been many good Forth papers written,
> > but finding approachable, self-contained ones is not always easy (for
> > me at least). Whilst it has been mentioned on the mailing list before,
> > here is one of my favourites
> >
> > Finite State Machines in Forth (J.V. Noble 1995)
> > http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html
> 
> This is indeed a very nice paper. So nice indeed, that I
> produced a working demo for AmForth :-)
> 
> https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2012-02.pdf
> page 6. in German, as you have guessed already.
> 
> 
> > Do you have any papers/articles to share?
> 
> One of my favourite papers is this:
> Salvatore Gaglio et al. -- Use of Forth to Enable Distributed
> Processing onWireless Sensor Networks
> 
> https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2016-01.pdf
> page 9, in English!
> and references therein.
> 
> 
> Cheers,
> Erich
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] 2020 festive paper exchange

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

Hello Tristan,

Tristan Williams writes:

> Hello AmForthers,
>
> With the season's TV not to everybody's taste and ownership of the
> remote control contested, having an alternative activity is a good
> idea. Over the decades there have been many good Forth papers written,
> but finding approachable, self-contained ones is not always easy (for
> me at least). Whilst it has been mentioned on the mailing list before,
> here is one of my favourites
>
> Finite State Machines in Forth (J.V. Noble 1995)
> http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html

This is indeed a very nice paper. So nice indeed, that I
produced a working demo for AmForth :-)

https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2012-02.pdf
page 6. in German, as you have guessed already.


> Do you have any papers/articles to share?

One of my favourite papers is this:
Salvatore Gaglio et al. -- Use of Forth to Enable Distributed
Processing onWireless Sensor Networks

https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2016-01.pdf
page 9, in English!
and references therein.


Cheers,
Erich

Re: [Amforth] 2020 festive paper exchange

[David K. <dvd...@po...>]

>>>>> "Tristan" == Tristan Williams <ho...@tj...> writes:

> Hello AmForthers, With the season's TV not to everybody's taste and
> ownership of the remote control contested, having an alternative
> activity is a good idea. Over the decades there have been many good
> Forth papers written, but finding approachable, self-contained ones is
> not always easy (for me at least). Whilst it has been mentioned on the
> mailing list before, here is one of my favourites

> Finite State Machines in Forth (J.V. Noble 1995)
> http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html

> Do you have any papers/articles to share?

Lots of papers here:

https://informatics.tuwien.ac.at/people/anton-ertl#publications

E.g.

https://publik.tuwien.ac.at/files/publik_277357.pdf
https://publik.tuwien.ac.at/files/publik_256658.pdf
https://publik.tuwien.ac.at/files/PubDat_247890.pdf
...

Maybe not properly self-contained, though you could try to traverse the
graph of references given in each paper :)

cheers,

David

[Amforth] 2020 festive paper exchange

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

Hello AmForthers,

With the season's TV not to everybody's taste and ownership of the
remote control contested, having an alternative activity is a good
idea. Over the decades there have been many good Forth papers written,
but finding approachable, self-contained ones is not always easy (for
me at least). Whilst it has been mentioned on the mailing list before,
here is one of my favourites  

Finite State Machines in Forth (J.V. Noble 1995)
http://galileo.phys.virginia.edu/classes/551.jvn.fall01/fsm.html

Do you have any papers/articles to share? 

Best wishes,
Tristan

https://sourceforge.net/p/amforth/mailman/search/?q=fsm
common/lib/fsm.frt
examples/fsm.frt

[Amforth] avr8 missing bm-test

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

A very minor item. 

avr8 has bm-set, bm-clear and bm-toggle as assembler words but does
not appear to have bm-test. This is not a big thing as it is easily
defined in forth as

: bm-test ( c a -- c ) c@ and ;

However, I've made myself an assembler version so I have a matching
set. It seems only very marginally faster than the forth one above.

; ( bitmask byte-addr -- byte )
; MCU
; return (byte at addr) AND bitmask 
VE_BM_TEST:
    .dw $ff07
    .db "bm-test"
    .dw VE_HEAD
    .set VE_HEAD = VE_BM_TEST
XT_BM_TEST:
    .dw PFA_BM_TEST
PFA_BM_TEST:
    movw zl, tosl                
    loadtos                     
    ld temp0, Z                 
    and tosl, temp0             
    clr tosh                    ; zero high byte of TOS  
    jmp_ DO_NEXT


msp430 is missing bm-toggle and arm, risc-v have none of them. 

It also seemed a reasonable opportunity to try out tester-amforth.frt
I could well be using it incorrectly. Corrections welcomed.  

\ #include tester-amforth.frt

variable v

$ffff v !

\ some passes and fails to see what it looks like 

\ should pass
t{ $ff v bm-test -> $ff }t
\ should pass
t{ $1 v bm-test -> $1 }t
\ should pass
t{ $0 v bm-test -> $0 }t
\ should pass
t{ $ffff v bm-test -> $ff }t
\ should fail 
t{ $ffff v bm-test -> $ffff }t 
\ should pass  
t{ $ff00 v bm-test -> $00 }t 
\ should fail 
t{ $ff00 v bm-test -> $ff00 }t 

\ Not sure if this is an approved way of using t{ ... }t  

\ should pass for all values 
: test.1
    #256 0 ?do
        i v ! 
        #256 0 ?do
            t{ i v bm-test -> j $ff and i and }t
        loop
    loop
;

\ intentionally broken word 
: bm-broken ( mask a -- n )
    2dup c@ dup 23 = rot rot = and if
        drop drop 0 
    else
        bm-test
    then
;

\ should fail only once when i=j=23 
: test.2
    #256 0 ?do
        i v !
        #256 0 ?do
            j 23 = if i . cr then
            t{ i v bm-broken -> j $ff and i and }t
        loop
    loop
;

Best wishes,
Tristan

Re: [Amforth] Trying to build AmForth for Atmega8

[David K. <dvd...@po...>]

Hi,

thanks to all of you for your helpful replies.  Was a little swamped
with work and didn't find time to revisit the amForth-on-Pong problem...
But with your comments so far, I think I'll give up on that idea.
Luckily I now have a half-assembled Uzebox with some first vital signs
(including a working grayscale video output), maybe this platform will
prove to be more tolerant WRT my amForth ambitions (but maybe not before
New Year).

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

[..]

> Arduboy features a atmega32u4. AmForth does not have support for the
> USB interface, should that be important.

Good to know, but it looks lika arduboy does not use the physical UART
pins [3], so maybe amForth could "just work" using those (at least if
you assemble your arduboy yourself anyway).

> uzebox features an atmega644 controller. Now that I use routinely and
> it has plenty of space.

Yes, time invested in getting amForth onto Uzebox will be better spent
than trying to make the Atmega-8 port work.  Partitioning the memory and
adding some inter-call code may even provide a simple way to integrate
"official" C/assembler board-support code (i.e. video, sound &
controller interface) with amForth.  Something like this [1-2] comes to
my mind.  Uzebox does not have a serial connector by default, but the
corresponding pins are unused, so no obstacles there.

> Dear David, you picked a new time sink, it seems. :-)

Unfortunately, a new time sink picked me :)  At least this is making
Playstations and Nintendo Switches look very boring in comparison :)

cheers,

David

[1] http://www.complang.tuwien.ac.at/anton/euroforth/ef10/papers/ertl.pdf
[2] https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2010-04.pdf
; see definition of "call1"
[3] https://aws1.discourse-cdn.com/standard14/uploads/arduboy/original/2X/0/0f375e1fd71a1f596d9d182cec7916bceacc50fd.png

Re: [Amforth] Trying to build AmForth for Atmega8

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

Hallo David,

long time no see :)
well, unfortunately ...

I have tried to assemble amforth-6.9 for atmega8.

The uart thing is quite simple to fix, as has been pointed out:

in template.asm:
-.include "drivers/usart_0.asm"
+.include "drivers/usart.asm"

And you made some progress on the "Overlap in .cseg".

cont. below ...

David Kuehling writes:

> Hi,
>
> I've been trying to get AmForth onto this Atmega 8 based platform:
>
>   https://www.elektronik-labor.de/Lernpakete/Pingong.html
>   https://www.elektronik-labor.de/Elo/ELO.html
>
> Which is sold cheaply as a toy:
>
>   https://de.elv.com/franzis-ping-pong-das-retro-spiel-zum-selberbauen-bausatz-144843
>
> Already soldered the ISP connector and a serial TTL cable.  However,
> AmForth (v6.9) does not seem to compile for Atmega8 in its current
> version.  Copying the template directory and editing makefile to say
> "MCU=atmega8", I'm getting a lot of compiler errors that indicate an
> overflow of the RWW dictionary space:
>
> ../../avr8\amforth-interpreter.asm(4): error: Overlap in .cseg: addr=0xc00 conflicts with 0x7a:0xc58
> ../../avr8\amforth-interpreter.asm(5): error: Overlap in .cseg: addr=0xc01 conflicts with 0x7a:0xc58
> [..]
>
> If I randomly comment out words in avr/appl_2k.inc, I get a little
> further.  However, then compilation errs out in the UART driver code and
> complains about stuff in macros.asm:
>
> ../../avr8\drivers/usart_0.asm(1): error: Undefined symbol: UBRR0L
> ../../avr8\drivers/usart_0.asm(2): error: Undefined symbol: UBRR0H
> ../../avr8\drivers/usart_0.asm(3): error: Undefined symbol: UCSR0C
> ../../avr8\drivers/usart_0.asm(4): error: Undefined symbol: UCSR0B
> ../../avr8\drivers/usart_0.asm(5): error: Undefined symbol: UCSR0A
> ../../avr8\drivers/usart_0.asm(12): error: Undefined symbol: RXC0
> ../../avr8\drivers/usart_0.asm(13): error: Undefined symbol: UDRE0
> ../../avr8\drivers/usart_0.asm(14): error: Undefined symbol: TXEN0
> ../../avr8\drivers/usart_0.asm(15): error: Undefined symbol: RXEN0
> ../../avr8\drivers/usart_0.asm(16): error: Undefined symbol: RXCIE0
> ../../avr8\drivers/usart_0.asm(17): error: Undefined symbol: UDRIE0
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
> ../../avr8\macros.asm(94): error: jmp k: Unsupported instruction on ATmega8
>
> And this is even before I try to resolve all the problems arising from
> the words that I commented out.
>
> Maybe the Atmega8-specific code has been bit-rotting without being used
> for too long already?  What do you think are my chances to make this
> work again?  Any ideas what's wrong about the Uart drivers and how to
> strip down AmForth to fit into 8 kB of flash?  Or has AmForth just
> gotten too old and fat over the years to render this undertaking
> unachievable?

Bitrot is maybe the wrong word for this. AmForth has grown in
features and thus in size. 8 kiB flash is imho too small. It was
too small for a long time already, because you really need a few
kB free space for your own programm, right?

Maybe starting with AmForth-4.x is more successful?

You may be able to just get it to work, but then what?

I would like to see, what needs to be stripped out until it
fits. But I guess it is really not worth the effort.


Just for the sake of the argument I tried AmForth-4.0 (release
2010-07-01). It does not assemble, even though there is only 1
overlap conflict. Sigh.

The atmega8 has worked, but I have no idea which release made it
fail the size constraints.


Maybe I should place a more prominent warning on the webpage.
Currently we have this:

webpage> AmForth for the AVR8 needs 8 to 12 KB Flash memory, 80
webpage> bytes EEPROM, and 200 bytes RAM for the core system.



> (I did some experiments with an Arduino Uno clone first, and had no
> problem compiling and setting up AmForth on it.)
>
> Maybe the Arduboy [1] would be better suited to AmForth, but it's also
> more costly and complex to program.  I'm also eyeing the uzebox [2], but
> getting its video driver into AmForth would be a daunting
> endevour.

Arduboy features a atmega32u4. AmForth does not have support for
the USB interface, should that be important.

uzebox features an atmega644 controller. Now that I use
routinely and it has plenty of space.


Dear David,
you picked a new time sink, it seems. :-)

Cheers,
Erich

>
> cheers,
>
> David
>
> [1] https://www.reichelt.de/arduboy-arduino-kompatibles-miniaturspielsystem-ard-arduboy-p254388.html?&trstct=pos_0&nbc=1
> [2] http://belogic.com/uzebox/index.asp


-- 
May the Forth be with you ...