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 > -- Nigel Rowe _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ [email protected] https://lists.sourceforge.net/lists/listinfo/amforth-devel
