[Coco] It's a small win, but a win nonetheless
William Astle
lost at l-w.ca
Sun Mar 12 01:11:16 EST 2017
On 2017-03-11 10:33 PM, Gene Heskett wrote:
> Without fiddling with the rom code. But, I am quite sure the protocol
> includes a start bit AND a stop bit. And the stop bit is probably a few
> microseconds wider than it has to be because its busy at that point,
> fetching the next byte to send. So a loss of sync, giving you an AA
> instead of a 55, (that is a one bit time slippage) may be symptomatic of
> the uC burning too much time putting the previously received byte away.
> Optimizing the uC code might be required by dropping into assembler for
> that.
Nope. There are no start or stop bits in the cassette signalling. The
only sync signal at all is the leader of $55 for every block written (in
most cases). It counts the time between zero crossings in the signal to
determine 1 or 0. There's a bit of slop there so a slight delay between
two bytes won't break the signal, nor will a slight bit of extra
processing between bytes when reading. However, anything more than that,
or a case where the tape is stopped and restarted, will require a new
leader. That's why data files have "gaps" (which just means every block
written has a leader) while binary saves of basic programs don't (it can
write all the data in one go with minimal processing between blocks).
More information about the Coco
mailing list