Re: [Amforth] A RISC-V update

On Tue, 16 Apr 2024 19:34:13 +0100 h...@tjnw.co.uk 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

Re: [Amforth] A RISC-V update

Thanks for your work. I've just ordered a development board. M. On Sat, 13 Apr 2024 17:08:53 +0100 h...@tjnw.co.uk 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, >

Re: [Amforth] Maintainer(s) for AmForth

On Sun, 10 Sep 2023 17:04:01 +0200 tristan 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

Re: [Amforth] AmForth Project open for adoption

Erich, Thanks for all your work. You may wish to advertise the vacancy on the USENET comp.lang.forth. A G account will do the job. On Fri, 06 May 2022 09:17:23 +0200 Erich Wälde wrote: > Dear AmForthers, > > I am herewith stepping down from the maintainer role of AmForth. For > details, read

Re: [Amforth] AmForth 6.9 on Arduino MEGA using ATmega2560- No reponse at console

On Sun, 17 Apr 2022 07:47:15 +0100 Tristan Williams wrote: > Hi Christian, > > Glad it worked. > > > How much of 256KB flash is effectively usable with AmForth on the > > 2560? ? > 64k only (which is heaps) - W and IP are 16-bits only. The upper 64k is still available, a little bit is used

Re: [Amforth] Compiling for a headless target

On Tue, 31 Aug 2021 06:27:50 +0200 Helge Kruse wrote: > Hello, I am new to amForth. > > amForth is an interactive Forth. The compiler runs on the target and > writes to the flash memory of the device. This requires to send all > the source code through the UART interface. > > I want to develop

[Amforth] AVR8: Mega 2560 Wiping Flash Memory

I had problems with my Arduino Mega erasing parts of the flash memory; sometimes the odd byte, sometimes the odd page. I changed 3 things to the flashing code to make the problem go away: 1. Checked the SPMCSR:RWWSB bit. This is a crib from the Atmel example (29.6.13 Simple Assembly Code

Re: [Amforth] Newbie with a mega2560

On Mon, 24 May 2021 17:57:51 -0700 Michael Picco wrote: > Hello Martin, > Thank you for responding! > In my work directory, which is aptly named 'amforth-6.9', I don't see > a copy of the template.asm file with "amforth-low.asm" mentioned. > The amforth-low.asm file is referenced in the avr8

Re: [Amforth] Newbie with a mega2560

The crucial file to include for an ATmega is the confusingly named: "amforth-low.asm" which needs to be un-commented in template.asm. All the code is then in low flash memory apart from the flash burning routine which should be found at NRWW_START_ADDR (0x01f000). Often, with a new device, you

Re: [Amforth] template.hex can't be build with MCU=atmega8

In template.asm, a better bet might be: > ; define which usart to use. > .include "drivers/usart.asm" See also: http://amforth.sourceforge.net/TG/recipes/Usart.html On Fri, 14 Aug 2020 13:17:13 +0200 Malte Frank Gerdes wrote: > Hi, > > this is the first time i'm using amforth. I followed >

[Amforth] Reference Card page now missing

Somehow this has gone from the RH menu: http://amforth.sourceforge.net/TG/refcard.html -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2020). ___ Amforth-devel mailing list for http://amforth.sf.net/

Re: [Amforth] Stack pointer

On Mon, 8 Jun 2020 11:58:15 +0100 tur bine wrote: > Hi just wished to expand my knowledge base with forth, the stack > pointer increases during runtime and does not decrease unless using > certain commands if etc, can somebody explain what happens when sp > and thus the stack gets full please >

Re: [Amforth] Watchdog Timer on AVR8s

I should add this is a follow-up to a thread started in 2019. Here's the archive of that thread: https://sourceforge.net/p/amforth/mailman/message/36683433/ -- Regards, Martin Nicholas. E-mail: m...@mgn.org.uk. ___ Amforth-devel mailing list for

Re: [Amforth] Watchdog Timer on AVR8s

Hi, I've had this one brewing for some time. Looking at schemes for: AT90CAN128 & ATA6612C. Common variables between chips: WDTCSR (WDTCR), WDTOE (WDCE), WDCE, WDE. WDTCSR & WDTOE are included "For compatibility" in the CAN chip. I include this in cold.asm. It should work with the two WDTs in

[Amforth] Missing DU

Not present in 6.8 as far as I can see. > 8.6.2.1270 DU< “d-u-less” DOUBLE EXT > ( ud1 ud2 -- flag ) > flag is true if and only if ud1 is less than ud2. Also, a bug in D0>: Hmmm, something wrong here I feel: > (ATmega2560)> decimal 1553994000. d0> . 1572137999. d0> . > -1 0 ok Cheers!

Re: [Amforth] Watchdog Timer on AVR8s

This snippet is a bit more like it (I think): lds temp0, WDTCSR ori temp0, (1

[Amforth] Watchdog Timer on AVR8s

Looking into a crashing ATmega2560, I found this clause in the docs: "If the Watchdog is accidentally enabled, for example by a runaway pointer or brown-out condition, the device will be reset and the Watchdog Timer will stay enabled. If the code is not set up to handle the Watchdog, this might

[Amforth] Amforth 6.8

Taken me months to notice, but 6.8 still reports a "ver" of 6.7 from env-forthversion.asm -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk (Address will be valid throughout 2019). ___ Amforth-devel mailing list for http://amforth.sf.net/

Re: [Amforth] 16/32 Bit Fetch & Store.

On Wed, 17 Oct 2018 13:27:09 +0100 Tristan Williams wrote: > On 17Oct18 10:25, Martin Nicholas via Amforth-devel wrote: > > Hi, > > > > I think that @ ! +! 2@ 2! d+! should disable interrupts on the AVR. > > Although it's possible to code around a variable being

[Amforth] AVR Fuses

Hi, With "make install" the fuses are burnt after the flash, it's possible the fuses are in such a state the the device is un-burnable. Off-the-shelf parts (Arduinos and the like) are sometimes like this. You can try burning the fuses first with: "make write-fuse" then followed by "make

[Amforth] 16/32 Bit Fetch & Store.

Hi, I think that @ ! +! 2@ 2! d+! should disable interrupts on the AVR. Although it's possible to code around a variable being changed by an interrupt (using C@ C! for example), the 16-bit counter registers can't be dealt with in a similar way. Section 17.3 of the datasheet "Accessing 16-bit

[Amforth] Bug in atmega2560 Code.

Hi, Looks like there is a bug in file: /amforth-6.7/avr8/words/store-i_big.asm That is: > out_ rampz, zl should be: > out_ eind, zl EICALL and EIJMP both use this register for the extra bits. -- Regards, Martin Nicholas. E-mail: reply-2...@mgn.org.uk

[Amforth] Bug in i2c-eeprom.frt

Thee should be a NACK as indicated below, I believe. : c...@i2c.ee ( addr hwid -- c ) dup i2c.begin swap i2c.ee.send-addr i2c.start \ repeated start i2c.rd i2c.tx \ hwid for reading i2c.rxn \ BUGFIX i2c.end ; -- Regards, Martin Nicholas.