Working around the W65C51 transmit buffer empty bug

[BigDumbDinosaur]

barnacle wrote:

(It also occurs to me that I’ve almost never relied on interrupts for tx anyway; rx, yes, usually to a buffer, but I tend to use a blocking transmit.)

I’m the other way around.

Way, way, way back when I did use the 6551 (the original, not the current broken one), I decided I was going to use IRQs in both directions and plugged away at it until I had a “foolproof” driver.  The old 6551 worked very well that way, despite its brain-dead design, and despite not having receive and transmit FIFOs.  System throughput actually got better when short bursts of output (<254 datums) were needed, since the foreground wouldn’t get stalled waiting on the UART to do its business.  I always gave priority to the RxD IRQ, since an overrun was always a threat at high bit rates. 

[John_M]

BigDumbDinosaur wrote:

Way, way, way back when I did use the 6551 (the original, not the current broken one), I decided I was going to use IRQs in both directions and plugged away at it until I had a “foolproof” driver.

I posted my first attempt at a driver along with my current schematic on the previous page, though I'm sure it's anything but foolproof. It's the W65C51.s attachment - with all the comments it's already too big to include inline. I believe I have to maintain a flag that tracks whether the transmitter is busy or idle; the IRQ handler clearing the flag to idle if it finds the Tx buffer empty and the user 'serial_sendchar' subroutine setting the flag to busy again. The Rx code is simpler and, I agree, ought to be the higher priority of the two.

I'll be away for the next ten days or so visiting family, so no more tinkering for a while. However you celebrate this time of year, I wish you all a happy and peaceful time.