Strange edge behavior on FF 5.0Atmega w.r.t. allocating, receiving and printing buffers

[Loren Cannon]

E FlashForth 5 ATmega328 13.01.2024

empty warm FlashForth 5 ATmega328 13.01.2024

create mybuff 5 allot ok<#,ram>

program
3
for
mybuff 5 accept
mybuff swap type
next

; ok<#,ram>
program 112233 ok<#,ram>
program 65535655356553565535 ok<#,ram>
ok<#,ram>

[Loren Cannon]

The create mybuff 5 allot line can be made more generous without making the program behave any differently.

When I try to accept 5 characters, something mysterious happens if I actually do enter 5 characters.

[Mikael Nordman]

Your terminal program is sending 12345<cr><lf>.
12345 ends the first ACCEPT, <cr> ends the second ACCEPT and <lf> ends the third ACCEPT.
<cr><lf> received in one ACCEPT will be treated as one end of line.</lf></cr></lf></cr></lf></cr>

[Loren Cannon]

I was technically not using carriage returns, but I can still follow what you're saying.

[Loren Cannon]

The program appears to accept input normally twice, but the third time it doesn't input normally, whether or not <cr><lf> or <lf> is used.</lf></lf></cr>

[Mikael Nordman]

I have difficulty to understand exactly what you are doing / want to do.
Anyhow the strange behaviour is caused by CR and/or LF being interpreted by ACCEPT.
I don't remember the logic exactly, but there has not been a complaint for normal interpreter operation for many years.

If a terminal program without line buffering is used it will send just the characters and your code works as it should.
I tested that with minicom and miniterm on linux.

[Mikael Nordman]

So, if you want to receive a line with a line ending like 12345LF, you need to use 6 ACCEPT so that the the character count does not prematurely end ACCEPT.
The buffer and the ACCEPT count has to be large enough to handle the largest input plus the line endings.

If you need to receive just raw data regardless of line endings you need to code your own word that uses KEY to get the input.