Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: ST @ 38400 baud???
Message-ID: <1517@atari.UUCP>
Date: 1 Jun 89 22:19:51 GMT
References: <43609a62.14a1f@gtephx.UUCP> <1506@atari.UUCP> <8551@chinet.chi.il.us> <665@stag.math.lsa.umich.edu>
Organization: Atari Corp., Sunnyvale CA
Lines: 29

In article <665@stag.math.lsa.umich.edu>, hyc@math.lsa.umich.edu (Howard Chu) writes:
> [38KBaud on an ST]

> It's easy. You need to call Rsconf to reset a bit in the UCR, then you need
> to reset the baud rate timer... Basically, when you use Rsconf to set the
> baud rate of the serial port, it always puts the UART in divide-by-4 mode.
> Reset that to divide-by-1, then you need to set the correct counter values
> in the timer [yes, it's Timer D] to get the
> baud rate you want. You can calculate them pretty easily...

Actually, the UART is in divide-by-16 mode, not divide-by-4.  Timer D is
running as fast as it can; *that* is where the divide-by-4 comes in.  If
you change the bit in the UART to divide-by-1, you disable certain
synchronization logic in the UART and reliability goes down the toilet. 
Talking to my VAX at 9600 with this trick, there is lots of noise.  19.2
is the pits, and I've hooked up two STs at 38 and it's unusable (too
many glitches). 

If you can do it and are satisfied with the results, more power to you. 
Personally, I would consider leaving the UART at divide-by-16 so the
synchronization logic works, and placing a different clock on the
68901's baud-rate inputs instead, but that involves finding a clock and
running a jumper, and makes the baud rate nonprogrammable.  (Just don't
put a different clock on the 68901's CLOCK input, since that controls
all the timers; there isn't a separate Timer D input.)

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt