Working around the W65C51 transmit buffer empty bug

[akohlbecker]

Interesting approach! Agreed that it is a lot of chips and it might be more practical to replace the 65C51 with something else (have you looked at the 16C550C in DIP?), but we're here to have fun not be practical!

If you enable receiver interrupts, you should also get interrupts for transitions on DSRB. So this means that you can have interrupt-driven communications in both directions - which is a good thing because it frees up your BIOS to do other things. I don't believe DSRB interrupts would be impacted by the bug, but your mileage may vary, I haven't tried it.

By the way, I recommend reading Rockwell's datasheet for their version of the ACIA (R6551), as it is much more detailed. Specifically, they have a recommended flow for interrupt handling, see page 6-178, Status Register Operation, below.

[AlanCanon]

AndrewP wrote:

Hey Alan, that's me who was chatting to you on YouTube. Good catch on needing to divide the 1.8432Mhz signal down.

Just to make sure I'm understanding. You're using the bottom set of jumpers to select the baud rate and the top set of jumpers to select the total number of bits?

Yep, that's the idea.

AndrewP wrote:

Also if you're feeling industrious in the future you could swap out the top jumpers for a '573 latch and make the bit count programmable by the 6502. If you're even more industrious you could swap out the bottom jumpers for another latch and the NAND gate U6A for a '521 comparator; feeding both the latch and the '590 counter into the comparator. You could alternatively swap out the '590 counter for two presettable latches and load them from a latch to make a programmable frequency divider.

Of course at this point there are enough discrete ICs knocking around you could just about throw out the 65C51 and replace it with a couple of shift registers... Right, that's enough rambling from me.

Cheers,
Andrew

YES, I am already thinking along those lines, I could trap writes to the command and control registers and set the latches up to count any baud divisor, any transmission unit length. And you're right about just adding shift registers and rolling my own UART (excuse me ACIA) but I'm sort of entertained by the idea of festooning the buggy 65C51 with a billion add-on chips until, at the end, I just delete the 65C51 from the schematic and the processor never knows the difference. It'd be the perfect way to put a definitive end to people (like me) bellyaching about how bad the ACIA is! ("You mean, you didn't just replace the entire functionality with a separate circuit?!")

I don't know if I'll ever be brave enough to order a PCB based on my schematics, but I'm having a blast learning Kicad and creating schematics as part of my learning process as I study the Ben Eater (and Adrien Kohlbecker) videos. At this point I have half a mind to reproduce the Ben Eater 8 bit breadboard computer, but using only 74HC138 3 to 8 decoders (on the back of a napkin, I figured out how you can hotwire one to be a NAND or NOR gate, and since the Apollo Guidance Computer was made exclusively out of NORs, that should be all that anyone ever needs to land on the moon again).

[AlanCanon]

akohlbecker wrote:

Interesting approach! Agreed that it is a lot of chips and it might be more practical to replace the 65C51 with something else (have you looked at the 16C550C in DIP?), but we're here to have fun not be practical!

If you enable receiver interrupts, you should also get interrupts for transitions on DSRB. So this means that you can have interrupt-driven communications in both directions - which is a good thing because it frees up your BIOS to do other things. I don't believe DSRB interrupts would be impacted by the bug, but your mileage may vary, I haven't tried it.

By the way, I recommend reading Rockwell's datasheet for their version of the ACIA (R6551), as it is much more detailed. Specifically, they have a recommended flow for interrupt handling, see page 6-178, Status Register Operation, below.

Yes about the fun and not practicality. Thank you so much for the BB816 videos, they have been incredibly entertaining and educational, just like the Ben Eater series. I'm putting a lot of effort into my BB816 breakout-based quad core 65816 project, Vega816, inspired by both your videos and personal encouragement that you have offered me. I was 13 when the Commodore 64 debuted, and one pleasure of this hobby is that it puts me back underneath the Christmas tree in 1983, reading the C64 Programmer's Reference Manual guide to 6510 assembly, and realizing, with a shock, that I now understood something very important about what a computer is and how it works.

People have gone to great lengths to replicate C64 elements like the SID and VIC-II (I am incorporating their work into my design, and in particular I am thinking about how a VIC-II style chip could boss the clock of my design to get done what it needs to). So why on earth shouldn't we come up with a 12 chip design that replaces the ACIA, pin for pin! We could even produce a schematic that replicates the W65C51N bug, for the purists! All of this has to be on a large circuit board that has a riser underneath it so you can pop it into any 6551 holder. And one jumper to set whether you want the transmission bug or not!

Here's a schematic with both your and Ben's ACIA circuits on it. I put an OR gate so that the ACIA can listen in on both yours and Ben's lines at once, and I fork the transmission line so that the ACIA can blast serial out over DB9 RS-232 and I2C at the same time. It is 2023, not 1983, and desperate times call for desperate measures. We need to act quickly before IBM and Apple come to dominate the PC market.

Thanks for endorsing the 16C550C, I will look into it. I've been going for new through-hole parts, because that's all I know how to solder, but I can see bending the rules to make an effective UART solution. I will also read the Rockwell datasheet you attached. I'm compelled by the idea that the DSR transitions can trigger interrupts on the receive side.

I have a Vector Pull rewrite module in schematic, with an 8to3 priority encoder, so I can have up to 8 different interrupt vectors, including a facility to turn my IRQ7 into an NMI. A programmable interrupt controller with a single memory mapped register allows software control of interrupt priority and CPU destination (for my quad core 65816 scenario).

[akohlbecker]

Glad to have been an inspiration, keep at it and you'll have your PCB made in no time!

Note that the 16C550C is still available new in dip at reichelt, but it might be old stock so not sure for how long. Still that UART powered so many actual PC serial cards that you can probably find it used anywhere.
https://www.reichelt.nl/nl/en/texas-uar ... GE=EN&&r=1. One good thing about it is it has auto hardware flow control and FIFOs, making more efficient use of the CPU time.

[BigDumbDinosaur]

akohlbecker wrote:

One good thing about [the 16550C] is it has auto hardware flow control and FIFOs, making more efficient use of the CPU time.

That is also true of the NXP/TI/Exar 26/88-series of UARTs. Plus these UARTs have dual channels and a precision timer, the latter which is something that is not in the 1655x series. Also, the UARTs offer general-purpose I/O that can be used for out-of-band signaling, IRQ steering (I use that feature in POC V1.3’s firmware), or other purposes.

Exar’s 88C92 is available from stock in PLCC44. If one is going to go with a UART other than the 6551, the 88C92 makes a lot more sense. If you’re up to it, you could use Exar’s 88C192 or TI’s 28L92—the two devices are functionally equivalent and are in a QFP package, to make a plug-in module that could replace the 6551.

Whatever the case, I view attempts to use the WDC 65C51 as flogging a horse that is not only dead, but is in an advanced state of decomp.

[AlanCanon]

AndrewP wrote:

Also if you're feeling industrious in the future you could swap out the top jumpers for a '573 latch and make the bit count programmable by the 6502. If you're even more industrious you could swap out the bottom jumpers for another latch and the NAND gate U6A for a '521 comparator; feeding both the latch and the '590 counter into the comparator. You could alternatively swap out the '590 counter for two presettable latches and load them from a latch to make a programmable frequency divider.

Cheers,
Andrew

Done, check it out! I use EEPROMS to replace combinatorial logic based on the line discipline settings, which I intercept with latches when there are writes to the command and control registers.

One thing it doesn't handle correctly is baud rate = 0000, i.e. 1/16 External Clock, but that would be easy to fix.

I just don't see why people complain about the W65C51N, it's a perfectly good UART if you simply add 14 support chips to work around the transmit bug!

[plasmo]

I have a design using W65C51. I run the serial port at 115200 and use software delay loop. It may seem inefficient but each byte takes 0.01% of CPU resource to transmit so it is not too costly.
Bill

[AlanCanon]

BigDumbDinosaur wrote:

akohlbecker wrote:

One good thing about [the 16550C] is it has auto hardware flow control and FIFOs, making more efficient use of the CPU time.

That is also true of the NXP/TI/Exar 26/88-series of UARTs. Plus these UARTs have dual channels and a precision timer, the latter which is something that is not in the 1655x series. Also, the UARTs offer general-purpose I/O that can be used for out-of-band signaling, IRQ steering (I use that feature in POC V1.3’s firmware), or other purposes.

Exar’s 88C92 is available from stock in PLCC44. If one is going to go with a UART other than the 6551, the 88C92 makes a lot more sense. If you’re up to it, you could use Exar’s 88C192 or TI’s 28L92—the two devices are functionally equivalent and are in a QFP package, to make a plug-in module that could replace the 6551.

Whatever the case, I view attempts to use the WDC 65C51 as flogging a horse that is not only dead, but is in an advanced state of decomp.

I spent the afternoon taking your advice. Here's a schematic for 3 VIAs and an 88C192, with both Ben and Adrien's serial circuits that previously depended on the 65C51. The four devices are mapped into a contiguous 64 bytes of memory.

I'm thinking of one VIA just to handle hardware registers to control my 65816 build, a second one to do the front console display and switches (like Ben's 6502 does), and a third one just for whatever people want to use it for.

The two serial ports should be sufficient for a teletype and/or high speed paper tape reader. It would be possible to adapt my schematic pretty easily for any combination of four VIAs/UARTs. (2 VIAs, 2 UARTs, 4 UARTS, etc). At 16 bytes of register space per UART, 2 serial channels per UART, one page of address space could manage 32 modems, which would make for a fairly killer dialup BBS setup. Filling the top 255 banks of the 65816's address space with UARTs allows up to 2,088,960 serial devices, which ought to be enough for anybody.

[gfoot]

I guess another option if you really want to use the 65C51 is to only use it for receiving data, and build your own transmit circuit that already includes an interrupt source. I did most of the latter for a YouTube video last year, to form a simple low-tech way of getting data off the computer - the idea being that a singe CPU instruction can send a byte of data (assuming the wire is clear - it's up to the CPU not to send anything else for a while). In particular, no registers to set up before being able to send data - the circuit just works on its own. It is very simple, it seems a lot fewer chips than are needed to work around the 65C51's built-in transmit circuit - but it only supports one output format. It doesn't directly provide the interrupt source but you could pretty easily do that through a 6522 I think, maybe adding a counter or using one of the timers on the 6522 to count the bits.

Here's the schematic for my circuit, it's pretty simple:

The counter on the left (U1) is dividing the system clock to generate a pulse at the desired baud rate. The flipflop (U3B) is resetting the circuit when the CPU sends data. The register (U2) holds the value the CPU wants to send, while the start bit is sent. The shift register (U4) shifts the bits out including the start bit and stop bits (which last forever).

[BigDumbDinosaur]

AlanCanon wrote:

I spent the afternoon taking your advice. Here's a schematic for 3 VIAs and an 88C192...

Could you please post schematics in monochrome?

[akohlbecker]

BigDumbDinosaur wrote:

akohlbecker wrote:

One good thing about [the 16550C] is it has auto hardware flow control and FIFOs, making more efficient use of the CPU time.

That is also true of the NXP/TI/Exar 26/88-series of UARTs. Plus these UARTs have dual channels and a precision timer, the latter which is something that is not in the 1655x series. Also, the UARTs offer general-purpose I/O that can be used for out-of-band signaling, IRQ steering (I use that feature in POC V1.3’s firmware), or other purposes.

Exar’s 88C92 is available from stock in PLCC44. If one is going to go with a UART other than the 6551, the 88C92 makes a lot more sense. If you’re up to it, you could use Exar’s 88C192 or TI’s 28L92—the two devices are functionally equivalent and are in a QFP package, to make a plug-in module that could replace the 6551.

Whatever the case, I view attempts to use the WDC 65C51 as flogging a horse that is not only dead, but is in an advanced state of decomp.

I've been looking at the datasheet for the SC28L92 and I have a question about auto flow control, asking you here since you're the resident expert on those chips. The datasheet says:

Quote:

RxRTS = 1 causes RTSAN to be negated (OP0 is driven to a
logic 1 [V CC ]) upon receipt of a valid start bit if the channel A FIFO is
full. This is the beginning of the reception of the 9th byte. If the FIFO is
not read before the start of the 10th or 17th byte, an overrun condition
will occur and the 10th or 17th or 17th byte will be lost.

My concern is FTDI USB-to-UARTs will actually send more bytes after RTS is negated, up to 3 or 4 I think depending on where it is in the USB packet (can't find this in the datasheet at the moment but I know I read it somewhere). Am I right to interpret the above as when the UART is set to 16 bytes FIFOs (FIFOSIZE = 1), it will negate RTS after the start of the 9th byte, leaving up to the 17th byte of margin? Or is this an omission in the datasheet, and RTS will be negated at the 17th byte in that setting? I find it curious that the statement above does not mention the fifo size.

[akohlbecker]

Ah yes, from https://www.ftdichip.com/old2020/Support/FAQs.htm

Quote:

If CTS# is logic 1 it is indicating the external device cannot accept more data. the FTxxx will stop transmitting within 0~3 characters, depending on what is in the buffer.

This potential 3 character overrun does occasionally present problems. Customers shoud be made aware the FTxxx is a USB device and not a "normal" RS232 device as seen on a PC. As such the device operates on a packet basis as opposed to a byte basis.

Which means I need to ensure at least 3 bytes of buffer space when RTS is pulled up by the UART.

[BigDumbDinosaur]

akohlbecker wrote:

I've been looking at the datasheet for the SC28L92...The datasheet says:

Quote:

RxRTS = 1 causes RTSAN to be negated (OP0 is driven to a logic 1 [V CC ]) upon receipt of a valid start bit if the channel A FIFO is full. This is the beginning of the reception of the 9th byte. If the FIFO is not read before the start of the 10th or 17th byte, an overrun condition will occur and the 10th or 17th or 17th byte will be lost.

My concern is FTDI USB-to-UARTs will actually send more bytes after RTS is negated, up to 3 or 4 I think depending on where it is in the USB packet (can't find this in the datasheet at the moment but I know I read it somewhere). Am I right to interpret the above as when the UART is set to 16 bytes FIFOs (FIFOSIZE = 1), it will negate RTS after the start of the 9th byte, leaving up to the 17th byte of margin?

Unfortunately, NXP’s data sheets leave something to be desired in lucidity. They apparently suffer from Dutch-to-English translation problems, which was a problem I have noted since the earliest days in which I’ve worked with their UARTs (over 30 years).

In the event the FIFO is full and a new start bit is detected, RTS will be deasserted within a few X1 clock cycles (I believe four cycles). As the receiver holding register can buffer one datum, the remote station effectively has one datum’s time to react to its CTS being deasserted. This will work out with any device that has its flow control logic entirely in hardware. It sounds as though this is not the case with the FTDI device.

BTW, I discovered that the US Robotics Sportster modem is also a laggard with responding to CTS. That modem has a microcontroller at its core, so it is likely the reaction to CTS is something that occurs in software.

I used to rely solely on auto-RTS, but after the discovery with the modem, I added some code to the reception part of my POC unit’s DUART driver to “manually” deassert RTS when the receiver circular queue (RXQ) is filled to approximately 90 percent. That takes care of the case in which there is incoming data flow, but the foreground is not fetching data from RXQ. As well, I’ve left the auto-RTS feature enabled as a last-resort measure in case IRQs are disabled, as there would be no servicing of incoming data and the FIFO would soon overflow.

[SamCoVT]

akohlbecker wrote:

My concern is FTDI USB-to-UARTs will actually send more bytes after RTS is negated, up to 3 or 4 I think depending on where it is in the USB packet (can't find this in the datasheet at the moment but I know I read it somewhere).

I ran into this issue on my SBC using an FTDI USB->Serial cable and ended up using Garth's interrupt driven receive for the 65C51 (essentially a software 256 byte FIFO) and I de-assert RTS when there are 16 bytes left. This has worked very reliably with all of the USB->Serial adapters I have including FTDI and Prolific chips and I commonly transmit 20K to 100K files over to my board in plain text (eg. no additional error detection/correction). Some of these are tests for Tali Forth 2 that take a second or two to run, so it's definitely using the handshaking a lot.

This information about the extra bytes when handshaking is not in the datasheet and is getting harder to find as it's on an "old" support page. It is currently available here https://www.ftdichip.com/old2020/Suppor ... htm#HwGen3 and I'm including the relevant text in case that link goes dead. Everything below is from that FAQ:

How does RTS/CTS flow control work in an FTDI chip?

FTxxx RTS# pin is an output. It should be connected to the CTS# input pin of the device at the other end of the UART link.

If RTS# is logic 0 it is indicating the FTxxx device can accept more data on the RXD pin.

If RTS# is logic 1 it is indicating the FTxxx device cannot accept more data.

RTS# changes state when the chip buffer reaches its last 32 bytes of space to allow time for the external device to stop sending data to the FTxxx device.

FTxxx CTS# pin is an input. It should be connected to the RTS# output pin of the device at the other end of the UART link.

If CTS# is logic 0 it is indicating the external device can accept more data, and the FTxxx will transmit on the TXD pin.

If CTS# is logic 1 it is indicating the external device cannot accept more data. the FTxxx will stop transmitting within 0~3 characters, depending on what is in the buffer.

This potential 3 character overrun does occasionally present problems. Customers shoud be made aware the FTxxx is a USB device and not a "normal" RS232 device as seen on a PC. As such the device operates on a packet basis as opposed to a byte basis.

Word to the wise. Not only do RS232 level shifting devices (e.g. MAX232) level shift, but they also invert the signal.

[akohlbecker]

BigDumbDinosaur wrote:

Unfortunately, NXP’s data sheets leave something to be desired in lucidity. They apparently suffer from Dutch-to-English translation problems, which was a problem I have noted since the earliest days in which I’ve worked with their UARTs (over 30 years).

In the event the FIFO is full and a new start bit is detected, RTS will be deasserted within a few X1 clock cycles (I believe four cycles). As the receiver holding register can buffer one datum, the remote station effectively has one datum’s time to react to its CTS being deasserted. This will work out with any device that has its flow control logic entirely in hardware. It sounds as though this is not the case with the FTDI device.

BTW, I discovered that the US Robotics Sportster modem is also a laggard with responding to CTS. That modem has a microcontroller at its core, so it is likely the reaction to CTS is something that occurs in software.

I used to rely solely on auto-RTS, but after the discovery with the modem, I added some code to the reception part of my POC unit’s DUART driver to “manually” deassert RTS when the receiver circular queue (RXQ) is filled to approximately 90 percent. That takes care of the case in which there is incoming data flow, but the foreground is not fetching data from RXQ. As well, I’ve left the auto-RTS feature enabled as a last-resort measure in case IRQs are disabled, as there would be no servicing of incoming data and the FIFO would soon overflow.

SamCoVT wrote:

I ran into this issue on my SBC using an FTDI USB->Serial cable and ended up using Garth's interrupt driven receive for the 65C51 (essentially a software 256 byte FIFO) and I de-assert RTS when there are 16 bytes left. This has worked very reliably with all of the USB->Serial adapters I have including FTDI and Prolific chips and I commonly transmit 20K to 100K files over to my board in plain text (eg. no additional error detection/correction). Some of these are tests for Tali Forth 2 that take a second or two to run, so it's definitely using the handshaking a lot.

Really appreciate you both sharing your experience with this, thanks! A software approach would work, but I'm trying to do everything in hardware, which will allow me to pause the CPU without loosing serial data.

It sounds like 16C550C UARTs and their variants are more appropriate for my use-case, then, as the auto-RTS trigger can be configured.

Too bad, I was able to get one of the recent batch of PLCC 28L92s on Mouser and was looking forward to playing with it. Instead, I now got some of Exar's XR16C2850 which I will be looking at.