There is no problem typing in characters at human typing speed.

10 REM The owl and the Pussy-cat went to sea

Problems arise with copy-and paste to terminals. The above line becomes:

10 REM Th owl andthe Puss-cat wet to seaa

At first I wondered if this was the PC missing incoming characters. Grant had wired the 6850 !CTS signal to ground so the 6850 would send characters even if there was no PC present to receive them. I modified the board so that the 6850 CTS signal is driven by the serial port. However, this did not cure the fault.

LIST shows the characters above are those actually stored:

10 REM Th owl andthe Puss-cat wet to seaa

so characters had disappeared on the way from PC to 6809. I don't know how the final extra 'a' got there.

Grant says that the RTS to PC RS232 handshaking cuts out all missed characters, and I expect that he has verified this. He goes on to describe how to to connect to a USB serial cable.

I suspected the PC USB cable is sending one character after being told to wait. A quick google leads to the FTDI FAQ page, which says:

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

This potential 3 character overrun does occasionally present problems. Customers should be 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 confirms my suspicion. The board needs a serial chip with at least a 3-byte buffer if pasting characters through an FTDI USB-to-TTL serial cable. PCs no longer have real serial ports, so unless you have a really old PC then you will be talking through some kind of USB to serial dongle. 

Workarounds: 

In Windows, you can tell Hyperterminal to add a delay between characters and lines. The minimum is 1 millisecond. This fixes the problem, and would suggest 1000 characters per second transfer rate, but in practice it did not look like that. I suspect the time delay causes the OS to limit the characters per USB packet (possibly just one character), and the transfer rate is limited by how often USB packets are sent.

In Linux, gtkTerm allows you to set a delay between lines, but not characters. You could effectively enforce time between characters by reducing the data rate. This may be a better Windows workaround too.

Proper fixes:

Use a different serial chip. The 6850 has just a one-byte buffer. Wikipedia has a useful table of UARTs:

https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter#UART_models

Grant's designs use the 6850's three chip select lines to simplify memory-mapping logic. 

The Zilog 8470 DART has a 3-byte receive FIFO plus the receive buffer itself, i.e. 4 bytes in total. This is just enough to handle FTDI's 3-byte overrun behaviour.  This probably explains why I don't get missing characters on my Z80 board.

The DART has no baud-rate generator, so as well as the 40-pin DART you would need something like a Z80 CTC (28-pin). Better to go for a chip with on-chip baud generator, like the Zilog 8530 SCC. These have the same size FIFO buffer as the DART.

A better solution is to replace the UART with a USB interface. These remove the baud-rate bottleneck, baud rate generators and RS232 buffers altogether. 

Grant's BASIC does not use interrupt-driven serial I/O, so it is likely that it could be busy longer than the interval between characters. 115200 baud is about 14400 bytes/second, or 70 microseconds per byte. That seems enough time to read and store a character. There is an interrupt-driven serial I/O routine in Lance Leventhal's 6809 assembly language subroutines book, so I typed that in and attached the code here. It says it takes 112 cycles to service an interrupt, so at 1.8432 MHz this would be about 61 microseconds. This would take...

Read more »