[Coco] It's a small win, but a win nonetheless

Gene Heskett gheskett at shentel.net
Sun Mar 12 01:18:52 EST 2017


On Sunday 12 March 2017 01:11:16 William Astle wrote:

> 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).

I'll take your word for it William, but I have a mental picture of a sign 
inviting that law author guy Murphy being invited in for lunch 
(yours). ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>


More information about the Coco mailing list