27 Mar
2002
27 Mar
'02
12:47 p.m.
That's not part of the standard I remember, Tony. Though it's been a while
(1970-something) I remember a string of meetings regarding a feeble attempt at
IBM to ascertain what the "correct" way to use the RS232-C (then) standard
signals might be. There was no agreement. DEC did it one way, DG another, TI
yet another, and the EIA standard, while quite precise about signal names,
definitions of the roles of terminal equipment and communcation equipment,
pins, and voltage levels, baud rates over distance, etc, said nothing at all
about any sort of signalling protocol either in hardware or software. This
caused LOTS of trouble out in the field when one wanted mfg ABC's equipment to
talk to mfg XYZ's. Everybody seemed, simply, to have assumed what was
intended and gone with that. Later, they had to figure out how to work around
the resulting problems. The answer, of course, was to strap back all the
handshakes so the hardware would work, then use X-on/X-off protocol in
software to do the work.
One reason this standard was so limited was because of its rather narrow
assumptions about what the roles of terminal vs. communication equipment were.
If there were no equipment other than terminals and modems it would have been
a piece of cake.
If you've got a pointer to a recent version of the spec, perhaps you could
share it with us so we can all get on the same page.
Dick
----- Original Message -----
From: "Tony Duell" <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, March 27, 2002 3:05 PM
Subject: Re: RS232 (was: QL-Quality (Was: ZX-81 Question))
I disagree, and so do many major manufacturers. Example : No DEC serial
port on any of my PDP8s or PDP11s (DL8, DL11, DZ11) uses RTS or CTS. Or,
indeed any other line for flow control. Mainly because they _should not_
be used for flow control.
This, of course, means you can't use a QL as a terminal to a PDP11 system
(!).
Eh? The RS232 spec I read made some interesting comments about the
correct use of the handshake lines. Things like one end had to change one
of them _before_ the other end could drop another line (I can't remember
the exact details, but it was something like it was forbidden for the DCE
(modem) to deassert CTS while the DTE (terminal) was still asserting RTS.
Which makes RTS/CTS flow control strictly illegal by the standard. It may
not have been that pair of lines, but it was certainly a commonly used pair).
The origianl use of RS232 was to link a terminal to a modem. Period. And
this modem does not have any internal character buffering (I am talking
about one of the old Bell or GPO modems, not some modern thing), so _it_
can't do flow control with the terminal. The 2 devices that need to do
flow control are the DTEs (terminal and computer), one at each end of the
link.
Now if you want to extend RS232 to link 2 local devices without
intermediate modems, fine. We all do that. But you should do it in a way
that is still compatible with the original usage. Not _require_ the
device to do hardware flow control when it may not be capable of it.
No, it's asking that devices should attempt to follow the standard. Add
extra features if you like (hardware flow control), but don't make them
madatory. Because there are a lot of devices out there, even quite modern
ones (I have one I bought _new_ in 2000) that don't support any form of
hardware flow control, and thus can't be used with a QL.
>
> > Hmm.. I regard the lack of reliable mass storage and useable serial
ports
I found the original Mac drive to be a lot more reliable than the QL
microdrives (which also were incompatible with everything else out there).
> > > > The
> > > > serial ports were broken as designed (I've looked at the
schematics.
The
> > > > RxD lines from the 2 ports are
just ORed together -- the external
devices
> > _must_ observe the handshake lines!), and
> Which every _real_ device should do. That's what the handshake
> lines are for. Always going for the least common ground isn't
Tony, as much as I apreciate your knowledge, now you
shoot yourself in the foot. Absolutely WRONG! Have you read the RS232
standard?
Yes I did, and I couldn't find any Note that they are just
funky add ons to till the sepc document. The handshake lines are _not_ there for flow
control. After all, the
RS232 interface was designed to link a terminal to a (dumb) modem. The 2
devices that need to perform flow control are the terminal and the
computer connected to the other modem. But the handshake lines are _not_
transmitted down the phone line and thus can't be used (officially) for
flow control.
Now you are talking about an end to end transmission, which
has NOTHING to do with RS232. RS232 defines the layout of The controllines are ment to tell the other sinde
about states
like data can be accepted or not etc. Let's just take said modem
and terminal - flowcontroll here is to be made by using the hand
shake lines. As for example if the modem can't send the data fast
enough it needs a way to tell that the terminal has to wait.
Perhaps you could tell me how a GPO Modem 2B (to quote one old modem I
know darn well) can do any form of flow control. The TxD input from the
terminal goes straight to the modulation input on a 2-frequency
oscillator. There is no intermediate data buffering. Period.
Of course everyvbody uses them for that, at least
on local connections.
But no device should _require_ them. It's one thing to allow them to be
used to prevent data loss if too much data is sent too fast. It's quite
another to require them to be used in all circumstances to prevent data
ending up in the wrong place.
This sounds to me like asking car manufacturers to build their
wheels according to the request that the car should still work
fine if not all nuts are tightened. (and no other I/O at all) to be rather more serious
than the lack of a
number pad (which, IIRC, was available as an option for the Mac).
Still, no real Disk drive (only the real weired Mac Drive,
not compatible to anything else, no hard disk (at a price where one could get a CP/M System with HD), no
accessable
system buss, no nothing. Only one serial port, and that's
Every Mac I've ever seen has 2 serial ports...
it. Na, I didn't like the Mac (from a
hardware point) back
then, an it didn't change over the years - the original Macs
are cloesed black box crap.
I don't like the Mac much either (particularly not the original ones). I
don't like closed systems. But that is not the point.
-tony