#2400 bauud XT BB problem
5 messages in this thread
I have an Amiga 2000 with an XT Bridgeboard, serial card, extra 128K memory
and WD controller with Miniscribe RLL HD (60 meg). Have recently upgraded
my modem to 2400 baud. I seem to be able to keep up at this rate with no
problem, all file transfers seem to execute flawlessly with no
retransmissions. However I seemed to have developed a problem. If I am
using an editor such as Emacs on a remote host which does cursor control,
then sending keystrokes to the editor, such as ^F, will cause the remote
side to echo back cursor control escape sequences for the terminal emulator
that I'm using. It seems, however, that AT NORMAL TYPING SPEEDS, every
once in a while a character (usually ESC) gets dropped and the terminal
emulator outputs the rest of the cursor control sequence as data to the
screen. In an effort to pinpoint this, I'm left with the unshakable
conclusion that somehow the Bridgeboard is dropping characters before they
ever reach the application.
1) All terminal emulators tried in the XT bridgeboard had the same
problem.
2) Different versions of Emacs on different remote hosts all had the
same problem with my XT BB.
3) Examination of the line input buffer showed that indeed the Escape
character had been dropped before reaching the application.
4) Trying the same scenario on XT or AT clones could not duplicate the
problem.
5) Running the scenario on the Amiga serial port at 2400 baud did not
show the problem (same modem and telephone lines).
6) Running from the same modem but at 1200 baud on the XT BB caused the
problem to go away
Does anyone have any ideas as to what could be causing this problem? Oh
yes, the scenario was tried with XON/XOFF and hardware flow control as well
with identical results. Somehow, it appears that in this scenario only,
characters can be lost at normal (slow) typeing speeds. Would appreciate
any input from anyone…
Thanks,
John
John,
Let me make sure I understand this:
If you type (for example) ESC A as a control sequence, sometimes,
the ESC doesn't get sent, so you see the A on screen as if you had simply
typed it by itself? Is that correct?
Since the keyboard input routines are separate from the serial
routines…I'm having a hard time thinking of what might be going on.
Is it possible with your terminal program to set up a few macros
that send the sequences rather than having to type them in? If so, try
that…and see if the same problem developes. If it doesn't, try cleaning
the ESC key…see if that fixes up things.
If the problem continues, even with the macro sending the sequence
rather than you hitting the keys…then it almost sounds like your terminal
program may be "eating" the ESC character for some reason or other. Try
reloading the terminal program..see if that helps.
Of course, none of this answers why it works at 1200 and not at
2400…but if you can…try the above anyway…it might help in narrowing
the problem down.
Don
Don,
No, you misunderstood me. If I am in a telecommunications program such
as MS-Kermit which emulates a VT102, and I am talking to a remote host
running Emacs on it, then if I type in ^F, for example, that tells Emacs to
move the cursor forward one character. So the remote Emacs responds by
sending back the VT102/ANSI escape sequence to position the cursor forwards
one character. Such escape sequences typically contain the ESCAPE
character. It is the escape character that is echoed back to the PC by the
remote that is being dropped somehow. For example, the escape sequence is
something like "ESC [ f $ %", if the ESC is dropped, then the "[f$%" is
treated as ordinary data, not cursor control data. Hope I have made myself
clearer, if not let me know.
John
John,
Ok…the PC is sending you the ESC sequence rather than you sending
it to the PC…and the ESC itself appears to be getting dropped, but only
at 2400 baud…right?
That sounds like a problem in your serial board, not in the Amiga.
The Amiga merely takes what your program puts into the BridgeBoard's video
RAM area and displays it. Your program is what controls what is in the
video RAM area. It (your program) does all translations, cursor control
and so forth. Since it's not getting the ESC character, as you've noted,
it is not translating the rest of the sequence into cursor control, so it
shows up as plain text.
The only way your program wouldn't get the ESC is:
a. It's not being sent (unlikely)
b. The modem is "eating" it (also unlikely)
c. The serial card is "eating" it (likely)
If the BB was too slow to read data from the serial card, it would
cause the serial card's buffer to overflow (or an XOFF to be sent) but
you'd drop random characters…not just ESC characters.
Is it possible for you to try another serial card?
Don
Don,
I didn't think it was the serial card because regular characters that
are being sent over have no problem. For example, I downloaded using
YMODEM a very large file (180K) with no retransmissions or errors
whatsoever. Like I stated earlier, normally characters are not dropped.
Only when the character sequence is being used for cursor control at the PC
while someone is simultaneously typing is there a problem. Now the modem
wouldn't know what the characters are being used for…As another test, I
composed a file on the remote host that had the cursor escape sequence in
it, and had the remote "type" the file out. I then captured the characters
coming in, and nothing was dropped. It appears to me that somehow, there is
an interaction going on between the keyboard, screen and modem. For
example, while the PC is handling keyboard interrupts, is it possible to
loose characters coming in on the serial port? Such a problem, I suspect
would be in the ROM BIOS. (I tried different versions of MS-DOS with the
same result). What do you think?
John