FORTNEY@FNALB.BITNET (03/07/88)
Does anyone know of a way to connect an atari 1040 to an Appletalk network? Hardware and/or software? Please email a reply to FORTNEY@FNAL.bitnet. L. R. Fortney Physics Dept, Duke Univ.
uace0@uhnix2.UUCP (Michael B. Vederman) (03/15/88)
In article <8803071434.AA04788@ucbvax.Berkeley.EDU> FORTNEY@FNALB.BITNET writes: > > Does anyone know of a way to connect an atari 1040 to an Appletalk >network? Hardware and/or software? > Please email a reply to FORTNEY@FNAL.bitnet. >L. R. Fortney >Physics Dept, Duke Univ. Unfortunately, this cannot be done with the ST as it stands without external hardware (probably thru the DMA port). The reason for this is that the AppleTalk network uses a baud rate far greater than the ST can produce. - Mike -- for (;;) : Use ATARINET, send an interactive do_it(c_programmers); : message such as: : Tell UH-INFO at UHUPVM1 ATARINET HELP University Atari Computer Enthusiasts : University of Houston UACE
david@bdt.UUCP (David Beckemeyer) (03/18/88)
In article <8803071434.AA04788@ucbvax.Berkeley.EDU> FORTNEY@FNALB.BITNET writes: > > Does anyone know of a way to connect an atari 1040 to an Appletalk >network? Hardware and/or software? I hate to spread rumors but... I hear that Supra has designed a prototype of a board that plugs into the HD DMA port and implements AppleTalk. If enough people hound them about it, they might see fit to introduce it as a product. Disclaimer: I am in no way affiliated with Supra Corp. -- David Beckemeyer | "To understand ranch lingo all yuh Beckemeyer Development Tools | have to do is to know in advance what 478 Santa Clara Ave, Oakland, CA 94610 | the other feller means an' then pay UUCP: ...!ihnp4!hoptoad!bdt!david | no attention to what he says"
wes@obie.UUCP (Barnacle Wes) (03/24/88)
In article <512@uhnix2.UUCP>, uace0@uhnix2.UUCP (Michael B. Vederman) writes: > Unfortunately, this cannot be done with the ST as it stands without external > hardware (probably thru the DMA port). The reason for this is that the > AppleTalk network uses a baud rate far greater than the ST can produce. Not true. The MIDI port can be easily driven at 500K bps, much faster than Apple's LocalTalk hardware, which is essentially an RS-422. If you play with the baud rate generator on the RS232 port, you might be able to get the kind of speed LocalTalk uses. The ST's RS232 port is driven off the USART built into the 68901 MFP chip. The clock for this USART is Timer D on the 68901. By programming the 68901 carefully, using the Timer D registers and the USART Conrtrol REgister (bit 7), you _might_ be able to build a LocalTalk connector. Software to use it is quite another question :-). Wes Peters -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes
jack@cwi.nl (Jack Jansen) (03/28/88)
In article <85@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >In article <512@uhnix2.UUCP>, uace0@uhnix2.UUCP (Michael B. Vederman) writes: >> Unfortunately, this cannot be done with the ST as it stands without external >> hardware (probably thru the DMA port). The reason for this is that the >> AppleTalk network uses a baud rate far greater than the ST can produce. > >Not true. The MIDI port can be easily driven at 500K bps, much faster >than Apple's LocalTalk hardware, which is essentially an RS-422. If >.... This is not the only problem. The main problem is that the UART used in the apple (don't remember the number. I seem to recollect that it's a Zilog chip) is a very nifty little device. Among other features, it can be programmed to generate NRZ output in stead of straight binary. [NRZ is an encoding scheme where a "1" bit is encoded as 1 transition, and a "0" bit as 2 transitions, like this: Data 0 0 1 0 1 1 Normal _________----____-------- NRZ _--__--__----__--____---- ] This is crucial for appletalk: the appletalk connector box is merely a bunch of transformers wired as a fork. This has two advantages: - You don't hear yourself talking. - All machines are completely galvanically separate from the cable, but you don't have to power the cable (as you would have to do in case of using optocouplers. Now, using transformers makes it next-to-impossible to use normal binary: you would never be able to reconstruct the signal after it has passed through two transformers: the phase-shift would differ per bit. No such problems with NRZ encoding, however: the only frequencies used are F and 2F (if you send at F baud), so a low-pass filter will convert you signal to almost-sine-waves, which can be turned into squares again at the receiving side. Thinking up the hardware to convert normal binary to NRZ is left as an exercise to the reader. Oh yes, and tell me if you find a scheme that'll cost less than, say, $10 and can be powered from the MIDI port:-( -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
davidli@umn-cs.cs.umn.edu (Dave Meile) (03/29/88)
As a point of information to those seeking some sort of "asynchronous
AppleTalk" (gotta be a tradmark here somewhere...):
"Asynchronous AppleTalk(tm) was first developed at Dartmouth College by
Rich Brown and Steve Liggett of the Kiewitt Computing Center. It was
developed in order to provide AppleTalk service to campus offices which
could not be directly connected to an AppleTalk(tm) bus or just required
the mobility of dial-in service."
"The technique is simple really, just remove the normal AppleTalk Link
Access Protocol drivers and replace them with a clever piece of code
which imposes some very simple handshaking and address verification, then
transmits AppleTalk packets asynchronously to what it believes is a bridge.
The bridge then routes the packets according to the destination ID (or
broadcasts the pacet). Although the Dartmouth system utimately joins
with normal 230Kbps AppleTalk buses, in no way is this necessary to
enjoy the benefits of such a well-supported LAN system."
"The Sand Hill reactor operates somewhat like an AppleTalk bridge, but
assumes that there are only asynchronous AppleTalk devices; devices that
are termed 'semi-formal' which are addressable from other reactors but
speak no flavor of AppleTalk (such as PC's, modems, printers, etc.); and
devices which are not addressable from the extended network"
(From TECHNICAL NOTES ON ASYNCHRONOUS APPLETALK AND THE SAND HILL NETWORK
REACTOR)
So, it CAN be done (HAS been done). The "trick" however is that in order
to use AppleTalk on an ST you'd have to LICENSE the AppleTalk Protocols
from Apple (or writer your own -- good luck)
Truly interested persons can write to me for the address of the authors
of the TECHNICAL NOTES. (I am in no way connected with Dartmouth or the
authors, but the information is of interest here, and I *do* own a Magic
Sac :-) )