Video driver testing (renamed)
potatohead
Posts: 10,253
After figuring out this NCO business, I modified the timing of the TV driver to make the pixel clock an exact multiple of the color clock. It's actually the same, though it could be doubled for higher resolution, overdriven TV drivers like we did on P1. At this timing, 320 nice, color pixels are possible without going into overscan. Doubling the clocks, while outputting the same "normal" colorburst, should yield 640.
This is equivalent to 8 PLLA, for those who have done P1 TV driver work. (3640/455)
There are 455 "pixels" per line, and I've made rough adjustments to the scanline for the shorter time period. Vertical sync is still goofy, and I'll work on that next.
When you have a moment, give this one a try on your display. There should now be only the colorburst beating against the 80Mhz clock, which on my display has eliminated the shimmer on color boundaries we've been seeing. On the A9, there seems to be more, light "ghosting" of the signal, which can be seen on the bright lines and image border. Of you look closely, there is a slight and slow shimmer on those, which is the 80Mhz beating against the colorburst very slowly. I think this can be ignored, and the real chip shouldn't have that ghosting, or we can make a circuit to minimize it.
This is equivalent to 8 PLLA, for those who have done P1 TV driver work. (3640/455)
There are 455 "pixels" per line, and I've made rough adjustments to the scanline for the shorter time period. Vertical sync is still goofy, and I'll work on that next.
When you have a moment, give this one a try on your display. There should now be only the colorburst beating against the 80Mhz clock, which on my display has eliminated the shimmer on color boundaries we've been seeing. On the A9, there seems to be more, light "ghosting" of the signal, which can be seen on the bright lines and image border. Of you look closely, there is a slight and slow shimmer on those, which is the 80Mhz beating against the colorburst very slowly. I think this can be ignored, and the real chip shouldn't have that ghosting, or we can make a circuit to minimize it.
' Here is the math:
'
' (3579545/227.5*455) / 80000000*(2^31) = 168,945,370.4347287912 = a11e6da.6f4a62d4df1223ec9670edd101
' (3579545) / 80000000*(2^31)*2 = 192,175,358.869504 = b745cfe.de97d06bbdbe3c105186db50f4
' (3579545*2)/(3579545/227.5) = 455 pixels / line
CON
{
f_color = 3_579_545.0 'colorburst frequency
f_scanline = f_color / 227.5 'scanline frequency
f_pixel = f_scanline * 455.0 'pixel frequency for 400 pixels per scanline
f_clock = 80_000_000.0 'clock frequency
f_xfr = f_pixel / f_clock * float($7FFF_FFFF)
f_csc = f_color / f_clock * float($7FFF_FFFF) * 2.0
}
ixfr = $0b745cfe 'Make pixel clock, same as color clocks, high precision math results
icsc = $0b745cfe 'from above.
Comments
Mine are holding white over an extended time. There are three close together, and those produce an artifact that is also staying constant. That's what you look for.
Either replace the bitmap file with this one, or change your driver code to "ddbitmap.bmp" to compare.
If this works out, we can mod the TV driver, fix the VSYNC, and display line art on TV with no real issues.
This stuff is only needed on the TV Composite driver, and it's due to the colorburst. On any other display mode, Component, VGA, etc... it's not so important to match the pixel clocks up like this.
What's the VSYNC issue you are encountering? I vaguely recall you mentioning this elsewhere, but don't feel like digging.
Interestingly, this effort is a different kind of wrong, but it appears to work better... go figure.
I plan on mooching good vsync from a solid P1 driver, but had to get a common timing basis first. This timing matches or is an even multiple of many P1 drivers.
I struggled to understand the NCO phase calculation. Made it a lot harder than it needed to be.
And that is: (Desired_Frequency / System_Clock_Frequency) * 2^31 = NCO Phase Value
Did the fractional math manually to validate it. The Windows Calculator doesn't seem to know what fractional binary is. I think it used to in Windows XP. Anyway, I found this handy thing: http://www.runiter.com/math-calculator/
It does high precision math, and it can input and output HEX, BINARY, OCTAL, DECIMAL.
Under 160 only requires running pixels at the colorburst clock.
For 320 and under, it's best to work with a 2x multiplier of the colorburst for the pixel clock. For 720 and under, it's best to work with a 4x multiplier of the colorburst. These even multiples allow for a little tweak or two on the scanline to adjust for small errors inherent in the NCO.
So far, I've left the color engine at 2x the colorburst. I don't understand everything about how it's working just yet.
I've also attached a 640 pixel bitmap driver running from the values in the spreadsheet. It's a multiple of the 320 pixel one posted above.
And a 320 pixel bitmap to test on. It will just scan double, for the 640.
I think this is enough to write some PASM to compute horizontal signal values of various kinds and from various clocks. When I get Vsync sorted, I'll add to this, but thought I would share work so far.
You can edit the spreadsheet to a 50mhz clock, edit the two frequently values in the beginning of the test driver, and go.
The rest of it will all be the same. (It better be, or I've botched part of it.)
Just saying...
I'll take a couple photos tonite. If that's an artifact of how the A9 works, no big deal. Just wondering if I'm doing something wrong.
A ghost is a signal delayed in time. I don't know why one board would do that and another wouldn't.
Did any of the demos I supplied in the .zip file not work on any board?
Will try this new driver tomorrow or day after with A9 too...
Perhaps they are looking for an exact VSYNC sequence, maybe interlaced? Or, maybe they want a 1.0V-peak signal?
I've never run into anything that is picky about the 1.0V peak, but I have run into both the need for interlace and precise VSYNC.
If it ends up being interlace, we can make a driver option to double scan all the lines for low resolution.
I've captured all the timing data for VSYNC, and will update or attach a spreadsheet here. Tonight, I plan on working through the timings for it. Don't know about you guys, but I found the VSYNC more difficult to understand.
Also, it's almost worthless for my car because have to be in park with parking brake on to work. Still, there are a couple times where it would be nice.
But, both did work if I turned s (scale) down from 84 to 15. But, the picture was dark. No idea what that means...
My vertical sync serration pulses' high-to-low ratios were not official. I just made them up. Maybe that's the problem. Everything else was to spec.
This vsync business has been slippery. I think we are close.
Do you have time to try the test frame program I did early on?
@chip, that should have worked anyway. I think the new wrinkle here has to do with not driving things from a PLL. Plenty of us have just slammed some vsync in there on P1. Almost anything close works when all lines are the same amount of time.
This timing scheme appears to need better precision to keep the vsync balanced.
My guess anyway. I could be wrong.
I'll be attempting that rigid timing on my next try. Once that gets sorted, we have pretty great TV! I'm gonna try driving all of it right off the colorburst.
At 50MHz, the max the NCO could be off by is only 20ns, or one clock period. I doubt that any TV is that sensitive. It's got to be something simpler, I think.
Does the NTSC demo I made fail on your monitor? If so, I could make the serration pulses more exact in their H/L ratio and we could see if that fixes it. By the way, do you have a scope?
I've tried the examples here and the examples in the latest download.
Also, this is 80 MHz with A9 board...
I do have a scope, fwiw
By that, I mean up to 20, maybe 25 scanline at the top of the frame are not in the right place. I have got it down to a couple. At 455 xfer per line, one xfer off will affect this. I was kind of surprised at that.
I have a couple of displays. All are impacted, some more than others. I suspect a capture card will do just fine, but I have not tried that yet.
Would be nice to express pixels as a multiple of the base xfer clock. Run xfer at 3640, and do it the P1 way. Right now, I'm using 455, 2x colorburst to nail the horizontal and get rid of shimmer. That works awesome.
I suppose we can frequency and mode change to get the same thing done. I may try this too.
If it works with just scaling, that's not sounding like a vertical sync issue ?
That would usually be top-lines tearing.
Can you put a low value pot on the Video, and scale it that way to see when it syncs, then loses the picture ?
For Vertical sync timing, to avoid tearing effects, one detail that is important is to have the falling edges always line-rate locked.
ie you double the Freq rate, and modulate PWM, but there is still always a =\_ on the line sampling time slot.
Good diagrams are here : (PAL & NTSC)
http://martin.hinner.info/vga/pal.html
Was dorking with the numbers here:
vsynch xcont m_bs,#1 'vertical sync high xcont m_hs,#2 xcont m_hl,#1 djnz x,#vsynch retChanged #2 to a register with different values like $0FFF_000. Didn't seem to matter what the value was, but I got a bright image, although not entirely stable.
Docs say this is immediate streamer mode, so I think the source should be directly output... So what's with #1 and #2? Don't get it. Maybe these are sync levels?
I fixed the serration pulses' high-to-low ratios. I think it might have been off enough to cause some monitors not to recognize VSYNC.
Try this: