Article 54793 of comp.sys.cbm: Xref: undergrad.math.uwaterloo.ca comp.sys.cbm:54793 Newsgroups: comp.sys.cbm Path: undergrad.math.uwaterloo.ca!csbruce From: csbruce@ccnga.uwaterloo.ca (Craig Bruce) Subject: Re: Zmodem send Sender: news@undergrad.math.uwaterloo.ca (news spool owner) Message-ID: Date: Fri, 31 May 1996 20:03:37 GMT References: <4oauf1$hle@ocean.CAM.ORG> <4olvk6$t32@news.inforamp.net> Nntp-Posting-Host: ccnga.uwaterloo.ca Organization: University of Waterloo, Canada (eh!) Geoffrey Welsh wrote: >csbruce@ccnga.uwaterloo.ca (Craig Bruce) wrote: >>It certainly could be. (Desterm needs hardware flow control too for >>connections above 19.2kbps too). If anyone wants to use the ACE code and >>can figure it out, they are welcome to it. > >Matt grumbled something the other day about adding hardware flow control to >DesTerm (it supports XON/XOFF now, but many people aren't comfortable with >that and it isn't always convenient). We also discussed some YMODEM-G >details. Because of a few idiosyncracies of the 6551, hardware flow control is a bit tricky to implement. For one thing, you can't transmit anything while you're asserting RTS. Another thing is that if you ever disable SL interrupts (I don't know if you ever do this, but ACE has to since it's a general environment), but there's a problem with receiving a character when interrupts are disabled in the SL: if you re-enable them, then the SL won't generate an interrupt for the received character. There's also a matter of the ugliness of using edge-triggered interrupts, although I only use interrupts for receiving, which gets rid of some of the problems. I use an arbitrarily large receive buffer, which causes some synchronization problems which have to be very carefully thought out to remove any race conditions. This is a problem since I can't temporarily disable receive interrupts while I am in critical sections of code, since I might lose a character because the SL won't generate an interrupt in this case as mentioned above. There's also bit of a compatibility issue with hardware flow control, but I think that it's a non-issue. The CTS line acts like normal, and really so does the RTS line, since you won't be sending anything while RTS is asserted (because you can't, because the 6551 was designed before RTS/CTS flow control became common). It's also the case that some older modems don't do anything with RTS/CTS signals for flow control, but this is also a non-issue since these signals can be safely ignored with you being no worse off that if you didn't use these signals. Also, the modems that don't support hardware flow control are probably slow enough (<=2400 bps) that you can always keep ahead of them. And, finally, you can also have both hardware flow control AND software flow control. All of these reasons are why I don't give the use the option of turning hardware flow control off; there's no reason to. >I suppose I shouldn't be talking about not yet released features! It's always a mistake. :-) Keep on Hackin'! -Craig Bruce csbruce@ccnga.uwaterloo.ca "How come wrong numbers are never busy?" --fort C=256,64K-VDC,REU,RL16,HD200,FD4000,SL,USR28.8,C=128,1581,1571,C=64C,1541,VIC20