This is being posted on behalf of Brendan Hoar: reply to him please, not me!
From: Brendan Hoar <Brendan_Hoar@notes.pw.com> or <BrendanHr@aol.com>
Hi folks!
I would have posted this myself, except its too big to mail from AOL
(the mail buffer is too small).
Hey, anyone remember my CTS problems I was complaining about before?
11/07/92 - First publically released draft (aka Draft 3)
Notes: This is a preliminary version of this file. I am releasing
this for comments. I would recommend NOT following the instructions
below until general reaction is positive. I also have not tested to
see if this modification affects the use of AppleTalk over the modem
port - from what I understand, it should not affect it.
I WILL be following this thread as best as I can.
Also, Greg Schaefer (of InSync Software) has no relation to those of
us at The TFSP Bar & Grill, except that many of us use his way-cool &
totally-awesome telecom program called ProTERM 3.0 (if you haven't
bought it yet, BUY IT!). He has been amazingly helpful in helping us
track down the problem and I'm still amazed that he has figured out a
software work-around for PT3.
Also, all references to 'GS' mean 'Apple IIgs' and not 'Greg
Schaefer'. Jerry wanted me to point this out... :)
---
Have an Apple IIGS? Have a high speed modem? Do you use the GS modem
port? If so, read on...
******************* WARNING *******************
Warning: This file/message contains instructions on how to do a
hardware modification to the Apple IIGS. If you are not well versed
in the art of carefully soldering parts directly to the leads of TTL
chips with a low wattage soldering iron/pencil, please DO NOT ATTEMPT
THIS. Neither I, nor TFSP Systems, nor the owner of The TFSP Bar &
Grill will be held responsible for any damage you may inflict on your
GS. And this means you, Tae!
And, no, my name is NOT Deathbringer, and this is NOT a way to upgrade
2400 bps modems to 9600 bps modems using a soldering iron,
potentiometers, and a blank EPROM...
With that said...
I purchased ProTERM 3.0 approximately about the time it was released
onto the market more than a year ago. In December of last year, I
also bought (for Xmas, for myself!) a ZyXEL U-1496E high speed modem.
I also obtained a 'Mac 9600 baud (sic) modem cable', which matches the
pinouts given in the PT3 manual, and an inline RS-232 monitor. I had
a lots of fun finding bugs in ProTERM 3.0, reporting them, obtaining
the fixes (which had usually already been done by the time I reported
the bug...), etc. I was checking the InSync BBS at least a few times a
week, so I always had/have the newest drivers, bug-fixes, updates and
add-ons to ProTERM 3.0.
If I were less of a software leech, I would have run into this odd
problem sooner, but I hardly ever upload.
To make a long story short(er): About a month or so back, I was
attempting to upload files to a local UNIX host with my port set at
19,200. Using PT3's Zmodem, I noticed that even though I was using
the 'Apple IIGS modem port driver (GS/OS)' and the Okidata 9600
(RTS/CTS) driver, the state of the CTS signal was being ignored when I
uploaded and PT3 would continue to stream until a ZRPOS was received.
This caused a massive loss of xfer throughput. Both the light on the
ZyXEL and the light on the RS-232 monitor were showing that the signal
was going low.
What's wrong??? :(
With the assistance of Greg Schaefer, I was able to prove to our
satisfaction that neither the modem nor the cable was at fault. I
then decided I'd try the same software installation (on a floppy) on
both my GSs with the same modem and same cable. My OTHER GS worked
fine. ARGH!
With the help of Scott Sidley (beta@gnh-tap.cts.com) and an
oscilloscope borrowed from his work, we were able to prove that the
signal was actually getting to the Zilog on all the machines. We
didn't pay too much attention to the quality of the signal at that
time, unfortunately.
At this point, I had tried the experiment on many different GSs. Some
worked, some did not. There was no correlation to ROM version or
Motherboard Revision Number or SCC manufacturer or Zilog (SCC)
month/year stamp or Zilog (SCC) mask number.
Greg hacked up a serial driver that, instead of reacting to CTS,
simply masked the rest of the SCC status byte out and simply put the
status of the CTS signal in the PT3 status bar as a text character.
Result: On GSs that worked correctly with CTS, the inverse ' ' changed
to an inverse '@' whenever CTS went low and stayed that way until it
went high again. On GSs that did NOT work correctly with CTS, the
character pulsed (flickered?) between inverse ' ' and inverse '@' at a
relatively high frequency whenever CTS went low. Uh-oh.
Notes for non-techies:
When the modem has CTS high, the SCC's CTS (aka HSKi) signal input
is low. When CTS goes low, the SCC's signal input is supposed to go
high (and stay high). How much do you want to bet that testing of the
modem port CTS signal was never done in Apple's motherboard tests?
After lots more experimenting, we found that it was NOT the SCC chip
that was at fault, but rather, the chip at position UC16 (on a ROM01),
a 26LS32 inverting buffer that drives the SCC chips CTS and TRCxB
pins. On the original two test GSs the chip at position UC16 on the
GS that did not work was a Motorola 26LS32, while the chip at position
UC16 on the GS that did work was a Fairchild 26LS32. Lights flashed
everywhere (ding, ding, ding!) as we checked each available test GS
for the brand of 26LS32 and discovered that the four GSs that did not
track CTS properly ALL had a Motorola 26LS32 in position UC16. The
two GSs that tracked CTS properly had either a Fairchild or Advanced
Micro Devices 26LS32. We have access to two more GSs that have Texas
Intstruments 26LS32, however, those have not been fully tested. Armed
with the possibilty that it was a chip problem we now had to determine
what the actual problem was in the Motorola 26LS32's. Thanks to the
loan of a Techtronics Oscilloscope we were able to look at the signals
coming from the 26LS32 to the Z8530. When looking at a Motorola
26LS32 the inverted CTS signal was not sufficiently high (not
asserted) in respect to normal TTL signal levels as the signal trace
clearly showed three distinct levels during the tests. When CTS was
asserted by the modem the inverted CTS signal at the output of the
Motorola 26LS32 was about +.1V (nearly GROUND, as it should have
been), however, when CTS was not asserted by the modem the inverted
CTS signal at the output of the Motorola 26LS32 was oscillating from
+1.2V to +3.5V. This oscillation showed that the CTS signal being
tracked by the Z8530 was not correct. The CTS signal was either
asserted or not asserted, which state would of course depend on the
actual time the Z8530 sampled the CTS signal. Since the Z8530 is
designed to do Syncronous handshaked Communcations at up to 1 Million
Bits per second, the oscillating CTS signal was probably tracked
correctly by the Z8530, however, the CTS signal was still allowing the
Z8530 to send chars at nearly full speed (we were at 57600 bps for the
tests).
The signal output from the 26LS32 is tied to both the CTS and TRxB
pins on the Z8530, both CTS and TRCxB can be programmed as input or
output pins. It is our assertion that the serial clock that may be
programmed to be output on the TRCxB pin is bleading thru and this is
the source of the oscillating signal. The Motorola 26LS32 does not
seem to have a good internal PULL-UP to +5V so the "noise" signal that
is bleeding through is able to pull the CTS signal down towards ground
(+0V) enough that the Z8530 sees CTS as being asserted, even though it
is not being asserted.
All GSs that we have found to contain Motorola 26LS32 buffer chips (4
out of 8 GSs that we have access to), CTS is not tracked correctly on
the modem port. In all GSs which have other manufacturers' chips, such
as Fairchild or AMD buffer chips, CTS is correctly tracked.
--- Solutions ---
Greg Schaefer's proposed SOFTWARE solution: He is working on a ProTerm
3.0 driver that 'samples' CTS and delays for a while when CTS is
detected low. Due to the buffering nature of high speed modems, this
should cause no noticeable performance hit.
Note: This feature will be only available via the 'Apple IIGS Modem
Port Driver (GS/OS)' which samples CTS manually. The other driver,
'Apple IIGS Modem Port Driver', uses the SCC's interrupts to detect a
CTS transition, and since the SCC isn't getting a correct signal, it
won't work.
Solution in detail: When CTS is first detected low (at this point, on
average, only a couple of characters will have gone through and will
have been buffered by the modem since it puts CTS low BEFORE the modem
buffer is full), PT3 will loop for 1/60th of a second and neither
check CTS nor transmit characters. Then PT3 will sample CTS for
1/60th of a second (Greg said that was either 200 or 1000 samples - I
can't remember!). If ANY of them show CTS as down, PT3 will go back
to delaying and checking, otherwise it'll continue 1:1 transmitting
and sampling until CTS goes low again. Since, on the average, CTS was
being read 50% of the time correctly on the 'bad' GSs, this should
work perfectly.
tfsp Systems HARDWARE solution:
******************* WARNING *******************
Do this at your own risk and only if you have the EXPERIENCE and skill.
Dangerous and risky unless you can handle it!
You have been warned.
This has been performed on 2 Apple IIgs's by tfsp Systems technician
Scott Sidley.
First, check to make sure that UC16 is REALLY a Motorola chip (it will
have an M with a circle around it on the second line at the
beginning).
Obtain
2+ - 470 ohm resistors
2+ - 220 ohm resistors
1 - 15 watt soldering
pencil
1 - roll of appropriate solder (63/37 fine is best, but 60/40
fine will do)
1 - pair of clippers for clipping the resistors leads,
or something similar.
1 - The latest set of PT3 update files
(PT3.CODE0 being the most important!) from the InSync BBS. If the
PT3.CODE0 is later than 22-SEP-92, then it may already have the
software fix in it. Don't get it, yet! If you already have it, then
use the non-'(GS/OS)' driver instead for testing.
Set up a ProTERM 3.0 3.5" disk with those files and your dial list.
Make sure that the modem driver you are using has '(RTS/CTS)' at the
end of its title. Otherwise, you'll never be able to hardware
handshake. Also, make sure that Misc/Prefs/Xfer "Force Zmodem 1k
Sends" is NOT selected.
Set up your GS with your high speed modem and cable, sans memory card,
sans hard drive (those slots need to be empty so you can reach the
chip). Boot PT3 off of a 3.5" floppy.
Call up your local hardware handshaking host at a speed faster than it
can handle. Do a Zmodem upload. Note: You must DIAL from the dial
menu and not from terminal mode - the current driver only enables
hardware handshaking when going through the DIAL process (or the
UnAttended process, which isn't useful here).
Notice that CTS goes down, but PT3 keep sending. Press the 470ohm
resistor onto pin 13 (CTS out) and pin 10 (+5) and hold it there (it
may take some pressure, and you will have to wait until the next
high/low transition to see the difference). Touch those two pins and
only those two pins! Does the problem go away? Good, keep the 470
handy. If not, try the 220. If that works, then keep THAT one handy.
If neither works you have other problems, and you may want to just
replace the Motorola 26LS32 with another brand (which is NOT trivial)
or you may not have a good +5V source.
Select the resistor that worked and clip the resistor lead down so
that the resistor lays flat on top of the 26LS32 and can touch the
pins flat on the side, but do not touch the mother board. Make sure
the resistor is FLAT against the 26LS32, since if it is not, your
memory card might touch it.
(ascii art ack!) ####<--- 470 or 220 ohm resister
| |
| | <--- clipped leads
26LS32
\ ____
/____\
| |<---- make sure the resisor leads touch
Motherboard ----> --------- this part of the 26LS32's pins
^A __________
MM -|1o<-dot 16|- Back of GS ^ (ports, etc)
v2 -| |- |
R6 -| _ |-
QL -| | |--+O 13/CTS
8S -| | | |-
63 -| | | |-
42 -| |_|--+O 10/+5V Front of GS | (keyboard, etc)
9P -|8________9|- v
AC
UC16 (may be labeled differently on a ROM03 GS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Solder one lead to pin 10, then solder the other lead to pin 13. Work slowly and watch for any solder blobs and other unsitely messes. Double CHECK your work.
You WILL need to remove the motherboard from the case in order to properly do the modification.
We had a problem with
a) Very old solder b) Possible cold solder joints
So, even though the 470 worked when pressed against the chip, it
wouldn't work when soldered to the pins. Scott added another 470 in
parallel to each original giving an approximately 235ohm reading,
ignoring the possible resistance of the solder/bad joint. This
worked.
For the record, we tried 4.7k, 2.2k, 1k resistors and none of them
were good enough pull ups. Pin 16 is supposed to be +5, but seems to
not work with the pull-up resistor - we didn't test it after finding
that pin 10 worked. Anyone have any idea why 16 didn't work?
And thats it folks!
If you have any questions about this (and hopefully this was
descriptive enought that you shouldn't!), feel free to email either
myself (badbunny@gnh-starport.cts.com or Brendan_Hoar@notes.pw.com) or
Scott (beta@gnh-starport.cts.com or beta@gnh-tap.cts.com) for
information.
Ob Larry Lee Auto Quote Tribute:
-=> Roll on, Tootsie, Roll on [>* LARRY LEE *<]
GOOD LUCK!
Brendan
--
Ian Schmidt: irsman@iastate.edu or aol.com, BITNET: twbv4@isuvax
"I will choose a path that's clear: I will choose free will." - Neil Peart
Ask me about the GS<>IRC demo...better yet ask daveh@ccwf.cc.utexas.edu!
