amforth-devel — Development discussion and user support

[Amforth] A RISC-V update

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

A risc-v update for CH32V307

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

Best wishes,
Tristan

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

[Amforth] A RISC-V update - USB

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

A RISC-V update - USB

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

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

Best wishes,
Tristan

Re: [Amforth] A RISC-V update

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

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

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


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

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

-- 
Regards,

Martin Nicholas.

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

Re: [Amforth] A RISC-V update

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

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

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

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

Re: [Amforth] A RISC-V update

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

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

Best wishes,
Tristan



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

Re: [Amforth] A RISC-V update

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

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

M.

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

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



-- 
Regards,

Martin Nicholas.

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

[Amforth] A RISC-V update

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

A RISC-V update.

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

Best wishes,
Tristan

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

[Amforth] A RISC-V update

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

A risc-v update.

Getting there [0]

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

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

Best wishes,
Tristan

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

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

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

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

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

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

-- 
May the Forth be with you ...

[Amforth] OFFLIST Re: A RISC-V update

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

Hello Tristan,

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

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

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

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


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


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

Let me know, what you think.
Cheers,
Erich

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

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




ho...@tj... writes:

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


-- 
May the Forth be with you ...

Re: [Amforth] A RISC-V update

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

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

Cheers!  Keith

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

[Amforth] A RISC-V update

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

A risc-v update.

AmForth-RV update

Good progress made with the CH32V307 [0]

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

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

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

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

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

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

Best wishes,
Tristan

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

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

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

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

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

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

// and see that it exists //

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

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

> save 3+
3+ HHHHBBBB 3+
  ok

// and see that it exists //

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

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

// reset the board //

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

// see if 3+ exists //

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

// see if it works //

> 100 3+
  ok
> u.
103  ok
> 

[Amforth] RISC-V update

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

A risc-v update.

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

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

Best wishes,
Tristan

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

A quick interactive session below

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

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

[Amforth] RISC-V update

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

A risc-v update.

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

Best wishes,
Tristan

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

[Amforth] AmForth RISC-V update

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

Hello AmForth'ers,

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

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

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

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

Best wishes,
Tristan

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

[Amforth] AmForth RISC-V

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

Hi,

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

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

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

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

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

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

COLON "hifive-turnkey", APPLTURNKEY

  .word XT_LED_INIT
  .word XT_DECIMAL
  .word XT_INIT_USART

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

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

.word XT_EXIT

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

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

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

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

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

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

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

Best wishes,
Tristan


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

Re: [Amforth] avra on a raspi zero v1

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

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

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

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


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


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


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


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


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


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


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

Re: [Amforth] avra on a raspi zero v1

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

Hello Mark,

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

Are you open to a pull request?

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

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

I have put up the html here as an idea.

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

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

Best wishes,
Tristan

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

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

Re: [Amforth] Maintainer(s) for AmForth

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

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

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

-- Keith

Re: [Amforth] Maintainer(s) for AmForth

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

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

Hello Keith,

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

Kind regards and thanks,
Tristan

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
>