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.

_________________
BB816 Computer YouTube series

Yep, that's the idea.


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).

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).

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.

_________________
BB816 Computer YouTube series

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

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!

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

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.

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).

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

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:



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.

_________________
BB816 Computer YouTube series

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



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

_________________
BB816 Computer YouTube series

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

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/Support/FAQs.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.

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.

_________________
BB816 Computer YouTube series