You might not need hardware flow control, as long as the host is able to pull data out of its UART fast enough so that the receive FIFO doesn't overflow - and that only for reads. For transfers from host to target, the host software should wait for an acknowledgement of the prior frame before sending the next one, at which time the target will be listening to the UART. Overrun errors should also be detectable and recoverable if they occur occasionally, since there's a CRC check both ways.

Writes from host to target should work reliably enough, even with a buggy 6551, but with the latter you won't be able to perform a successful readback (as a minimum of 6 bytes are sent in a burst, due to the CRC and frame header). There isn't room within 256 bytes to add a timing loop. You could comment or NOP out a few lines in order to get an "austere" readback capability without CRC protection, one byte at a time. I prefer to make the assumption of correctly functioning hardware, though.

Actually, the host software could test for the presence of a buggy 6551 by performing a test readback of some of the utility code, and upload a patch as a workaround. But that's a refinement to consider later.

Currently I haven't posted a complete copy of the code, because I want to test it locally first. Some of the optimisations are a bit hairy, so the chances of my having made a mistake are significant.