Video driver testing (renamed)

potatoheadpotatohead Posts: 10,121
edited 2015-12-21 - 19:28:22 in Propeller 2
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.
' 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.


«1

Comments

  • potatoheadpotatohead Posts: 10,121
    edited 2015-11-27 - 19:59:56
    Here is a test bitmap to compare. I added some single pixel lines, that should render white and grey with light, consistent artifacts. On this timing, they hold steady. On the original timing, they will shimmer through a rainbow of colors. This doesn't appear too much different from either P1, or the "hot" chip output.

    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. :) And we've got the math to translate into PASM, using the CORDIC to dynamically adjust the display for different clocks and pixel sizes, etc.. too. If this displays well, I will probably put all the math into Excel, get it matching the high precision math, then translate to PASM for an easily configurable display.

    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.

  • Got it up and going (A9 board, connected to HDTV), and it looks good.

    What's the VSYNC issue you are encountering? I vaguely recall you mentioning this elsewhere, but don't feel like digging.
  • potatoheadpotatohead Posts: 10,121
    edited 2015-11-27 - 20:41:51
    The pulses are wrong, and some displays will show tearing on interlaced signals.

    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.

  • potatoheadpotatohead Posts: 10,121
    edited 2015-11-29 - 03:23:20
    Here is an excel spreadsheet I used to calculate various timings for the TV display. I've been able to get a very stable, no or low shimmer display at a pile of different resolutions. 160, 256, 320, 512, 640.

    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.

  • Excellent work potatohead, I'll wait for my A9 to arrive to test it :D
  • potatoheadpotatohead Posts: 10,121
    edited 2015-11-29 - 18:26:31
    Getting there...

    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 actually will do this to run on the DE2 to compare DAC output.



  • The A9 boards are the only ones that have 1.0V outputs, under load. The A7 boards were 0.7V and the DE0/DE2 boards were about 1.5V.
  • Chip, I'm seeing an image ghost on the A9 that I don't think I saw on the DE2. My A7 never worked...

    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.
  • potatohead wrote: »
    Chip, I'm seeing an image ghost on the A9 that I don't think I saw on the DE2. My A7 never worked...

    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?
  • I've not had a failure. DE2 and A9.
  • For some reason the TV output from DE2, DE0, P123-A7 didn't work with my new car's composite input.... Just got a black screen...

    Will try this new driver tomorrow or day after with A9 too...
  • cgraceycgracey Posts: 13,125
    edited 2015-11-29 - 16:53:44
    Rayman wrote: »
    For some reason the TV output from DE2, DE0, P123-A7 didn't work with my new car's composite input.... Just got a black screen...

    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?
  • potatoheadpotatohead Posts: 10,121
    edited 2015-11-29 - 18:30:01
    Well, if this code doesn't work, then we've got a good test for the VSYNC, when it's done.

    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.
  • RaymanRayman Posts: 11,492
    edited 2015-11-29 - 19:10:44
    FWIW: It worked with P1 video out.
    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.
  • Which driver? Interlace?

  • Was the regular "TV_Text.spin"
  • FWIW, I tried this again with the driver here and Chips drivers and new A9 board and still didn't work with my car's AV input.

    But, both did work if I turned s (scale) down from 84 to 15. But, the picture was dark. No idea what that means...
  • Rayman wrote: »
    FWIW, I tried this again with the driver here and Chips drivers and new A9 board and still didn't work with my car's AV input.

    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.
  • potatoheadpotatohead Posts: 10,121
    edited 2015-12-02 - 18:24:47
    Rayman, was TV text interlaced?

    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.

  • potatohead wrote: »
    Rayman, was TV text interlaced?

    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?
  • This monitor may be picky, but it worked with P1 video and it worked with another video source (handheld game) that I tried.

    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
  • potatoheadpotatohead Posts: 10,121
    edited 2015-12-02 - 18:43:04
    Everything fails.

    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.

  • Actually, I didn't try the one in the sixth post here, I'll try that now.
  • potatoheadpotatohead Posts: 10,121
    edited 2015-12-02 - 18:41:38
    I do have a scope, and I'll be where I can use it this weekend. Not having it has been part of the difficulty.

  • potatoheadpotatohead Posts: 10,121
    edited 2015-12-02 - 18:56:55
    I just thought of something. On P1 we could use a high PLLA. I often used 3640 PLLA per scanline. Pixels were several clocks wide, depending, but the overall precision possible remained fine. We use VSCL to nail sync pulses with that precision. Visible can be 2560 PLLA, which divides down to all sorts of good things.

    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.

  • jmgjmg Posts: 14,540
    Rayman wrote: »
    FWIW, I tried this again with the driver here and Chips drivers and new A9 board and still didn't work with my car's AV input.

    But, both did work if I turned s (scale) down from 84 to 15. But, the picture was dark. No idea what that means...

    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
  • Played around with Chip's code and found a way to make it kinda work, but have no idea why...

    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
                    ret
    

    Changed #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?
  • cgraceycgracey Posts: 13,125
    edited 2015-12-02 - 19:49:17
    <deleted>
  • Potatohead and Rayman,

    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:

  • It works! Nice bright and steady image.
Sign In or Register to comment.