> It is all down to handshaking and how fast the QL can accept and
process
> the data. If the QL invoked the handshake line, and DTR was connected
> to RTS .....
Just to throw in my two pen'orth (by the way hello, I'm a new Q40
user), how exactly is RTS/CTS handshaking implemented on the [Linux] PC
side? I have a hardware book that shows several complicated ways of
connecting two PCs via serial ports, but taking the following scheme as
an example:
PC 'A' PC 'B'
TD ----------> RD
RD <---------- TD
RTS ----------> Input X
CTS <---------- Output Y
Input X <---------- RTS
Output Y ----------> CTS
Then if, for example, PC A wants to transmit to PC B, A would signal
its intention on its RTS output driving an input pin on PC B. PC B then
uses an output pin driving PC A's CTS to control the flow of data from
PC A. The question is, when the Linux PC is the receiver, which pin
does it expect the sender's RTS to come in on and which output pin does
it use to drive the sender's CTS?
I have some homemade devices, as well as the Q40, that I'd like to
connect to a PC but so far I've been forced to use XON/XOFF because
it's the only protocol I understand (and the cable is easy - just TD/RD
crossed and a ground).
regards,
Ian Pine.
-----Original Message-----
From: tony
Sent: 08 May 2001 09:39
To: ql-users
Cc: tony
Subject: Re: [ql-users] QL serial ports
On Mon, 7 May 2001 at 22:46:18, you wrote:
(ref: <[EMAIL PROTECTED]>)
>> You could try copy <filename> ser2 (or ser1) but at a slow baud rate
to
>> avoid problems. When we first developed QL Terminal (in 1988) we
found
>> 2400 was the maximum safe rate, and even then sometimes chrs were
lost.
>> The main problem was input to QL.
>
>When developing a terminal emulator to connect to my college computer
>system (around 87/88), we encountered major problems on the input side
>if the rate was too high: the buffer in the 2nd processor would
>over-run, causing an 11 (if eyes remembers correctly) character delay -
>nothing would appear from the SER port and then as each further
>character was received, we'd get the 11th previous character (with no
>loss); the only cure [we found] being a RESET. We generally used 1200.
..... but _not_ the reset button - the resultant system reset does not
get through to the 8049. The only cure is a power down.
>
>I still use the emulator that was written to connect my QL to my other
>PC (486, running Dos+Windoze 3.1/FreeBSD Unix) and I find 1200 baud is
>the best rate I can manage.
It is all down to handshaking and how fast the QL can accept and process
the data. If the QL invoked the handshake line, and DTR was connected
to RTS, then it was possible to get 9600 successfully - especially with
Gold Card/Super Gold card. The Astracom modem succeeded by buffering
the data and feeding it to the QL more evenly, and always reacting
correctly to handshake. At the time it was the only non-specific QL
modem designed to cope with the QL serial input.
The buffer-overrun happened if QL DTR (really an RTS in this use) was
connected to remote DTR (ie printer lead), or if the 8049 failed to set
DTR (if correct cable used). This happened very easily, as the 8049
code was bugged. For instance if it was making a sound, it 'forgot' to
to much else.
Even the Astracom could not cope with this.
This discussion is a classic example of how even the basic QL problems
keep re-surfacing. This issue was fully understood and solved in 1988
(if I recall correctly) with Hermes - a replacement 8049.
--
QBBS (QL fido BBS 2:257/67) +44(0)1442-828255
mailto:[EMAIL PROTECTED] http://www.firshman.demon.co.uk
Voice: +44(0)1442-828254 Fax: +44(0)1442-828255
TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
