[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