Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!rutgers!ames!oliveb!pyramid!voder!apple!huxham From: huxham@apple.UUCP (Fred Huxham) Newsgroups: comp.sys.mac Subject: Re: Programming for High Baud Rates Message-ID: <648@apple.UUCP> Date: Tue, 21-Apr-87 20:55:20 EST Article-I.D.: apple.648 Posted: Tue Apr 21 20:55:20 1987 Date-Received: Thu, 23-Apr-87 04:48:51 EST References: <441@wang.UUCP> <8602@clyde.ATT.COM> Reply-To: huxham@apple.UUCP (Fred Huxham) Organization: Secret Projects Group, Apple Computer Inc., Cupertino, USA Lines: 33 Keywords: SCC, programming, compatibility, yuck >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