[Coco] CoCoRX

Gene Heskett gheskett at wdtv.com
Tue Jun 2 19:20:46 EDT 2015



On Tuesday 02 June 2015 18:08:06 Robert Gault wrote:
> Frank Pittel wrote:
> > Sorry for responding so late but I got behind in reading email.
> >
> > Isn't the idea of the cartridge to test actual cocos? Unless
> > seriously broken in ways I can't imagine possible a 6809 or 6309 is
> > always going to clock cycle accurate. In the case of an emulator
> > running on a PC or FPGA it should be up to the author(s) to indicate
> > if it's clock cycle accurate. It's well known that the "cpu" on the
> > coco3fpga isn't cycle accurate and neither will anything based on
> > that core.
> >
> > The Other Frank
> >
> > On Sat, May 30, 2015 at 02:43:25PM -0500, Melanie and John Mark 
Mobley wrote:
> >> We need a diagnostic test that will prove out the cycle accuracy
> >> timing of the CPU so that it can be used to test the FPGA design.
> >>
> >> John Mark Mobley
>
> To add a comment on this request, it would be impossible for any
> software to verify a "clock cycle" as it would run using the clock
> cycle in question. Unless the PAK contained its own crystal and timing
> circuits, there would not be any basis for measuring the Coco or
> emulator timing. If the PAK did include a clock circuit, how would
> that timing be verified?
>
> Perhaps if the PAK included a realtime clock, the crystal in the clock
> could be used to validate the Coco/emulator timing by measuring the
> number of software loop cycles per some unit time. I have doubts about
> the precision of such measurements and the added cost to the PAK would
> probably be prohibitive.
>
> A high precision counter would be needed to measure the Coco/emulator
> at various test points and the counter would need to be certified as
> to its accuracy to provide meaningful results.
> Better just to assume if the unit under question produces reasonable
> pictures on a monitor, the timing is adequate.
>
> Robert

I would add that while we as broadcasters were required to keep the color 
subcarrier within +-10 hertz, the cyrstals used in tv sets could be 
pushed by up to 200 hertz either way & could still be adjusted with the 
hue control for decent color.

The failure mechanism that causes the drift, ever downward on frequency, 
is the inadequate package sealing of the crystal, allowing oxygen from 
the air to enter, which over time converts the silver plating used to 
connect the crystal to its leads into silver oxide, aka tarnish to put 
it into the vernacular.

The added weight, caused by the oxygen added to the silver to do the 
tarnishing, makes the crystal run flat.  In my time doing CB radio 
service at Norfolk 2-Way Radio back in the 70's, I have encountered 
crystals that were as much as 30 kilohertz flat!  But they wre still 
running.

With that as background, the clocking of the coco's color signals, might 
be called good/suspect when a tv is fed the composite rf output, and 
makes locked up color.  If the coco is too flat from old age, then the 
color is likely to be rainbowed in bands on the tv set.  Good color is 
good, rainbowed color is suspect.

So that is the test I would apply in lieu of putting a counter on it. 

Lots more tv's out there than counters. I do not own one myself. I 
haven't had to maintain that critical signal in any of what I am doing 
today. I have a fairly new scope, digital storage yadda yadda, and it 
can display the frequency of what it is measuring to about 4 decimal 
places to the right of the decimal point,  and for what I am doing, 
its "close enough for the girls I go with."

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