Is it OK to use a crystal (or crystal oscillator) other than 1.8432 MHz for the 6551 baud rate generator?

I just wired up my first ACIA (a W65C51N) and sent and received my first characters. I had to wire CTSB and DCDB to GND as noted elsewhere. I used a discrete crystal with 30pF load capacitors and the 1 MΩ resistor across the crystal. I used $8b in the Command register (No parity, echo or TX interrupt, RTS and DTR low) and $1f (1 Stop bit, 8 bit word, internal baud rate with a divisor of 96 for 19,200 baud) in the Control register. Interestingly, TDRE (the stuck bit) did go to 0 when TDR was written if CTS was left high (my chip is A6A749.1 1016G015, which is reported as having the bug).

Ideally I'd like to use 115,200 baud without being forced to choose a UART-friendly PHI2 frequency and then use the x16 divider with SBR 0000. I tried a 7.3728 MHz crystal and although 76,800 baud didn't work (possibly because my USB to serial adapter didn't like it), 38,400 using SBR 1110 worked nicely.

I'm hoping that a 11.0592 MHz crystal with SBR 1111 (divider = 96) will yield 115,200 baud. Would this work? And if it does, is there anything wrong with it?

It's not guaranteed to work with the higher-frequency crystal, so the thing to do would be to just try it (going beyond to make sure you have some margin and aren't sitting on the raggedy edge where it could quit working if the temperature is higher or something like that). 115,200bps is definitely within spec though for the external 16x clock. (Conveniently, 115,200 times 16 comes out to 1.8432MHz.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'm currently running my breadboard 65C02 system at 1.8432MHz and feeding that clock signal to the ACIA and as Garth suggests, using the 16x divider to get 115,200bps and is all works nicely. My clock signal is not very tidy, being on a breadboard and all, but it still works reliably. I'm using a Rockwell R65C52 DACIA, but I don't think that makes any difference.

Per the data sheet (which also highlights the stuck TDRE bit) the TDRE bit should go inactive (0) when CTSB goes high. In normal mode, CTSB is active (low) which enables transmitter operation. In this case, writing a character to the transmitter should result in the bit going to zero (meaning the TDR is not empty, i.e., it's transmitting a character). Once the character is transmitted, the bit should go active (normal operation), meaning it completed transmitting the character and is ready for another. The bad chip always shows the TDRE bit as active, meaning the chip is ready to send another character. This IS the problem. All existing software that controls the 6551 uses this bit to determine when another character can be transmitted. The stuck bit will force code to write the next character before the existing one is sent, which results in corrupted output from the 6551.

_________________
Regards, KM
https://github.com/floobydust

Thats interesting. Could it be possible to use CTSB to unlock the sticky TDRE?

If you connect an inverter (or a single MOSFET) between TxD and CTSB each time you start a transmission the startbit (and any other 0 within the data) would briefly negate CTSB but finally the stopbit would assert CTSB again. This should (re)enable the transmitter and perhaps even enable the TxEmpty IRQ (if enabled).

Perhaps you could give it a try?

It may be more stable with a can oscillator.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!