flow control on PDP11 MMJ
shadoooo
I'm trying to install a full 2.11BSD from PC using serial port and
vtserver@38400 baud.
I used a cable where I connected the MMJ signals to the serial port in
this way:
MMJ / RS232
TXD -> RXD
RXD -> TXD
DTR -> DSR
DSR -> DTR
It worked, so I correctly installed the root on my HD. After that, I
would try to transfer some file to the PDP11 using 2.11BSD directly,
so I tried to copy a uudecode.c and compile it on the PDP (cc is on
root).
So i tried to use "cat > uudecode.c" on the PDP and send the file from
the PC using a terminal emulation. The transfer is dropping a lot of
bytes, so the flow control probably doesn't works.
I'm using kermit on PC, configured for serial operation with flow
control, serial 7E1.
On the 2.11BSD I tried to enable both XON and RTS flow control with
stty tandem
or
stty rtscts
changing the flow control also on kermit accordingly, but the flow
control still doesn't works.
The MMJ cable has only DTR/DSR wires, so maybe the flow control isn't
available here?
I tried also to connect the DTR/DST pair of the MMJ to the RTS/CTS
pair of the PC, because linux seems not supporting DTR/DSR flow
control (at least it is not available in kermit), but in this case
simply the PC is not sending anything, maybe the PDP11 is telling
always to "wait" to the PC.
So the question: how to do a reliable serial connection between PDP11
and PC, with flow control?
How to set the port on 2.11BSD and on linux?
Thanks
Rob Brown
> I'm trying to install a full 2.11BSD from PC using serial port and
> vtserver@38400 baud.
How long is your cable? I'm pretty sure that >~100 ft is iffy at this
speed.
> I used a cable where I connected the MMJ signals to the serial port
> in this way:
>
> MMJ / RS232
> TXD -> RXD
> RXD -> TXD
> DTR -> DSR
> DSR -> DTR
You don't say that you have signal ground connected. Check out
<http://www.stanq.com/cable.html#DEC_Adapters> and search for "MMJ to
DB-9 Female" (or whatever is appropriate for you).
> On the 2.11BSD I tried to enable both XON and RTS flow control with
As you noted, you don't have RTS on the MMJ. I don't know why
XON/XOFF would not work for you. It has always worked for me, but the
only OS on the PDP-11 that I have used it with is RSX.
--
Rob Brown b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd. (780)438-9343 (voice)
Edmonton (780)437-3367 (FAX)
http://gmcl.com/
shadoooo
> speed.
2 meters, no lenght problems...
>
> You don't say that you have signal ground connected.
yes, I connected it, I jsu omitted for simplicity...
I don't know why
> XON/XOFF would not work for you. It has always worked for me, but the
> only OS on the PDP-11 that I have used it with is RSX.
That's what I would know...
John Santos
@m16g2000yqc.googlegroups.com>, shad...@gmail.com says...>
Is this a real PDP-11 or an emulator? If it's a real PDP-11, 38400
is pretty fast for the serial port. It might work much better at
a lower baud rate, for example at 9600. The console UARTs on most
of the PDPs have only about 2 characters of buffering, and no DMA
to store the data, so the PDP has to respond to an XOFF or drop of
DSR/CTS or whatever in less than 2 character times. (The various
async multiplexers such as the DH11, DHV-11, CXY's, etc. are much
better, having DMA, deep character silos, and sometimes the flow
control is implemented in hardware, IIRC, and doesn't rely on an
interrupt getting processed promptly, but these are never used for
the console terminal. But if you have one of these and have Unix
sufficiently installed that you can log in on one of the ports,
you would be much better off running Kermit over it, rather than
the console.)
--
John Santos
Evans Griffiths & Hart, Inc.
shadoooo
> is pretty fast for the serial port. It might work much better at
> a lower baud rate, for example at 9600. The console UARTs on most
> of the PDPs have only about 2 characters of buffering, and no DMA
> to store the data, so the PDP has to respond to an XOFF or drop of
> DSR/CTS or whatever in less than 2 character times. (The various
> async multiplexers such as the DH11, DHV-11, CXY's, etc. are much
> better, having DMA, deep character silos, and sometimes the flow
> control is implemented in hardware, IIRC, and doesn't rely on an
> interrupt getting processed promptly, but these are never used for
> the console terminal. But if you have one of these and have Unix
> sufficiently installed that you can log in on one of the ports,
> you would be much better off running Kermit over it, rather than
> the console.)
This is a real PDP11. In fact maybe the speed is too high, but of
course the hardware flow control seems to be not accessible from
2.11BSD.
In other words, even if I enable rtscts with stty on 2.11BSD, these
lines doesn't do anything. I suspect that this is not the right way.
In fact the rtscts option maybe is not remapped to the dtr/dsr lines
of the MMJ.
Bill Gunshannon
Just out of curiosity, why would you expect Unix to somehow map
CTS/RTS to DTR/DSR they are totally different and well defined
functions and do not provide equivalent actions. One is flow
control and the other is modem control.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Tim Radde
> In article <4c2eb668-dfb3-4fba-b397-82ab4f62a...@u7g2000yqm.googlegroups.com>,
> University of Scranton |
> Scranton, Pennsylvania | #include <std.disclaimer.h> - Hide quoted text -
>
> - Show quoted text -
Just wanted to state I used 38400 when I was trying to load BSD via
VTServer and my 11/84. Didn't have any issues
besides the 32Mb file limitation of VTServer. When I later tried to
use Kermit I had to drop that to 9600, since it
did not handle anything higher without some minor changes.
Johnny Billquist
My responses seem to not always go that far, so I don't know who, if
any, will be able to read this.
However: flow control using CTS/RTS is actually abusing the interface as
well. And DEC never did that. So it's normally XON/XOFF or nothing.
But, since this is using Unix, all bets are off. However, I would not
expect hardware flow control to even be possible using MMJ, since the
signals normally used for that are not present.
That said, hardware flow control, being an abuse already from the start,
have also been observed using DTR/DSR and other combinations. But this
is all a question of how Unix might be able/want to do it.
"stty tandem" to get xon/xoff flow control on Unix was a new one for me
(as per the original poster).
Check that 2.11BSD really supports that compatibility option, and that
it does the "right" thing.
(Why not check and post the output of stty -a here?)
All that being said, there are a chance that even with flow control
enabled, the system might loose characters on input, just because
sending an xoff takes a little time, and if we're talking about the
console port here (which I guess we are), then the hardware FIFO is
basically non-existant, so unless the system really can keep up with the
interrupts, you will loose characters.
And Unix is perhaps not the most responsive software. :-)
The best bet on getting it to would would probably be to lower the
speed. But you probably still want to figure out the flow control issue.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Bill Gunshannon
>> VTServer and my 11/84. Didn't have any issues
>> besides the 32Mb file limitation of VTServer. When I later tried to
>> use Kermit I had to drop that to 9600, since it
>> did not handle anything higher without some minor changes.
>
> My responses seem to not always go that far, so I don't know who, if
> any, will be able to read this.
>
> However: flow control using CTS/RTS is actually abusing the interface as
> well.
How so?
From Wiki (for whatever that is worth!):
CTS (Clear To Send)
This is the response signal from the DCE regarding if the terminal
equipment should be transmitting any data. When this signal is -15V
the terminal is "permitted" to transmit data. Like the DTR/DSR pins,
this one can be directly connected to the RTS pin to reduce the number
of wires needed, but this eliminates the possibility of hardware flow
control. Some software ignores this pin and the RTS pin, so other flow
control systems are also used. That will be explained when we get to
actual software.
Looks like flow control is precisely what RTS/CTS are for. That's the
way I remembered it, but I don;t have access to my copy of the actual
standard, which is why I regressed to Wiki. :-)
> And DEC never did that. So it's normally XON/XOFF or nothing.
>
> But, since this is using Unix, all bets are off. However, I would not
> expect hardware flow control to even be possible using MMJ, since the
> signals normally used for that are not present.
True. Unless the manufaturer violates the standard and uses modem control
to implement something that looks like flow control. Droping DTR from the
terminal end should log you off the Unix system, which I guess would pretty
much throttle the flow of data coming to the terminal :-) so I guess that
would be a form of flow control. :-)
>
> That said, hardware flow control, being an abuse already from the start,
Why do you keep saying this? RS232 had hardware flow control defined
fromthe start.
> have also been observed using DTR/DSR and other combinations. But this
> is all a question of how Unix might be able/want to do it.
>
> "stty tandem" to get xon/xoff flow control on Unix was a new one for me
> (as per the original poster).
> Check that 2.11BSD really supports that compatibility option, and that
> it does the "right" thing.
> (Why not check and post the output of stty -a here?)
>
> All that being said, there are a chance that even with flow control
> enabled, the system might loose characters on input, just because
> sending an xoff takes a little time, and if we're talking about the
> console port here (which I guess we are), then the hardware FIFO is
> basically non-existant, so unless the system really can keep up with the
> interrupts, you will loose characters.
> And Unix is perhaps not the most responsive software. :-)
>
> The best bet on getting it to would would probably be to lower the
> speed. But you probably still want to figure out the flow control issue.
>
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
Christian Corti
> How so?
> From Wiki (for whatever that is worth!):
> CTS (Clear To Send)
> This is the response signal from the DCE regarding if the terminal
> equipment should be transmitting any data. When this signal is -15V
> the terminal is "permitted" to transmit data. Like the DTR/DSR pins,
And that is wrong. CTS is the response to RTS. The terminal requests to send
data, e.g. when the user presses a key, and has to wait until it is permitted
to do so (via CTS). On a DTE, RTS is an output and CTS an input, and on a
DCE it's vice-versa.
For DTE-DTE communications you don't need RTS and CTS, but instead, you
would need "receiver ready" signals on both ends. Since they
don't exist, RTS and CTS have been "hacked" in order to provide some kind
of this functionality (RTS as receiver ready output, and CTS as its
corresponding input).
> of wires needed, but this eliminates the possibility of hardware flow
Hardware flow control is done in hardware by definition, which is easily
done on older UART designs (like with the TR1602). I usually modify the
PDP11 console board (DL11) to provide one-way hardware handshake signals
directly derived from the "receiver done" signal.
Christian
Bill Gunshannon
Christian Corti <Christi...@studserv.uni-stuttgart.de> writes:
> Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>> How so?
>
>> From Wiki (for whatever that is worth!):
>> CTS (Clear To Send)
>> This is the response signal from the DCE regarding if the terminal
>> equipment should be transmitting any data. When this signal is -15V
>> the terminal is "permitted" to transmit data. Like the DTR/DSR pins,
>
> And that is wrong. CTS is the response to RTS. The terminal requests to send
> data, e.g. when the user presses a key, and has to wait until it is permitted
> to do so (via CTS).
Right, up to this point.
> On a DTE, RTS is an output and CTS an input, and on a
> DCE it's vice-versa.
No. RTS is always outbound and CTS is always inbound. What changes
between DCE and DTE is the pins they appear on. They reverse (as do
others) in order to make sure the DTE and DCE are talking to each other
and not just butting heads.
>
> For DTE-DTE communications you don't need RTS and CTS, but instead, you
> would need "receiver ready" signals on both ends.
No, what you nead is a null modem cable to wensure that RTS and CTS are
properly matched between both ends. They still serve exactly the same
purpose. Although most of the terminals I have experienced merely keep
RTS high all the time and toggle CTS for flow control.
> Since they
> don't exist, RTS and CTS have been "hacked" in order to provide some kind
> of this functionality (RTS as receiver ready output, and CTS as its
> corresponding input).
I have never seen a device that used RTS to signal tot he remote end that
it was ready to receive. That is, after all, exactly what CTS is for.
>
>> of wires needed, but this eliminates the possibility of hardware flow
>
> Hardware flow control is done in hardware by definition, which is easily
> done on older UART designs (like with the TR1602). I usually modify the
> PDP11 console board (DL11) to provide one-way hardware handshake signals
> directly derived from the "receiver done" signal.
bill
glen herrmannsfeldt
> In article <hfmevn$54j$1...@tempo.update.uu.se>,
> Johnny Billquist <b...@softjar.se> writes:
>> However: flow control using CTS/RTS is actually abusing
>> the interface as well.
> How so?
> From Wiki (for whatever that is worth!):
> CTS (Clear To Send)
> This is the response signal from the DCE regarding if the terminal
> equipment should be transmitting any data. When this signal is -15V
> the terminal is "permitted" to transmit data. Like the DTR/DSR pins,
> this one can be directly connected to the RTS pin to reduce the number
> of wires needed, but this eliminates the possibility of hardware flow
> control. Some software ignores this pin and the RTS pin, so other flow
> control systems are also used. That will be explained when we get to
> actual software.
> Looks like flow control is precisely what RTS/CTS are for. That's the
> way I remembered it, but I don;t have access to my copy of the actual
> standard, which is why I regressed to Wiki. :-)
As far as I know, they were for half duplex systems that could only
send data one direction at a time. (Unlike the currently popular
definition of half duplex, which should be called full duplex local
copy.)
The modems have to do line turnaround, where they switch between
transmit and receive, with the appropriate signal lines to/from
the terminal.
-- glen
shadoooo
so in the end the discussion is going to be too hot, and with no
solution!
I would need some advice: please suggest me:
- a schematic for a right cable
- some command to setup the flow control on 2.11BSD (preferred
hardware)
I will do a try to see if I can finally guarantee the text file
transfer...
Thanks
Johnny Billquist
You need to look at the right wiki, in the right section:
(From Wikipedia, on RS-232)
************************
RTS/CTS handshaking
In older versions of the specification, RS-232's use of the RTS and CTS
lines is asymmetric: The DTE asserts RTS to indicate a desire to
transmit to the DCE, and the DCE asserts CTS in response to grant
permission. This allows for half-duplex modems that disable their
transmitters when not required, and must transmit a synchronization
preamble to the receiver when they are re-enabled. This scheme is also
employed on present-day RS-232 to RS-485 converters, where the RS-232's
RTS signal is used to ask the converter to take control of the RS-485
bus - a concept that doesn't otherwise exist in RS-232. There is no way
for the DTE to indicate that it is unable to accept data from the DCE.
A non-standard symmetric alternative, commonly called "RTS/CTS
handshaking," was developed by various equipment manufacturers: CTS
indicates permission from the DCE for the DTE to send data to the DCE
(and is controlled by the DCE independent of RTS), and RTS indicates
permission from the DTE for the DCE to send data to the DTE. This was
eventually codified in version RS-232-E (actually TIA-232-E by that
time) by defining a new signal, "RTR (Ready to Receive)," which is CCITT
V.24 circuit 133. TIA-232-E and the corresponding international
standards were updated to show that circuit 133, when implemented,
shares the same pin as RTS (Request to Send), and that when 133 is in
use, RTS is assumed by the DCE to be ON at all times.[9]
Thus, with this alternative usage, one can think of RTS asserted (logic
0) meaning that the DTE is indicating it is "ready to receive" from the
DCE, rather than requesting permission from the DCE to send characters
to the DCE.
Note that equipment using this protocol must be prepared to buffer some
extra data, since a transmission may have begun just before the control
line state change.
******************
Note, that DEC equipment don't have RS-232E ports, so you don't have an
RTR signal.
And trying to use RTS/CTS for flow control *is* abusing the standard.
'Nuff said.
Christian Corti
> > On a DTE, RTS is an output and CTS an input, and on a
> > DCE it's vice-versa.
> No. RTS is always outbound and CTS is always inbound. What changes
No, a modem (i.e. DCE) responds with CTS to a RTS and thus it is an output
(we're talking about the original specification with half-duplex links).
RTS is sent from a DTE to request to change from receiving mode to
transmitting mode of the modem. When the modem is ready, it signals to
the DTE with CTS.
Christian