amforth-devel — Development discussion and user support

[Amforth] OFFLIST Re: A RISC-V update

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

Hello Tristan,

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

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

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

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


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


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

Let me know, what you think.
Cheers,
Erich

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

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




ho...@tj... writes:

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


-- 
May the Forth be with you ...

Re: [Amforth] A RISC-V update

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

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

Cheers!  Keith

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

[Amforth] A RISC-V update

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

A risc-v update.

AmForth-RV update

Good progress made with the CH32V307 [0]

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

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

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

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

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

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

Best wishes,
Tristan

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

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

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

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

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

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

// and see that it exists //

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

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

> save 3+
3+ HHHHBBBB 3+
  ok

// and see that it exists //

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

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

// reset the board //

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

// see if 3+ exists //

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

// see if it works //

> 100 3+
  ok
> u.
103  ok
> 

[Amforth] RISC-V update

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

A risc-v update.

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

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

Best wishes,
Tristan

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

A quick interactive session below

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

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

[Amforth] RISC-V update

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

A risc-v update.

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

Best wishes,
Tristan

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

[Amforth] AmForth RISC-V update

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

Hello AmForth'ers,

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

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

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

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

Best wishes,
Tristan

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

[Amforth] AmForth RISC-V

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

Hi,

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

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

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

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

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

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

COLON "hifive-turnkey", APPLTURNKEY

  .word XT_LED_INIT
  .word XT_DECIMAL
  .word XT_INIT_USART

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

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

.word XT_EXIT

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

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

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

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

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

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

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

Best wishes,
Tristan


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

Re: [Amforth] avra on a raspi zero v1

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

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

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

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


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


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


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


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


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


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


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

Re: [Amforth] avra on a raspi zero v1

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

Hello Mark,

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

Are you open to a pull request?

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

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

I have put up the html here as an idea.

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

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

Best wishes,
Tristan

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

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

Re: [Amforth] Maintainer(s) for AmForth

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

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

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

-- Keith

Re: [Amforth] Maintainer(s) for AmForth

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

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

Hello Keith,

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

Kind regards and thanks,
Tristan

Re: [Amforth] avra on a raspi zero v1

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

On Sat, Sep 30, 2023 at 9:46 PM Keith Amidon wrote:

> On 9/30/23 03:17, Mark Roth wrote:
> > Hello weekend AmForth'ers
> >
> > So, while waiting to see what will happen with the repo I have continued
> to
> > play with a git version for my own use. I have reworked the makefile and
> > made some changes to the repo structure to accommodate for the new avra
> > code (which is still only a placeholder until I get that repository in
> > properly). I think that the new makefile should make it very easy to get
> > started and there is a bit of a long winded readme to explain anything
> that
> > has changed. If anyone wants to take a look and give feedback that would
> be
> > great.
> >
> > https://github.com/CableGuy67/AmForth
>
> I took a quick look at the makefile and related fines in the
> appl/template directory, which I believe is what you're referring to
> here. I have two minor suggestions:
>
>  1. How about renaming "template.asm" as "app.asm" and making the
>     corresponding changes to the makefile? I think this would make a
>     workflow of copying the template directory to one named for a new
>     application without updating names within the template directory
>     very natural. I would feel weird leaving around a file called
>     "template.asm" because that doesn't communicate well the purpose of
>     the file in the ultimate project. But "app.asm" seems like it could
>     usually fit. Having a consistent name like this could also simplify
>     documentation.
>

Yeah, that does sound like a good idea. I like the way it implies intent.


>  2. This is really just a template for an avr8 project, right? Perhaps
>     the directory containing this sub-tree should be named
>     "avr8-template" instead of "template"? It seems to me that really
>     all the directories under "/appl" are currently templates for
>     different targets? Is that right?
>
> Note that I haven't tried anything here, these all come from code
> inspection and may be due to misunderstandings on my part.
>
> Cheers!  Keith
>

You're not wrong in that. Since I only use the avr-8 chips I only recently
even looked into those other appl directories. It seems that it just sort
of grew like mushrooms (appl that is) and never had any cohesiveness.
Indicating that it is the appl template for avr8 is a no brainer. I have to
wonder if the makefile at one point in time was supposed to be more
inclusive with the other platforms but just never got there.

Thanks for the suggestions. Different eyes and all.

All the best,
Mark


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

Re: [Amforth] avra on a raspi zero v1

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

On 9/30/23 03:17, Mark Roth wrote:
> Hello weekend AmForth'ers
>
> So, while waiting to see what will happen with the repo I have continued to
> play with a git version for my own use. I have reworked the makefile and
> made some changes to the repo structure to accommodate for the new avra
> code (which is still only a placeholder until I get that repository in
> properly). I think that the new makefile should make it very easy to get
> started and there is a bit of a long winded readme to explain anything that
> has changed. If anyone wants to take a look and give feedback that would be
> great.
>
> https://github.com/CableGuy67/AmForth

I took a quick look at the makefile and related fines in the 
appl/template directory, which I believe is what you're referring to 
here. I have two minor suggestions:

 1. How about renaming "template.asm" as "app.asm" and making the
    corresponding changes to the makefile? I think this would make a
    workflow of copying the template directory to one named for a new
    application without updating names within the template directory
    very natural. I would feel weird leaving around a file called
    "template.asm" because that doesn't communicate well the purpose of
    the file in the ultimate project. But "app.asm" seems like it could
    usually fit. Having a consistent name like this could also simplify
    documentation.
 2. This is really just a template for an avr8 project, right? Perhaps
    the directory containing this sub-tree should be named
    "avr8-template" instead of "template"? It seems to me that really
    all the directories under "/appl" are currently templates for
    different targets? Is that right?

Note that I haven't tried anything here, these all come from code 
inspection and may be due to misunderstandings on my part.

Cheers!  Keith

Re: [Amforth] Maintainer(s) for AmForth

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

On 9/30/23 05:25, Mark Roth wrote:
> Hello Keith. I'm glad you mentioned the shell (and that you wrote it in the
> way back when) because it had slipped my mind to get back to trying it.
> I've gotten so used to using e4thcom that the tool in the repo is just
> collecting figurative dust for me. Tristan W brought it up into the python3
> realm some time back and I think sorted some bug or another after that.
> I get the feeling there are a number of the back in the old days folks
> doing the same and glancing at the mailing list. One would hope anyway.
> Seeing the dates on the really old commits this past week really drove it
> home just how long this project has been around. :)

Thanks! I'm not familiar with e4thcom. It looks interesting.

I'm curious if it also solves the primary reason I had for writing 
amforth-shell.py in the first place, which had to do with making higher 
baud rates work reliably without overrunning the very small serial input 
buffer amforth uses. When using a terminal emulator file transfer that 
just sent at maximum baud rate I frequently had problems with this on 
ATMega 328 based arduinos if the baud rate was greater than 19200 
because amforth would fall behind as it was storing new words. 
amforth-shell.py solves this problem by waiting for a positive echo of 
the character it sent before sending the next which let me run at 115k 
and greatly sped up larger file transfers while ensuring they were 
reliable. For my project I had 12+ microcontrollers I had to regularly 
reprogram with a fairly large forth program and this was necessary to 
keep myself going crazy while waiting during updates.  :-)

--- Keith

Re: [Amforth] Maintainer(s) for AmForth

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

On Fri, Sep 29, 2023 at 5:26 PM Keith Amidon wrote:

> On 9/26/23 23:33, Mark Roth wrote:
> > Hello AmForth'ers. I like to see this little blip of activity and hope
> more
> > of the less than usual suspects join in with their thoughts!
>
> I'm one of those "less usual" suspects, so l'll jump in. For those with
> long memories my one claim to fame in the amforth community is that I
> wrote the original version of amforth-shell.py. The project I originally
> wrote that for wrapped up many years ago now and I have not had time to
> do much of anything with my list of microcontroller project ideas where
> amforth is most applicable since. I hope to get back to it though, which
> is why I continue to follow the mailing list.
>

Hello Keith. I'm glad you mentioned the shell (and that you wrote it in the
way back when) because it had slipped my mind to get back to trying it.
I've gotten so used to using e4thcom that the tool in the repo is just
collecting figurative dust for me. Tristan W brought it up into the python3
realm some time back and I think sorted some bug or another after that.
I get the feeling there are a number of the back in the old days folks
doing the same and glancing at the mailing list. One would hope anyway.
Seeing the dates on the really old commits this past week really drove it
home just how long this project has been around. :)


> > I have played around with your git repos quite a lot this summer. I
> really
> > wanted the branches one to work so that each branch could have been
> tagged
> > and merged upward to the current state. That just won't work. There are
> far
> > too many breaking changes, or things that just didn't get captured as
> > commits or something. While it is nice to have all the releases easy to
> > swap to by changing branches, it's not really what branches are for. I
> have
> > to agree that the way things are with the releases off to the side is the
> > best solution.
> >
> > I have not spent as much time poking around sourcehut but from what I did
> > see it is pretty much as listed on the tin, a git repo. If the cost is
> > relatively low I guess that isn't much of an issue but it would still
> need
> > to be integrated with the rest of the tools for bug reporting,
> discussions
> > etc. It seems like it could end up making more work and be even more
> > difficult to maintain long term or when more or less dormant.
> On this topic, I would say that I am very much for moving to some
> git-based source control system. I'm not particular about which "forge"
> hosts it.
> > That being said: I am still somewhat hesitant to move everything
> It definitely looks like a fair amount of work!
>

The problem is that is only the half of it. One thing I didn't consider
when suggesting to move to a git based repo is the tools that do things
like generate the docs. That has always been one of the things I really
liked. The pdf version in particular is really well done. The epub is,
well, it is usable but the format isn't the best for things with codeblocks
etc. It works but even when reading on my phone I've found myself reading
pdfs more and more. Reflowable works great for novels but less great on a
small screen for manuals. So that is a thing that would have to be
addressed. Or it would have to be done locally and then just added to the
repo as part of the workflow.


> > lol, by definition '3' is probably too many to merely constitute a
> majority
> > ;)
> > The point I was, as I'm sure you sussed out, is that I'd really like to
> > find out what people want to do, but also that something needs to be done
> > sooner rather than later. If it is only one person it is nothing more
> than
> > another splinter fork.
> It would be great to see a group of maintainers form who collectively
> could contribute enough time to build more momentum in the project
> again. I personally can't commit to doing much in the near-term
> unfortunately.
> >> 2. Make a 7.0 release at that time including
> >>>> a. the avra build
> >>>> b. an up to date version of the project makefile
> >>>> c. at least the first layers of documentation brought up to date
> >>>> d. the prebuilt hex files (really just a cleaning of the project
> >>>> directory in general)
> >> I personally think, the avra build is important. This was the
> >> remaining head ache for me, relying on a piece of proprietary
> >> software, which might break at the least convenient time. Now I
> >> do accept, that not everyone is on Linux/*BSD.
> >>
> > I totally agree and Tristan has also voiced the same. The avra stuff is a
> > little bit of a head-scratcher for me since I wanted to enclose it in the
> > AmForth repo in a stable state. There is virtually no activity for years
> on
> > either the Rob3rt repo or the other fix fork by srtlg. The thing is, just
> > as with the conversion from AmForth CVS to git, I want all the histories
> > maintained but not so much the hassle of an unknown repo. The best
> solution
> > I came up with my brother (who is a developer) is to fork it to a
> personal
> > repo then use that. That is sort of but not exactly what I tried. I
> forked
> > it, updated it then yanked out just enough of the code and put it in a
> new
> > location in my AmForth git repo with the windows version and allowed for
> > building it from the appl makefile if needed. That still needs work but
> as
> > a process it works pretty well. The real way to do it would be to create
> > the repo as a submodule within the AmForth tree. If people are going to
> > want to use avra they are going to have to build it locally anyhow. Plus,
> > then they have the source which is what it is really about.
>
> I also think that the avra build is important. The complexity of getting
> a working build environment on Linux was the biggest stumbling block I
> had in getting going for the project where I did use amforth.
>

One thing I really enjoyed while testing my new makefiles (now with avra!)
was just how fast avra is compared to avrasm2 under wine. I get that part
of it is that avrasm spits out the .lst file stuff into bash while working
(and haven't bothered to see about shutting that down) but I love the idea
that I can whip up everything in seconds even on a Raspberry pi zero
original flavor board. Running wine on a zero is a non-starter which is one
of the reasons I've been keeping an eye on avra over the last few years.


> One thing I would be interested in finding time to do (for myself even
> if no-one else is interested) is create a nix-shell
> <https://nixos.wiki/wiki/Development_environment_with_nix-shell>
> environment that would make all of the build tooling conveniently
> available to anyone using Nix. I have found this to be an incredibly
> powerful method for creating reproducible build environments that are
> easy to use. Note that Nix has good support for OS-X and I believe these
> days can even be used in the Windows Subsystem for Linux, so it could
> help more than just Linux users.
>
> >> I still have a file which documents the steps to build a release
> >> and the associated web site. (I'll stuff this into a separate
> >> email)
> >>
> >> I am not a friend of prebuilt hex files, but again, other people
> >> have different preferences. I'd rather push someone through
> >> creating their .hex files, because it opens the world for them.
> FWIW, it was the availability of pre-built hex files that caused me to
> start my project with amforth to begin with, because it gave me
> something I could get running quickly to experiment with before figuring
> out all of the complexities of the build environment. I think everyone
> has to graduate to building their own .hex files relatively quickly but
> having pre-built files is a great onboarding first-step. Following that
> up with an easy-to-obtain build environment I think would really help
> with adoption.
>

I agree with this as well. Sometimes you don't want the recipe for a
cookie, you just want to try it out and see if you like it before making
your own batch.


> >> 4. Discussing what it would take to continue on with something
> >>> like the RISC-V side of the repo.
> >> I have created a personal fork of amForth starting at version
> >> 5.0, because it did build with avra, and it is before the other
> >> target platforms were included
> >> - MSP430 at version 5.6
> >> - RV32 at version 6.7
> >> - ARM at version 6.8
> >>
> >> I have yet to find a stability problem in my use/setup on avr
> >> amForth, which has not surfaced. I decided to go back to a
> >> version with simpler overall structure (and some known bugs :)
> >>
> >> I agree that risc-v is the most appealing future target, I would
> >> not hesitate to remove msp430 and arm and point users to
> >> mecrisp.
> I also think RISC-V is the most interesting future target.
> > That's all I have for this morning. Anyone reading this, particularly
> > someone not usually heard here please let it be known what you would like
> > or not like. Or what you do or don't like about the current state of
> > things. I'd like to see AmForth around for a long time even in it's more
> or
> > less current state. And adding some new chips like Tristan mentioned
> would
> > be a good way to start once we can all come to some agreement on how to
> > move into the near future.
>
> Whatever happens from this discussion, I'd like to say a big thank you
> to everyone that is interested in keeping amforth alive into the future.
> I'm very fond of it and would really like to see it continue to be a
> tool for those curious about how to work efficiently with their hardware.
>
> Thanks!    Keith
>

And a thanks to you for your past (and perhaps future) contributions!

All the best,
Mark


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

Re: [Amforth] avra on a raspi zero v1

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

> congrats to your hack-box! :)
>

Thanks! Slowly but surely I am collecting some better cables so I can put
it in an enclosure. :)

Hello weekend AmForth'ers

So, while waiting to see what will happen with the repo I have continued to
play with a git version for my own use. I have reworked the makefile and
made some changes to the repo structure to accommodate for the new avra
code (which is still only a placeholder until I get that repository in
properly). I think that the new makefile should make it very easy to get
started and there is a bit of a long winded readme to explain anything that
has changed. If anyone wants to take a look and give feedback that would be
great.

https://github.com/CableGuy67/AmForth

All the best,
Mark



> This is very close to what I am currently using (software wise).
> I had ordered a Hifive Unmatched, a riscv64 computer in miniITX
> Format. And once I got it going with Debian unstable, I
> installed: avra, minicom (terminal), avrdude (burner), perl and
> my scripts to use it for dabbling with amForth. No wine and
> avrasm.exe involved. I have not upgraded my avra along the lines
> mentioned recently, but I plan to. Granted, it is a much bigger
> machine, but at least it is not collecting dust.
>
> The warning with "'" missing a closing ' ... yes well. It does
> work in the end, so no sweat.
>
> Cheers,
> Erich
>
> Mark Roth <cab...@gm...> writes:
>
> > Hello all.
> >
> > I managed to day to cobble together my AmForth "computer" which is pretty
> > much the reason for avoiding using wine to build things. It consists of a
> > raspberry pi zero W v1(whatever point 5 maybe) as a base with raspian
> lite
> > on it. That has a usb hub, an old palm pilot folding keyboard the
> > connection to my uart for the controller and the usbasp to program. The
> > display was a bit overboard as it's a waveshare hdmi 800x480 7 inch thing
> > that makes it possible to actually use it for real.
> >
> > Tonight I managed to get all the cobbled bits to work together and to
> build
> > everything including avra on the zero then flash the controller. So, no
> > real computer but using e4thcom after flashing let me get in and use that
> > nice big screen as a terminal.
> >
> > I still haven't sorted out the single tick thing but I can kind of see
> > where it is coming from in avra. Pretty sure my C skills have faded over
> > the decades that it may just be a problem to look past.
> >
> > I guess now it's time to work on a nice box for the whole thing so I
> could
> > sit anywhere, plug in a powerbank and hack away. I'll try and get some
> > better documentation up soon but it really wasn't terribly difficult. It
> > was really really nice to do everything from Raspian knowing that wine
> > wasn't an option.
> >
> > Enjoy the weekend,
> > Mark
> >
> > _______________________________________________
> > 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-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Maintainer(s) for AmForth

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

On 9/26/23 23:33, Mark Roth wrote:
> Hello AmForth'ers. I like to see this little blip of activity and hope more
> of the less than usual suspects join in with their thoughts!

I'm one of those "less usual" suspects, so l'll jump in. For those with 
long memories my one claim to fame in the amforth community is that I 
wrote the original version of amforth-shell.py. The project I originally 
wrote that for wrapped up many years ago now and I have not had time to 
do much of anything with my list of microcontroller project ideas where 
amforth is most applicable since. I hope to get back to it though, which 
is why I continue to follow the mailing list.

> I have played around with your git repos quite a lot this summer. I really
> wanted the branches one to work so that each branch could have been tagged
> and merged upward to the current state. That just won't work. There are far
> too many breaking changes, or things that just didn't get captured as
> commits or something. While it is nice to have all the releases easy to
> swap to by changing branches, it's not really what branches are for. I have
> to agree that the way things are with the releases off to the side is the
> best solution.
>
> I have not spent as much time poking around sourcehut but from what I did
> see it is pretty much as listed on the tin, a git repo. If the cost is
> relatively low I guess that isn't much of an issue but it would still need
> to be integrated with the rest of the tools for bug reporting, discussions
> etc. It seems like it could end up making more work and be even more
> difficult to maintain long term or when more or less dormant.
On this topic, I would say that I am very much for moving to some 
git-based source control system. I'm not particular about which "forge" 
hosts it.
> That being said: I am still somewhat hesitant to move everything
It definitely looks like a fair amount of work!
> lol, by definition '3' is probably too many to merely constitute a majority
> ;)
> The point I was, as I'm sure you sussed out, is that I'd really like to
> find out what people want to do, but also that something needs to be done
> sooner rather than later. If it is only one person it is nothing more than
> another splinter fork.
It would be great to see a group of maintainers form who collectively 
could contribute enough time to build more momentum in the project 
again. I personally can't commit to doing much in the near-term 
unfortunately.
>> 2. Make a 7.0 release at that time including
>>>> a. the avra build
>>>> b. an up to date version of the project makefile
>>>> c. at least the first layers of documentation brought up to date
>>>> d. the prebuilt hex files (really just a cleaning of the project
>>>> directory in general)
>> I personally think, the avra build is important. This was the
>> remaining head ache for me, relying on a piece of proprietary
>> software, which might break at the least convenient time. Now I
>> do accept, that not everyone is on Linux/*BSD.
>>
> I totally agree and Tristan has also voiced the same. The avra stuff is a
> little bit of a head-scratcher for me since I wanted to enclose it in the
> AmForth repo in a stable state. There is virtually no activity for years on
> either the Rob3rt repo or the other fix fork by srtlg. The thing is, just
> as with the conversion from AmForth CVS to git, I want all the histories
> maintained but not so much the hassle of an unknown repo. The best solution
> I came up with my brother (who is a developer) is to fork it to a personal
> repo then use that. That is sort of but not exactly what I tried. I forked
> it, updated it then yanked out just enough of the code and put it in a new
> location in my AmForth git repo with the windows version and allowed for
> building it from the appl makefile if needed. That still needs work but as
> a process it works pretty well. The real way to do it would be to create
> the repo as a submodule within the AmForth tree. If people are going to
> want to use avra they are going to have to build it locally anyhow. Plus,
> then they have the source which is what it is really about.

I also think that the avra build is important. The complexity of getting 
a working build environment on Linux was the biggest stumbling block I 
had in getting going for the project where I did use amforth.

One thing I would be interested in finding time to do (for myself even 
if no-one else is interested) is create a nix-shell 
<https://nixos.wiki/wiki/Development_environment_with_nix-shell> 
environment that would make all of the build tooling conveniently 
available to anyone using Nix. I have found this to be an incredibly 
powerful method for creating reproducible build environments that are 
easy to use. Note that Nix has good support for OS-X and I believe these 
days can even be used in the Windows Subsystem for Linux, so it could 
help more than just Linux users.

>> I still have a file which documents the steps to build a release
>> and the associated web site. (I'll stuff this into a separate
>> email)
>>
>> I am not a friend of prebuilt hex files, but again, other people
>> have different preferences. I'd rather push someone through
>> creating their .hex files, because it opens the world for them.
FWIW, it was the availability of pre-built hex files that caused me to 
start my project with amforth to begin with, because it gave me 
something I could get running quickly to experiment with before figuring 
out all of the complexities of the build environment. I think everyone 
has to graduate to building their own .hex files relatively quickly but 
having pre-built files is a great onboarding first-step. Following that 
up with an easy-to-obtain build environment I think would really help 
with adoption.
>> 4. Discussing what it would take to continue on with something
>>> like the RISC-V side of the repo.
>> I have created a personal fork of amForth starting at version
>> 5.0, because it did build with avra, and it is before the other
>> target platforms were included
>> - MSP430 at version 5.6
>> - RV32 at version 6.7
>> - ARM at version 6.8
>>
>> I have yet to find a stability problem in my use/setup on avr
>> amForth, which has not surfaced. I decided to go back to a
>> version with simpler overall structure (and some known bugs :)
>>
>> I agree that risc-v is the most appealing future target, I would
>> not hesitate to remove msp430 and arm and point users to
>> mecrisp.
I also think RISC-V is the most interesting future target.
> That's all I have for this morning. Anyone reading this, particularly
> someone not usually heard here please let it be known what you would like
> or not like. Or what you do or don't like about the current state of
> things. I'd like to see AmForth around for a long time even in it's more or
> less current state. And adding some new chips like Tristan mentioned would
> be a good way to start once we can all come to some agreement on how to
> move into the near future.

Whatever happens from this discussion, I'd like to say a big thank you 
to everyone that is interested in keeping amforth alive into the future. 
I'm very fond of it and would really like to see it continue to be a 
tool for those curious about how to work efficiently with their hardware.

Thanks!    Keith

Re: [Amforth] Maintainer(s) for AmForth

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

Hello AmForth'ers. I like to see this little blip of activity and hope more
of the less than usual suspects join in with their thoughts!

On Tue, Sep 26, 2023 at 7:06 PM Erich Wälde <ew....@na...> wrote:

> Hello all,
>
> good to see some interest in this project again.
>
>
>
> Mark Roth <cab...@gm...> writes:
>
> > Good morning AmForth'ers (feel free to adjust the greeting with your
> RTC).
>
> >snip<<<<<<
>
> >> Tristan wrote, if I'm not mistaken
> >>
> >> The fact is that this project is still useful.
> >>
> >> I completely agree. AmForth is quite special as an embedded Forth in
> >> that it has wordlists, recognizers and comprehensive documentation.
> >>
> >> In suggesting a maintainer group the idea was that the effort required
> >> to preserve and update AmForth could be divided up, and perhaps if
> >> some of the more mundane aspects of avoiding bit rot are done, then
> >> people with more specialised skills, but less time, might feel more
> >> able to help.
> >>
> >> What would I suggest for the near term?
> >>
> >
> > This seems to me to pretty much sum up a good mission statement of what
> > AmForth is and why it can continue to be viable. Even with ONLY the focus
> > on the AVR8 side of the repo, which is the core of it, adding more up to
> > date chips as Tristan mentions later is a great way to interest new
> people
> > and keep things from going to seed. So I'll sum up the points made and
> > expand where needed.
>
>
> So, jumping right into the TODO section
> >
> > 0. Where should the official repo be?
> in December 2020 I have created a git based version of the
> repository at
>   https://git.sr.ht/~amforth/
>
> it comes in two flavours:
> - code-tree :: the releases tree is preserved as is, since it is
> a lot simpler for me to find changes across versions with find,
> grep et al.
> - code :: the releases tree is converted to git branches, which
> just proves, that it can be done.
>
> The repository at sourcehut is currently paid by me. Sourcehut
> has integration with email workflows, it is possible to have
> tickets and commits be handled by email to some extent, maybe
> completely. The web frontend works without javascript, which is
> why I am there with my private stuff as well.
>

I have played around with your git repos quite a lot this summer. I really
wanted the branches one to work so that each branch could have been tagged
and merged upward to the current state. That just won't work. There are far
too many breaking changes, or things that just didn't get captured as
commits or something. While it is nice to have all the releases easy to
swap to by changing branches, it's not really what branches are for. I have
to agree that the way things are with the releases off to the side is the
best solution.

I have not spent as much time poking around sourcehut but from what I did
see it is pretty much as listed on the tin, a git repo. If the cost is
relatively low I guess that isn't much of an issue but it would still need
to be integrated with the rest of the tools for bug reporting, discussions
etc. It seems like it could end up making more work and be even more
difficult to maintain long term or when more or less dormant.

That being said: I am still somewhat hesitant to move everything
> over, since I fear that the small community (think mailing list)
> might not resubscribe at the new place. I could be wrong though.
> And if a quorum of '3' is sufficient, go for it :)
>

lol, by definition '3' is probably too many to merely constitute a majority
;)
The point I was, as I'm sure you sussed out, is that I'd really like to
find out what people want to do, but also that something needs to be done
sooner rather than later. If it is only one person it is nothing more than
another splinter fork.


> I still offer to send authentication stuff regarding
> sourceforge.net to folks on this list. However, at the time
> nobody expressed interest.
>
>
> > 1. At least two people with write access to the repo for
> > redundancy.
> Tristan? Mark? Else?
>

If push comes to shove I 'can' probably manage to keep the lights on at SF.
I wouldn't like that to be the option we go with, but if there is no other
option than I will step up. But I do find SF to be dated and sort of
clunky. Also, as stated before, I detest this mailing list as the only way
to maintain a flow of communication with users and development. I do find
it a very handy resource to search though when having a problem but most of
that information could be integrated into the wiki pages that exist in
either an extension to the recipe section or similar. Not having a bug
tracker to me is a deal breaker. Even that can serve as a forum of sorts.

To me, the AmForth SF website is the biggest thing to really be concerned
with. It is full of pretty much everything but the code base that can get
anyone going. It just needs some maintenance as there are parts that are
glaringly out of date. The other side of that coin is that the SVN repo
seems like a whole separate thing. If you jump over to the download section
there is no obvious way back.

SVN
I'm not a fan anymore of this. Many years ago I was but once you get git
you're got in my opinion. I use it locally for most anything. Is there
anything else for interaction at SF with users and/or developers? I thought
they used to have a rudimentary form sort of thing. Not really a forum but
a set of lists that could be used like that. That could be used as a
discussion, request and/or bug tracking thing right on SF.

GIT
Erich has put a great effort in transferring the svn repo into git. Having
done so myself a couple years ago I can say his looks like a pretty clean
piece of work. Preserving the history of commits is really what it came
down to and it appears to be a nearly flawless job. My vote is that the
releases version be used moving forward. Personally, I would like to see
everything continue on as an organization. Having to work all the
documentation into MD might be tedious, but only once. This is something I
was getting ready to play with to see if it actually works as expected.
https://nimblehq.co/blog/create-github-wiki-pull-request


> 2. Make a 7.0 release at that time including
> >> a. the avra build
> >> b. an up to date version of the project makefile
> >> c. at least the first layers of documentation brought up to date
> >> d. the prebuilt hex files (really just a cleaning of the project
> >> directory in general)
>
> I personally think, the avra build is important. This was the
> remaining head ache for me, relying on a piece of proprietary
> software, which might break at the least convenient time. Now I
> do accept, that not everyone is on Linux/*BSD.
>

I totally agree and Tristan has also voiced the same. The avra stuff is a
little bit of a head-scratcher for me since I wanted to enclose it in the
AmForth repo in a stable state. There is virtually no activity for years on
either the Rob3rt repo or the other fix fork by srtlg. The thing is, just
as with the conversion from AmForth CVS to git, I want all the histories
maintained but not so much the hassle of an unknown repo. The best solution
I came up with my brother (who is a developer) is to fork it to a personal
repo then use that. That is sort of but not exactly what I tried. I forked
it, updated it then yanked out just enough of the code and put it in a new
location in my AmForth git repo with the windows version and allowed for
building it from the appl makefile if needed. That still needs work but as
a process it works pretty well. The real way to do it would be to create
the repo as a submodule within the AmForth tree. If people are going to
want to use avra they are going to have to build it locally anyhow. Plus,
then they have the source which is what it is really about.


> I still have a file which documents the steps to build a release
> and the associated web site. (I'll stuff this into a separate
> email)
>
> I am not a friend of prebuilt hex files, but again, other people
> have different preferences. I'd rather push someone through
> creating their .hex files, because it opens the world for them.
>
> > 3. Deciding on a better way to communicate be it built in like
> > github has or something that goes hand in hand.
>
>
> > 4. Discussing what it would take to continue on with something
> > like the RISC-V side of the repo.
>
> I have created a personal fork of amForth starting at version
> 5.0, because it did build with avra, and it is before the other
> target platforms were included
> - MSP430 at version 5.6
> - RV32 at version 6.7
> - ARM at version 6.8
>
> I have yet to find a stability problem in my use/setup on avr
> amForth, which has not surfaced. I decided to go back to a
> version with simpler overall structure (and some known bugs :)
>
> I agree that risc-v is the most appealing future target, I would
> not hesitate to remove msp430 and arm and point users to
> mecrisp.
>
>
The build document from the other message really needs to be put into the
repo somewhere. Well, the TS stuff for the website side I mean. But then
things are diverging from your git so we seem to have a race condition.
Your points about the hex files are valid, but I do think there are people
that will just want to load it up with as little fuss as possible and start
working with forth. I could be wrong but I don't see the harm in including
them. Once someone starts working from the template project they will be
building anyhow. Having prebuilt hex files for known popular platforms
isn't going to hurt, it just creates more access.

That's all I have for this morning. Anyone reading this, particularly
someone not usually heard here please let it be known what you would like
or not like. Or what you do or don't like about the current state of
things. I'd like to see AmForth around for a long time even in it's more or
less current state. And adding some new chips like Tristan mentioned would
be a good way to start once we can all come to some agreement on how to
move into the near future.

All the best,
Mark


> >
> > So, that is the way I see it. I'd like to add right up front that while I
> > am not very skilled with forth I have spent a good deal of time learning
> > how to get better with it. It is pretty much the only language I have
> > studied these last couple of years. I am time rich so I will volunteer a
> > portion of that time if there is a viable way to make AmForth feel more
> > modern. To me right now it feels like an old dusty attic. There are still
> > great things to be discovered, but they are up a creaky flight of stairs,
> > in a poorly lit room and covered in a bit of dusty age. A big part of
> that
> > for me is the Source Forge side. I use git locally and github publicly
> > (although I have used a couple other flavors of public git when needed).
> I
> > am painfully aware that there are issues in using github. I get that,
> but I
> > like the overall tool and the fact there is no cost outlay to have
> > something anyone can get at. A bugtracker, discussions, wiki etc are
> things
> > I put a lot of value in when it comes to the choice if moving happens.
> >
> > At the very least though, some sort of better way to communicate is
> > required. I love email but am finding more and more that less and less
> > people use it as a primary means of communication. So coupling that with
> > the somewhat more difficult method of the mailing list could perhaps, or
> > I'd say probably, be a deterrent for people, in particular new people, to
> > participate. I would like to have read and search access to all of the
> past
> > mailing list text though since there are a lot of really good
> conversations
> > and problem solving that have been done. If only to use that when
> bringing
> > the documentation up to date.
> >
> > And that brings up a really big part of things, the documentation.
> > The entire thing needs to be edited and overhauled. I honestly don't care
> > what flavor of markup it uses. Most that I have used are similar enough
> > that a small cheat sheet is all that is needed to be good at it. I will
> > happily take a big part of that project once a decision has been reached
> on
> > where it will live. While doing this the source tree should be cleaned up
> > as well. There are some inconsistencies with the comments and stack
> effect
> > diagrams, some things like should it be .dw $ff03 or .dw $0003. I'm
> pretty
> > sure the former is the desired way since the newer files are like that,
> as
> > well as the way that the AVR blanks to $ffff (I think). Perhaps then the
> > refcard could once again be brought up to date from scratch giving yet
> > another good thing for new people to access. I did have a look at the
> test
> > host that Tristan put up temporarily at
> > https://www.mostlymostly.uk/amforthdocs and it does seem to work
> perfectly.
> > So keeping the RST stuff (of which there is a lot in the repo) is a very
> > viable option no matter where things end up. I also was reading a gist
> > about converting from that to markdown that I have been meaning to try to
> > see how well it works.
> >
> > Okay, that went on way too long. But I did want to address the group
> since
> > I have found so much value here in the last couple of years. I'll leave
> the
> > quoted bit below from the original message since Tristan was very concise
> > about things. I hope there are no hard feelings for dicing up this
> message
> > to make it as legible as possible.  I would like to see a more lively
> > official AmForth home wherever and however it will end up.
> >
> > All the best,
> > Mark
> >
> > What would I like to see longer term?
> >>
> >> 1. For avr8. The ATmega328 (like me) is no longer a spring chicken. It
> >> would be great to see AmForth running on, say, an ATmega4809 [1]. It
> >> is one of the megaAVR 0-series with newer peripherals, including a
> >> CCL. I've used similar on newer PIC mcus and they are very nice to
> >> have. Why the ATmega4809 in particular? (a) There is some support for
> >> it in avra (b) it is on the Arduino Nano Every [2] (c) it is available
> >> in 40 Pin DIP (48 pin die, minus some pads). I would be interested to
> >> know if anyone has done it/similar or how hard it might be ;)
> >>
> >> 2. For RISC-V. Of AmForth's non-avr8 branches it is the one that
> >> interests me most. The hardware used to be relatively expensive and
> >> hard to come by. Now it is not, which presents the problem of
> >> choice. It would be nice to have an approachable build for AmForth
> >> RISC-V on an inexpensive but obtainable board - but which one? Again,
> >> I would be interested in what people have done and opinions as to what
> >> might work. Additionally, has anyone got AmForth RISC-V running in a
> >> simulator?
> >>
> >> > There is something about thinking in forth that seems to be good for
> >> > my aging brain.
> >>
> >> I feel the same way.
> >>
> >> Best wishes,
> >> Tristan
> >>
> >> [1] https://www.microchip.com/en-us/product/atmega4809
> >> [2] https://docs.arduino.cc/hardware/nano-every
> >> [3] https://docs.github.com/pages
> >> _______________________________________________
> >> 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
>
>
> So. Epilogue of sorts. I still like to work with amForth, I am
> still in no position to really understand, how the core works. I
> could get there if absolutely needed. Matthias mentioned, that
> he was developing it in the AVR Simulator that comes with the
> Atmel tools. I accept that I have to write ISR callback
> functions entirely in assembly, because of that bug that got
> fixed in 6.9 iirc. I still do simple stuff, and a atmega644pa is
> "big".
>
> Cheers,
> Erich
>
> --
> 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] Maintainer(s) for AmForth

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

Hello all,

good to see some interest in this project again.



Mark Roth <cab...@gm...> writes:

> Good morning AmForth'ers (feel free to adjust the greeting with your RTC).

>snip<<<<<<

>> Tristan wrote, if I'm not mistaken
>>
>> The fact is that this project is still useful.
>>
>> I completely agree. AmForth is quite special as an embedded Forth in
>> that it has wordlists, recognizers and comprehensive documentation.
>>
>> In suggesting a maintainer group the idea was that the effort required
>> to preserve and update AmForth could be divided up, and perhaps if
>> some of the more mundane aspects of avoiding bit rot are done, then
>> people with more specialised skills, but less time, might feel more
>> able to help.
>>
>> What would I suggest for the near term?
>>
>
> This seems to me to pretty much sum up a good mission statement of what
> AmForth is and why it can continue to be viable. Even with ONLY the focus
> on the AVR8 side of the repo, which is the core of it, adding more up to
> date chips as Tristan mentions later is a great way to interest new people
> and keep things from going to seed. So I'll sum up the points made and
> expand where needed.


So, jumping right into the TODO section
>
> 0. Where should the official repo be?
in December 2020 I have created a git based version of the
repository at
  https://git.sr.ht/~amforth/

it comes in two flavours:
- code-tree :: the releases tree is preserved as is, since it is
a lot simpler for me to find changes across versions with find,
grep et al.
- code :: the releases tree is converted to git branches, which
just proves, that it can be done.

The repository at sourcehut is currently paid by me. Sourcehut
has integration with email workflows, it is possible to have
tickets and commits be handled by email to some extent, maybe
completely. The web frontend works without javascript, which is
why I am there with my private stuff as well.

That being said: I am still somewhat hesitant to move everything
over, since I fear that the small community (think mailing list)
might not resubscribe at the new place. I could be wrong though.
And if a quorum of '3' is sufficient, go for it :)

I still offer to send authentication stuff regarding
sourceforge.net to folks on this list. However, at the time
nobody expressed interest.


> 1. At least two people with write access to the repo for
> redundancy.
Tristan? Mark? Else?

> 2. Make a 7.0 release at that time including
>> a. the avra build
>> b. an up to date version of the project makefile
>> c. at least the first layers of documentation brought up to date
>> d. the prebuilt hex files (really just a cleaning of the project
>> directory in general)

I personally think, the avra build is important. This was the
remaining head ache for me, relying on a piece of proprietary
software, which might break at the least convenient time. Now I
do accept, that not everyone is on Linux/*BSD.

I still have a file which documents the steps to build a release
and the associated web site. (I'll stuff this into a separate
email)

I am not a friend of prebuilt hex files, but again, other people
have different preferences. I'd rather push someone through
creating their .hex files, because it opens the world for them.

> 3. Deciding on a better way to communicate be it built in like
> github has or something that goes hand in hand.


> 4. Discussing what it would take to continue on with something
> like the RISC-V side of the repo.

I have created a personal fork of amForth starting at version
5.0, because it did build with avra, and it is before the other
target platforms were included
- MSP430 at version 5.6
- RV32 at version 6.7
- ARM at version 6.8

I have yet to find a stability problem in my use/setup on avr
amForth, which has not surfaced. I decided to go back to a
version with simpler overall structure (and some known bugs :)

I agree that risc-v is the most appealing future target, I would
not hesitate to remove msp430 and arm and point users to
mecrisp.



>
> So, that is the way I see it. I'd like to add right up front that while I
> am not very skilled with forth I have spent a good deal of time learning
> how to get better with it. It is pretty much the only language I have
> studied these last couple of years. I am time rich so I will volunteer a
> portion of that time if there is a viable way to make AmForth feel more
> modern. To me right now it feels like an old dusty attic. There are still
> great things to be discovered, but they are up a creaky flight of stairs,
> in a poorly lit room and covered in a bit of dusty age. A big part of that
> for me is the Source Forge side. I use git locally and github publicly
> (although I have used a couple other flavors of public git when needed). I
> am painfully aware that there are issues in using github. I get that, but I
> like the overall tool and the fact there is no cost outlay to have
> something anyone can get at. A bugtracker, discussions, wiki etc are things
> I put a lot of value in when it comes to the choice if moving happens.
>
> At the very least though, some sort of better way to communicate is
> required. I love email but am finding more and more that less and less
> people use it as a primary means of communication. So coupling that with
> the somewhat more difficult method of the mailing list could perhaps, or
> I'd say probably, be a deterrent for people, in particular new people, to
> participate. I would like to have read and search access to all of the past
> mailing list text though since there are a lot of really good conversations
> and problem solving that have been done. If only to use that when bringing
> the documentation up to date.
>
> And that brings up a really big part of things, the documentation.
> The entire thing needs to be edited and overhauled. I honestly don't care
> what flavor of markup it uses. Most that I have used are similar enough
> that a small cheat sheet is all that is needed to be good at it. I will
> happily take a big part of that project once a decision has been reached on
> where it will live. While doing this the source tree should be cleaned up
> as well. There are some inconsistencies with the comments and stack effect
> diagrams, some things like should it be .dw $ff03 or .dw $0003. I'm pretty
> sure the former is the desired way since the newer files are like that, as
> well as the way that the AVR blanks to $ffff (I think). Perhaps then the
> refcard could once again be brought up to date from scratch giving yet
> another good thing for new people to access. I did have a look at the test
> host that Tristan put up temporarily at
> https://www.mostlymostly.uk/amforthdocs and it does seem to work perfectly.
> So keeping the RST stuff (of which there is a lot in the repo) is a very
> viable option no matter where things end up. I also was reading a gist
> about converting from that to markdown that I have been meaning to try to
> see how well it works.
>
> Okay, that went on way too long. But I did want to address the group since
> I have found so much value here in the last couple of years. I'll leave the
> quoted bit below from the original message since Tristan was very concise
> about things. I hope there are no hard feelings for dicing up this message
> to make it as legible as possible.  I would like to see a more lively
> official AmForth home wherever and however it will end up.
>
> All the best,
> Mark
>
> What would I like to see longer term?
>>
>> 1. For avr8. The ATmega328 (like me) is no longer a spring chicken. It
>> would be great to see AmForth running on, say, an ATmega4809 [1]. It
>> is one of the megaAVR 0-series with newer peripherals, including a
>> CCL. I've used similar on newer PIC mcus and they are very nice to
>> have. Why the ATmega4809 in particular? (a) There is some support for
>> it in avra (b) it is on the Arduino Nano Every [2] (c) it is available
>> in 40 Pin DIP (48 pin die, minus some pads). I would be interested to
>> know if anyone has done it/similar or how hard it might be ;)
>>
>> 2. For RISC-V. Of AmForth's non-avr8 branches it is the one that
>> interests me most. The hardware used to be relatively expensive and
>> hard to come by. Now it is not, which presents the problem of
>> choice. It would be nice to have an approachable build for AmForth
>> RISC-V on an inexpensive but obtainable board - but which one? Again,
>> I would be interested in what people have done and opinions as to what
>> might work. Additionally, has anyone got AmForth RISC-V running in a
>> simulator?
>>
>> > There is something about thinking in forth that seems to be good for
>> > my aging brain.
>>
>> I feel the same way.
>>
>> Best wishes,
>> Tristan
>>
>> [1] https://www.microchip.com/en-us/product/atmega4809
>> [2] https://docs.arduino.cc/hardware/nano-every
>> [3] https://docs.github.com/pages
>> _______________________________________________
>> 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


So. Epilogue of sorts. I still like to work with amForth, I am
still in no position to really understand, how the core works. I
could get there if absolutely needed. Matthias mentioned, that
he was developing it in the AVR Simulator that comes with the
Atmel tools. I accept that I have to write ISR callback
functions entirely in assembly, because of that bug that got
fixed in 6.9 iirc. I still do simple stuff, and a atmega644pa is
"big".

Cheers,
Erich

-- 
May the Forth be with you ...

[Amforth] promised doc: how to make a release

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

As promised.
The file is plain ascii .org mode format:


--- Howto-make-a-release.org -----------------------------------
# 2020-10-12  amforth/erwaelde

* How to properly make a release?

  Somewhat machine readable version.

** Intro

   #+begin_quote
 1. check all version numbers in trunk

    - doc/Makefile being one place. This seems to be used in all
      generated documentation, which is nice.
    - common/words/env-forthversion.asm is another place with different
      syntax!
    Judging by commit r2271, these are all places indeed. Yay!

 2. update doc/source/index.rst and optionally history.rst in
    trunk and commit

 3. "svn copy" trunk to releases/$VERSION; commit message collects
    the accumulated one line change descriptions
    This is the most visible change in the source tree
    e.g. see commit r2244 (rel 6.5)

 4. create all .hex files for target boards in appl/
    arduino,atmega2561,eval-pollin,hifive1,launchpad-arm,launchpad430,
    template

    I had forgotten that these exsisted. They are in the release archive
    only, not in the source tree. Now I understand, why people
    sometimes ask about them.

    This step is detailed in a few .xml files. Matthias used ant to
    build them. I have not built these before, but this looks doable,
    provided I get all relevant toolchains up and running.

 5. create the documentation
    - htdocs, the web page
    - books, did you know that all the content of the webpage shows up
      in amforth.pdf (made with pdflatex) and AmForth.epub (made with
      sphinx-build)? Amazing! These books are part of the download .zip
      archive.

      This step is a "cd doc; make all" --- provided sphinx pdflatex
      and all the good stuff is installed.

 6. create a new temporary tree to collect everything, that goes into
    the release archive:
    - sources
    - some of the scripts, tools, meta-files
    - the generated documentation from releases/$VERSION, without the
      document sources, but including the "books"

    I have not found anything that looks like doing this.

 7. create the .zip and .tar.gz archives (the easy part), and upload
    them to their correct location in the sourceforge.net file tree
    (the not so obvious part).

    I found out that these release archives were built by Matthias.
    The files for 6.8 are about 7 MB in size.

    Whereas if you download "the latest sources", sourceforge will
    generate a snapshot of "trunk". This is a plain copy, without all
    the niceties included in the archives mentioned here. This archive
    is currently 35 MB in size.

 8. sync the generated documentation with the online website

    I have done this a few times now, but I'm still asking myself, if I
    see all relevant pieces or not.

 9. Increment the version numbers in trunk and commit


 So nine easy steps to code nirvana? Hmmm.
   #+end_quote


** Go to the correct directory

   #+begin_src sh
cd ~/eGeek/sourceforge.net/amforth-code
   #+end_src

** Check current Version Strings

   Fortunately only three files:

   #+begin_src sh
(
    cd trunk
    grep '^VERSION' doc/Makefile

    cat common/words/env-forthversion.asm
    cat shared/words/env-forthversion.s
)
   #+end_src

** update doc/source/index.rst

   Do /not/ delete any blank lines in this file, they are sorely needed!

   #+begin_src diff
ew@ceres:~/eGeek/sourceforge.net/amforth-code 7 > svn diff trunk/
Index: trunk/doc/source/index.rst
===================================================================
--- trunk/doc/source/index.rst  (revision 2451)
+++ trunk/doc/source/index.rst  (working copy)
@@ -36,6 +36,9 @@
 See the code section at Sourceforge to get the
 `most recent sources <http://sourceforge.net/p/amforth/code/HEAD/tree/trunk/>`__
 
+18.10.2020: release 6.9
+.......................
+
 * tools/amforth-shell.py fixed python3 error (in --no-error-on-output
   option path), fix provided by Tristan Williams.
 * tools/amforth-shell.py fixed indentation error in line 1146, fix provided by Tristan Williams.
   #+end_src

   : svn commit trunk/doc/source/index.rst -m 'call it version 6.9'
   : svn up


** create releases/$Version

   #+begin_src sh
svn cp trunk/ releases/6.9
   #+end_src

   Alle ? Dateien werden hier mitkopiert, aber wenigstens nicht mit
   add verziert. Aha.

   edit svn.msg, collect all comments from index.rst since last release

   : svn commit . --file svn.msg
   : svn up


** increment $Version

   : vi trunk/doc/Makefile
   : vi trunk/common/words/env-forthversion.asm
   : vi trunk/shared/words/env-forthversion.s
   : svn commit trunk/doc/Makefile trunk/common/words/env-forthversion.asm trunk/shared/words/env-forthversion.s -m 'Increment version to 7.0'


** commit

   see e.g. r2432 .. r2434

** checkout a temp. release tree

   #+begin_src sh
cd ~
mkdir tmp-amforth-code
cd tmp-amforth-code
svn checkout svn://svn.code.sf.net/p/amforth/code/releases/6.9
cd 6.9
# add Atmel AvrAsm2 tree
wget https://sourceforge.net/projects/amforth/files/Atmel-AVR8-Assembler/Atmel-Assembler.tgz
tar xf Atmel-Assembler.tgz # unpacks into ./avr8/Atmel

(
    cd appl
    ( cd hifive1 && make )         # hifive1, riscv64-linux-gnu-as
    ( cd linux-arm && make )       # linux-arm, arm-linux-gnueabi-as
    ( cd launchpad-arm && make )   # launchpad-arm, arm-none-eabi-as

    (                              # several, wine AvrAsm2
        for DIR in arduino atmega2561 eval-pollin template
        do
            ( cd $DIR; ant compile )
        done

    )
)
   #+end_src


** in release/$Version create .hex files

   Das hab ich neulich mal ausgetüftelt:
   #+begin_src sh
# once, on Debian 10 at this moment:
(
    sudo -i
    apt install binutils-riscv64-linux-gnu binutils-arm-linux-gnueabi binutils-arm-none-eabi
)
(
    cd ~/Projekte/17_naken_asm
    git clone https://github.com/mikeakohn/naken_asm
    cd naken_asm
    ./configure
    make
    ./naken_asm | grep -i version  # Version: March 15, 2020 # BROKEN ???
    cp ./naken_asm ~/bin/
    naken_asm | grep -i version    # Version: December 28, 2015
)
tar xf ~/Forth/amforth/Atmel-Assembler.tgz
mv avr8/Atmel/ .
rmdir avr8
# always:
(
    cd release/6.9
    ( cd avr8 && ln -snf ../../../Atmel . )

    cd appl
    ( cd hifive1 && make )         # hifive1, riscv64-linux-gnu-as
    ( cd linux-arm && make )       # linux-arm, arm-linux-gnueabi-as
    ( cd launchpad-arm && make )   # launchpad-arm, arm-none-eabi-as

    (                              # several, wine AvrAsm2
        for DIR in arduino atmega2561 eval-pollin template
        do
            ( cd $DIR; ant compile )
        done

    )
                                   # launchpad430, naken_asm
    ( cd launchpad430 && make lp-2553.hex lp-5529.hex lp-5969.hex )
)

   #+end_src

   TEST them!!! This is the unresolved bit at this moment ...

   no need to commit the artefacts. They are included in the
   release-$version.tar.gz archive.


** in release/$Version build the documentation

   #+begin_src sh
(
    cd release/6.9/
    rm -fr ./avr8/Atmel ./doc/Projects ./doc/build

    cd doc
    make all sitemap
)
   #+end_src

** create a new release tar archive

   #+begin_src sh
(
    version=6.9
    cd release/${version}
    mkdir ../amforth-${version}

    cp -a examples/ avr8/ LICENSE.txt  \
       risc-v/ appl/ shared/ common/ arm/ readme.txt  msp430/  tests/ \
       ../amforth-${version}/
    mkdir ../amforth-${version}/tools
    cp -a tools/{am4up.c,amforth-upload.py,amforth-shell.py} ../amforth-${version}/tools
    mkdir ../amforth-${version}/doc
    cp -a doc/build/htdocs/ ../amforth-${version}/doc/
    mkdir ../amforth-${version}/doc/tools
    cp -a doc/tools/{forth.py,_mapping.py} ../amforth-${version}/doc/tools/
    mv ../amforth-${version}/doc/htdocs/AmForth.epub ../amforth-${version}/doc/
    mv ../amforth-${version}/doc/htdocs/amforth.pdf ../amforth-${version}/doc/


    cd ..
    tar -czvf amforth-${version}.tar.gz ./amforth-${version}
    zip -r    amforth-${version}.zip      amforth-${version}

)
   #+end_src

   Wenn man die Unterschiede zum 6.8 tar.gz anguckt:
   - -104 ich hab viele no-jtag.asm weggeschmissen.
   - +4 ich hab in launchpad430 hex files gebaut, die fehlen in 6.8
   - +4 Opinion
   - +58 Projects/ClockWorks
   - +2 Projects/RS485
   - +2 refcard
   - +3 .js .css
   - +20 doc/_images

   Die Zahl kann ich jetzt nicht komplett nachvollziehen, aber die
   Unterschiede sind plausibel. Das passt so schon einigermaßen.

** create the new website and sync

   die wohnt jetzt unter
   : releases/6.9/doc/build/htdocs
   oder?

** Increment Version numbers in trunk and commit

   #+begin_src sh
(
    cd trunk/doc
    sed -i.bak -e '/^VERSION/s/6.9/7.0/' Makefile
)
(
    cd trunk/common/words
    sed -i.bak -e 's/\.dw 69/\.dw 70/' env-forthversion.asm
)
svn st
svn commit trunk/doc/Makefile trunk/common/words/env-forthversion.asm -m 'start version 7.0'
   #+end_src


** upload release tar archive(s)


** send announcement


** update the website!!!

   #+begin_src sh
cd ~
mkdir tmp-amforth-website
cd tmp-amforth-website
svn checkout svn://svn.code.sf.net/p/amforth/code/trunk
cd trunk/doc
make htdocs

cd ~/eGeek/sourceforge.net/amforth-web/
mkdir amforth-2020-10-18-upload
cp -a amforth/amforth_config.xml amforth/cgi-bin/ amforth/upload  amforth-2020-10-18-upload/
cp -a ~/tmp-amforth-website/trunk/doc/build/htdocs/ amforth-2020-10-18-upload/

cd amforth-2020-10-18-upload/
rsync -vax --delete . erw...@we...:/home/project-web/amforth
   #+end_src

   puhh.
----------------------------------------------------------------

-- 
May the Forth be with you ...

Re: [Amforth] Maintainer(s) for AmForth

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

Good morning AmForth'ers (feel free to adjust the greeting with your RTC).

disclaimer: I am going to cherry pick the commentary by Tristan for this
post. You can safely assume that the single quotes are their's and any
quoted quotes are mine unless noted. This thread is getting a little wound
up and I think it is important to be clear for anyone wanting to toss in
their vote about what to do. But we need to do something or I fear the
group will just finish dissolving.

> I am guessing you mean the SourceForge repo and the mailing list?
>
> Yes, my primary focus is the SF AmForth repo, website, community and
> mailing list.
>

This is I think the core of it all. When I first talked about getting a
working version of avra working with linux I was pleasantly surprised to
find a number of people pop in to talk about it. I fully expected to hear
from Tristan and Erich (hoped so anyway) since you both were the most
active at the end of the recent activity. That others are still subscribed
to this list and have an interest is great. This makes me think that we
very well could (should) form a quorum, which, in our depleted state could
be as little as 3. ;)

> The fact is that this project is still useful.
>
> I completely agree. AmForth is quite special as an embedded Forth in
> that it has wordlists, recognizers and comprehensive documentation.
>
> In suggesting a maintainer group the idea was that the effort required
> to preserve and update AmForth could be divided up, and perhaps if
> some of the more mundane aspects of avoiding bit rot are done, then
> people with more specialised skills, but less time, might feel more
> able to help.
>
> What would I suggest for the near term?
>

This seems to me to pretty much sum up a good mission statement of what
AmForth is and why it can continue to be viable. Even with ONLY the focus
on the AVR8 side of the repo, which is the core of it, adding more up to
date chips as Tristan mentions later is a great way to interest new people
and keep things from going to seed. So I'll sum up the points made and
expand where needed.

0. Where should the official repo be?
1. At least two people with write access to the repo for redundancy.
2. Make a 7.0 release at that time including
> a. the avra build
> b. an up to date version of the project makefile
> c. at least the first layers of documentation brought up to date
> d. the prebuilt hex files (really just a cleaning of the project
directory in general)
3. Deciding on a better way to communicate be it built in like github has
or something that goes hand in hand.
4. Discussing what it would take to continue on with something like the
RISC-V side of the repo.

So, that is the way I see it. I'd like to add right up front that while I
am not very skilled with forth I have spent a good deal of time learning
how to get better with it. It is pretty much the only language I have
studied these last couple of years. I am time rich so I will volunteer a
portion of that time if there is a viable way to make AmForth feel more
modern. To me right now it feels like an old dusty attic. There are still
great things to be discovered, but they are up a creaky flight of stairs,
in a poorly lit room and covered in a bit of dusty age. A big part of that
for me is the Source Forge side. I use git locally and github publicly
(although I have used a couple other flavors of public git when needed). I
am painfully aware that there are issues in using github. I get that, but I
like the overall tool and the fact there is no cost outlay to have
something anyone can get at. A bugtracker, discussions, wiki etc are things
I put a lot of value in when it comes to the choice if moving happens.

At the very least though, some sort of better way to communicate is
required. I love email but am finding more and more that less and less
people use it as a primary means of communication. So coupling that with
the somewhat more difficult method of the mailing list could perhaps, or
I'd say probably, be a deterrent for people, in particular new people, to
participate. I would like to have read and search access to all of the past
mailing list text though since there are a lot of really good conversations
and problem solving that have been done. If only to use that when bringing
the documentation up to date.

And that brings up a really big part of things, the documentation.
The entire thing needs to be edited and overhauled. I honestly don't care
what flavor of markup it uses. Most that I have used are similar enough
that a small cheat sheet is all that is needed to be good at it. I will
happily take a big part of that project once a decision has been reached on
where it will live. While doing this the source tree should be cleaned up
as well. There are some inconsistencies with the comments and stack effect
diagrams, some things like should it be .dw $ff03 or .dw $0003. I'm pretty
sure the former is the desired way since the newer files are like that, as
well as the way that the AVR blanks to $ffff (I think). Perhaps then the
refcard could once again be brought up to date from scratch giving yet
another good thing for new people to access. I did have a look at the test
host that Tristan put up temporarily at
https://www.mostlymostly.uk/amforthdocs and it does seem to work perfectly.
So keeping the RST stuff (of which there is a lot in the repo) is a very
viable option no matter where things end up. I also was reading a gist
about converting from that to markdown that I have been meaning to try to
see how well it works.

Okay, that went on way too long. But I did want to address the group since
I have found so much value here in the last couple of years. I'll leave the
quoted bit below from the original message since Tristan was very concise
about things. I hope there are no hard feelings for dicing up this message
to make it as legible as possible.  I would like to see a more lively
official AmForth home wherever and however it will end up.

All the best,
Mark

What would I like to see longer term?
>
> 1. For avr8. The ATmega328 (like me) is no longer a spring chicken. It
> would be great to see AmForth running on, say, an ATmega4809 [1]. It
> is one of the megaAVR 0-series with newer peripherals, including a
> CCL. I've used similar on newer PIC mcus and they are very nice to
> have. Why the ATmega4809 in particular? (a) There is some support for
> it in avra (b) it is on the Arduino Nano Every [2] (c) it is available
> in 40 Pin DIP (48 pin die, minus some pads). I would be interested to
> know if anyone has done it/similar or how hard it might be ;)
>
> 2. For RISC-V. Of AmForth's non-avr8 branches it is the one that
> interests me most. The hardware used to be relatively expensive and
> hard to come by. Now it is not, which presents the problem of
> choice. It would be nice to have an approachable build for AmForth
> RISC-V on an inexpensive but obtainable board - but which one? Again,
> I would be interested in what people have done and opinions as to what
> might work. Additionally, has anyone got AmForth RISC-V running in a
> simulator?
>
> > There is something about thinking in forth that seems to be good for
> > my aging brain.
>
> I feel the same way.
>
> Best wishes,
> Tristan
>
> [1] https://www.microchip.com/en-us/product/atmega4809
> [2] https://docs.arduino.cc/hardware/nano-every
> [3] https://docs.github.com/pages
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Maintainer(s) for AmForth

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

Hi Mark,

Mark Roth <cab...@gm...> writes:

> Here is the clean link.
>
> https://github.com/CableGuy67/avra

Thanks for pulling this together.

I can successfully build the executable on debian 12, gcc 13.2
on a riscv64 machine. :)

I would kindly suggest to increase the version number, or add
some local suffix.

Thanks,
Erich

> On Mon, Sep 25, 2023 at 8:30 AM Mark Roth <cab...@gm...> wrote:
>
>>
>>
>> > Talking of maintenance, I note that avra (on Sourceforge) hasn't been
>>
>>> > updated since 2019. Maybe it's completed?

PS: to me it seems, that Robert Russel has ceased all activity
on github. Whatever that means.

Re: [Amforth] Maintainer(s) for AmForth

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

Here is the clean link.

https://github.com/CableGuy67/avra

On Mon, Sep 25, 2023 at 8:30 AM Mark Roth <cab...@gm...> wrote:

>
>
> > Talking of maintenance, I note that avra (on Sourceforge) hasn't been
>
>> > updated since 2019. Maybe it's completed?
>>
>> At least the home page points to https://github.com/Ro5bert/avra which
>> has seen some commits since 2019.
>>
>
>  There were some PRs for that one that led to a development branch for
> another fork. I took that one and pushed them into main. You can find it
> here here at my github fork <https://github.com/CableGuy67/avra>.
>
> It builds with just a simple 'make' easily enough for me on Debian. I've
> even built it for Raspian successfully. There are a few little things that
> could be fixed but it does work and build AmForth in its current state
> (both avra and AmForth).
>
> Cheers,
> Mark
>

Re: [Amforth] Maintainer(s) for AmForth

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

> Talking of maintenance, I note that avra (on Sourceforge) hasn't been

> > updated since 2019. Maybe it's completed?
>
> At least the home page points to https://github.com/Ro5bert/avra which
> has seen some commits since 2019.
>

 There were some PRs for that one that led to a development branch for
another fork. I took that one and pushed them into main. You can find it
here here at my github fork <https://github.com/CableGuy67/avra>.

It builds with just a simple 'make' easily enough for me on Debian. I've
even built it for Raspian successfully. There are a few little things that
could be fixed but it does work and build AmForth in its current state
(both avra and AmForth).

Cheers,
Mark

Re: [Amforth] Maintainer(s) for AmForth

[Malte F. G. <mal...@gm...>]

Martin Nicholas via Amforth-devel <amf...@li...> writes:

> On Sun, 10 Sep 2023 17:04:01 +0200
> tristan <ho...@tj...> wrote:
>
>> Fellow AmForth-ers,
>> 
>> Perhaps it is time again to consider having a formal maintainer for
>> AmForth. Back in May 2022 Erich stepped down [1] and put in place
>> various resources that could be potentially be used to maintain
>> AmForth (in addition to those that already exist at sourceforge)
>> 
>> To my knowledge, nobody from the mailing list has volunteered
>> individually. Additionally, having a single maintainer does have its
>> own issues. So perhaps a way forward would be to have a small group of
>> maintainers for AmForth. The revelation from Mark R [2] that the
>> latest AmForth can be made using avra does make a difference to me,
>> such that I would volunteer for such a group. So are there others on
>> the mailing list who would be willing to join such a maintainers
>> group?
>
> I would be happy to make some sort of contribution, but being
> essentially a hobbyist programmer, I'm not sure how useful I could be.
> I've never worked in any type of devlopment team.
>
> Documentation is something I could contribute to, but not until next
> year due to on-going commitments in 2023.
>
> Certainly an "advert" for maintiners on AmForth's new home would be a
> good thing; together messages on the socials.
>
> Talking of maintenance, I note that avra (on Sourceforge) hasn't been
> updated since 2019. Maybe it's completed?

At least the home page points to https://github.com/Ro5bert/avra which
has seen some commits since 2019.


mfg²