At the end of the last log I had a computer connected to the teletype and a lot of garbage being printed onto the paper.

This was partly because the memory buffer for the incoming serial was too small and partly because of too many things needing precise timing: 
1. When printing, timing is tight and interrupts have to be disabled 
2. The serial chip (68B50) can only latch a single received byte. Flow control isn't configured on the teletype side or on some of the RC2014s that I'll want to plug into it and so interrupts have to be used or the chip has to be polled frequently.

We have no fancy multi-core technology here, I'm trying to handle this with a single Z80 @ 7.6Mhz. I thought about other serial options, but nothing will buffer the amount of bytes that could arrive in the time it takes to print a line. I thought about a module that could store the line to be sent to the printer and shift it out to the printer using logic. That's an interesting idea but developing hardware is outside the scope of this project.

Strategy one
To get the print routine working I had to introduce a small delay between pixels when writing to the printer. After some T-state counting, this turned out to be long enough (with spare) to check the serial chip and fetch and buffer a byte if necessary. 

I very nearly got this working but at best had dropped and repeated characters, then the whole thing would lose the plot after a little while. I spent hours on this problem. The solution may have been minutes away or weeks. Who knows. 

Strategy two
I had another think about the overall flow of information. Initially I'd been printing a line when the incoming information reached 32 characters or a carriage return received. This inevitably leads to printing and incoming data happening at the same time. 

This thinking came from early experiments when I had a closed loop - sending my own typing straight from the terminal's keyboard to the printer. 

It occurred to me that things work differently when connected to a computer. Data doesn't come one line at a time. On the whole it goes like this:

- computer sends a chunk of data. Anywhere between a single character and a screenful
- then waits for user input.
- user responds with a single key or a single line and presses return.

I'm thinking of this as 'walkie talkie' style. The serial chip is capable of handling data in both directions at the same time and this can happen but *usually* chunks of data are heading one way or the other at one time.

So I sketched a flow chart to handle this. While data is incoming, the terminal will just keep buffering until there's a pause. Then print what it has, which may be multiple lines or even a screenful. 

A screenful of text (the maximum we can reasonably expect the computer to send at once) will be 1 - 2k depending on what resolution the computer is expecting the 'display' to be. This will require a bigger buffer than I started out with, but that's OK, we've got 32k of RAM. It'll also expect data to go back and forth in chunks and that's OK too. Operating systems and monitors work in this way, as do programming languages like BASIC and FORTH, as do the 'turn based' games and other applications that I can see being usable on this type of terminal.

Changing the program flow and implementing the bigger buffer all took longer than expected (quick to do, slow to troubleshoot).

At the end I had this. It proves that I can send multiple lines of text, buffer everything and print it. (I needed multiple rows of text in short lines!) 

This was pasted into the terminal emulator. At this point I still haven't had a real RC2014 having a meaningful exchange with it. There are still issues there.

It doesn't feel like very much progress for the time spent, but I do feel that everything's on a more solid footing now.