Hi.
..
> Are you (or anyone) using lib/xonxoff.frt?
No.
I modified QUIT to achieve a xon xoff handshake with Zterm (mac OSX).
The Idea was:
Create 2 vectors in eeprom to hold execution token (xt) for words to
send control characters to terminal - value startterminal and value
stopterminal.
>> Kalus Michael wrote:
> I use ZTerm with Mac OSX. In typing mode, it stops sending when XOFF
> character is echoed, and continues after XON. So my amforth CR sends
> xoff to the Terminal too, and the OK is followed by XON.
> (Typing mode: copy&paste forth souce into ZTerm window, do not use
the amforth issues one additional SPACE and that creates an issue
with Mosaic when editing the line and using backspace. The fix - do
comment out the XT_SPACE below:
...
PFA_ACCEPT5:
.dw XT_DUP; ( -- addr k k )
.dw XT_EMIT ; ( -- addr k )
;.dw XT_SPACE ; ( -- addr k ) < 20101
.. there is an issue with Mosaic Terminal - the BackSpace issue I've
addressed in one of my last year's topics - the fix is easy (just a
small change in one amforth word). P.
- PŮVODNÍ ZPRÁVA -
Od: "pito"
Komu: michael.ka...@onlinehome.de,
amforth-devel@lists.sourceforge.net
Předmět: Re:
I've been using "Mosaic Terminal" (free download, designed for
forth)under XP. Just set "Wait for Echo" ON and "Binary Char Delay"
0.005 (or less). It runs 115200 8N1 without a problem (when your
crystal allows such speed, of course). Copy/paste sources. This
terminal is the only one I can use with
Hi.
Am 29.03.2011 um 21:33 schrieb Matthias Trute:
..
> Receiving characters is a completly different thing. The characters
> can come at any time, therefore the code needs to deal with the
> situation relativly fast (at least before the next character
> arrives).
If you just want to connect a t
Hi,
> As I understand it, the amforth way of dealing with interrupts on the
> serial port is to have the ISR set a flag, and the uart is truly
> serviced when the inner interpreter steps to the next word.
You are right that the inner interpreter can deal with interrupts (to
some extent), but th
On 3/27/2011 8:22:27 PM, kenmcc...@allmail.net wrote:
> Hi, I soldered in a crystal and a couple of caps and
> it's working fine
> now, Amforth seems much more sensitive to clock frequency than the
> Arduino C programs.
>
> I've
> had no trouble with the serial interface running C programs o
Hi, I soldered in a crystal and a couple of caps and it's working fine
now, Amforth seems much more sensitive to clock frequency than the
Arduino C programs.
I've had no trouble with the serial interface running C programs on the
BBB. That sent me on some wild goose chases trying to figure out w
I have few resources but the advice I can ask for here, and patience.
There's only so much you can lean on others who are not on payroll, so
I'd darn better be able to scrape up buckets of patience, or I'll get
frustrated and make no progress! :) This would have been more fun with a
digital st
My thanks to all who worked on this problem. I have had an almost
identical problem on a low cost arduino clone, the BBB by Modern Device.
It uses a ceramic resonator rather than a crystal, so I expect the
clock frequency to be a little off. I'll know whether that is the
problem when I solder up
>> D Nyberg wrote:
> entered "1 1 + ." I think the error was because I am using tera term,
> which sends a whole line at once. Combine that with the imperfect clock
> setting, and I think the atmel uart saw unprintable characters by byte 6
> or 7 in a string because of timing problems. Or possi
Yes, my fuse settings were wrong, and that was part of the problem.
Also, for reasons I don't understand, the 18.4 mHz crystal isn't making
it run at 18.4, but rather I measure it (crudely) at around 17.5. I'll
try to make a more precise measurement with oscilloscope in a little
while. Adjustin
>> D Nyberg wrote:
> Issue 2: With the console running, I can do a few really basic things
> such as 1 . yields a correct response of 1 ok, but... If I enter 1
> 2 + . I get the strange response "?? -13 6" ok.
Does the "words" command work? If not, there may be different issues.
First, did
Okay, the problem seems to have been a combination of wrong fuse bits,
plus my hardware is running at 17.5 mHz instead of 18.4 as the crystal
is marked. I'm thinking maybe the caps attached to the crystal are funny
or something. But now it works, even from startup.
Now to better re-learn forth
Hello,
On 03/26/2011 11:31 AM, D Nyberg wrote:
> Okay gang, I'm making progress with my efforts to get amforth running,
> but encountering perplexing problems.
>
> Issue 1: I got the console running, but only by overriding the kernel's
> calculated uart divider value of 0x33 with my empirically de
Okay gang, I'm making progress with my efforts to get amforth running,
but encountering perplexing problems.
Issue 1: I got the console running, but only by overriding the kernel's
calculated uart divider value of 0x33 with my empirically determined
value of 0x71. Must be running at a clock rat
17 matches
Mail list logo
