Page 5 of 5
Re: Working around the W65C51 transmit buffer empty bug
Posted: Wed Dec 20, 2023 10:57 am
by BigDumbDinosaur
(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. 
Re: Working around the W65C51 transmit buffer empty bug
Posted: Thu Dec 21, 2023 9:29 pm
by John_M
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.