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

[RETRO Innovations]

On 3/11/2017 11: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.
I can confirm it does not.  I can save off a CSV file of the zero 
crossing detector, which shows the 1200/2400 Hz cycles.
> 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.
In this case, the issue is a "glitch" in the zero detector.  If the 
detector sees a crossing that is not there, it counts that as a bit 
time, if it falls in the 1200/2400 period window (the code currently 
counts 31250Hz pulses, and if it sees a count less that 26 but more than 
12, that's a 1, and a count less than 40 but more than 25 that's a 0.  
The count is generated on the falling edge of the zero crossing detector 
(my code is 180 degree phase shifted from the output (a high portion of 
the cycle makes the detector go low), and 13 corresponds to the time 
needed to do a 2400 Hz pulse (13 cycles of 31250Hz, or 2403Hz, and 26 is 
1202Hz)

Hopefully, with the detector now better soldered into the PCB, the issue 
will disappear.  It looks like it is working.  Now, I need to find a 
chunk of C code that will interpret Color BASIC... :-)

Jim