murray@jumbo.dec.com (Hal Murray) (03/28/89)
AppleTalk runs at 256K bits/second. I was expecting the vanilla serial driver to be able to go as fast. I connected the send side of the modem port back to the receiver and wrote a simple test program that uses ASYNC writes and simple/sync reads. It starts a write. Then, while polling for the write to finish, it reads whatever is available. At 19.2K it works as expected: I get almost the full speed when sending to myself. I do go around the poll/read loop several times for each send and I receive all the characters I send. The send side is only single buffered, but each buffer is 1000 characters so the gaps before starting another send don't mess up the timings much. When I turn the clock speed up to 56K, things no longer do what I want. It acts like the interrupts are using the whole CPU: mouse tracking goes crazy and the send is already finished when it returns. I haven't hooked up a scope to see how fast the characters are actually going out, but my program prints out 30K bits/second. When I unplug the echo jumper, I do go around the polling loop and the mouse is happy. (But of course, I don't receive anything.) Am I missing something dumb? How does AppleTalk work? Does an SE get real sluggish when sending or receiving an AppleTalk packet? What I want to do is grab several (say 6 to 10) seconds of data as fast as I can without missing any characters. They will all fit into memory. I'm willing to disable all interrupts if necessary. I can process the info after collection. Is there some easy way to do this, and/or how fast can I go with the normal driver? I've worked with the SCC chip before, so writing a non-interrupt polling loop shouldn't be too hard. The data I want to grab is coming from an A/D. I'm building the hardware myself. It only takes 3 or 4 chips to serialize and level convert so that seemed like a reasonable way to go. Would the SCSI port be simpler at these speeds? I've never worked with either the SCSI hardware or software.
han@Apple.COM (Byron Han, wyl E. coyote ) (03/29/89)
In article <13655@jumbo.dec.com> murray@jumbo.dec.com (Hal Murray) writes: >AppleTalk runs at 256K bits/second. I was expecting the vanilla serial >driver to be able to go as fast. "How fast could a woodchuck chuck wood if a woodchuck could chuck wood." I have a copy of the Macintosh (R) Family Hardware Reference. Chapter 12 has a section on the SCC (serial communications controller). AppleTalk can operate at 256KBits/second because it is not interrupt driven and when the AppleTalk driver is running, it has complete control over the Macintosh. Serial drivers are limited to a theoretical limit of 500kbaud with external clocking and the serial driver having complete uninterrupted control of the Macintosh. Nominally, you can probably get 57.6Kbaud with the standard serial driver The Hardware Family Reference is an Addison Wesley book and contains lots of interesting tidbits of information. Hope this helps. +-----------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-----------------------------------------------------------------------------+ Byron Han, Communications Architect Cereal, anyone? :-) A1! Apple Computer, Inc. ------------------------------------- 20525 Mariani Ave, MS27Y Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han -------------------------------------- GENIE: BYRONHAN ATTnet: 408-974-6450 Applelink: HAN1 CompuServe: 72167,1664 ------------------------------------------------------------------------------
poynton@vector.Sun.COM (Charles A. Poynton) (03/30/89)
The official documentation states that AppleTalk runs at 230.4 kb/s, a nice even multiple of 9600 b/s. Macintosh Family Hardware Reference Manual says that the AppleTalk driver runs the SCC timed with a 3.672 MHz clock, which the SCC divides by 16 to obtain the bit rate. This does not divide out to 230.4 kb/s. I suspect that the figure should be 3.6864 MHz, which is the dot clock of the video circuitry (exactly 15.6672 MHz) divided by four and a quarter. Sorry, I can't help you with the software issues, but as Byron Han points out, AppleTalk communications are not interrupt driven: the AppleTAalk driver takes over the machine. C. ----- Charles A. Poynton Sun Microsystems Inc. <poynton@sun.com> 2550 Garcia Avenue, MS 8-04 415-336-7846 Mountain View, CA 94043 -----
alexis@ccnysci.UUCP (Alexis Rosen) (04/07/89)
In article <28021@apple.Apple.COM> han@Apple.COM (Byron Han, wyl E. coyote ) writes: >AppleTalk can operate at 256KBits/second because it is not interrupt driven >and when the AppleTalk driver is running, it has complete control over the >Macintosh. > >Serial drivers are limited to a theoretical limit of 500kbaud with external >clocking and the serial driver having complete uninterrupted control of the >Macintosh. > >Byron Han, Communications Architect ^^^^^^^^^^^^^^^^^^^^^^^^ It is with great trepidation that I venture to correct a man with such a title on a subject like AppleTalk, but here goes... :-) Minor nitpick: I thought AppleTalk ran at 230.4 kbps. Major nitpick: Both TOPS and Dayna would be surprised to hear that their FlashTalk and DaynaTalk products, which run at 768 to 850 kbps, can't ever go faster than 500 kbps. I was also under the impression that the old serial hard disks (Tecmar, Davong, MacBottom) could do close to 1Mbps, but that's a long time ago... --- Alexis Rosen alexis@ccnysci.{uucp,bitnet}
phil@Apple.COM (Phil Ronzone) (04/08/89)
In article <1514@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes: Discusssion about LocalTalk and seriol I/O data rates. >Major nitpick: Both TOPS and Dayna would be surprised to hear that their >FlashTalk and DaynaTalk products, which run at 768 to 850 kbps, can't >ever go faster than 500 kbps. The SCC has a clock MAXIMUM of 4 MHz (unless we have changed to a faster part lately). The SCC is clocked for baud rate generation at 3.673 MHz. AppleTalk, which uses SDLC phsyical transmission, runs as FM0 using the onboard PLL -- thus, at around 4MHZ, 230.4 KB is the fastest you can run the machine. In serial I/O, you need to sample at 16X the baud rate. The limiting factor is the divisor given to divide the clock rate and still sample at 16X. The SCC is a pretty interesting USUART, but for the current clock rates, SDLC in FM0 can't go faster than 230.4KB -- serial I think (can't remember) can be pushed to twice that. +------------------------+-----------------------+----------------------------+ | Philip K. Ronzone | A/UX System Architect | APPLELINK: RONZONE1 | | Apple Computer MS 27AJ +-----------------------+----------------------------+ | 10500 N. DeAnza Blvd. | Computer viruses don't cause security problems, | | Cupertino CA 95014 | computer programmers do ... | +------------------------+----------------------------------------------------+ |{amdahl,decwrl,sun,voder,nsc,mtxinu,dual,unisoft}!apple!phil | +-----------------------------------------------------------------------------+
paul@taniwha.UUCP (Paul Campbell) (04/08/89)
In article <28564@apple.Apple.COM> phil@Apple.COM (Phil Ronzone) writes: >In article <1514@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes: > >Discusssion about LocalTalk and seriol I/O data rates. > >>Major nitpick: Both TOPS and Dayna would be surprised to hear that their >>FlashTalk and DaynaTalk products, which run at 768 to 850 kbps, can't >>ever go faster than 500 kbps. > >The SCC has a clock MAXIMUM of 4 MHz (unless we have changed to a faster >part lately). The SCC is clocked for baud rate generation at 3.673 MHz. >AppleTalk, which uses SDLC phsyical transmission, runs as FM0 using the >onboard PLL -- thus, at around 4MHZ, 230.4 KB is the fastest you can run >the machine. > >In serial I/O, you need to sample at 16X the baud rate. The limiting >factor is the divisor given to divide the clock rate and still sample at 16X. > >The SCC is a pretty interesting USUART, but for the current clock rates, >SDLC in FM0 can't go faster than 230.4KB -- serial I think (can't remember) >can be pushed to twice that. Hi Phil, Alexis .... actually there are 2 limits in what the SCC can do, - one is the max speed at which the SCC can be clocked at, either externally (using the clock inputs) or derived from the internal clock (3.672 or whatever). I've driven SCCs at 1MHz output from an internal 4MHz clock. For stnchronous reception you either need an external synchronized clock (direct from the remote transmitter or from an external PLL [ie the external FlashTalk or DaynaTalk boxes]) which is derived from the received signal or from the internal PLL which brings us to the second limit: - the internal PLL can't run at much above 230.4 (this magic number comes from the SCC's clock rate which in turn is designed to generate 9600 and all the other baud rates correctly when divided down) because it has to run at 1/16 the SCC's clock rate (which is fixed in the Macs design) in order to do clock recovery hence the confusion Paul -- Paul Campbell, Taniwha Systems Design, Oakland CA ..!mtxinu!taniwha!paul
alexis@ccnysci.UUCP (Alexis Rosen) (04/14/89)
In article <28564@apple.Apple.COM> phil@Apple.COM (Phil Ronzone) writes: >In article <1514@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes: >> [...] Both TOPS and Dayna would be surprised to hear that their >>FlashTalk and DaynaTalk products, which run at 768 to 850 kbps, can't >>ever go faster than 500 kbps. Just to clarify things: The FlashTalk product definitely does 768Kbps. (There are lots of nasty reasons you don't see 3x speedups on appletalk, but the raw data goes out at that speed [except LAP packet enclosures]). >The SCC has a clock MAXIMUM of 4 MHz (unless we have changed to a faster >part lately). The SCC is clocked for baud rate generation at 3.673 MHz. >AppleTalk, which uses SDLC phsyical transmission, runs as FM0 using the >onboard PLL -- thus, at around 4MHZ, 230.4 KB is the fastest you can run >the machine. > >In serial I/O, you need to sample at 16X the baud rate. The limiting >factor is the divisor given to divide the clock rate and still sample at 16X. > >The SCC is a pretty interesting USUART, but for the current clock rates, >SDLC in FM0 can't go faster than 230.4KB -- serial I think (can't remember) >can be pushed to twice that. Hm. Something I don't know about. What is "FM0" in this context? Anyway (not that I mind the posting, but), what has this to do with the original message? I guess we are just drawing a distinction between what can be done with just a cable, and what you need a sync separator to do. --- Alexis Rosen alexis@ccnysci.{uucp,bitnet}
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (04/15/89)
In article <1581@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes: ->The SCC has a clock MAXIMUM of 4 MHz (unless we have changed to a faster ->part lately). The SCC is clocked for baud rate generation at 3.673 MHz. make that 3.6864 MHz ->AppleTalk, which uses SDLC phsyical transmission, runs as FM0 using the SDLC Framing... ->onboard PLL -- thus, at around 4MHZ, 230.4 KB is the fastest you can run ->the machine. ->In serial I/O, you need to sample at 16X the baud rate. The limiting ^asynchronous ->factor is the divisor given to divide the clock rate and still sample at 16X. ->The SCC is a pretty interesting USUART, but for the current clock rates, ->SDLC in FM0 can't go faster than 230.4KB -- serial I think (can't remember) ->can be pushed to twice that. Synchronous data can run at clock/4, or 921.6 Kbps, with an External clock. The limiting factor is the internal state machine in the SCC, which needs at least 4 clocks per bit to move things about. >Hm. Something I don't know about. What is "FM0" in this context? FM (biphase) coding is a coding scheme wherein there is a change of state (mark to space or space to mark) at the boundaries (beginning and end of each bit timing cell), and, for FM0, a change of phase in the middle of the cell for '0' bits. For FM1, '1' bits get a change in the middle. If you think of FM as Frequency Modulation, you will see that a stream of '1's is a square wave at 115.2 KHz, and a stream of '0's is a square wave at 230.4 KHz. Digital phase lock loops work very reliably on such stuff. There is such a DPLL in the SCC. BTW: the SCC can also lock on "REAL" SDLC (the NRZI kind) but the frequency spectrum is not as tight, so it's harder to put through transformers. Marc Kaufman (kaufman@polya.stanford.edu)