techtravels.org

Video artifacts present in scan doubled video

I uploaded a video to youtube that shows some video artifacts happening with the scan doubled video.

The entire video shakes as if interlaced, but it’s not. Original res 320×200(15.7khz), doubled to 640×400.(~31khz)

There is a colored wavy pattern across the white sections.

Video showing artifacts

On a monitor directly attached to the amiga, the screen is very stable, crisp, and nice looking. 🙂

 

keith

Amateur Electronics Design Engineer and Hacker

4 comments

Leave a Reply to Dweller Cancel reply

  • Great progress! I looked at your video. The wavy color thing seems to happen mostly where a white pixel is left/right adjacent with a darker pixel. In long horizontal lines of solid white, it doesn’t happen. Just a guess, but this makes me think it’s some kind of sample framing error between your video output and the monitor. If the amount of time between HSYNC and the VGA data for a particular pixel is not 100% consistent, that might cause this problem you’re seeing. Or if the amount of time between one HSYNC and the next is not 100% consistent, that might do it too.

    I didn’t notice any interlace-style shaking in your video– maybe it’s not visible in the YouTube version? But again, I could definitely see that being a problem with HSYNC timing.

  • I spent some time on this last night and really didn’t make any further progress.

    I was using the 7.15909mhz clock off of Denise as a read clock — but further experimentation, simply reading regularly(starting from HSYNC pulse), produces equivalent results. Looking closely at edges in the logic analyzer, and such, the 7.15909 clock is _not_ a pixel clock.

    I still see this goofy overlaid pattern, although I have isolated it to the left hand portion of the screen — about 80 pixels worth.

    I now have something new, a very faint vertically moving centered “retrace pattern”, diagonal dotted lines. Color is a faint red.

    If I move the amiga window away from the left, the overlaid pattern doesn’t follow it.

    I have my outbound VSYNC locked to the inbound VSYNC, in that when I see a vertical sync pulse from the amiga, I set the Y value in my HV sync generator to a fixed point (happens to be a Y=435) I did this earlier which stopped the vertical scrolling of the entire video.

    I can’t easily do the same thing with HSYNC, because the HSYNC rate is different (doubled)

    So there’s no real relationship between HSYNC coming in, and HSYNC going out. Now I don’t start sampling a line (and storing it in a buffer), until I see HSYNC on input. And then I output based on my hvsync generators X counter as the address into the buffer, so pixel data at address 0 is displayed at x-coordinate zero on the output monitor.

    But the timing of the incoming horizontal blanking interval does not match (not even the same length,per specs) the timing of the outgoing blanking interval.

    I do pixel counting on the sampling, offset from the incoming hsync pulse, and once I get 370 pixels (seems to be the magic number), I stop storing into my buffer and wait for HSYNC again.

  • Is that being shown on an LCD ? if so, have you looked to see what it looks like on a CRT ? can get some great artifacts on LCDs when the signal being fed drifts around a bit, when the old CRT seemed to be more tolerant (plus sometimes the info panel on the later CRTs was handy for finding out exactly what you’d managed to coax the amiga to output when playing with moned/resmon)

  • I had this same thought last night.

    So I broke out an older CRT, and I’m getting exactly the same image.

    This does give me hope because it tells me I’m generating (or passing on) this junk. ie, probably not an artifact of LCD processing, for instance.

    I’m definitely violating some fairly basic rules. I just don’t know where/how yet.