Hello Nigel,
Great news that you have got to the root of the problem.
With wordlists and recognisers, AmForth is quite unusual for a small mcu
self-hosted forth. One that has been a great platform for my automation,
programming and instrumentation projects over the last few years. The
wide
availability of inexpensive and usually reliable :) 328p and 2560 dev
boards has sometimes made it hard to move on.
ATmega328PB
How are the device files generated?
The mechanism for generating them is no longer available. See mailing
list
message below
https://sourceforge.net/p/amforth/mailman/message/36606482/
Is it worth generating one for the 328pb?
It's a good question. The AmForth avr8 codebase is mature and so are the
ATmega mcus it runs on. From [1] and your symlink workaround there is a
very good chance that AmForth will run very well on the ATmega328PB.
A quick check of the usual places shows plenty of clones with
ATmega328PB.
IIRC the ATmega328PB has two USARTS - something the ATmega328P does not.
Something potentially useful in a nano format board. So yes, if
anyone has the time/hardware to create and test the files for a
ATmega328PB build, AmForth would be better for it.
The bigger picture question for AmForth avr8 is whether there is enough
collective resource to port it to a more current 8 bit mcu such as the
ATmega4809. These offer a *lot* more in terms of modern peripherals, but
are sufficiently different that a considerable amount of work on the
codebase would be needed IMO. There is a very reasonably priced
self-contained development board [2] if anyone is interested in pursuing
that.
Best wishes,
Tristan
[1]
https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ApplicationNotes/ApplicationNotes/Atmel-42559-Differences-between-ATmega328P-and-ATmega328PB_ApplicationNote_AT15007.pdf
[2]
https://www.microchipdirect.com/dev-tools/DM320115?productLoaded=true&allDevTools=true
On 2026-01-01 09:42, Nigel Rowe wrote:
Greetings,
OK, I've climbed back out of the rabbit hole.
Bottom line, some of the batch of Arduino Nanos I got from Aliexpress
were
faulty. They came with hflag set to 0xDA and avrdude would fail
changing
it to 0xD9, leaving it at 0xDA, which means the boot area was too
small,
and as the manual says, "Fuses are the main cause for problems with the
flash write operations.". (I won't say how much stuffing around it
took me
to find this.)
BTW, *: const create , does> @i ; *now works fine.
It's at least partially my fault for not noticing the "make write-fuse"
failed, before I went ahead and did "make install". Mea culpa.
I have trashed the bad Nanos and found some good ones.
As an aside, some of my spare Nanos have an Atmega328pb installed,
which is
supposed to be software compatible with the 328p, but with some extra
peripherals. There is no entry for the 328pb in the devices directory,
and
I can't see how to create the files (that all say "generated
automatically,
do not edit"). As a workaround I symlinked devices/atmega328p to
devices/atmega328pb, which seems get me around the problem.
How are the device files generated? Is it worth generating one for the
328pb?
Thanks all who responded.
Cheers,
Nigel
On Thu, 1 Jan 2026 at 04:43, John Sarabacha <[email protected]>
wrote:
Hello,
Brad Nelson (ueForth & esp32Forth) was kind enough to provide his work
on a
forth assembler for RISCV and Xtensa and also porting information and
current limitations and learnings of his implementation. This feature
is
missing from AmForth (that I can see), although AmForth can compile
dictionary words to sram it is missing an assembler that can compile
words
interactively that embed RISCV assembly instructions which run in
sram.
This feature can speed up code execution (running in sram) of forth
because
flash memory execution of code can involve wait states. This port of
RISCV
assembler for AmForth is experimental at this point and any successful
and
useful findings can be listed in the opinion section. This feature may
also
work for ARM32 AmForth (using the ARM primitives). However Brad Nelson
ran
into roadblocks in his arduino implementation of assembler for ESP32.
The
Xtensa support could assemble and disassemble but the RISCV support
could
only disassemble.
Regards,
John S
On Wed, Dec 31, 2025 at 7:26 AM Erich Wälde <[email protected]>
wrote:
> Hello,
>
> > On 2025-12-31 02:32, Nigel Rowe wrote:
>
> >> having got amforth running on an arduino nano, I wanted to
> >> use *marker* ...
>
> >> OK, so the problem is in does>, ...
>
> I have used marker and definitions with does> extensively, and
> they do work as advertised, at least up to version 6.9, on avr
> controllers (mostly atmega644p).
>
> From what you describe, I would rather suspect, that there is
> something else wrong. Maybe your build has a subtle shortcoming,
> or flashing/uploading is missing something, or eeprom content is
> not correct, i.e. not correctly coresponding to ram. Or your
> controller is configured strangely (fuse bits?). Or your
> controller could be subtly broken. Also consider using another
> board, like an uno, if possible.
>
> I have wasted countless hours chasing ghosts like these.
>
> Good luck!
> Erich
>
> [email protected] writes:
>
> > Hello Nigel,
> >
> > I can't reproduce the error from the pastebin with my build of AmForth.
> >
> > |S| 1|anew empty.tests
> > |W| 2|
> > |S| 3|: const create , does> @i ;
> > |S| 4|42 const ltuae
> > |S| 5|ltuae
> > |S| 6|.
> > |O| 6|42
> > |W| 7|
> >
> > Above works as expected
> >
> > |S| 8|anew empty.tests
> > |W| 9|
> > |S| 10|ltuae
> > |E= ?? -13 5
> > |S| 11|.
> >
> > Above works as expected (can't find ltuae)
> >
> > |E=0 ?? -4 1
> > |W| 12|
> > |S| 13|words
> > |O| 13|empty.tests empty White Cyan Brown Blue Yellow Green Red Black
> > text_reverse text_blink text_underline text_bold text_normal
background
> > foreground page at-xy ESC[ .;n .n ESC[ mandelbrot dorow docell
doescape
> > init_vars count_and_test? escapes? .char zi_sq zr_sq count zimag zreal
> cimag
> > creal s_escape rescale maxval minval maxiter empty.fun show show.short
> > show.long (show)
> >
> > Above works as expected - words works (output truncated)
> >
> > So that leaves differences between our hardware/builds.
> >
> > For hardware a set of known working hex files could be
> > flashed to your hardware. For the build, it is more complicated,
> > as AmForth will build on multiple operating systems/assemblers.
> >
> > How are you building AmForth?
> >
> > One option would be to try building from below in your current way.
> >
> > https://sourceforge.net/p/amforth/code/2457/tree/releases/6.9/
> >
> > This removes the few changes I have made (see link) since
> >
> > https://sourceforge.net/p/amforth/mailman/message/59254494/
> >
> > Best wishes,
> > Tristan
> >
> >
> > On 2025-12-31 02:32, Nigel Rowe wrote:
> >> Greetings,
> >> having got amforth running on an arduino nano, I wanted to use
*marker*
> >> (I'm using italics for amforth words). Actually I want to use *anew*,
> but
> >> that requires *marker*.
> >> So I #included marker.frt, then did *marker* -*empty*-. got the prompt
> >> back, but when I then typed *words*, I got " ?? -13 5".
> >> I tried a few other words, same result, numbers however, were accepted
> >> without complaint.
> >> I then did the "make install", #include mymarker.frt (a sucessivly
> >> truncated version of marker), got the same result, rinse and repeat,
> until
> >> removing *does>* stopped crashing amforth.
> >> OK, so the problem is in does>, so rather than playing with marker, I
> >> created the most basic word that uses *does>*.
> >> *: const create , does> @i ;* (straight out of the cookbook). Same
> >> problem, it compiles ok, but when I do
> >> *42 const ltuae *now I'm back to the same " ?? -13 x" problem (x
> obviously
> >> varies depending on the word I type).
> >> The symptoms make me think executing does> fouls up *dp*, or *newest*,
> or
> >> maybe something used by *get-current*. But what do I know?
> >> So I look at the source (does.asm), paper traced through XT_DODOES,
> makes
> >> sense, looks like it does what the comments indicate it should. So I
> >> looked at DO_DODOES, and I have no idea, last time I did any assembler
> was
> >> in the 1980s on a Z80. So I'm lost.
> >> Copy of last amshell session is here https://pastebin.com/L60vNSrY
> >> Thanks for reading, hopefully someone can help.
> >> Nigel
> >
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
> --
> May the Forth be with you ...
>
>
> _______________________________________________
> 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
