Subject: Re: newbie needs advice
Newsgroups: comp.sys.apple2
From: dempson@actrix.gen.nz (David Empson)
Date: Tue, 2 Feb 1999 02:52:47 +1300
Message-ID: <1dmkskb.1ahgzot1m3ncg1N@dempson.actrix.gen.nz>
References: <000110a7719-597-7877@coloradosprings.org> <791lgf$o6p$1@nnrp1.dejanews.com> <19990131142934.19988.00002108@ng144.aol.com>
Organization: Empsoft
X-Newsreader: MacSOUP 2.3
NNTP-Posting-Host: 202.49.157.176
X-Trace: 2 Feb 1999 00:44:53 -1300, 202.49.157.176
Lines: 85
Path: lobby!newstf02.news.aol.com!portc03.blue.aol.com!newsfeed.cwix.com!128.32.206.55!newsfeed.berkeley.edu!news-stock.gip.net!news.gsl.net!gip.net!news.iprolink.co.nz!news.actrix.gen.nz!dempson



Supertimer <supertimer@aol.com> wrote:

> mairsil@my-dejanews.com wrote:
> >
> >I got an email a few days ago from someone who said they set their Proterm on
> >19.6k and used a 14.4k modem, and it worked fine. <shrug> Personally, I had
> >always thought it had to do with the clocking speed on the computer
> 
> Nope.  Think about it, the Disk II interface is pumping more data
> in terms of speed into an Apple II than even a 56k modem.

Sure, but the (1 MHz) Apple II is holding on for dear life keeping up
with it - it has absolutely no CPU time left to do anything other than
transferring the data (and possibly doing 6-and-2 encoding or decoding
on the fly).

The raw data rate of the Disk ][ drive is 250kpbs (4 microseconds per
bit).  The UniDisk 3.5 (and other "SmartPort" drives) have the same data
rate.

The Apple 3.5 Drive is twice as fast.

While doing something like a modem file transfer, the computer is
generally trying to do other things at the same time, e.g. handle data
acknowledgements, update the screen and/or copy data to or from a disk.
Modem data is usually received under interrupt, one character at a time.

Hardware handshaking is needed to stop data flow during lengthy
operations or when the receive buffer gets full (as I'm sure you know).

> Why can't an Apple II keep up with a mere 19.6k transfer?  The answer is
> that it CAN.  The Apple IIGS, for example, has serial ports capable of
> AppleTalk, which is 230k.

Again, this is a bad comparison.  AppleTalk works pretty much the same
as floppies - it takes over the entire CPU while a packet is being
transmitted or received, and like floppies it is half duplex (data only
goes one way at a time).  The most time critical part is that the
computer has to respond to an interrupt within about 100 microseconds or
it could miss an incoming packet.  It then remains in the interrupt
handler for up to 20 milliseconds while the packet is received.

A modem can potentially send data in both directions at the full
bandwidth, e.g. 57600 bps x 2 = 115200 bps total throughput, together
with any additional processing that needs to be dealt with.

> The reason why the Apple IIc and IIc+ (and only these two models)
> have problems above 9600k is not clocking speed, but a missing
> wire in their serial connectors that prevents them from doing
> hardware handshaking.

They can at least try to do hardware handshaking, but the signals they
have available prevent it from working too well.

Computer to Modem: "stop - I can't keep up": the computer is now unable
to transmit data, since it turned off its RTS (request to send) signal.
The same problem occurs on the IIe with a Super Serial Card.  In short,
data will flow in neither direction while the computer is busy doing
something else.

Modem to Computer: "stop - you're sending too fast": the computer
ignores any data the modem transmits until its flow control signal goes
active again, because the incoming flow control line is DCD (carrier
detect).  This problem doesn't affect the Super Serial Card, since it
can use the CTS (clear to send) pin for hardware handshaking.

The serial chip used in the IIgs doesn't have hard-coded behaviour for
its flow control lines - it is up the software to interpret them
correctly.

> If you have an Apple IIe and a Super Serial Card, most of the cards
> also have problems above 9600k because of a nasty bug in the
> 6551 serial chip that scrambles characters when using hardware
> handshaking.

In case anyone cares, the reason for this is that dropping the CTS input
causes outgoing characters to be truncated immediately.  It is _not_ a
"bug".  It is a design feature of the original 6551 (a very bad design
feature), which was eliminated in the 65C51 and some other 6551
implementations.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand