alfter@uns-helios.nevada.edu (SCOTT ALFTER) (10/06/90)
I'm working on a telecomm system for the Apple II; presently I'm making a modem
driver for a Hayes Smartmodem hooked through an Apple Super Serial Card. (My
actual setup is an Applied Engineering DataLink 2400, but what's the difference
to the driver? :-) ) This is an interrupt-driven driver. The interrupt
"daemon" dumps incoming text into a 256-byte buffer, where it can be pulled out
by the telecomm program's routines when they need it.
A feature I recently added was XON/XOFF handshaking. When the buffer contains
128 characters, the daemon automatically sends XOFF. XON is sent to resume
operation when the buffer's contents drop to 64 characters.
XON/XOFF handshaking is fine for an interactive session, but what about file
transfers? You need all 256 possible byte values available for most file
transfer protocols (some, such as Kermit, make do with less), so you can't use
handshaking that adds stuff to the bitstream. The obvious solution is hardware
handshaking--playing with the DTR line. However, this doesn't seem to work. I
reassembled my modem driver for DTR instead of XON/XOFF and called a BBS at
2400 baud, using a BASIC program to interface with the ML routines. With XON/
XOFF, incoming text was whole--it appeared slowly, but you'd get it all. With
DTR, though, large chunks of text would be missing. All I'm doing is playing
with bit 0 of the ACIA's command register--a 1 means ready, 0 should tell the
remote device not to send. My Imagewriter works this way; are modems
different? Do handshaking signals get sent, or is XON/XOFF the only
possibility?
Thanx in advance for any help with this problem.
-------------------------------------------------------------------------------
Scott Alfter _/_
/ v \ Apple II:
Internet: alfter@uns-helios.nevada.edu ( ( the power to be your best!
GEnie: S.ALFTER \_^_/toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/06/90)
When you use the hardware handshake lines, you are telling the modem that it is ok/not ok to send, but the modem has no way to communicate this fact to the other end of the phone line. This means that your modem will quit sending characters, but the modem itself will still be recieving them -- so when the modem's own internal buffer (assuming it has one) overflows, you lose gobs of characters. My suggestion would be to have your drivers be able to turn XON/XOFF mode on or off, so the higher-ups can inform the driver whether or not to use XON/XOFF. A bigger buffer than 256 characters would also be a good idea if you are not really tight on memory. Todd Whitesel toddpw @ tybalt.caltech.edu
ART100@PSUVM.PSU.EDU ("Andy Tefft 725-1344", 814) (10/07/90)
Hmm. It would seem to me that you would have problems doing hardware handshaking with a modem. For sending, things would probably be fine, but imagine when you are receiving. You drop cts or whatever to tell your modem not to sen to your computer, but how does your modem tell the other modem this, when all it has to talk to the other modem with is a rd/sd line (the phone line)?? Your printer works because it isn't receiving data from another printer and sending it along to you.
jb10320@uxa.cso.uiuc.edu (Desdinova) (10/07/90)
In article <2092@unsvax.NEVADA.EDU> alfter@uns-helios.nevada.edu (SCOTT ALFTER) writes: [about his term program] >XON/XOFF handshaking is fine for an interactive session, but what about file >transfers? You need all 256 possible byte values available for most file >transfer protocols (some, such as Kermit, make do with less), so you can't use >handshaking that adds stuff to the bitstream. The obvious solution is hardware >handshaking--playing with the DTR line. However, this doesn't seem to work. I >reassembled my modem driver for DTR instead of XON/XOFF and called a BBS at >2400 baud, using a BASIC program to interface with the ML routines. With XON/ >XOFF, incoming text was whole--it appeared slowly, but you'd get it all. With >DTR, though, large chunks of text would be missing. All I'm doing is playing >with bit 0 of the ACIA's command register--a 1 means ready, 0 should tell the >remote device not to send. My Imagewriter works this way; are modems >different? Do handshaking signals get sent, or is XON/XOFF the only >possibility? a 0 does tell the remote device not to send. Unfortunately, the remote device is YOUR modem. DTR only controls the computer-modem connection. Most modems allow a DTR drop to hang up the modem (that's how ZLink and TelCom do it). There's no way around XON/XOFF- it's the only method of over-the-phone handshaking. You can usually pick whichever characters XON and XOFF are, with Kermit and Zmodem. With XModem and YModem, handshaking is not a problem, since just about any computer can handle a 1K burst (with a small buffer). ZModem is where the problem begins to happen on an apple II (disk access kills ACIA/SCC interrupts, making Zmodem freak). You must have your XON/XOFF handshaking turned off during a transfer. It's the only way. >Thanx in advance for any help with this problem. >Scott Alfter _/_ > / v \ Apple II: >Internet: alfter@uns-helios.nevada.edu ( ( the power to be your best! > GEnie: S.ALFTER \_^_/ -- Jawaid Bazyar | Blondes in big black cars look better wearing Senior/Computer Engineering | their dark sunglasses at night. (unk. wierdo) jb10320@uxa.cso.uiuc.edu | The gin, the gin, glows in the Dark! | (B O'Cult) Apple II Users Unite! Storm the New Product Announcement and Demand Justice!
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (10/07/90)
Yes, the hankshaking signals work. Over RS232. However, your
connection to the remote machine is not RS232. It's a modem link that
supports only normal characters and a special "character" known as
BREAK, which isn't a normal character. All DTR does is tell your MODEM
not to send to you, and some modems ignore it or use it as hangup.
For file transfers, make the buffer large enough to handle 1 packet.
Normally, you shouldn't get many more characters than 1 packet at a time.
-----------------
Jeffrey Hutzelman
America Online: JeffreyH11
Internet/BITNET:jh4o+@andrew.cmu.edu, jhutz@drycas.club.cc.cmu.edu
>> Apple // Forever!!! <<alfter@uns-helios.nevada.edu (SCOTT ALFTER) (10/07/90)
So, basically, what you're saying is that the handshaking lines don't get
turned into signals that go through the modem. I suppose that's what I needed
to hear--better to know it can't be done than to keep trying forever. :-) I'll
need to make XON/XOFF switchable for file transfers, of course. As for buffer
size, I picked 256 bytes because that's the width of the 6502's index
registers, though I could probably make a larger buffer at the expense of more
involved code.
-------------------------------------------------------------------------------
Scott Alfter _/_
/ v \ Apple II:
Internet: alfter@uns-helios.nevada.edu ( ( the power to be your best!
GEnie: S.ALFTER \_^_/russotto@eng.umd.edu (Matthew T. Russotto) (10/07/90)
In article <2092@unsvax.NEVADA.EDU> alfter@uns-helios.nevada.edu (SCOTT ALFTER) writes: >A feature I recently added was XON/XOFF handshaking. When the buffer contains >128 characters, the daemon automatically sends XOFF. XON is sent to resume >operation when the buffer's contents drop to 64 characters. > >XON/XOFF handshaking is fine for an interactive session, but what about file >transfers? You need all 256 possible byte values available for most file >transfer protocols (some, such as Kermit, make do with less), so you can't use >handshaking that adds stuff to the bitstream. The obvious solution is hardware >handshaking--playing with the DTR line. However, this doesn't seem to work. I >reassembled my modem driver for DTR instead of XON/XOFF and called a BBS at >2400 baud, using a BASIC program to interface with the ML routines. With XON/ >XOFF, incoming text was whole--it appeared slowly, but you'd get it all. With >DTR, though, large chunks of text would be missing. All I'm doing is playing >with bit 0 of the ACIA's command register--a 1 means ready, 0 should tell the >remote device not to send. My Imagewriter works this way; are modems >different? Do handshaking signals get sent, or is XON/XOFF the only >possibility? DTR low means 'drop carrier' to modems, or means nothing, depending on the setting of various DIP switches. You want to use CTS/RTS, not DTR. (CTS and RTS are on pins 4 and 5, DTR is on pin 20. There may be jumpers on the Super Serial to enable/disable these-- there are on my CCS 7711, based on the same chip) Your other alternative is to wire Pin 20 (DTR) of the Super Serial Card to pin 4 (RTS) of the modem. It's probably better to change your program to use RTS, though. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/07/90)
In article <2092@unsvax.NEVADA.EDU> alfter@uns-helios.nevada.edu (SCOTT ALFTER) writes: >XON/XOFF handshaking is fine for an interactive session, but what about file >transfers? You need all 256 possible byte values available for most file >transfer protocols ... This isn't true. There are two general classes of file transfer protocols; one of them sends limited-size packets, where the initial connection negotiation establishes how big a packet can be without the receiver getting overrun. In such a protocol, generally a subsequent packet is not sent until the receiver acknowledges the previous one, which it does only after it has made room for one more incoming packet. The other style of serial-line transfer protocol utilizes only a subset of the available (usually 7-bit) data bit patterns, specifically to avoid sending a control character by mistake. There are several obvious ways to map from generic 8-bit byte contents into less-than-7 bit patterns. UUCP typically contains "uuencode"/"uudecode" to handle such a mapping, for example. DTR should not be toggled to flow-control a modem, because in many cases one or more characters have already been sent and disabling DTR will not stop them from arriving, and at worst will cause that data to be lost. Similarly, RTS/CTS handshaking generally doesn't work for flow control either. Even with DC3/DC1 (XOFF/XON) in-band flow control, you still need to be prepared to handle a few characters that arrive after you have requested that no more be sent. This is simply inherent in asynchronous full-duplex communication. Positive-acknowledgement packetizing schemes avoid this particular problem.
jeffn@nuchat.UUCP (Jeff Noxon) (10/07/90)
In article <1990Oct6.122802.28306@nntp-server.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: |When you use the hardware handshake lines, you are telling the modem that |it is ok/not ok to send, but the modem has no way to communicate this fact |to the other end of the phone line. This means that your modem will quit |sending characters, but the modem itself will still be recieving them -- |so when the modem's own internal buffer (assuming it has one) overflows, |you lose gobs of characters. | |My suggestion would be to have your drivers be able to turn XON/XOFF mode |on or off, so the higher-ups can inform the driver whether or not to use |XON/XOFF. A bigger buffer than 256 characters would also be a good idea if |you are not really tight on memory. | |Todd Whitesel |toddpw @ tybalt.caltech.edu Is hardware handshaking even supported by any of the GS term programs? But anyway, the only reason I can see anyone wanting to do this is if they have a high speed or MNP modem. Take this example: My T2500, in PEP mode, runs on the average at about 17kbps. The DTE rate (Modem<->Computer) is set to 19.2kbps. This makes it easy to overrun the modem's buffer and lose characters. Handshaking prevents this from happening. It works in two ways: the modem tells you when it's buffer is full, and you tell the modem when your buffer is full. Every high speed protocol I have heard of communicates this information with the other modem as well. It's built in with PEP. Other modems use MNP and V.42 to take care of this. If your XON/XOFF handshaking is acknowleged by the modem as handshaking, you're in trouble because file transfers will fail. That's why the hardware solution is best, if possible. Jeff -- Jeff Noxon | Stop complaining and do something about jeffn@nuchat.sccsi.com | it. Really! 713/721-6820 (CDT) Houston, TX |