Newsgroups: comp.sys.apple2 Path: news.weeg.uiowa.edu!news.uiowa.edu!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!news.iastate.edu!irsman From: irsman@iastate.edu (That Ian Guy) Subject: ATTENTION high-speed modem users! Message-ID: Sender: news@news.iastate.edu (USENET News System) Organization: Iowa State University, Ames, IA Date: Sun, 8 Nov 1992 00:35:37 GMT Lines: 313 This is being posted on behalf of Brendan Hoar: reply to him please, not me! From: Brendan Hoar or 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! Path: news.weeg.uiowa.edu!news.uiowa.edu!uunet!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!ut-emx!ccwf.cc.utexas.edu From: daveh@ccwf.cc.utexas.edu (Calamity Coyote) Newsgroups: comp.sys.apple2 Subject: Re: ATTENTION high-speed modem users! Message-ID: <83209@ut-emx.uucp> Date: 8 Nov 92 01:56:19 GMT References: Sender: news@ut-emx.uucp Organization: The University of Texas at Austin, Austin TX Lines: 20 Well, I was having the same problems with CTS/Zmodem uploads... PT3 would keep on sending regardless of the state of CTS, the modem's buffer would overflow, and I'd get tons of ZRPOS errors. After talking to some people on IRC about this, Brendan told me about the problem with the Motorola chip and the fix for it. So, I opened up my GS, took a look at my 26LS32, and whaddaya know? It's a Motorola! Anyways, after experimenting with a couple of resistors, I found that a 270 ohm resistor did the job for me; PT3 stops sending when my modem's buffer fills, I can upload without any problems, and I get cool xfer rates of about 1550 cps :-) BTW, according to the Hardware Reference, the modem port's 26LS32 is labelled UC13 in a ROM 3 GS... -- David Huang | Internet: daveh@ccwf.cc.utexas.edu | "Microwaves: They're not just UUCP: ...!ut-emx!ccwf.cc.utexas.edu!daveh | for cooking anymore." America Online: DrWho29 |