rs4u#@ANDREW.CMU.EDU (Richard Siegel) (04/09/87)
I've heard that the serial ports on the Mac (all machines) can communicate at up to a megabit (1024Kbaud??) per second, unclocked, and 230.4 KBaud, clocked (this is Appletalk speed, yes?). I'm interested in doing high-speed serial communications with some instrumentation, and I was wondering how to set the baud rate that high. Using SerReset only allows me to go up to 57.6 kbaud. On IM vol 2, page 254, a call is described that allows you to set the baud rate to any value, which is supplied as an *integer*, which limits me to 32K baud. I think. Is this true? How do I get the most speed out of the ports, in terms of baud rate? Thanks in advance for any help. -Rich
marct@crash.UUCP (04/11/87)
>In article <MS.V3.18.rs4u.80022e03.dorrance.ibm032.743.6@andrew.cmu.edu> rs4u#@ANDREW.CMU.EDU (Richard Siegel) writes: >> >> [ how can I write code that will use the serial ports on the mac at speeds >> higher than those allowed through the serial driver ? ] >> >>Thanks in advance for any help. >> >> -Rich > > >I wrote some code for the serial ports on the mac, and I would guess that what >you'ld have to do is either write a device driver, that would give you control >of the hardware registers on the SCC, or work your way into the current device >driver, but putting the address of your own routine in one of the interupt >dispatch tables. I don't know what the top speed of the SCC is but if you get >the appropriate hardware manuals for the SCC im sure you could find out. There is a VERY good article that describes how to directly access the Z8530 SCC chip. It is in MacTutor, Vol.2 No.1 Jan '86. pg. 34 The article describes the nine read-only registers, and the 16 write-only registers and how to access them from pascal (Modula 2 actually is what the source is given in, which makes for very readable code.) It also gives the Address for Zilog, Inc. Zilog, Inc. 1315 Dell Ave. Campbell, CA 95008 Attn: Publications Send $6 and ask for the Z8030/Z8530 SCC Serial Communications Controller Technical Manual, part number 00-2057-02. (I hope my english-teacher never sees that sentence :-) The MacTutor article also gives the low-memory globals location of the SCCRd and SCCWr pointers to the SCC chip registers. ( You will need these to be compatable with the SE & Mac// serial configurations.) Good luck - Marc Tamsky Sinners can repent, but stupid is forever. ARPA: crash!marct@nosc - Fortune Cookie INET: marct@crash.CTS.COM UUCP: {akgua, hplabs!hp-sdd, sdcsvax, nosc}!crash!marct
lee@wang.UUCP (04/13/87)
In article <8254@clyde.ATT.COM>, saf@moss.ATT.COM writes: > > Another way is to supply an external clock to the SCC (through the same wire > used for DSR). Note that you can never supply a clock of more than 4Mhz > because of limitations in the SCC chip itself, so this in and of itself > doesn't let you go faster, but it does allow you to use an external divider > and get all those non-standard baud rates you may need. This is what is > done for MIDI interfaces; the programmable divider is turned off, and an > external clock of 500kHz, 1MHz, or 2MHz is fed in. By choosing the > appropriate sampling divisor, the MIDI rate of 31.25kbaud is achieved. > > The only problem is that again, you can't do this with the standard driver, > you have to write your own. > Steve Falco AT&T Bell Laboratories The rest of Steve's posting seems impeccably accurate, but I must take issue with the comment that the standard driver won't support external clocking. Indeed, you have to retrieve the SCC's control address from low memory and poke the chip into "clock channel A from TRxC" and "divide-by-(16,32,64)", but having done so, I've had no trouble running MIDI data capture, filtering, rechannelizing and echoing utilities written entirely in Lightspeed Pascal (even the poking for setup is done in Pascal). The ROM serial driver of the Mac+ works fine and is remarkably efficient. I can't guarantee that the 64K ROM driver or the RAM driver work, but I suspect suspect that they do. Lee Story @ Wang Labs
saf@moss.ATT.COM (04/20/87)
> Indeed, you have to retrieve the SCC's control address from low memory and > poke the chip into "clock channel A from TRxC" and "divide-by-(16,32,64)", > but having done so, I've had no trouble running MIDI data capture, filtering, > rechannelizing and echoing utilities written entirely in Lightspeed Pascal > Lee Story @ Wang Labs Lee is entirely correct. You can use the existing driver with an external clock provided you poke the appropriate SCC hardware control register. My objection is that there is no IM call that does this for you in a portable way. Once you resort to hardware fiddling (either by my approach or Lee's), you have violated Apple's portability advice. There just doesn't seem to be any clean way to get high, non-standard baud rates "legally." Aside: The DEC machines often have two baud rates called Ext A and Ext B which are specifically for external clock support. Maybe Apple will provide that in a future release of the serial driver. Please. Steve Falco
huxham@apple.UUCP (Fred Huxham) (04/22/87)
>My >objection is that there is no IM call that does this for you in a portable >way. Once you resort to hardware fiddling (either by my approach or Lee's), >you have violated Apple's portability advice. There just doesn't seem to be >any clean way to get high, non-standard baud rates "legally." It is true that going directly to the hardware is "discouraged" and can cause upward incompatibilities. Yet it is also true that you must sometimes go directly to hardware to get adequate performance. I had to go directly to the SCC to write some network analysis software. Even though I broke the "rules" and went directly to the hardware, my software runs fine on MacPlus, MacSE, as well as the MacII. I did two things to ensure (as best I could), that my software would be compatible with future Mac architectures. (Oh, and by the way, I wrote the software before I came to Apple, so I didn't have any special inside information). 1) Get the base address of the SCC out of a low-memory global. This way, if on a new machine the chip moves you'll be ok. 2) Most code that talks directly with communication hardware has timing sensitive loops (at least mine did). Don't assume the speed of the CPU you're running on. At startup you can execute a DBRA loop a good number of times and see how long it takes you. From this you can calculate how fast your CPU is and adjust all of your timing sensitive loops accordingly. I hope these two tips help the .01% of the programmers that need to go directly to hardware. To the rest of you "Don't go to hardware directly" (Of course I have to say that). Fred
lsr@apple.UUCP (Larry Rosenstein) (04/22/87)
In article <648@apple.UUCP> huxham@apple.UUCP (Fred Huxham) writes: >2) Most code that talks directly with communication hardware has timing >sensitive loops (at least mine did). Don't assume the speed of the >CPU you're running on. At startup you can execute a DBRA loop a good number >of times and see how long it takes you. From this you can calculate how >fast your CPU is and adjust all of your timing sensitive loops accordingly. Inside Macintosh Volume V defines a new global variable called TimeDBRA, which defines the speed of the processor in this way. This is discussed in the Start Manager chapter. Larry -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.CSNET
stoltz%clem@Sun.COM (Ben Stoltz) (04/24/87)
In article <441@wang.UUCP> lee@wang.UUCP (Lee Story x77155 ms 019 890) writes: >In article <8254@clyde.ATT.COM>, saf@moss.ATT.COM writes: >> >> The only problem is that again, you can't do this with the standard driver, >> you have to write your own. >> Steve Falco AT&T Bell Laboratories > >The rest of Steve's posting seems impeccably accurate, but I must take issue >with the comment that the standard driver won't support external clocking. >Indeed, you have to retrieve the SCC's control address from low memory and >poke the chip into "clock channel A from TRxC" and "divide-by-(16,32,64)", >but having done so, I've had no trouble running MIDI data capture, filtering, >rechannelizing and echoing utilities written entirely in Lightspeed Pascal >(even the poking for setup is done in Pascal). The ROM serial driver of >the Mac+ works fine and is remarkably efficient. >I can't guarantee that the 64K ROM driver or the RAM driver work, >but I suspect suspect that they do. > > Lee Story @ Wang Labs I've done the same on my 512e(quivalent). RAMSDOpen followed by "clock channel A from TRxC" and "divide-by-(16,32,64)" works very well as long as you don't need your driver to time stamp the data (which I don't). Ben Stoltz stoltz@sun.com