I'm playing with the USART on the ATTiny 2313a currently. Since I have all of the SPI writes working excellently, the first thing I wanted to do was have a simple method of blasting writes over the (new, since we didn't have it before!) serial connection to VGATonic!

Instead of writing a new protocol from scratch, I looked into some of the early methods of file transfer over (slow, at least relative to today) early modems.

In 1977, Ward Christensen released a protocol called 'XMODEM' for a terminal program he was making. XMODEM's algorithm is relatively simple (Christiansen referred to it as a "hack" - was it ever featured on Hackaday?):

1) SOH - Start of Header Packet
2) Sequence - Counter to 255 (the packet order)
3) 1s Complement of Sequence: (255 and seq) xor 255
4) 128 Bytes of Data
5) Checksum - add all data bytes together and disregard the carries
6) Receiver sends back 'ACK' or 'NAK', ACK being a match and 
    NAK meaning 'resend, there is a mismatch'

As Christiansen put it, his resulting XMODEM protocol may very well be the most modified code (and supported file transfer protocol!) of all time. It's quite efficient: 4 bytes of overhead for 128 Bytes of data. (With 8-N-1 Serial you also lose 2 bytes every 10 due to start and stop bits)

Instead of reinventing the wheel, I'm basing my protocol on XMODEM. Here's what I've got working:

1) Escape character
    a) Receiver sends back '>'
2) Start Packet (I'm using a 'W')
    b) Receiver sends back '#'
3) x = message length (One byte, so 0 - 255)
    c) Receiver echos size
4) Send x single bytes
5) Receiver sends back ACK

Note that I don't care about checksums, and VGATonic will never ask for a resend - a slight pixel difference is fine for our application.

So, We've got 7 bytes of overhead for (up to) 255 bytes of data, or roughly 97.3% channel efficiency. Now, multiply the 262 bytes by (10/8) (the inverse of the efficiency of our asynchronous serial connection) to find how many 'raw' bytes from the serial connection are needed:

Bytes Needed:            (10/8) * 262 = 327.5
Bits Needed:               327.5*8 = 2,620
Data Bits Transferred: 255*8 = 2,040

Overall Efficiency: 255/327.5 = 77.86%

Now that you've got an idea of overhead - almost a quarter(!) - you can calculate how some of the VGATonic screen writes would work:

640*480*8 bit depth needs 2,457,600 bits, which would take 
3,156,330 bit transfers after overhead.

... (etc)

320*240*4 bit depth needs 307,200 bits, which would take 
394,541 bit transfers after overhead.

... (etc)

80*60*1 bit depth needs 4,800 bits, which would take 
6,165 bit transfers after overhead.

I've tested it at 9,600 baud and 38,400 baud - common enough speeds. For those 3 (Remember, we have all 16 combinations if we want them):

640*480@8bpp (256 color)
9,600 Baud: 328.8 seconds per frame ( 5.5 minutes(!) )
38,400 Baud: 82.2 seconds per frame ( 1.4 minutes )

320*240@4bpp (16 color)
9,600 Baud: 41.1 seconds per frame
38,400 Baud: 10.3 seconds per frame

80*60@1bpp (B&W)
9,600 Baud: .64 seconds per frame
38,400 Baud: .16 seconds per frame

Okay, that's a slideshow at best (other than, arguably, the 6.25 frames per second we can get out of our most modest resolution/color depth at 38,400 baud).

Worse, I'm also leaving out latency, so it will be even slower than the above waiting for responses before continuing.

Anyway, it's in the code now - and hopefully this post also illuminates why terminal emulators were so popular - getting a lot of useful-to-humans-data across 'slow' asynchronous connections. Demos of VGATonic connected to Raspberry Pis running Doom at 25 frames per second over SPI (a synchronous serial connection, remember!) are fun, but it's making these slow connections useful which is really driving the work on VGATonic.

All of this is thanks to, of course, protocols like XMODEM which paved the way - before yours truly was even born!