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_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Wednesday, March 27, 2002 3:05 PM
Subject: Re: RS232 (was: QL-Quality (Was: ZX-81 Question))
> > > > > 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.
>
> 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
> (!).
>
> >
> > > 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.
>
> 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 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 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.
>
>
> > 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.
>
> 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
> > > (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
>
> 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).
>
> > 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
>
>
Received on Wed Mar 27 2002 - 20:47:00 GMT