Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!sri-unix!sri-spam!ames!ptsfa!ihnp4!alberta!auvax!rwa
From: rwa@auvax.UUCP (Ross Alexander)
Newsgroups: comp.sys.atari.st
Subject: Re: Atari ST, Mac emulator and TOPS network
Message-ID: <416@auvax.UUCP>
Date: Sun, 22-Nov-87 13:29:55 EST
Article-I.D.: auvax.416
Posted: Sun Nov 22 13:29:55 1987
Date-Received: Wed, 25-Nov-87 06:49:34 EST
References: <441*woslyng@arc.cdn> <2698@sphinx.uchicago.edu>
Organization: Athabasca U., Alberta, Canada
Lines: 62
Summary: what atari uses for serial chip(s)

In article <2698@sphinx.uchicago.edu>, cute@sphinx.uchicago.edu (John Cavallino) writes:
> In article <441*woslyng@arc.cdn> woslyng@arc.CDN (Fred Woslyng) writes:
> >Is is possible to connect an Atari 520 or 1040ST running a Macintosh 
> >emulator (such as Magic Sac) to a TOPS network?  
> The Macintosh serial ports are driven by a standard Zilog 8530 SCC on the
> motherboard. [...] Unless of course Atari ALSO uses said chip for
> THEIR serial ports. Anyone know?

Atari uses two different chips for serial i/o.  The modem port is
driven by a Motorola MC68901 "Multi-Function Peripheral" (MFP) chip,
while the midi port gets its bits from a Motorola MC6850
"Asynchronous Communications Interface Adaptor" (ACIA).  We can
essentailly forget about the midi port in this discussion because
1) it's clocked at a fixed rate and thus we can't tweak the baud to
match Appletalk & 2) it's an asynchronous-only part (ACIA, right ;-).

OK, now the MFP is a little more flexible than the ACIA.  We can get
it to run async up to 62.5 Kbps, and synchronously up to 1Mbps [an
aside: my source for _all_ this stuff is the Mostek MK68901 write-up
that came with my (otherwise almost *totaly* useless) Developer's
Kit.  Sure hope it's better than some of the other info; flame,
flame!!].

However, there's a rub (and I don't have my Zilog books handy, but
I'm pretty sure about this), and that's that the Z8350 is a fairly
clever little fellah and knows about things like HDLC bit stuffing
and framing, and how to generate/check CRC's on the fly, and station
address recognition, and a lot of other stuff which is good to be
handled by the serial chip rather than the CPU, especially in a
machine as lethargic as a Mac (well, a Mac's lethargic compared to a
Sun 3, and that's what I'm used to...) when you're in a network
environment and there's a lot of traffic on the backbone which isn't
addressed to you in particular, but you have to watch it all anyway
because some might be for you eventually.  Good grief, what a
horrible sentence!  But I think that's the case.  Whereas the 68901
can sync up to the input datastream and receive/xmit but it has no
idea of bit stuffing or CRC's or any of that good stuff.  Which
means somebody else (and it's not going to be the power supply,
foax) is going to have to supply the smarts.

Now assuming Appletalk is built on top of all the nice HDLC stuff
that the Z8350 manages so nicely (seems like a safe bet to me; I
would have done it that way myself, and Apple never puts hardware in
their machines that they don't use to the max), the MFP is at a bit
of a disadvantage.  The CPU is going to have to do all the clever
stuff; and I would expect the overhead to be pretty painful.
Especially all the bit stuffing; lots of shifting and masking and
partial-word assembly.  CRC's, on the other hand, are easy enough.
Still, the overhead gets you down, especially if there are other
stations out there on the net - the 68000 is standing there taking
interrupts off the 68901, checking the station address, finds the
packet's not for him, great - we can throw it away, but in the
meantime the user (that's US foax) is standin there waiting for a
compile to get done or whatever and its not going along very fast
:-(.  

Any Appletalk gurus out there?  I'm just looking at datasheets and
thinking about implementations and bottlenecks.  But it's for sure
the 68901 is not a very clever synchronous part at all, at all.

Ross Alexander, Athabasca University
alberta!auvax!rwa