Capture Phase Edges at 17.46ns reolution using Prop Counters?
tonyp12
Posts: 1,951
The Prop would probably be the only MCU that could do this all by itself.
The Job: Capture C64's VIC-II Chroma Phase edges.
There are only 8 different edge timings but some colors are just 22.5deg apart so a 17.46ns Counter capture resolution would be needed.
Then output a scan-doubled VGA output, the Prop HUB will store a entire line of pixels/colors and output it twice, but first the above step
I was thinking:
Take the 14.31818Mhz color clock signal and /2 to it and feed it to the Prop Xin, so the Prop would be running at 8xPLL = 57.27MHz (eg a 17.46ns clock)
Or does the PLL only work on crystals?, as PLL is needed for VGA later this is a must.
So could you just read PHSA? (maybe use frqa 32bit/16 so it keeps overflowing by itself?)
and get:
0=yellow, 1=brown, 2=orange, 3=red, 6=purple, 8=blue, 11=cyan, 14=green
If it would be hard to sync it to color-burst, maybe if any results has an illegal color increase it one clock and try again.
As you have to read Luma at 8.18Mhz (using 9 Prop-pins as a Flash A/D) these 2 different clocks will cause a little problem I think.
Though I also have access to DotClk, the Prop does not do latching, But If I alternate of reading INA every 7 or 8 clocks I should still be reading mid-bit in the long run
Maybe 6 Cogs will be need to do all this capture alone, and 1-2 for VGA out.
The Job: Capture C64's VIC-II Chroma Phase edges.
There are only 8 different edge timings but some colors are just 22.5deg apart so a 17.46ns Counter capture resolution would be needed.
Then output a scan-doubled VGA output, the Prop HUB will store a entire line of pixels/colors and output it twice, but first the above step
I was thinking:
Take the 14.31818Mhz color clock signal and /2 to it and feed it to the Prop Xin, so the Prop would be running at 8xPLL = 57.27MHz (eg a 17.46ns clock)
Or does the PLL only work on crystals?, as PLL is needed for VGA later this is a must.
So could you just read PHSA? (maybe use frqa 32bit/16 so it keeps overflowing by itself?)
and get:
0=yellow, 1=brown, 2=orange, 3=red, 6=purple, 8=blue, 11=cyan, 14=green
If it would be hard to sync it to color-burst, maybe if any results has an illegal color increase it one clock and try again.
As you have to read Luma at 8.18Mhz (using 9 Prop-pins as a Flash A/D) these 2 different clocks will cause a little problem I think.
Though I also have access to DotClk, the Prop does not do latching, But If I alternate of reading INA every 7 or 8 clocks I should still be reading mid-bit in the long run
Maybe 6 Cogs will be need to do all this capture alone, and 1-2 for VGA out.
1024 x 285 - 31K
Comments
-Phil
In the pic below, I'm reading the Color-in pin
The C64 uses "color-resistors" to sum 4 different 3.5795MHz waves, waves that all come from the 14MHz color-clk but is offset by one clk each then /4.
This is done all internally inside the VIC-II so no digital access anywhere, so I think the sines are already smoothed inside the IC.
I was thinking of data-snooping on the digital input lines and emulate the VIC-II on the Prop,
but there is so many non-official tricks people do with it that getting everything to look the same would be hard.