🚀 go-pugleaf

>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