CTS Stuff...

[Brendan_Hoar@notes.pw.com]

ARGH!

From: t_captain@bluemoon.rn.com (Tc Wilson):
>Date: Thu, 12 Nov 92 08:00:59 EST
>
>irsman@iastate.edu (That Ian Guy) writes:
>
>> Brendan, in further testing, has ascertained that TI buffer chips are also
>> defective for CTS tracking.  Thus, if your chips are TI you may wish to 
follo
>> the procedure outlined in the previous posting.  The good news is, that
>> Greg Scheafer has written new drivers for PT3 which eliminate the problem 
eve
>> on systems with bad chips.  Watch this space for more details.
>>
>
>
>Right, and where do you think he got the idea from?

Not from you.

Anyway, I didn't get the idea - Greg did.  There were various ideas to be 
tested:

-rw-brd 0000 bin     20992 Sep 20 17:47 1992 pt3.code0rlse 
The latest released version.  Has the CTS problem on some GSs.

-rw-brd 0000 bin     20992 Sep 20 17:47 1992 pt3.code0txt 
With a byte zapped patch to display the status of CTS in the status bar.  
This  is a kludge, & also ignore the date on the file.  This helped us track 
down what was going on.

-rw-brd 0000 bin     20992 Sep 20 17:47 1992 PT3.CODE0 
The version I'm using now on both my GSs.  Same as the first one.

-rw-brd 0000 bin     20992 Oct 28 18:56 1992 pt3.code0delay 
This didn't fix the problem.  The delay was high enough that the modem's 
buffer never overflowed when CTS went low under normal circumstances but the 
GS was still sending a large number of characters to the modem when CTS went 
low.  If a retrain ocurred or CTS went down for a long time for other 
reasons, my guess is that this one would fail.

-rw-brd 0000 bin     21248 Oct 28 21:32 1992 pt3.code0samp
This had a result similar to the last one.  CTS was sampled a number of times 
(3?) and then if any of the reads were low, it was sampled again.  This was 
doomed to fail.  Again, it WORKED (no chars were lost), but it let through 
even more characters than the previous driver.  A retrain,etc would kill it.

-rw-brd 0000 bin     20992 Nov  5 18:31 1992 PT3.CODE0delsam
This contains the second version of the 'delay & sample' driver.  The first 
one had a logic bug ('Infinite CTS response' - CTS goes down, and the GS 
needs  to be rebooted to continue transferring data...), but Greg didn't know 
about it for about 4 days since:
a) He doesn't have an answering machine - only a fax - and I don't have any GS
fax software (I do have the fax modem, so I'm in the market for the 
software...).
b) He's been in 'programming mode' on ProTerm for the Mac and hasn't been
logging into the InSync BBS regularly (but when he does, he responds to all 
the
posts).
Anyway, this last driver works.  Unfortunately, another bug appeared and this 
one
may leave the PRINTER port in an unknown state.  Not good.  He's got that 
fixed and will put up another driver soon for beta testing (he may have 
already - I didn't check last night).

>
>Hint: I've had this problem solved software wise sunce late spring.

You mentioned on IRC (this was after I'd been testing Greg's delay driver and 
Greg's sample driver, & possibly after the second delay&sample driver - I 
don't recall) that you had to program 'an idiot timing loop' (or something 
like that).  Thats all you told me.  I've never seen your software before.  
You may have fixed the problem first.  I'll accept that.  Whatever.  Greg 
came up with his solution independantly of yours.  Just to keep the record 
straight.

>
>
>Tc Wilson/The Captain           "Programming is an art form
>t.captain@bluemoon.rn.com        that fights back."
>.... or try: TCQ, The Captain's Quarters (614) 488-8401, 300-38400 hst

Also on a similar subject...

>Subject: Re: ATTENTION high-speed modem users!
>From: mdavis@crash.cts.com (Morgan Davis)
>Date: 13 Nov 92 06:44:13 GMT
>
>In <1992Nov12.022902.16202@netcom.com> tbc@netcom.com (Mike Garvey) writes:
>
>>Paul "The Oggman" Parkhurst says that the cable he mentioned in his "HST
>>Speed" articles (described below) neatly sidesteps this problem with the
>>CTS signal and the HSKi line; this cable basically uses the GPi line to
>>support the CTS signal. Is it possible that more software (PT3, METAL,
>>ProLine/ModemWorks, GNO's drivers) be modified to work with this cable?
>
>Its doubtful that ModemWorks (which ProLine uses) would be able to work
>with this configuration because ModemWorks uses the Extended Firmware
>routines in the Apple IIGS's serial interface.  You'd basically have to
>rewrite the ROMs to do this.  On the other hand, 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?  To 
cause it to occur would require a situation like this.  Pro-line'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.  Oh wait - 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...

>
>This may be because the IIGS firmware uses the CTS transition interrupt
>rather than polling the CTS signal as do many programs that go right
>to the metal in dealing with the 8530 directly.

PT3 has two GS modem port drivers.

Apple IIGS Modem Port:
Greg calls this driver 'blood thirsty'.  Its the 'fastest', but on a Zipped 
system at least, I can't tell the difference.  It uses the SCC's CTS 
transition interrupt rather than polling the CTS signal just as Morgan says 
the Firmware does.  It fails on a number of GS's we have here, and works on 
others.  Depends on the 26LS32 installed in the machine.

Apple IIGS Modem Port (GS/OS):
This driver uses polling of the CTS signal.  This also fails on a number of 
GS's we have here.  However, by adding the delay&sample to this driver, it 
now works.  It would be impossible to make the other driver do that since 
there is no way to change the SCC's internal logic.

Of course, both of the above drivers work on GSs that have had the pull up 
resistor installed on the 26LS32.

I have a hunch that the firmware would fail CTS flow control on those GSs we 
have had problem with.

Anyway, there's an easy way to test if your GS has the CTS problem that 
requires.

PT3
a GS with the correct cable on the modem port
a small wire
the appropriate macro (Which is at HOME - I'll attempt to post it tonight).

Basically there is a macro that calls a PT3 macro command to get data from 
the SCC.  It reports either "CTS is high" or "CTS is low" and scrolls thru 
them on the screen, maybe 10 times a second.

If you attach a wire between pins 2 and 5 on the end of the GS cable (the 
RS232 end), you will force the TXD output (Which will the negative - since no 
chars are being sent) into the the CTS input.

If the macro prints 'CTS is Low' over and over again, your GS probably does 
not have the problem.

If the macro prints 'CTS is Low' and 'CTS is High' alternately, the you 
probably have the problem.

Anyway I'll post the macro from AO tonight.