Hi Martin & Tristan, Better still, our current work being used (amforth riscv - or glanForth) can easily be synched to your code base without much effort. The CH32X033 is still being used with glanForth with the GLANN communication interface, the RP2350 (Pico 2) also now being added as computational nodes in a physical neural network which could get quite large. CLIPS V7.0 (our version) to manage the network. Since the RP2350 also has Arm32 cores along with Riscv (Hazard) cores and PIO (programmable IO) things could get quite interesting.
Thanks again, John S On Sun, Apr 19, 2026 at 9:42 PM John Sarabacha <[email protected]> wrote: > Hi Martin, > This definitely helps, the RP2350 (Pico 2) is our next target device in > our research. > Would like to benchmark Amforth32 against micropython (there should be no > contest performance wise). > They both could also co-exist on separate cores (Arm or Riscv). > > Thank you for this information, > John S > > > > On Sun, Apr 19, 2026 at 5:50 PM Martin Kobetic <[email protected]> wrote: > >> Hi John >> >> We don't have a porting guide yet, but (as with the original AmForth) >> the structure is purposely set up to facilitate porting. There are >> multiple layers at which portability decisions are made. There is the >> shared core, then the two main CPU architectures: ARM and RISC-V and >> then within each of those there are various MCUs (directories >> arm/mcu/... and rv/mcu/...). Porting to a new MCU within one of the >> supported architectures should be reasonably straightforward, the key >> bit to implement is the UART for the connection to the board. Probably >> the best canonical/minimal example is one of the qemu MCUs that target >> the virtual `qemu -M virt`, you can pick whether you're more >> interested in the arm/mcu/qemu or rv/mcu/qemu. The main file is alway >> amforth.s supported by the corresponding linker file (qemu.ld in this >> case). The core readme [1] describes the directory structure in a bit >> more detail. The user guide [2] discusses how the build system and >> other development aspects are set up [2]. >> >> Probably the easiest way to start is to copy the mcu/<arch>/qemu >> directory and start modifying it for the new MCU. Hope this helps. >> >> Best regards, >> Martin >> >> [1] https://github.com/amforth32/amforth32/blob/main/core/readme.md >> [2] https://amforth32.github.io/amforth32/00-ug/00.00-Overview.html >> >> On Sun, Apr 19, 2026 at 2:49 PM John Sarabacha <[email protected]> >> wrote: >> > >> > Are the hardware dependencies reasonably isolated for porting? >> > Thanks, >> > John S >> > >> > On Sun, Apr 19, 2026 at 1:30 PM John Sarabacha <[email protected]> >> wrote: >> > >> > > Definitely good news. >> > > >> > > John S >> > > >> > > On Thu, Apr 16, 2026 at 1:34 PM <[email protected]> wrote: >> > > >> > >> Fellow AmForthers, >> > >> >> > >> Martin Kobetic and I are pleased to announce the initial release of >> > >> amforth32. This GPLv3 licensed project aims to advance the 32-bit ARM >> > >> and RISC-V variants of AmForth. As many will know, a RISC-V target >> was >> > >> introduced in AmForth release 6.7 in 2018 [1], joined by two ARM >> targets >> > >> in release 6.8 in 2019 [2]. With Martin's interest in getting AmForth >> > >> running on the ARM based Arduino(R) UNO R4, there was a great >> > >> opportunity to restart the development of the 32 bit variants of >> AmForth >> > >> in a conserted way, resulting in amforth32. Below is a link to the >> > >> precompiled binaries with instructions on their use. >> > >> >> > >> https://github.com/amforth32/amforth32/releases/tag/v1.0 >> > >> >> > >> Intrinsically, amforth32 is AmForth at heart; an ITC Forth with >> > >> recognisers. However, the codebase, build system and ecosystem have >> > >> changed quite a bit since the 6.8 release. >> > >> >> > >> One key change is the adoption of QEMU virtual machines as first >> class >> > >> targets, alongside their close (or not so close) real mcu >> counterparts. >> > >> This allows non-mcu dependant elements of the codebase to be subject >> to >> > >> automated testing. It also means that hardware is not required to try >> > >> out amforth32 or to participate in the project. >> > >> >> > >> There is also a Forth debugger, a dynamic transpiler, a flash >> framework >> > >> and ports to obtainable development board targets [3]. More details >> on >> > >> the documentation website [a] and repo [b] >> > >> >> > >> [a] amforth32.github.io/amforth32 >> > >> [b] github.com/amforth32/amforth32 >> > >> >> > >> Most of all, it has been a lot of fun getting this far. Of course, >> there >> > >> are still things missing, and things which can be improved. We very >> much >> > >> welcome participation, and contributions should be a little easier to >> > >> make. >> > >> >> > >> A little early for May 4th be with you, but happy Forthing >> nevertheless. >> > >> >> > >> Best wishes, >> > >> Tristan / Martin >> > >> >> > >> [1] https://sourceforge.net/p/amforth/mailman/message/36375091/ >> > >> [2] https://sourceforge.net/p/amforth/mailman/message/36511255/ >> > >> [3] and some less obtainable ones too >> > >> >> > >> >> > >> _______________________________________________ >> > >> Amforth-devel mailing list for http://amforth.sf.net/ >> > >> [email protected] >> > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > >> >> > > >> > >> > _______________________________________________ >> > Amforth-devel mailing list for http://amforth.sf.net/ >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/amforth-devel >> >> >> _______________________________________________ >> Amforth-devel mailing list for http://amforth.sf.net/ >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ [email protected] https://lists.sourceforge.net/lists/listinfo/amforth-devel
