amforth-devel — Development discussion and user support

Re: [Amforth] Trying to build AmForth for Atmega8

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

Hello David,

The ping-pong[1] looks interesting!

You are correct the ATMega8 does present some challenges for AmForth 6.9
This issue came up on the mailing list earlier this year.

> Any ideas what's wrong about the Uart drivers

https://sourceforge.net/p/amforth/mailman/message/37085124/ 

> 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?

https://sourceforge.net/p/amforth/mailman/message/37085843/

I think also that the ATMega8 may be missing some assembly
instructions that are now relied upon by the current build. Whether
it is technically possible to put AmForth 6.9 on a diet such that it
would fit in 8k flash I don't know, but faced with the task, I would
try to do it on an ATMega328p first.  

>From a quick look at the ping-pong manual[3] I think it uses the
internal RC oscillator as the system clock as I couldn't see a crystal
or resonator. Sadly, the manual does not show a nicely socket-ed DIP-28
ATMega8. Otherwise replacing it physically with an ATMega328[2] might
have been an option to consider.

Best wishes,
Tristan

[1] https://de.elv.com/franzis-ping-pong-das-retro-spiel-zum-selberbauen-bausatz-144843
[2] https://www.avrfreaks.net/forum/difference-between-atmega8-and-atmega328
[3] https://files2.elv.com/public/14/1448/144843/Internet/144843_manual.pdf


On 23Nov20 23:17, David Kuehling wrote:
> 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?
> 
> (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.
> 
> 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
> -- 
> GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg
> Fingerprint: B63B 6AF2 4EEB F033 46F7  7F1D 935E 6F08 E457 205F
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Trying to build AmForth for Atmega8

[tur b. <mai...@gm...>]

David looks like preamble.Inc is not finding device.asm in devices/atmega8
could be to many folders in path. I have used avrstudio4 and enter the
avr8/devices/atmega8 in its additional path setting, you may need to look
up the serial the chip has and set that in the config file

On Mon, 23 Nov 2020 22:18 David Kuehling, <dvd...@po...> wrote:

> 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?
>
> (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.
>
> 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
> --
> GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg
> Fingerprint: B63B 6AF2 4EEB F033 46F7  7F1D 935E 6F08 E457 205F
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] Trying to build AmForth for Atmega8

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

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?

(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.

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
-- 
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg
Fingerprint: B63B 6AF2 4EEB F033 46F7  7F1D 935E 6F08 E457 205F

[Amforth] Contemplating automatic tests

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

Dear AmForthers,

Monday evening doing a little AmForth related stuff, how is that?
Full disclosure: I am using emacs/org-mode. So I created a habit
for Monday. And boy those red colored bars saying "not done"
become annoying quickly. So better do something :)


Contemplating the Test Cases Thing

> 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.

Turns out that the set of scripts isn't all that great. So:
What would I like to achieve?

There will be a ./test/ directory, which holds the test cases and
the files to programm my available target hw for the tests.

: cd test
: make targets          # shall produce firmware for target boards
: make install $target  # flash the particular target board
: make test $target     # calls the runner on a given list of test cases

The result should be something like this:
: make test $target
: . loading tester on $target, ok.
: . 0/12  test/common/test-A.frt, ok
: . 1/19  test/common/test-B.frt, 1 error
: 1 error in 21 tests

The verbatim output goes to runner.log or something such.


*configuration*

- which target board do I want to use?
- which programmer and its paramters do I have?
- which details for the serial (or other?) connection?


*terminology*

- unit-under-test :: this is the function (asm of forth word) to
  be tested.
  : : unit-under-test ( stack -- effect )
  :   definition
  : ;

  These live in the directories arm, avr8, common, msp430,
  risc-v, shared ... these trees should remain unchanged imho.

- test case :: this is a statement to load unit-under-test and
  its possible dependencies, plus a collection of "t{ ... }t"
  statements to exercise unit-under-test:
  : #include unit-under-test.fs
  : t{ stack  function  changed stack }t

  Other forms of test procedures should be possible as long as
  they produce output, which can be understood by the runner.

  There are dragons lurking here when it comes to #include or
  #require.

- runner :: this is a script which can talk to a target board
  (via serial), feed a testcase file, collect the resulting
  output and extract the results

- tester :: this is an implementation of the Hayes tester. It
  defines 't{' '}t' and a few more words.

- firmware :: for every target board to be used, we require
  a well equipped AmForth firmware. I expect this firmware to be
  somewhat special and separate from the examples in the ./appl/
  subdirectory.

There are possible complications known as setup/teardown. Markers
could possibly help. On the other hand, I have not yet exhausted
the flash or RAM of a atmega-644a.


*possible tree layout*

: amforth/trunk
: ...
: +-- test/
:     +-- Makefile                     \ top of magic
:     +-- M.programmer.mk              \ make vars to specify my programmer
:     +-- M.connection.mk              \ make vars to specify serial connection
:     +-- bin/                         \ any tools
:     |   +-- runner.pl
:     |
:     +-- tester/                      \ place for tester words? optional?
:     |
:     +-- firmware/
:     |   +-- avr8-at644p/
:     |   |   +-- Makefile
:     |   |   +-- dict_appl_core.inc
:     |   |   +-- dict_appl.inc        \ includes dict_local.inc
:     |   |   +-- dict_local.inc       \ all additional words to load in this context
:     |   |   +-- testfirmware.asm     \ top level definition for target firmware
:     |   |   +-- words/
:     |   |       +-- applturnkey.asm  \ project specific
:     |   |
:     |   +-- $target-$controller/
:     |   |   +-- Makefile
:     |   |   +-- ...
:     |   ...
:     |
:     +-- cases/
:     |   +-- common/                  \ testcases for all target boards
:     |   |   +-- stack-test.frt
:     |   |   ...
:     |   |
:     |   +-- avr8/                    \ testcases for specific target boards
:     |   |   +-- ...
:     |   ...
:     |
:     +-- logs/                        \ place for logfiles?


Assuming that Mr.Someone has installed the relevant tools,
editing the M.*.mk files should be enough to
- produce firmware for at least one target
- install the firmware on said target
- load and evaluate the available tests

All of this in a few lines of shell commands.

Does that sound like a plausible plan?

Next step: create this structure for one target and a few test
cases and see, how we fare.

Cheers,
Erich


-- 
May the Forth be with you ...

Re: [Amforth] some patches to the ARM section of the webpage

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

Hello Carsten,

Carsten Strotmann writes:

> please find attached two patches for the amForth website
> source, ARM pages.

thank you for the patches. I have committed them and updated the
web site --- not without deleting it first, sigh.

> My editor (Emacs) cleans the whitespace, if that is an issue,
> I'll remove that and resend.

Not a problem.

Cheers,
Erich

>
> Greetings
>
> Carsten
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: 0001-Adding-information-that-amForth-targets-32bit-ARM.patch
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: 0002-Fixed-a-typo.patch
>
> _______________________________________________
> 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 ...

[Amforth] some patches to the ARM section of the webpage

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

Hi Erich,

please find attached two patches for the amForth website source, ARM 
pages.

My editor (Emacs) cleans the whitespace, if that is an issue, I'll 
remove that and resend.

Greetings

Carsten
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-Adding-information-that-amForth-targets-32bit-ARM.patch
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0002-Fixed-a-typo.patch

Re: [Amforth] SVN to GIT [Re: draft: roadmap for AmForth]

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

Hi,

On 3 Nov 2020, at 21:47, Ian Jefferson wrote:

> Some good points here:
>
>> On Nov 3, 2020, at 4:33 AM, fr...@fr... wrote:
>>
>> - Gradual or "big bang" migration?
>>   Should SVN and GIT run in parallel for some time, or is
>>   it OK to have a single big bang migration? Big bang is
>>   a lot easier…
>>
>
> Big Bang.  We are too small and under staffed (current Army of Erich!) 
>  to maintain stuff in parallel.  Given the opportunity we can all grab 
> working copies before the transition.  A good thought here Frank.
>

+1

>> - Do you want to completely ignore GitHub?
>>   GitHub is the go-to place for open source software.
>>   Google does heavy indexing there. If you want AmForth
>>   to reach a large community, then you have to  publish
>>   there. However, it doesn't need to the the primary repo...
>
> Another wise comment Frank.  There is something eventually even I 
> could maintain for the community!  Keeping things as open to the main 
> stream opensource crowd is a good thought even if the day to day is 
> managed elsewhere and when.

I use both sourcehut and GitHub, I prefer sourcehut but I agree that 
amForth should have a presence on Github as well. There are already 
various forks of amForth on Github, as well as amForth related code. 
Being on Github is important to be visible.

And yes, an automated sync between sr.ht and GitHub could be possible.

A repo on GitHub should be "official", e.g. the same people that run the 
main repo (Erich at the moment) should also have control there, even if 
someone from the community operates the repo and the sync. This prevents 
that the two repos will diverge later.

Greetings

Carsten

Re: [Amforth] SVN to GIT [Re: draft: roadmap for AmForth]

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

Hello Dieter,

On 3 Nov 2020, at 20:07, di...@sc... wrote:

> I gave it a try and started a svn2git conversion on my machine with 
> the command:
> svn2git https://svn.code.sf.net/p/amforth/code --branches releases
> This takes about 10 minutes, depending on host power and network 
> connection.
> This converts the trunk to themaster branch and converts all the 
> releases tree to branches.
> The result looks quite well to me.

thank you. I've cloned your git repo and indeed it looks good to me (but 
I'm not a big expert on "git", but I see the different commits and 
diffs)

Greetings

Carsten

Re: [Amforth] SVN to GIT [Re: draft: roadmap for AmForth]

[Ian J. <ij...@sa...>]

Some good points here:

> On Nov 3, 2020, at 4:33 AM, fr...@fr... wrote:
> 
> - Gradual or "big bang" migration?
>   Should SVN and GIT run in parallel for some time, or is
>   it OK to have a single big bang migration? Big bang is
>   a lot easier…
> 

Big Bang.  We are too small and under staffed (current Army of Erich!)  to maintain stuff in parallel.  Given the opportunity we can all grab working copies before the transition.  A good thought here Frank.

> - Do you want to completely ignore GitHub?
>   GitHub is the go-to place for open source software.
>   Google does heavy indexing there. If you want AmForth
>   to reach a large community, then you have to  publish
>   there. However, it doesn't need to the the primary repo...

Another wise comment Frank.  There is something eventually even I could maintain for the community!  Keeping things as open to the main stream opensource crowd is a good thought even if the day to day is managed elsewhere and when.

Ian

Re: [Amforth] SVN to GIT [Re: draft: roadmap for AmForth]

[<di...@sc...>]

Hi all,
I think I introduced myself already, but that was years ago.
I first played around with forth in the 80s, but never had a chance to use it properly for a real project.
Maybe this changes now, because due to corona I am working part-time now..
On the svn2git topic:
I gave it a try and started a svn2git conversion on my machine with the command:
svn2git https://svn.code.sf.net/p/amforth/code --branches releases
This takes about 10 minutes, depending on host power and network connection.
This converts the trunk to themaster branch and converts all the releases tree to branches.
The result looks quite well to me.
I have uploaded it to a private server, you can have a look at:
fo...@ho...:amforth.git
The password is the name of this project in uppercase, a dot, and 0x7d6 in decimal.
If you like, I could also upload it to gitlab or github.
Kind regards,
Dieter
Am Di., Nov. 3, 2020 10:34 schrieb fr...@fr...:
Hi!

Point 5 is huge and needs to be broken into smaller steps.

I would appreciate any response, and if you could
include, which target you are using, all the better.

We (http://www.project-open.com/ (http://www.project-open.com/)) are in the process of
moving from CVS to GIT for the next ]project-open[ V5.1
release. The process is the same for SVN, the tool is actually
called svn2git...

We decided to host our repos on a private GitLab instance
because:

- GitLab allows us to setup permissions for "packages"
  (see below). That's important for us, because customer
  specific packages contain code that is not public.

- GitLab is open source.

- The GitLab founders are credible with their open source
  philosophy and the business model seems viable.

We also publish on GitHub for PR reasons. It's free...

Previously, our code was kept in a CVS repository.
We installed GitLab in a VM and moved the CVS
repository to the same CentOS VM  that is running
GitLab. Every night we now run "cvs2git" which is
originally from http://cvs2svn.tigris.org/cvs2svn.html (http://cvs2svn.tigris.org/cvs2svn.html)
but now available for example here:
https://github.com/mhagger/cvs2svn (https://github.com/mhagger/cvs2svn)

We have configured cvs2git to push the CVS
changes both to GitHub and our private GitLab repos.

This has worked without problems for quite some time,
many repositories (our product consists of ~200
"packages" which are represented by separate repos)
and very large repositories (we've got ~4 million LoC
in total). Our next ]po[ V5.1 release will be based on GIT.

We like that we can work with GIT on the "customer"
side, while still using CVS as the upstream/master
repository for some time. CVS is still referenced by
many integration links, so we can't just break this.

I believe the AmForth community should take several
decisions:

- Gradual or "big bang" migration?
  Should SVN and GIT run in parallel for some time, or is
  it OK to have a single big bang migration? Big bang is
  a lot easier...

- Do you want to completely ignore GitHub?
  GitHub is the go-to place for open source software.
  Google does heavy indexing there. If you want AmForth
  to reach a large community, then you have to  publish
  there. However, it doesn't need to the the primary repo...

convert the releases/N.M directories

This seems to be quite difficult to me. Maybe just keep
these directories during the initial migration and delete
them in the following releases?

Keep up the good work!

Cheers!
Frank

On 2/11/20 20:36, Erich Wälde wrote:
Dear AmForthers,

some time ago (2020-08-02), Mark Roth suggested to come up with a
"road map". Now while mapping unknown territory is a challenge of
sorts, it might be not that difficult in this case.

This my personal point of view, it might change anytime without prior
notice.

1. Accumulate all commits since Jan 2019 and call it *release 6.9*
That I have done. :)

2. Document the exact steps that were needed to create "a release".
Well yes, I have these lines, but not in shape and maybe not
complete. It should be added to the repository nonetheless.

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.

4. Call this *release 7.0*

5. Convert and Move Repository

Currently it looks like I would have to convert the svn repository
to a git repository with a tool like svn2git. This is a process I
would like to avoid, so if someone knows how to convert the
repository "server side", or even how to export the complete svn
repository on sourceforge into a big file ... all hints are kindly
appreciated.

I would then move to sourcehut.org. Why?

- I do have an account there already
- sourcehut offers accounts for a very reasonable amount of money.
- sourchut works without javascript! Can you believe this? No? Try it.
For me this is a major step in the correct direction. [1]
- I would order and pay for a new project account
- I would like to add at least two collaborators with full access
from day one. Volunteers?

This is going to include more things than just converting the
repository:

- possibly convert the releases/N.M directories into branches
- create a new space for the webpage
- automate generation of the webpage, serverside if possible
- document how to locally generate the documentation --- well, the
stuff you have to install before "cd doc; make all".
- look into the use of javascript and possible ways to reduce that,
should it be desirable
- create an archive for (some of) the old tarballs
- archive and transfer the mailing list content
- create a new mailing list
- automate the generation of a release
- document the release process
- start using the bugtracker (preferably with connection to the
mailing list)
- test the branch-edit-pull.request-merge workflow
- possibly convert "Opinion" into a prober blog?
- setup a redirection notice on sourceforge, close everything else
down.
- possibly dissolve amforth/community into a ./contrib/
subdirectory, test the stuff again and document it better
https://sourceforge.net/p/amforth/community/HEAD/tree/ (https://sourceforge.net/p/amforth/community/HEAD/tree/)

And this list is not complete.

6. Call this *release 8.0*

7. Remove arm msp430 riscv for the sake of simplicity -- unless
someone speaks up to offer help.

Carsten has offered support for arm and riscv --- Thank you!

msp430 anyone?

8. Fix and automate the creation of the reference cards

- include ALL available WORDs (not only the ones in a particular
build)
- include the exact file path(s), where WORD is defined
- possibly add a Forth equivalent (.asm WORDS)
- possibly a pointer to a worked example

In order to achieve that I would rework the existing perl script
AND add any missing file headers, possibly in a new/enhanced
format.

If we get this far, then imho we have /advanced considerably/.

Does this sound like a worthwile plan?

I'm sure there are other ideas and suggestions.

Point 5 is huge and needs to be broken into smaller steps.

I would appreciate any response, and if you could
include, which target you are using, all the better.

Still reading?
Thank you for your precious time.

Happy forthing,
Erich

[1] I'm using torbrowser most of the time. I'm using firefox to
work at amforth.sourceforge.net. However, NoScript or uMatrix do
an excellent job, but break the sf.net webpage routinely. I do
not see all the buttons and what not unless I really switch off
NoScript. This is not, what I prefer.

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

[Amforth] SVN to GIT [Re: draft: roadmap for AmForth]

[<fr...@fr...>]

Hi!


 > Point 5 is huge and needs to be broken into smaller steps.
 >
 > I would appreciate any response, and if you could
 > include, which target you are using, all the better.


We (http://www.project-open.com/) are in the process of
moving from CVS to GIT for the next ]project-open[ V5.1
release. The process is the same for SVN, the tool is actually
called svn2git...

We decided to host our repos on a private GitLab instance
because:

- GitLab allows us to setup permissions for "packages"
   (see below). That's important for us, because customer
   specific packages contain code that is not public.

- GitLab is open source.

- The GitLab founders are credible with their open source
   philosophy and the business model seems viable.


We also publish on GitHub for PR reasons. It's free...

Previously, our code was kept in a CVS repository.
We installed GitLab in a VM and moved the CVS
repository to the same CentOS VM  that is running
GitLab. Every night we now run "cvs2git" which is
originally from http://cvs2svn.tigris.org/cvs2svn.html
but now available for example here:
https://github.com/mhagger/cvs2svn

We have configured cvs2git to push the CVS
changes both to GitHub and our private GitLab repos.

This has worked without problems for quite some time,
many repositories (our product consists of ~200
"packages" which are represented by separate repos)
and very large repositories (we've got ~4 million LoC
in total). Our next ]po[ V5.1 release will be based on GIT.

We like that we can work with GIT on the "customer"
side, while still using CVS as the upstream/master
repository for some time. CVS is still referenced by
many integration links, so we can't just break this.

I believe the AmForth community should take several
decisions:

- Gradual or "big bang" migration?
   Should SVN and GIT run in parallel for some time, or is
   it OK to have a single big bang migration? Big bang is
   a lot easier...

- Do you want to completely ignore GitHub?
   GitHub is the go-to place for open source software.
   Google does heavy indexing there. If you want AmForth
   to reach a large community, then you have to  publish
   there. However, it doesn't need to the the primary repo...


 > convert the releases/N.M directories

This seems to be quite difficult to me. Maybe just keep
these directories during the initial migration and delete
them in the following releases?


Keep up the good work!



Cheers!
Frank


On 2/11/20 20:36, Erich Wälde wrote:
> Dear AmForthers,
>
> some time ago (2020-08-02), Mark Roth suggested to come up with a
> "road map". Now while mapping unknown territory is a challenge of
> sorts, it might be not that difficult in this case.
>
> This my personal point of view, it might change anytime without prior
> notice.
>
> 1. Accumulate all commits since Jan 2019 and call it *release 6.9*
>      That I have done. :)
>
> 2. Document the exact steps that were needed to create "a release".
>      Well yes, I have these lines, but not in shape and maybe not
>      complete. It should be added to the repository nonetheless.
>
> 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.
>
> 4. Call this *release 7.0*
>
> 5. Convert and Move Repository
>
>      Currently it looks like I would have to convert the svn repository
>      to a git repository with a tool like svn2git. This is a process I
>      would like to avoid, so if someone knows how to convert the
>      repository "server side", or even how to export the complete svn
>      repository on sourceforge into a big file ... all hints are kindly
>      appreciated.
>
>      I would then move to sourcehut.org. Why?
>
>      - I do have an account there already
>      - sourcehut offers accounts for a very reasonable amount of money.
>      - sourchut works without javascript! Can you believe this? No? Try it.
>        For me this is a major step in the correct direction. [1]
>      - I would order and pay for a new project account
>      - I would like to add at least two collaborators with full access
>        from day one. Volunteers?
>
>      This is going to include more things than just converting the
>      repository:
>
>      - possibly convert the releases/N.M directories into branches
>      - create a new space for the webpage
>      - automate generation of the webpage, serverside if possible
>      - document how to locally generate the documentation --- well, the
>        stuff you have to install before "cd doc; make all".
>      - look into the use of javascript and possible ways to reduce that,
>        should it be desirable
>      - create an archive for (some of) the old tarballs
>      - archive and transfer the mailing list content
>      - create a new mailing list
>      - automate the generation of a release
>      - document the release process
>      - start using the bugtracker (preferably with connection to the
>        mailing list)
>      - test the branch-edit-pull.request-merge workflow
>      - possibly convert "Opinion" into a prober blog?
>      - setup a redirection notice on sourceforge, close everything else
>        down.
>      - possibly dissolve amforth/community into a ./contrib/
>        subdirectory, test the stuff again and document it better
>        https://sourceforge.net/p/amforth/community/HEAD/tree/
>
>      And this list is not complete.
>
> 6. Call this *release 8.0*
>
> 7. Remove arm msp430 riscv for the sake of simplicity -- unless
>      someone speaks up to offer help.
>
>      Carsten has offered support for arm and riscv --- Thank you!
>
>      msp430 anyone?
>
> 8. Fix and automate the creation of the reference cards
>
>      - include ALL available WORDs (not only the ones in a particular
>        build)
>      - include the exact file path(s), where WORD is defined
>      - possibly add a Forth equivalent (.asm WORDS)
>      - possibly a pointer to a worked example
>
>      In order to achieve that I would rework the existing perl script
>      AND add any missing file headers, possibly in a new/enhanced
>      format.
>
>
> If we get this far, then imho we have /advanced considerably/.
>
>
>
>
> Does this sound like a worthwile plan?
>
> I'm sure there are other ideas and suggestions.
>
> Point 5 is huge and needs to be broken into smaller steps.
>
>
> I would appreciate any response, and if you could
> include, which target you are using, all the better.
>
>
> Still reading?
> Thank you for your precious time.
>
> Happy forthing,
> Erich
>
>
>
> [1] I'm using torbrowser most of the time. I'm using firefox to
> work at amforth.sourceforge.net. However, NoScript or uMatrix do
> an excellent job, but break the sf.net webpage routinely. I do
> not see all the buttons and what not unless I really switch off
> NoScript. This is not, what I prefer.
>

Re: [Amforth] draft: roadmap for AmForth

[Ian J. <ij...@sa...>]

Hi Erich,

I’m probably another year out to offer any help if I’m even still capable… although I think I could muddle through and contribute some system admin type help with the irksome repositories.  

It seems to me that embedded hardware is vibrantly healthy and with the pressures IoT and of energy management low power etc. may stay that way.  

I’m curious therefore about the future of the current Atmel platform vs some of the other chips out there.  Should amforth keep its name or has it evolved to something else than Atmel Forth?

As for the plan it sounds great to me.  I am especially the part about realizing that having a plan makes us better prepared for change not resistant to it.  “it might change anytime without prior notice” . 

Thank you again for stepping in on this project.  I hope to return to forth when I unpack my Oscilloscope and bench power supply wherever they went.   

May the forth be with all the AMForthers - or any other corny positive greeting I can offer in this very strange and ugly year.

Ian 


> On Nov 2, 2020, at 2:36 PM, Erich Wälde <ew....@na...> wrote:
> 
> 
> Dear AmForthers,
> 
> some time ago (2020-08-02), Mark Roth suggested to come up with a
> "road map". Now while mapping unknown territory is a challenge of
> sorts, it might be not that difficult in this case.
> 
> This my personal point of view, it might change anytime without prior
> notice.
> 
> 1. Accumulate all commits since Jan 2019 and call it *release 6.9*
>   That I have done. :)
> 
> 2. Document the exact steps that were needed to create "a release".
>   Well yes, I have these lines, but not in shape and maybe not
>   complete. It should be added to the repository nonetheless.
> 
> 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.
> 
> 4. Call this *release 7.0*
> 
> 5. Convert and Move Repository
> 
>   Currently it looks like I would have to convert the svn repository
>   to a git repository with a tool like svn2git. This is a process I
>   would like to avoid, so if someone knows how to convert the
>   repository "server side", or even how to export the complete svn
>   repository on sourceforge into a big file ... all hints are kindly
>   appreciated.
> 
>   I would then move to sourcehut.org. Why?
> 
>   - I do have an account there already
>   - sourcehut offers accounts for a very reasonable amount of money.
>   - sourchut works without javascript! Can you believe this? No? Try it.
>     For me this is a major step in the correct direction. [1]
>   - I would order and pay for a new project account
>   - I would like to add at least two collaborators with full access
>     from day one. Volunteers?
> 
>   This is going to include more things than just converting the
>   repository:
> 
>   - possibly convert the releases/N.M directories into branches
>   - create a new space for the webpage
>   - automate generation of the webpage, serverside if possible
>   - document how to locally generate the documentation --- well, the
>     stuff you have to install before "cd doc; make all".
>   - look into the use of javascript and possible ways to reduce that,
>     should it be desirable
>   - create an archive for (some of) the old tarballs
>   - archive and transfer the mailing list content
>   - create a new mailing list
>   - automate the generation of a release
>   - document the release process
>   - start using the bugtracker (preferably with connection to the
>     mailing list)
>   - test the branch-edit-pull.request-merge workflow
>   - possibly convert "Opinion" into a prober blog?
>   - setup a redirection notice on sourceforge, close everything else
>     down.
>   - possibly dissolve amforth/community into a ./contrib/
>     subdirectory, test the stuff again and document it better
>     https://sourceforge.net/p/amforth/community/HEAD/tree/
> 
>   And this list is not complete.
> 
> 6. Call this *release 8.0*
> 
> 7. Remove arm msp430 riscv for the sake of simplicity -- unless
>   someone speaks up to offer help.
> 
>   Carsten has offered support for arm and riscv --- Thank you!
> 
>   msp430 anyone?
> 
> 8. Fix and automate the creation of the reference cards
> 
>   - include ALL available WORDs (not only the ones in a particular
>     build)
>   - include the exact file path(s), where WORD is defined
>   - possibly add a Forth equivalent (.asm WORDS)
>   - possibly a pointer to a worked example
> 
>   In order to achieve that I would rework the existing perl script
>   AND add any missing file headers, possibly in a new/enhanced
>   format.
> 
> 
> If we get this far, then imho we have /advanced considerably/.
> 
> 
> 
> 
> Does this sound like a worthwile plan?
> 
> I'm sure there are other ideas and suggestions.
> 
> Point 5 is huge and needs to be broken into smaller steps.
> 
> 
> I would appreciate any response, and if you could
> include, which target you are using, all the better.
> 
> 
> Still reading?
> Thank you for your precious time.
> 
> Happy forthing,
> Erich
> 
> 
> 
> [1] I'm using torbrowser most of the time. I'm using firefox to
> work at amforth.sourceforge.net. However, NoScript or uMatrix do
> an excellent job, but break the sf.net webpage routinely. I do
> not see all the buttons and what not unless I really switch off
> NoScript. This is not, what I prefer.
> 
> -- 
> 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

Re: [Amforth] draft: roadmap for AmForth

[Matt L. <ma...@te...>]

I would love to see native Forth on the ESP8266 boards.  With 4mb of 
storage that my boards have, it would be really handy.

-- Matt

On 11/2/20 3:36 PM, Tristan Williams wrote:
> Hello Erich, AmForthers,
>
>> Does this sound like a worthwile plan?
> Yes, very much so.
>
> I would be interested in progressing further with AmForth for
> RISC-V. The existing AmForth target board HiFive1 has been
> discontinued [1] - though there is the upgraded HiFive1 Rev B [2].
>
> Are there any views on which RISC-V board(s) should be considered for
> AmForth?
>
> I like the idea of converting "opinion" into a proper blog, perhaps
> extending it to some more general Forth ideas/resources.
>
> Best wishes,
> Tristan
>
> [1] https://www.sifive.com/boards/hifive1
> [2] https://www.sifive.com/boards/hifive1-rev-b
>
> On 02Nov20 20:36, Erich Wälde wrote:
>> Dear AmForthers,
>>
>> some time ago (2020-08-02), Mark Roth suggested to come up with a
>> "road map". Now while mapping unknown territory is a challenge of
>> sorts, it might be not that difficult in this case.
>>
>> This my personal point of view, it might change anytime without prior
>> notice.
>>
>> 1. Accumulate all commits since Jan 2019 and call it *release 6.9*
>>     That I have done. :)
>>
>> 2. Document the exact steps that were needed to create "a release".
>>     Well yes, I have these lines, but not in shape and maybe not
>>     complete. It should be added to the repository nonetheless.
>>
>> 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.
>>
>> 4. Call this *release 7.0*
>>
>> 5. Convert and Move Repository
>>
>>     Currently it looks like I would have to convert the svn repository
>>     to a git repository with a tool like svn2git. This is a process I
>>     would like to avoid, so if someone knows how to convert the
>>     repository "server side", or even how to export the complete svn
>>     repository on sourceforge into a big file ... all hints are kindly
>>     appreciated.
>>
>>     I would then move to sourcehut.org. Why?
>>
>>     - I do have an account there already
>>     - sourcehut offers accounts for a very reasonable amount of money.
>>     - sourchut works without javascript! Can you believe this? No? Try it.
>>       For me this is a major step in the correct direction. [1]
>>     - I would order and pay for a new project account
>>     - I would like to add at least two collaborators with full access
>>       from day one. Volunteers?
>>
>>     This is going to include more things than just converting the
>>     repository:
>>
>>     - possibly convert the releases/N.M directories into branches
>>     - create a new space for the webpage
>>     - automate generation of the webpage, serverside if possible
>>     - document how to locally generate the documentation --- well, the
>>       stuff you have to install before "cd doc; make all".
>>     - look into the use of javascript and possible ways to reduce that,
>>       should it be desirable
>>     - create an archive for (some of) the old tarballs
>>     - archive and transfer the mailing list content
>>     - create a new mailing list
>>     - automate the generation of a release
>>     - document the release process
>>     - start using the bugtracker (preferably with connection to the
>>       mailing list)
>>     - test the branch-edit-pull.request-merge workflow
>>     - possibly convert "Opinion" into a prober blog?
>>     - setup a redirection notice on sourceforge, close everything else
>>       down.
>>     - possibly dissolve amforth/community into a ./contrib/
>>       subdirectory, test the stuff again and document it better
>>       https://sourceforge.net/p/amforth/community/HEAD/tree/
>>
>>     And this list is not complete.
>>
>> 6. Call this *release 8.0*
>>
>> 7. Remove arm msp430 riscv for the sake of simplicity -- unless
>>     someone speaks up to offer help.
>>
>>     Carsten has offered support for arm and riscv --- Thank you!
>>
>>     msp430 anyone?
>>
>> 8. Fix and automate the creation of the reference cards
>>
>>     - include ALL available WORDs (not only the ones in a particular
>>       build)
>>     - include the exact file path(s), where WORD is defined
>>     - possibly add a Forth equivalent (.asm WORDS)
>>     - possibly a pointer to a worked example
>>
>>     In order to achieve that I would rework the existing perl script
>>     AND add any missing file headers, possibly in a new/enhanced
>>     format.
>>
>>
>> If we get this far, then imho we have /advanced considerably/.
>>
>>
>>
>>
>> Does this sound like a worthwile plan?
>>
>> I'm sure there are other ideas and suggestions.
>>
>> Point 5 is huge and needs to be broken into smaller steps.
>>
>>
>> I would appreciate any response, and if you could
>> include, which target you are using, all the better.
>>
>>
>> Still reading?
>> Thank you for your precious time.
>>
>> Happy forthing,
>> Erich
>>
>>
>>
>> [1] I'm using torbrowser most of the time. I'm using firefox to
>> work at amforth.sourceforge.net. However, NoScript or uMatrix do
>> an excellent job, but break the sf.net webpage routinely. I do
>> not see all the buttons and what not unless I really switch off
>> NoScript. This is not, what I prefer.
>>
>> -- 
>> 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-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] draft: roadmap for AmForth

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

Hello Erich, AmForthers,

> Does this sound like a worthwile plan?

Yes, very much so.

I would be interested in progressing further with AmForth for
RISC-V. The existing AmForth target board HiFive1 has been
discontinued [1] - though there is the upgraded HiFive1 Rev B [2].

Are there any views on which RISC-V board(s) should be considered for
AmForth?

I like the idea of converting "opinion" into a proper blog, perhaps
extending it to some more general Forth ideas/resources.

Best wishes,
Tristan

[1] https://www.sifive.com/boards/hifive1
[2] https://www.sifive.com/boards/hifive1-rev-b

On 02Nov20 20:36, Erich Wälde wrote:
> 
> Dear AmForthers,
> 
> some time ago (2020-08-02), Mark Roth suggested to come up with a
> "road map". Now while mapping unknown territory is a challenge of
> sorts, it might be not that difficult in this case.
> 
> This my personal point of view, it might change anytime without prior
> notice.
> 
> 1. Accumulate all commits since Jan 2019 and call it *release 6.9*
>    That I have done. :)
> 
> 2. Document the exact steps that were needed to create "a release".
>    Well yes, I have these lines, but not in shape and maybe not
>    complete. It should be added to the repository nonetheless.
> 
> 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.
> 
> 4. Call this *release 7.0*
> 
> 5. Convert and Move Repository
> 
>    Currently it looks like I would have to convert the svn repository
>    to a git repository with a tool like svn2git. This is a process I
>    would like to avoid, so if someone knows how to convert the
>    repository "server side", or even how to export the complete svn
>    repository on sourceforge into a big file ... all hints are kindly
>    appreciated.
> 
>    I would then move to sourcehut.org. Why?
> 
>    - I do have an account there already
>    - sourcehut offers accounts for a very reasonable amount of money.
>    - sourchut works without javascript! Can you believe this? No? Try it.
>      For me this is a major step in the correct direction. [1]
>    - I would order and pay for a new project account
>    - I would like to add at least two collaborators with full access
>      from day one. Volunteers?
> 
>    This is going to include more things than just converting the
>    repository:
> 
>    - possibly convert the releases/N.M directories into branches
>    - create a new space for the webpage
>    - automate generation of the webpage, serverside if possible
>    - document how to locally generate the documentation --- well, the
>      stuff you have to install before "cd doc; make all".
>    - look into the use of javascript and possible ways to reduce that,
>      should it be desirable
>    - create an archive for (some of) the old tarballs
>    - archive and transfer the mailing list content
>    - create a new mailing list
>    - automate the generation of a release
>    - document the release process
>    - start using the bugtracker (preferably with connection to the
>      mailing list)
>    - test the branch-edit-pull.request-merge workflow
>    - possibly convert "Opinion" into a prober blog?
>    - setup a redirection notice on sourceforge, close everything else
>      down.
>    - possibly dissolve amforth/community into a ./contrib/
>      subdirectory, test the stuff again and document it better
>      https://sourceforge.net/p/amforth/community/HEAD/tree/
> 
>    And this list is not complete.
> 
> 6. Call this *release 8.0*
> 
> 7. Remove arm msp430 riscv for the sake of simplicity -- unless
>    someone speaks up to offer help.
> 
>    Carsten has offered support for arm and riscv --- Thank you!
> 
>    msp430 anyone?
> 
> 8. Fix and automate the creation of the reference cards
> 
>    - include ALL available WORDs (not only the ones in a particular
>      build)
>    - include the exact file path(s), where WORD is defined
>    - possibly add a Forth equivalent (.asm WORDS)
>    - possibly a pointer to a worked example
> 
>    In order to achieve that I would rework the existing perl script
>    AND add any missing file headers, possibly in a new/enhanced
>    format.
> 
> 
> If we get this far, then imho we have /advanced considerably/.
> 
> 
> 
> 
> Does this sound like a worthwile plan?
> 
> I'm sure there are other ideas and suggestions.
> 
> Point 5 is huge and needs to be broken into smaller steps.
> 
> 
> I would appreciate any response, and if you could
> include, which target you are using, all the better.
> 
> 
> Still reading?
> Thank you for your precious time.
> 
> Happy forthing,
> Erich
> 
> 
> 
> [1] I'm using torbrowser most of the time. I'm using firefox to
> work at amforth.sourceforge.net. However, NoScript or uMatrix do
> an excellent job, but break the sf.net webpage routinely. I do
> not see all the buttons and what not unless I really switch off
> NoScript. This is not, what I prefer.
> 
> -- 
> 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] draft: roadmap for AmForth

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

Dear AmForthers,

some time ago (2020-08-02), Mark Roth suggested to come up with a
"road map". Now while mapping unknown territory is a challenge of
sorts, it might be not that difficult in this case.

This my personal point of view, it might change anytime without prior
notice.

1. Accumulate all commits since Jan 2019 and call it *release 6.9*
   That I have done. :)

2. Document the exact steps that were needed to create "a release".
   Well yes, I have these lines, but not in shape and maybe not
   complete. It should be added to the repository nonetheless.

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.

4. Call this *release 7.0*

5. Convert and Move Repository

   Currently it looks like I would have to convert the svn repository
   to a git repository with a tool like svn2git. This is a process I
   would like to avoid, so if someone knows how to convert the
   repository "server side", or even how to export the complete svn
   repository on sourceforge into a big file ... all hints are kindly
   appreciated.

   I would then move to sourcehut.org. Why?

   - I do have an account there already
   - sourcehut offers accounts for a very reasonable amount of money.
   - sourchut works without javascript! Can you believe this? No? Try it.
     For me this is a major step in the correct direction. [1]
   - I would order and pay for a new project account
   - I would like to add at least two collaborators with full access
     from day one. Volunteers?

   This is going to include more things than just converting the
   repository:

   - possibly convert the releases/N.M directories into branches
   - create a new space for the webpage
   - automate generation of the webpage, serverside if possible
   - document how to locally generate the documentation --- well, the
     stuff you have to install before "cd doc; make all".
   - look into the use of javascript and possible ways to reduce that,
     should it be desirable
   - create an archive for (some of) the old tarballs
   - archive and transfer the mailing list content
   - create a new mailing list
   - automate the generation of a release
   - document the release process
   - start using the bugtracker (preferably with connection to the
     mailing list)
   - test the branch-edit-pull.request-merge workflow
   - possibly convert "Opinion" into a prober blog?
   - setup a redirection notice on sourceforge, close everything else
     down.
   - possibly dissolve amforth/community into a ./contrib/
     subdirectory, test the stuff again and document it better
     https://sourceforge.net/p/amforth/community/HEAD/tree/

   And this list is not complete.

6. Call this *release 8.0*

7. Remove arm msp430 riscv for the sake of simplicity -- unless
   someone speaks up to offer help.

   Carsten has offered support for arm and riscv --- Thank you!

   msp430 anyone?

8. Fix and automate the creation of the reference cards

   - include ALL available WORDs (not only the ones in a particular
     build)
   - include the exact file path(s), where WORD is defined
   - possibly add a Forth equivalent (.asm WORDS)
   - possibly a pointer to a worked example

   In order to achieve that I would rework the existing perl script
   AND add any missing file headers, possibly in a new/enhanced
   format.


If we get this far, then imho we have /advanced considerably/.




Does this sound like a worthwile plan?

I'm sure there are other ideas and suggestions.

Point 5 is huge and needs to be broken into smaller steps.


I would appreciate any response, and if you could
include, which target you are using, all the better.


Still reading?
Thank you for your precious time.

Happy forthing,
Erich



[1] I'm using torbrowser most of the time. I'm using firefox to
work at amforth.sourceforge.net. However, NoScript or uMatrix do
an excellent job, but break the sf.net webpage routinely. I do
not see all the buttons and what not unless I really switch off
NoScript. This is not, what I prefer.

-- 
May the Forth be with you ...

[Amforth] Feedback on "Whacky ideas" from " AmForth Weekend 1 (2020-06-27/28)"

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

Hi Erich,
Hi amForth coders,

@Erich: thank you for continuing the work on amForth!

I've been absent from amForth for a long time, but I consider to 
join
back in to do some work on the RISC-V and ARM side of things (I
currently have no usecase for AVR, but that is fine).

I want to respond to an list of questions from Erich earlier this 
year
(sorry for being so late). I think these ideas could need more 
discussion.

>- Whacky Ideas
>
>  - git? -- With all the cool kids using git repositories, should
>    I attempt do convert the existing repositories, webpage, etc?
>    does sourceforge.net provide git repositories? Can the
>    existing svn repository be converted on the server side?

I find SourceForge (SF) a real pain and I don't like to interact 
with
the SF system/webpage.

I think there is a =git= interface on SF, but it does not have the 
workflow
the workflow that makes =git= successful elsewhere. =git= alone 
does not
help much, it's the workflow around it that makes developent and
contribution fun to use.

I really prefer to use SourceHut (https://sr.ht) these days, the
interface is quick and lean (no JavaScript required). I also find 
that
Drew DeVault, who runs SH, has a good view on free software 
development.

GitLab and GitHub have their own problems, but are quite popular 
and, for
me, are less painful compared to SF.

>  - Should we use a ticket system rather than mailing list?

Both. The ticket system should work over email and should 
integrate into
an email workflow. A mailing list is nice(er) for general 
discussions.

>  - Who of you is using which target controller? Would it be
>    feasible to drop msp430, arm, risc-v in order to simplify the
>    whole thing? yes/no?

As I would like to work on RISC-V and ARM, I vote =NO= here.

>  - Can we get rid of the Atmel/Microchip Avrasm Assembler?
>
>    One big difference between the avr8 and the risc-v tree is
>    the assembly language. avr8 is using Atmels assembly. Which
>    is good, because it is thoroughly documented. And which is
>    bad, because there is no working free/libre alternative to
>    avrasm.exe. Yes there is the "avra" project but it has been
>    abandoned long ago. I have been able to assemble AmForth with
>    avra way back in releases 4.2 up until maybe 4.9. I have even
>    contributed a small patch to make atmega644p working.
>    https://sourceforge.net/projects/avra/
>
>    Matthias has contemplated the idea to port AmForth/avr8 to
>    use gnu assembly. He might even have produced a working
>    branch, I don't know.

I've used AVRA back in the day when I've worked with amForth 4.x.

Using Wine and non free software is generally a no go for me, 
esp. as I often work
on non-Intel machines (ARM, MIPS, PPC). There I need to be able to
compile from source.

>    For risc-v there is no avr assembly, naturally. That's where
>    all the .s assembly files come into the game.
>
>    I personally would love to have a free/libre assembler for
>    avr assembly. AVRASM.EXE is the only thing that forces me to
>    install wine on my system.

Maybe porting amForth own AVR assembler
(http://amforth.sourceforge.net/TG/recipes/Assembler.html) to 
GNU/Forth
and use that as the base assembler?

Greetings

Carsten

Re: [Amforth] List of Supported Device Features in Amforth Documentation?

[<fr...@fr...>]

Hi Erich,


Thanks for welcoming me to your community.
Thanks to everybody for the constructive feed-back
and the good pointers!


> reading a datasheet

In my case I first found Amforth and then I read the
datasheet. I believe that's true for 95% of potential
users.

Is being able to read datasheets a precondition to
using Amforth? This would keep out 95% to 98% of
potential users...

Actually, we are doing something similar at
]project-open[, we call it "customer self-selection" :-)
Only users with experience in SAP / ERP understand
our system. But in our case it's not intended...

We use a Wiki to document our internal procedures
because it is so little effort...



George Herzog wrote:

> USB is to some extent proprietary, where as RS-232,
> SPI, and I2C are easier to deploy.

I mentioned that SPI failed for me completely in a bus-
like setup (a stack of multiple PCBs with connectors on
one side). I guess that's because it requires a common
GND between all components.

Also, debugging via SPI didn't work. There were several
debugging sources in Amforth that sent stuff directly to
the UART so that I needed a serial port anyway :-(
And in my setup I'm not ready to replace the RasPI with
anything else, because it's great for WiFi and we plan to
run some AI functions.


> If you come up with patches to make usb on the 32u4 work

Tristan Williams wrote:

> AmForth 6.9 does not support a connection to the USB
> controller of the ATmega32U4 or any AVR8 as far as I know.
> This is something I, and quite a few other people I believe,
> would like - but it is not there yet.

No 32u4! I just bought 5 pieces of CP2102 / FT232 based
USB to UART converters for EUR 1.00 / pcs in order to
connect my good ol' 328s to USB. So I'm going to skip
any experiments with Leonardo or Mega 2560:


USB Advantage and Disadvantages:

+ Cheap and proven:
     The protocol even does re-sends in case of noise
     in the line and reports failures.

+ USB has differential signalling:
     (RS-422 and RS-485 also have, but sooo much overhead...)

+ Just one cable to each subsystem for both data
    and power (space for cables is critical in my setup).
    Plus a second cable for motor power, obviously...

+ 3.3V and 5.0V output from FT232:
     The FT232 provides 3.3V, that should be enough
     for my 328s

+ USB is fast

+ I can connect as many devices as I want using an
     USB hub as RasPI HAT. I will use a HUB with extra
     2.5A 5V power connector.

+ For debugging I can take the subsystem and attach
     it to a laptop.

+ No common GND anymore:
     I would like to locate my 328s close to the motors,
     because there is some space. USB comes with it's
     own GND, but it's OK if that is not perfect because
     of the USB differential drivers.

+ Linux drivers available

Downsides:

- USB may not be as reliable as a electrically stable
   RS232 or similar? Any references?

- Did I miss something?



> I would never even try to build something on USB,
> should my life depend on it.

OK, it's just a robot, no life depends on it.
Thank you very much Erich for sharing your Amforth
4.6 vs. 6.8 experience.

I'll definitely proceed with caution and make sure
there's a watchdog and/or central reset button :-)

> The essence of this is: start very simple.
> Try to make your project run for extented periods of time.

Thank you! Very good advice!

I'll let you know about my USB experience.
I will definitely make sure DC motors and Atmegas
won't share common GND!


> Should you decide to climb it

I'm pretty much on top already, I believe...
As I said, I even had a SPI driver for Amforth running,
allowing my RasPI to send commands to the various
328s via SPI and my angle encoders for the DC motors
work using interrupts. I guess that's getting close to
the core, isn't it?


George Herzog wrote:

> More appropriate than a Raspberry Pi with Linux.

The RasPi Zero W is great to handle WiFi communications
etc. I also plan to deploy a camera and some AI functions
there.

The USB Hub HAT can distribute separate 2.5A power,
so that should be enough for the logic part. Thanks for
pointing to the pitfall, though.


> Use of Forth to Enable Distributed Processing on Wireless
> Sensor Networks

Thanks, read! Right, this is the type of system I was
thinking about, just using a wireless protocol.
Actually, I read this paper already a year ago and used
it as one of the "inspirations" for the SPI driver code.


Cheers!
Frank

Re: [Amforth] List of Supported Device Features in Amforth Documentation?

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

Hello Frank,

and welcome to the list.

fr...@fr... writes:

> Hi!
>
>
> Summary: I believe you could greatly increase the
> number of Amforth users with little effort providing
> one Wiki page per hardware device. There you would
> provide fuse settings, name of a suitable binary,
> parameters for the flasher etc. in order to reduce the
> frustration of a rookie to see the first Forth prompt.
> It's only 20-50 devices, that's not much compared to
> the list of devices in Arch Linux for example (I found
> my specific laptop model there...).
> SourceForge offers a Wiki very suitable for that!

* wiki pages:

Well, maybe. However man- or woman-power is the key resource to
this. I will certainly not start such a thing on my own.

Moreover, I'm convinced that reading a datasheet and having
"control" over your board is worth more than writing more
documentation --- which will be outdated sooner than you wish.


> In Detail:
>
> I'm a fellow open source guy, running a project
> here on SourceForge for a living:
> https://sourceforge.net/projects/project-open/
> Also, 30 years ago I wrote a Forth for Inmos
> Transputers...

Cool! I have not written my own Forth, and I have resisted the
urge for over 10 years. I just try to keep this project alive
after the original author had to abandon it.

> So: Congratulations to your work on Amforth!
> I managed to get it running on a barebone AtMega
> 328 for a hobby project (a tracked robot with my
> son...).
>
> I implemented drivers for both stepper motors
> and DC motors with angle coders without too much
> trouble and to send Forth commands over SPI.
>
> However, I got some trouble trying to connect
> multiple 328s to a single RasPi and finally serious
> trouble with spikes from the DC motors affecting
> the SPI bus :-(

You absolutely must provide separate power supplies for the
controller and for the DC motors. I would not even share the
same ground. Use opto couplers and appropriate diodes and
capacitors to filter the effects of the motors. Other projects
have solved this sort of thing, just hunt for them.
https://roboternetz.de/ is one.

> For the next iteration I'd like to decouple the
> various I/O subsystems electrically and use UART
> over USB for communication in order to address the
> issues both with multiple devices (USB hub as PI
> HAT) and noise (USB has differential signaling...)
>
> So, I'd like to use a 32U4 or Mega 2560 or similar
> for each subsystem and a RasPi Zero W as a base,
> but I haven't yet purchased anything.
> Here some information on the supported features
> would come in handy. I've spent several hours
> trying to understand if/how Amforth supports
> USB/UART in these model. 6.9 doesn't seem to
> support it at all, correct?
>
>
> There isn't much space in a robot, and USB cables
> are surprisingly bulky. And now imagine that I'd
> somehow need to have 2x USB for each Atmega...

* USB is,

well, not cool. I would never even try to build something on
USB, should my life depend on it. I have seen way too many
difficulties with industrial anything on USB. Keep it simple!

If you come up with patches to make usb on the 32u4 work, I
shall look into integrating them. And I'm sure there are more
readers on the list, who would try them.


> I wonder if I'm the only one trying to build a more
> complex system using Amforth or if others had
> similar problems...
>
> I have also found very few postings in the Internet
> from people connecting multiple Arduinos to
> a RasPI or to build bigger projects in general.
> That's precisely where I see the value of Amforth,
> because it introduces a protocol layer that is
> easy to debug and decouples the subsystems.

* robot or other complex system:

If you play with software (no matter which one exactly), you are
not dealing with software alone. Never. You are dealing with
hardware (printed circuit board, components, chips, cables! and
connectors!), power (there is much to be learned about power
supplies), signals and impedance (like it or not), a programmer,
an assembler, and finally the software system itself. You cannot
run this software in empty space.


I myself have a modestly complex setup with atmega32 controllers
on a RS485 bus. The software I wrote using AmForth 4.6 is
running since maybe 10 years with very few hiccups. However: I
have failed miserably to recreate this system with AmForth 6.8+
on nice and shiny boards with atmega644pa controllers. And I
have no idea, why. It works for some time and then all of a
sudden the controller stops dead in it's tracks and blocks any
access. Very interestingly: a reset or power cycle does *NOT*
help. So I'm currently completely out of ideas.


The essence of this is: start very simple. Try to make your
project run for extented periods of time. And see where it gets
you. If you tend to use an ARM controller, do not hesitate to
try Mecrisp (Author Matthias Koch). Mecrisp is a native Forth
and not an indirect threaded one. I have no experience with arm
controllers, so others on the list may have a say.


Yes, I know, the initial hill is steep. Should you decide to
climb it, the mailing list is there to help. The Archives
harbour lots of hints, too.

The fuse settings can be found in appl/arduino/Makefile. Did
you see them?


Using forth itself as a protocol to talk to other controllers
has been tried in at least 2 places, one is not public, the
other is this: Vierte Dimension 2016/1 page 9ff
Salvatore Gaglio et al. -- Use of Forth to Enable Distributed
Processing on Wireless Sensor Networks (english text)
https://forth-ev.de/wiki/res/lib/exe/fetch.php/vd-archiv:4d2016-01.pdf
and references therein.



Happy forthing!
Erich


> Cheers, and keep up the good work!
> Frank

Re: [Amforth] List of Supported Device Features in Amforth Documentation?

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

Frankly, making everything USB dependent takes you into trouble.
USB is to some extent proprietary, where as RS-232, SPI, and I2C are easier
to deploy.

Early versions of the Raspberry Pi had deeply constrained power
distribution. That may be a source of further woes.

Perhaps a shift to an STM324xx device with multiple available USARTs and
Mecrisp-Stellaris Forth would be more appropriate than a Raspberry Pi with
Linux.

Individual wikis for each device would certainly be nice in AmForth, but I
suspect this is suffering sufficient manpower to maintain. There are ARM
fuse selection applications available that can be somewhat useful.


On Fri, Oct 23, 2020, 6:54 AM <fr...@fr...> wrote:

> Hi!
>
>
> Summary: I believe you could greatly increase the
> number of Amforth users with little effort providing
> one Wiki page per hardware device. There you would
> provide fuse settings, name of a suitable binary,
> parameters for the flasher etc. in order to reduce the
> frustration of a rookie to see the first Forth prompt.
> It's only 20-50 devices, that's not much compared to
> the list of devices in Arch Linux for example (I found
> my specific laptop model there...).
> SourceForge offers a Wiki very suitable for that!
>
>
> In Detail:
>
> I'm a fellow open source guy, running a project
> here on SourceForge for a living:
> https://sourceforge.net/projects/project-open/
> Also, 30 years ago I wrote a Forth for Inmos
> Transputers...
>
>
> So: Congratulations to your work on Amforth!
> I managed to get it running on a barebone AtMega
> 328 for a hobby project (a tracked robot with my
> son...).
>
> I implemented drivers for both stepper motors
> and DC motors with angle coders without too much
> trouble and to send Forth commands over SPI.
>
> However, I got some trouble trying to connect
> multiple 328s to a single RasPi and finally serious
> trouble with spikes from the DC motors affecting
> the SPI bus :-(
>
> For the next iteration I'd like to decouple the
> various I/O subsystems electrically and use UART
> over USB for communication in order to address the
> issues both with multiple devices (USB hub as PI
> HAT) and noise (USB has differential signaling...)
>
> So, I'd like to use a 32U4 or Mega 2560 or similar
> for each subsystem and a RasPi Zero W as a base,
> but I haven't yet purchased anything.
> Here some information on the supported features
> would come in handy. I've spent several hours
> trying to understand if/how Amforth supports
> USB/UART in these model. 6.9 doesn't seem to
> support it at all, correct?
>
>
> There isn't much space in a robot, and USB cables
> are surprisingly bulky. And now imagine that I'd
> somehow need to have 2x USB for each Atmega...
>
> I wonder if I'm the only one trying to build a more
> complex system using Amforth or if others had
> similar problems...
>
> I have also found very few postings in the Internet
> from people connecting multiple Arduinos to
> a RasPI or to build bigger projects in general.
> That's precisely where I see the value of Amforth,
> because it introduces a protocol layer that is
> easy to debug and decouples the subsystems.
>
>
> Cheers, and keep up the good work!
> Frank
>
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] List of Supported Device Features in Amforth Documentation?

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

On 23Oct20 00:28, fr...@fr... wrote:
> Hi!
> 
> 
> Summary: I believe you could greatly increase the
> number of Amforth users with little effort providing
> one Wiki page per hardware device. There you would
> provide fuse settings, name of a suitable binary,
> parameters for the flasher etc. in order to reduce the
> frustration of a rookie to see the first Forth prompt.
> It's only 20-50 devices, that's not much compared to
> the list of devices in Arch Linux for example (I found
> my specific laptop model there...).
> SourceForge offers a Wiki very suitable for that!
> 
> 
> In Detail:
> 
> I'm a fellow open source guy, running a project
> here on SourceForge for a living:
> https://sourceforge.net/projects/project-open/
> Also, 30 years ago I wrote a Forth for Inmos
> Transputers...
> 
> 
> So: Congratulations to your work on Amforth!
> I managed to get it running on a barebone AtMega
> 328 for a hobby project (a tracked robot with my
> son...).
> 
> I implemented drivers for both stepper motors
> and DC motors with angle coders without too much
> trouble and to send Forth commands over SPI.
> 
> However, I got some trouble trying to connect
> multiple 328s to a single RasPi and finally serious
> trouble with spikes from the DC motors affecting
> the SPI bus :-(
> 
> For the next iteration I'd like to decouple the
> various I/O subsystems electrically and use UART
> over USB for communication in order to address the
> issues both with multiple devices (USB hub as PI
> HAT) and noise (USB has differential signaling...)
> 
> So, I'd like to use a 32U4 or Mega 2560 or similar
> for each subsystem and a RasPi Zero W as a base,
> but I haven't yet purchased anything.
> Here some information on the supported features
> would come in handy. I've spent several hours
> trying to understand if/how Amforth supports
> USB/UART in these model. 6.9 doesn't seem to
> support it at all, correct?
> 
> 
> There isn't much space in a robot, and USB cables
> are surprisingly bulky. And now imagine that I'd
> somehow need to have 2x USB for each Atmega...
> 
> I wonder if I'm the only one trying to build a more
> complex system using Amforth or if others had
> similar problems...
> 
> I have also found very few postings in the Internet
> from people connecting multiple Arduinos to
> a RasPI or to build bigger projects in general.
> That's precisely where I see the value of Amforth,
> because it introduces a protocol layer that is
> easy to debug and decouples the subsystems.
> 
> 
> Cheers, and keep up the good work!
> Frank
> 
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Hello Frank,

> Also, 30 years ago I wrote a Forth for Inmos
> Transputers...

Transputers - that does take me back. I remember looking longingly at
an add-on transputer box for the Atari ST at a computer fair in London
in the 1980s. It was well beyond my budget, however.

> So, I'd like to use a 32U4 or Mega 2560 or similar
> for each subsystem and a RasPi Zero W as a base,
> but I haven't yet purchased anything.
> Here some information on the supported features
> would come in handy. I've spent several hours
> trying to understand if/how Amforth supports
> USB/UART in these model. 6.9 doesn't seem to
> support it at all, correct?

AmForth 6.9 does not support a connection to the USB controller of the
ATmega32U4 or any AVR8 as far as I know.  This is something I, and
quite a few other people I believe, would like - but it is not there
yet.

Best wishes,
Tristan

[Amforth] List of Supported Device Features in Amforth Documentation?

[<fr...@fr...>]

Hi!


Summary: I believe you could greatly increase the
number of Amforth users with little effort providing
one Wiki page per hardware device. There you would
provide fuse settings, name of a suitable binary,
parameters for the flasher etc. in order to reduce the
frustration of a rookie to see the first Forth prompt.
It's only 20-50 devices, that's not much compared to
the list of devices in Arch Linux for example (I found
my specific laptop model there...).
SourceForge offers a Wiki very suitable for that!


In Detail:

I'm a fellow open source guy, running a project
here on SourceForge for a living:
https://sourceforge.net/projects/project-open/
Also, 30 years ago I wrote a Forth for Inmos
Transputers...


So: Congratulations to your work on Amforth!
I managed to get it running on a barebone AtMega
328 for a hobby project (a tracked robot with my
son...).

I implemented drivers for both stepper motors
and DC motors with angle coders without too much
trouble and to send Forth commands over SPI.

However, I got some trouble trying to connect
multiple 328s to a single RasPi and finally serious
trouble with spikes from the DC motors affecting
the SPI bus :-(

For the next iteration I'd like to decouple the
various I/O subsystems electrically and use UART
over USB for communication in order to address the
issues both with multiple devices (USB hub as PI
HAT) and noise (USB has differential signaling...)

So, I'd like to use a 32U4 or Mega 2560 or similar
for each subsystem and a RasPi Zero W as a base,
but I haven't yet purchased anything.
Here some information on the supported features
would come in handy. I've spent several hours
trying to understand if/how Amforth supports
USB/UART in these model. 6.9 doesn't seem to
support it at all, correct?


There isn't much space in a robot, and USB cables
are surprisingly bulky. And now imagine that I'd
somehow need to have 2x USB for each Atmega...

I wonder if I'm the only one trying to build a more
complex system using Amforth or if others had
similar problems...

I have also found very few postings in the Internet
from people connecting multiple Arduinos to
a RasPI or to build bigger projects in general.
That's precisely where I see the value of Amforth,
because it introduces a protocol layer that is
easy to debug and decouples the subsystems.


Cheers, and keep up the good work!
Frank

Re: [Amforth] [ANN] release 6.9 is available

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

Hello Jim,

Jim Tittsler writes:

> On Mon, Oct 19, 2020 at 2:46 AM Erich Wälde <ew....@na...> wrote:
>> One thing remains: the "download the latest release" Button still
>> points to 6.8 --- I have no idea, where to look. Oh well.
>
> As project administrator, visit
> https://sourceforge.net/projects/amforth/files/amforth/6.9/ then click
> the 'i' (information) button for the desired file.  In addition to the
> normal file details, an administrator can specify a "default download"
> (by platform).

With sufficient thrust, äh javascript and 3rd party connections
and reloading ... yes there are (i) buttons showing up. :)

Thank you very much for pointing me to the correct place!

Cheers,
Erich

-- 
May the Forth be with you ...

Re: [Amforth] [ANN] release 6.9 is available

[Jim T. <jti...@gm...>]

On Mon, Oct 19, 2020 at 2:46 AM Erich Wälde <ew....@na...> wrote:
> One thing remains: the "download the latest release" Button still
> points to 6.8 --- I have no idea, where to look. Oh well.

As project administrator, visit
https://sourceforge.net/projects/amforth/files/amforth/6.9/ then click
the 'i' (information) button for the desired file.  In addition to the
normal file details, an administrator can specify a "default download"
(by platform).

Jim

[Amforth] [ANN] release 6.9 is available

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

Dear AmForthers,

today I called it "release 6.9".

The "commits" part is quite simple.

- r2452 -- only doc/source/index.rst
- r2453 -- copy of trunk as release/6.9
- r2454 -- in trunk increment version strings (3 files)

There is some more work in creating the tar balls.

I have decided to remove the doc/Projects folder from the release
tarballs, because it increases their size from <10 MB to >100 MB.
This is probably the reason why Matthias had the Projects not included
in the archives either.

One thing remains: the "download the latest release" Button still
points to 6.8 --- I have no idea, where to look. Oh well.

This release rolls up everything that had been committed since
2019-01-07.

The website is updated, too.

Happy Forthing!

Erich

-- 
May the Forth be with you ...

Re: [Amforth] Ref Card Generation quo vadis?

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

Dear AmForthers,

I tend to disagree on some of this ...

What you argue for is a "architecture and project-specific"
"reduced" refcard. At least this is, what I understand.


I have used the refcard extensively in the beginnings of my
AmForth journey. And I would argue any time, that the refcard
should please include /all/ /available/ things --- whether or
not they are in my build. This is akin to the "Complete
Instruction Set Summary" found in the document describing the
AVR assembly instructions.

Whether or not a given word is /in my build/ ... " words " to
rescue. Or just trying this /interactively/ on the serial
prompt. Or reading the .lst file from the build (for .asm
definitions).


The examples by Tristan
>> https://tjnw.co.uk//amforth-6.92/appl/arduino/uno.html
>> https://tjnw.co.uk//amforth-6.92/appl/arduino/custom.html
look nice and clean.

However, /I/ did not notice, the words are actually links ---
only after Marks comment. For me attributes like this are pretty
much /invisible/, although they are quite common (They can be
topped by buttons that appear only /after/ I have selected
something -- sigh).


IMHO a worthwhile extension of the refcard would include a
pointer to the source (in readable form), something like

> WORD  ( stack -- effect )
> - one-line-description
> - colon definition equivalent, if the word is in .asm
> - .../path/to/file.frt -- one entry if this is a /common/ .frt file
> - .../path/to/arch/file.asm -- several entries (one per line) if
>   this is a target-specific .asm file

This way it is clear, where to look, if the word is missing in
my build. It even indirectly tells you, on what targets this
WORD is available. And all this information should be visible on
a printed version of the refcard, too.


The pre-made .hex files for the arduino targets are a double
edged sword imho: On one hand they considerably lower the bar to
get to your first AmForth-prompt. On the other hand, they do not
teach users about fuses, about .lst and .map and include files,
etc. This is where the "can we please include words X and Y"-
wishlist comes from. But with pre-made files, users give up
control over their project --- to some extent. I would encourage
everyone get on top of the complete tool chain immediately after
the first pre-made file runs successfully.


But lets assume for this paragraph we want these "target and
build specific" refcards (which formats is another question
imho). How are we going about them? Is their production included
in the project Makefile? Are they produced by /every/ build? How
long does that take and what would be an acceptable time? And
how much tools do we add as a dependency?

The minimal toolchain is already substantial (from my Linux
centric point of view):

- the sources (via tarball, subversion/git, ...)
- the assembler (AvrAsm2 plus wine, unfortunately)
- an editor (/any!/)
- make to help with the build (could be done with shell commands
  in principle)
- a programmer (hardware)
- a program to talk to the programmer (avrdude or similar)
- a serial cable of some sort (hardware)
- a program to talk to the serial interface (minicom et al.,
  amforth-upload.py, amforth-shell.py)
- possibly some programm (evince, xpdf, ...) to read the
  documentation offline.

Even if we produce the refcard using an upgraded perl script,
imho this is going the wrong way.



One other thing I find interesting to note in this lengthy
thread: So far we have only looked at

"How to generate the documentation from the sources?"

But there is another option:

"How to generate the source from a (large) description of the
whole system?"

This is called "literate programming", as everyone and their dog
knows, of course :-)

I envision something like "every word has a description,
including any reasoning why it is implemented in such a way,
plus a description of the source code in some form. From this
description a .frt and/or .asm (variable asm formats)" is
generated, along with the Technical Handbook, the RefCard and
what not.

HOWEVER! I have tried to produce code like this. This is a not
so modest pain up the backside for a project, which is on the
move, which is not fully implemented. Literate Programming alone
is unable to track the evolution of the code, unless you rewrite
the description every time. I still think there is value to this
idea, but it is not the one answer to rule all questions.

I will not even try to convert AmForth to such a structure,
because it requires a lot of work PLUS an even larger tool
chain. :-)


Too Long; Didn't Read:

- I argue for a full refcard, not a reduced one
- I argue for a bit more information on the refcard
- I argue against pre-made .hex files
- I argue for less dependencies
- I do not argue for "produce the code from documentation" :-)

- my current priority is "how to make a release". And I'm not
  there yet.

- I'm willing to accept patches fixing the headers of .asm
  files.

- I'm willing to rewrite the refcard scripts, since I still use
  perl for my own stuff, too.


Thank you for your precious time!

Happy häcking!
Erich

PS: I'm very uneasy about the "answer above the thread text"
format. But I didn't see a convincing "merged form".

Mark Roth writes:

> Hello Tristan, Erich and AmForthers around the world.
>
> Tristan, I really like the direction you have gone in. Coupling the build
> process with the local refcard really is a solution that I can put my
> support behind. When push comes to shove what really matters to the end
> user? The words that have been installed into their system. From what I can
> see, it just works. AHHH and I just noticed that you linked the names to
> the source file. That is the solution to having the info you might need
> easy to find. Super.
>
> Since the build process would create individual refcards, it would just be
> a matter of making group of refcards based on the builds. But that begs
> the question of what other platforms is AmForth being used on? Is it enough
> to just make a project that loads every single common and avr8 file and use
> that for the website. I think maybe yes. Sort of the one refcard to rule
> them all.
>
> In any case, I really like what you've done so far Tristan. It is a big
> improvement upon the oundated version. Cleaning up the source to give a
> better card will be a minor issue in the long run since it will only have
> to be done once. When it is done locally during the build, the created html
> file should be dumped somewhere convenient, perhaps even in the build
> directory so one could just click on it to load it into a browser.
>
> All the best,
> Mark
>
> On Sat, Sep 19, 2020 at 6:30 PM Tristan Williams <ho...@tj...> wrote:
>
>> Hello Mark, Erich, AmForthers,
>>
>> I made some more modifications to the perl reference card script so
>> that it will write out an AVR8 build specific reference card in
>> html. Below are example outputs for the stock UNO build and
>> a custom build
>>
>> https://tjnw.co.uk//amforth-6.92/appl/arduino/uno.html
>> https://tjnw.co.uk//amforth-6.92/appl/arduino/custom.html
>>
>> The issues relating to the presence and correctness of the
>> documentation in the .asm files still remain.
>>
>> Best wishes,
>> Tristan
>>
>> On 09Sep20 08:38, Tristan Williams wrote:
>> > Hello Mark, Erich, AmForthers,
>> >
>> > Yes, I completely agree the format of my refcard excerpt has some
>> > issues. I just wanted to show that, with the hard work done by the
>> > perl script, all of the documentation data fields for AVR8 built-in
>> > words with compliant doc headers are readily available for
>> > output using the .lst file. That data could be formatted as desired
>> > and then written out in html, rst, LaTeX, Lout, etc.
>> >
>> > For the above to be useful, the .asm source files need to have
>> > compliant (and correct) doc headers. Lots of files are, but sufficient
>> > are not that some coordinated way of doing this is needed.
>> >
>> > How is this best done?
>> >
>> > Part of my motivation for pursuing this is that I think there is some
>> > value in having "fuller" pre-built AVR8 hex files in the distribution
>> > and giving them greater prominence in the documentation[1]. A build
>> > specific reference card would be helpful in such cases and it ought to
>> > be created by the same process that creates the hex files. Whilst I
>> > agree with [2] that it would be impractical to build hex files for an
>> > extensive combinations of clock frequency/mcu/baud rate, appl/arduino
>> > already exists and caters for arguably the most popular AVR8
>> > development boards plus a few other interesting ones - perhaps ~6
>> > pairs of hex files in total. Adding assembler words such as bm-set,
>> > bm-clear, bm-toggle, sleep, spirw, store-wdc etc. to the default build
>> > for these larger flash devices would just make the default build more
>> > useful.
>> >
>> > > This does drastically change what the current refcard is. That is to
>> say,
>> > > right now it was just a dump of the base system without regard to
>> usage,
>> > > more to availability.
>> >
>> > It does not have to be a replacement, just something that I think fits
>> > well with "fuller" pre-built AVR8 hex files and I see as achievable.
>> >
>> > > For the website there would have to be cards generated for different
>> > > architectures and perhaps even NWWR sizes. So, what to do?
>> >
>> > Limiting this to AVR8 and those boards that already are in
>> > appl/arduino (or perhaps should be) etc. makes it simpler.
>> >
>> > For existing non AVR8 pre-built hex/binary then having a matching
>> > refcard would make sense. However, I don't know enough about the details
>> > of the non AVR8 build process to say whether the same approach would
>> > work. Also risc-v/words/1-minus.s does not use the same doc headers as
>> > avr8/words/1minus.asm which suggests problems.
>> >
>> > > Maybe the easiest would be to have some generic setups in the appl
>> > > dir (most likely many already exist) and run the refcard script against
>> > > them while building for the website (or perhaps even locally, it won't
>> take
>> > > much time) then using that to create an array of refcards that could be
>> > > grouped together as web pages. The point is, that amforth.asm will
>> dictate
>> > > what a more or less default system will be and that can be used for the
>> > > site.
>> >
>> > Yes, I would agree - with board level customisation in uno.asm etc as
>> > it is currently. A refcard reflecting the built-in words of hex file
>> > created, be that built locally or pre-built on the website.
>> >
>> > With the current AmForth and AVR8 it is likely the built-in refcards for
>> > appl/arduino boards would be very similar - if not identical.
>> >
>> > So for an AVR8 builtin-ref card I think this is needed
>> >
>> > 1. Compliant doc headers for all the .asm files
>> > 2. Modify the perl script to write out refcard as desired in the desired
>> formats
>> > 3. Connect this to the build system
>> > 4. Connect the pre-built hex files and their refcards to the main
>> documentation
>> >
>> > All can be done for a local build setup, but most value would be with
>> > 1 and 4 done at the distribution/website level.
>> >
>> > Best wishes,
>> > Tristan
>> >
>> > [1] https://sourceforge.net/p/amforth/mailman/message/37054617/
>> > [2]
>> http://amforth.sourceforge.net/faq.html#there-are-no-hexfiles-in-the-distribution-archive
>> >
>> >
>> > On 08Sep20 13:14, Mark Roth wrote:
>> > > Hello Tristan, Erich and fellow lurking AmForthers (I really do like
>> this
>> > > intro Tristan) :)
>> > >
>> > > It really does seem that you may have caught the tiger by the tail
>> Tristan.
>> > > For better or for worse even!
>> > >
>> > > For the better (hey, you caught the tiger) :
>> > > I think your layout really goes a long way toward documenting the used
>> > > words. The last few days before I saw your mail I had been thinking of
>> this
>> > > very thing, to use the local build for the refcard. I hadn't, however,
>> seen
>> > > the obvious which was to use the list file. I used it when I was
>> trying to
>> > > find what was compiled into the base system and then finding useful
>> > > assembly files to build into my hex. It's funny how a new set of eyes
>> sees
>> > > the obvious. Well played indeed.
>> > > A few things of note from your examples. Since the items will most
>> likely
>> > > be listed by category the "category:" would be redundant. It also would
>> > > seem pretty trivial to remove the "C:" or "R:" from the stack effects
>> if
>> > > they were to be listed in the way you have. It makes it very clear
>> what is
>> > > going on as well as being consistent. Having the location of the asm
>> file
>> > > is super. Too many times I'm searching my local system for just that
>> very
>> > > thing. Of course it is listed in the lst file which makes perfect
>> sense to
>> > > show it. It could even open the door to having a location to forth
>> source
>> > > files there as well. It would just be a matter of putting the location
>> in
>> > > the comments in some way. I know you have shown interest in having that
>> > > easy to find as well Erich. Perhaps something like that could be a good
>> > > compromise?
>> > > I have a file in my appl directory that I use to upload everything I
>> add
>> > > after burning a new hex into the controller. It is just a list of
>> locations
>> > > for files that get added after the fact. It would seem that something
>> like
>> > > this could even be added into the documentation process. Say perhaps,
>> to
>> > > give an upload file name to the script before running so it could
>> parse out
>> > > the frt files that will be added after. Of course, that would mean they
>> > > would have to have some consistent system of comments as well... In any
>> > > case, it does open that door.
>> > >
>> > > And for the worse:
>> > > This does drastically change what the current refcard is. That is to
>> say,
>> > > right now it was just a dump of the base system without regard to
>> usage,
>> > > more to availability. For the website there would have to be cards
>> > > generated for different architectures and perhaps even NWWR sizes. So,
>> what
>> > > to do? Maybe the easiest would be to have some generic setups in the
>> appl
>> > > dir (most likely many already exist) and run the refcard script against
>> > > them while building for the website (or perhaps even locally, it won't
>> take
>> > > much time) then using that to create an array of refcards that could be
>> > > grouped together as web pages. The point is, that amforth.asm will
>> dictate
>> > > what a more or less default system will be and that can be used for the
>> > > site.
>> > >
>> > > Overall, I really like the direction of this proposal from Tristan. I
>> think
>> > > it does capture what the refcard should do for the end user.
>> > >
>> > > All the best,
>> > > Mark
>> > >
>> > > On Mon, Sep 7, 2020 at 3:00 PM Tristan Williams <ho...@tj...>
>> wrote:
>> > >
>> > > > Hello Mark, Erich, AmForthers,
>> > > >
>> > > > I agreed with Mark's comment below
>> > > >
>> > > > >> It seems that the intent of the refcard was to document the
>> things that
>> > > > >> are compiled into the system.
>> > > >
>> > > > and commented
>> > > >
>> > > > > For me, the scope of the/each refcard is defined by the
>> > > > > distribution build for each architecture (AVR8, msp430, etc.). If
>> the
>> > > > > refcard script were part of the hex build process then a custom
>> > > > > refcard could be a product of the build process also.
>> > > >
>> > > > For AVR8, the .lst file produced as part of the build process lists
>> > > > all the .asm files used in building the hex files. Modifying Mark's
>> > > > perl script from
>> > > >
>> > > > https://sourceforge.net/p/amforth/mailman/message/37060541/
>> > > >
>> > > > so that it uses only the included files listed in the .lst file, a
>> > > > list of words with the their documentation fields can output. These
>> > > > are specific to the individual build, rather than to the general
>> > > > assembly source tree.  Giving something like this (see end of
>> > > > message). As Mark pointed out
>> > > >
>> > > > >> There is still the issue of files that don't have the 3 lines at
>> the top
>> > > > >> of stack effects, category and description.
>> > > >
>> > > > Making these (assembly) files compliant would require some
>> coordinated
>> > > > effort - some of which has been already done I believe, but after
>> that
>> > > > a build specific ref card documenting built-in words could just
>> > > > be another automated part of the hex build process.
>> > > >
>> > > > Not perhaps the perfect ref card - whatever that is, but achievable
>> > > > and with a clearly defined scope. Certainly something I would make
>> use
>> > > > of.
>> > > >
>> > > > Best wishes,
>> > > > Tristan
>> > > >
>> > > > Edited example (text) output of the modified script for uno.lst
>> > > >
>> > > > ....
>> > > >
>> > > > Arithmetics
>> > > > -----------
>> > > >
>> > > > VOC      : 1-
>> > > > DSTACK   : ( n1 -- n2 )
>> > > > RSTACK   :
>> > > > CSTACK   :
>> > > > DESC     :  optimized decrement
>> > > > CATEGORY :  Arithmetics
>> > > > ASM_FILE : amforth-6.92/avr8/words/1minus.asm
>> > > >
>> > > > VOC      : 1+
>> > > > DSTACK   : ( n1|u1 -- n2|u2 )
>> > > > RSTACK   :
>> > > > CSTACK   :
>> > > > DESC     :  optimized increment
>> > > > CATEGORY :  Arithmetics
>> > > > ASM_FILE : amforth-6.92/avr8/words/1plus.asm
>> > > >
>> > > > VOC      : 2/
>> > > > DSTACK   : ( n1 -- n2 )
>> > > > RSTACK   :
>> > > > CSTACK   :
>> > > > DESC     :  arithmetic shift right
>> > > > CATEGORY :  Arithmetics
>> > > > ASM_FILE : amforth-6.92/avr8/words/2slash.asm
>> > > >
>> > > >
>> > > > Compiler
>> > > > --------
>> > > >
>> > > > VOC      : 2literal
>> > > > DSTACK   : ( -- x1 x2 )
>> > > > RSTACK   :
>> > > > CSTACK   : (C: x1 x2 -- )
>> > > > DESC     :  compile a cell pair literal in colon definitions
>> > > > CATEGORY :  Compiler
>> > > > ASM_FILE : amforth-6.92/common/words/2literal.asm
>> > > >
>> > > > VOC      : again
>> > > > DSTACK   : ( -- )
>> > > > RSTACK   :
>> > > > CSTACK   : (C: dest -- )
>> > > > DESC     :  compile a jump back to dest
>> > > > CATEGORY :  Compiler
>> > > > ASM_FILE : amforth-6.92/common/words/again.asm
>> > > >
>> > > > VOC      : ahead
>> > > > DSTACK   : ( f -- )
>> > > > RSTACK   :
>> > > > CSTACK   : (C: -- orig )
>> > > > DESC     :  do a unconditional branch
>> > > > CATEGORY :  Compiler
>> > > > ASM_FILE : amforth-6.92/common/words/ahead.asm
>> > > >
>> > > > ....
>> > > >
>> > > >
>> > > >
>> > > >


-- 
May the Forth be with you ...