Glenn Saunders:
> So what's the width ratio between clock run-in high-point (as square
wave)
> and a data bit? I'm assuming 8/1? A player pixel is 1/4 of a playfield
> pixel and to do the CC you'd want to just double up the data bits into
two
> playfield bits per data bit, hence 8 player pixel widths per data bit.
The info I have says that the data rate is 32 times the horizontal
frequency. (Which is 15.734kHz for NTSC, or colorburst/227.5.) "However,
decoders should not rely on this timing relationship..."
> I was counting on CC having convenient timing characteristics linked to
the
> colorburst frequency, colorclocks, etc.... It would have been a logical
> design decision as it was with the 2600 itself. But maybe this wasn't
the
> case?
Unfortunately, the 2600 line is 228 colorburst clocks rather than the NTSC
standard of 227.5 (assuming the NTSC colorburst crystal isn't off by 0.2%),
and 228 isn't evenly divisible by 32 (about 7.1 pixels per bit).
Hmm, we might have a problem. The active portion of the 2600 screen is
only 44.7us, while the active portion of NTSC is 52.9us. If we assume the
2600 screen is centered, that puts the right edge at 58.0us from 0H (the
falling edge of the horizontal sync). Unfortunately, the end of the second
parity bit is at 61.146us from 0H. We're about 2 bits short.
Once I can spare some time away from Skeleton, I will try to create a test
application.
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
