Path: news.weeg.uiowa.edu!news.uiowa.edu!uunet!caen!zaphod.mps.ohio-state.edu!cs.utexas.edu!gateway From: Brendan_Hoar@notes.pw.com Newsgroups: comp.sys.apple2 Subject: CTS wars... :) (j/k!) Date: 17 Nov 1992 09:50:26 -0600 Organization: UTexas Mail-to-News Gateway Lines: 207 Sender: daemon@cs.utexas.edu Message-ID: <9211171549.AA10117@pwtc.tc.pw.com> NNTP-Posting-Host: cs.utexas.edu ..RrL----|-------|-------|-------|-------|-------|-------|-------|-------|-------R ^ Hey everyone, meet the ProTerm v3.0 ruler.__| :( >From: mdavis@crash.cts.com (Morgan Davis) >Subject: Re: CTS Stuff... >Date: 15 Nov 92 22:57:34 GMT .... >In <9211131547.AA14279@pwtc.tc.pw.com> Brendan_Hoar@notes.pw.com >writes: > >>>ModemWorks uses the Extended Firmware >>>routines in the Apple IIGS's serial interface. >>>I've not heard of any >>>ModemWorks-based systems having any trouble with hardware flow >>>control. > >>Interesting. How often is hardware flow control exercised with >>MW3.0? > >This is transparent to ModemWorks because the IIGS serial port >firmware takes care of it. The answer to your question is: as often ^^^^^^^^ ^^^^^ ^^^^ ^^ ^^ - uhoh. >as is necessary. Since ModemWorks operates using the IIGS's default 2K >interrupt buffer, flow control would be asserted when it became >approximately 3/4 full. Er. We are talking OUTPUT to the modem here. CTS signal, not RTS. The buffer size doesn't matter, get it? :) > >>To cause it to occur would require a situation like this: ProLine's >>port rate at a higher rate than the caller has his/her port rate set to or >>higher than the modem can move the data, & a Zmodem download to a system >>that can't handle the speed. > >That's one scenario. And, yes, ModemWorks wants to run with the port >set to a high fixed speed (to get the most out of high speed modems >with data compression). You can say the same thing for a caller who >is connected at 300bps and is getting a file with 1K XMODEM. The Er. Well, actually that depends on a) the ability of ModemWorks to actually send at the high bps rate & cause an overflow and b) the internal buffer size of the modem. I wouldn't be surprised if a common MODEM internal buffer size was about 1kbyte and CTS would never go low in your scenario if that were the case. >protocol isn't the factor. Flow control would also come into play if >the caller was simply bulk-reading messages in the conference system >non-stop (raw ASCII stream). True. Of course, how fast pro-line can output messages comes in to play here as well. It could be the case that pro-line is not outputting them at a rate that is overflowing the communications link (or overflowing it more than 1k (or MODEM_TRANSMIT_BUFFER_SIZE) at any one point in time). A thought just occurred to me that the 'CTS bug' might only appear at 38,400 and 57,600 since those were the two speeds I was testing at. This would be odd though. I'll have to go look into it. Er...I do recall, however, that Scott/beta was doing testing at 19,200. My guess is that the problem is speed independent, however. Yes, I know - I should do MORE research. :( >The only time I've ever heard of ModemWorks/ProLine systems having >trouble with flow control is when they've not been using a properly >wired HWFC cable. I can believe it! :) > >>Does ModemWork's Zmodem stream (keep sending until naks appear - >>regardless of lack of acks) or does it have a relatively small window >>size? If the latter, then flow control might almost never be >>exercised... > >When sending, it waits for ACKs if the receiving end requires them. You are saying that if the other end does not accept streaming, then pro-line will not stream when sending a file to the user. What you didn't explicitly say was that if the end-user CAN handle receiving Zmodem streaming, that MW will Zmodem stream and will NOT wait for ACKs. Sorry if this was supposed to be inferred by me, but I just want to make sure. Can you clarify? Be as specific if possible. I had this problem trying to get information out of an ANSITerm user and finally was lead to believe that ANSITerm does not support full Zmodem streaming for uploads. If I am wrong, let me know. >When receiving, the buffer size varies depending on available memory, >but 12K is average. Receiving 12K could easily overflow the IIGS's 2K >serial buffer and/or the modem's internal buffer, so flow control >would be asserted. Again, RECEIVING files on the GS is not the issue here. So far RTS has been working fine with a proper cable. >Again, we've had no problems except with systems that aren't set up >properly to handle high speed communications (e.g. anemic cables). >Most Mac and PC users of ProLine have had success in uploading and >downloading with ZMODEM. ProLine/ProLine and ProLine/UNIX systems >have not had trouble exchanging large packet transfers at high speed. >But the majority of users experiencing difficulty are Apple II users >using ProTERM. Again people keep trying to tell me that it is a ProTERM bug. I have shown one other programmer that her/his software was failing in other more subtle ways because she/he had Motorola chips, but had been lucky enough to program in an odd hack in his/her CTS handling that made filling of the modem buffer unlikely when CTS was low. But characters were still crawling through at a slow rate. It is a hardware problem. We scoped it. Isn't that proof enough? *sigh* Guess not. If there were some terminal program out there that I could get my hands on which: a) Used the FIRMWARE b) Did full Zmodem stream uploading I could prove to you that on some GSs, when CTS went down, the Firmware would not react 'correctly'. Of course, this is based on the assumption that Apple did not notice the problem and put special code into the Firmware to sample the CTS signal to tell if it is really up or down. But if they DID do that, why wouldn't they have written a technote about it? Also - my guess (again - I am not a programmer so that's the best I can do) would be that the Firmware uses the SCC's CTS transition interrupts to handle handshaking. If so, it would always fail on these GSs. Unfortunately, there is only one RELEASED terminal program (not BBS) that does hardware handshaking that I can test with. That is ProTERM v3.0. From what I understand ANSITerm has Zmodem but it does not STREAM and I'm not sure it has CTS handshaking (correct me if I am wrong Paul!). Again, I have two Apple IIGSs with the exact same motherboard revision. One of them DOES CTS handshaking correctly under PT3. One of them DOES NOT. The non-working one has a much more dodgy signal coming off of pin 13 on the 26LS32 (which is a motorola part). This problem crops up regardless of the fact that I am using: a) The Apple IIGS Modem Port Driver - which uses CTS transition interrupts or b) The Apple IIGS Modem Port Driver (GS/OS) - which uses polling to test the state of the CTS signal. If anyone else out there has had experience with other software that does CTS handshaking on one GS but not another, PLEASE post about it. I feel kind of lonely out here butting heads with Morgan Davis. :( Jawaid - does GNO's `sz` handle handshaking via the firmware? If so, I guess I could use that to test the firmware - let me know. :) All I have to do is set the Modem Port control panel correctly, reboot and sz a file under GNO, right? Here is Greg's little (previously posted in two parts) CTS checker macro: @@c * CTS Checker * set &0="CTS is Low^m" set &8="CTS is High^m" while (1) { pr #2,&(bits(modem),8) } ex Copy this into your PT3.GLOBAL file (preferably at the beginning). Save the changes. Go to the main menu and hit option-z to re-load the global macros. Unplug your (properly wired according to the PT3 manual, of course) din8 -> DB-25 cable from the modem (but not from the GS). Hold the DB-25 end in your (non-primary) hand. Use your other (aka primary) hand to hit option-c. The screen will scroll and say "CTS is High" over and over again. Attach a wire between pins 2 and 5 on the DB-25 end using your primary hand. At this point you will probably find yourself in a position where you are unable to type, etc. This is good, since you are supposed to be paying attention to a) keeping the contact good and b) looking at the screen. If the screen says (continuously, assuming good wire contact) "CTS is Low", then your GS will NOT exhibit this CTS problem. Ignore the rest of my rants and raves. :) If the screen says "CTS is Low" and "CTS is High" alternately, seemingly unable to decide WHAT state CTS is in, then your GS will exhibit the CTS problem, and single reads of the CTS signal aren't trustworthy (and neither is the CTS transition interrupt which won't save you from overflowing the modem's buffer since the SCC will be producing bazillions of the transition interrupts). Anyway, its almost midnight and I've been typing this too long. I need sleep - I'll post this tomorrow (Tue 17 Nov 92). Oh shoot, make that later today. :( And if any of the Apple guys have read down this far and don't feel upset that I am addressing them directly (if you do, please ignore this plea, I don't like creating bad blood) - Does Apple have any documented cases of problems with the CTS signal on GSs, ever, or is it just me? Does anyone except me care? :( PS - As I typed the address for this article (comp-sys-apple2@cs.utexas.edu@internet) I did something really psycho. I typed '...le2@cts.utex...'. I've got CTS on the brain! :( :( :( Help me! LOL! PPS - Email sent between 10pm and 2:30pm EST should go to Brendan_Hoar@notes.pw.com. This applies to weeknights (incl Sunday, excl Friday) & weekdays (M-F) only. Otherwise, BrendanHr@aol.com will probably get a faster reply. That is, assuming that their gateway ain't hosed again.