Re: Appletalk on IIC

[nathan@visi.com (Nathan Mates)]

In article <3365f5d7.0@news1.ibm.net>,  <wshek@ibm.net> wrote:
>>   Same reason why a //e with Super Serial Card (or clone) or PC can't
>>do Appletalk right out of the box-- Apple used nonstandard serial
>>chips to pull off Appletalk in the first place. 

>Hey this is 'all' just trivia at this point even the dear //gs. However
>the 'extra hardware' is just serial buffering. 

   Oh dear, looks like you haven't understood a word of what's been
said about the hardware differences, and you're dead wrong again. Do
you have the faintest clue as to how Appletalk is transmitted, what is
necessary to decode it, or do you just like sticking to an impossible
position once you've staked it out?

   Once again, for a clue, look at the numbers. Appletalk 238,400 bps.
//c max serial port speed: probably 19200, maybe 38400. Do you notice
anything different? Also, synchronous vs asychronous serial data
communication. Appletalk uses one, the //c another. And the different
spellings are there for a darn good reason: they're totally different
ways of sending data. 

   In plain english (in case you can't deal with numbers), Appletalk
wants to communicate MUCH faster and in a different language than what
the //c can listen to. That _is_ a problem. It's not buffering that
lets the GS/Mac/etc do Appletalk, it's a serial chip capable of the
speeds and protocols that Appletalk requires.


>Of course as with anything else you can move function to firmware to
>improve performance or ease of use.

   Bull****. Go ahead and write all the firmware, software, vaporware,
or the like, Appletalk's still going to be coming in an order of
magnitude faster and in a different signaling type than your serial
chip can handle. Thus, you could write the most elegant Appletalk
protocol stack in the world, but the serial chip on the //c will be
UNABLE to give you a set of bits anywhere near what was sent out.
Thus, all your nice software can't do a damn bit of good, because it's
being fed the wrong information. There is no way to bypass the serial
chip from software, thus no way to get at the original bitstream on the
wires before it got mangled by the chip.

   BTW, this is almost exactly the same discussion on GCR vs MFM for
Apple II vs IBM PC 5.25" drives. In both cases, the normal disk
controller _chip_ only speaks one of the two protocols, and cannot
make heads or tails of the other. Again, all the software in the world
is not going to make up for the fact that your hardware is the problem,
and fixing the problem, in hardware, is the only solution.


   Also, stop asking me for "credentials" in email for my "opinions"
on this subject. [Which these numbers ain't-- they're well documented,
and _everyone_ but you is quoting the same stuff at you. They're facts
of life, and trying to pass them off otherwise makes you just look the
pigheaded fool.] I _am_ a Apple II developer (and stop the crap in
email about csa2 being GS only-- the facts are the facts here, and
you've refused to accept them), and I do know a bit about the Apple II
family.

   Ignore the facts at your risk, but you're only making yourself look
bad by ignoring the realities of hardware. I'll say this again: the
serial port in the //c cannot do Appletalk, no matter how much
software you care to write. You'll need to find a serial chip capable
of it before you can proceed in the slightest manner.

Nathan Mates
--
<*> Nathan Mates http://www.visi.com/~nathan/      <*>
# What are the facts? Again and again and again-- what are the _facts_?
# Shun wishful thinking, avoid opinion, care not what the neighbors
# think-- what are the facts, and to how many decimal places?  -R.A. Heinlein