NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/sys/apple2/23848

Internet Message Format | 1992-11-14 | 7.3 KB

Path: sparky!uunet!caen!zaphod.mps.ohio-state.edu!cs.utexas.edu!gateway
From: [e-mail]
Newsgroups: comp.sys.apple2
Subject: CTS Stuff...
Date: 13 Nov 1992 09:48:01 -0600
Organization: UTexas Mail-to-News Gateway
Lines: 162
Sender: [e-mail]
Message-ID: <[e-mail]>
NNTP-Posting-Host: cs.utexas.edu


ARGH!

From: [e-mail] (Tc Wilson):
>Date: Thu, 12 Nov 92 08:00:59 EST
>
>[e-mail] (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
>[e-mail]        that fights back."
>.... or try: TCQ, The Captain's Quarters [phone], 300-38400 hst

Also on a similar subject...

>Subject: Re: ATTENTION high-speed modem users!
>From: [e-mail] (Morgan Davis)
>Date: 13 Nov 92 06:44:13 GMT
>
>In <[e-mail]> [e-mail] (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.