NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/apple2/24066

Internet Message Format | 1992-11-17 | 9.7 KB

Path: sparky!uunet!caen!zaphod.mps.ohio-state.edu!cs.utexas.edu!gateway
From: [e-mail]
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: [e-mail]
Message-ID: <[e-mail]>
NNTP-Posting-Host: cs.utexas.edu


.RrL----|-------|-------|-------|-------|-------|-------|-------|-------|-------R
                                            ^
Hey everyone, meet the ProTerm v3.0 ruler.__|
:(

>From: [e-mail] (Morgan Davis)
>Subject: Re: CTS Stuff...
>Date: 15 Nov 92 22:57:34 GMT
...
>In <[e-mail]> [e-mail]
>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
([e-mail]@internet) I did something really psycho.  I
typed '[e-mail]...'.  I've got CTS on the brain!  :( :( :(  Help me!
LOL!

PPS - Email sent between 10pm and 2:30pm EST should go to
[e-mail].  This applies to weeknights (incl Sunday, excl
Friday) & weekdays (M-F) only.
Otherwise, [e-mail] will probably get a faster reply.  That is,
assuming that their gateway ain't hosed again.