Shop Learn
All PASM2 gurus - help optimizing a text driver over DVI? - Page 21 — Parallax Forums

All PASM2 gurus - help optimizing a text driver over DVI?

1181921232429

Comments

  • The P1 PAL driver is correctly written and works, but it just doesn't produce a very good quality image due to P1 hardware problems (it really depends on TV, too, it works as good as anything else on my little portable PAL TV, I've attached an image I've taken yesterday, because why not?).

    Hardware capture devices didn't like the P1 PAL driver much. Pretty sure that came down to jitter. PAL requires more precision and consistency than NTSC does. Those things do matter on an NTSC signal, and can be seen too. It's just that NTSC will allow a lower grade signal, and variations in color tend to blend in the human eye across frames and fields. (Hello VHS!)

    I would imagine newer TV's, sampling at 13.5Mhz may have issues with the P1 driver.

    But, more analog displays, basically older ones, displayed it very reasonably.

  • cgraceycgracey Posts: 13,610
    Rogloh, you ought to be able to get the levels up to where they need to be. Just play with the math a bit.
  • potatohead wrote: »
    Hardware capture devices didn't like the P1 PAL driver much.
    I've actually never had an issue with that. Chip's driver (and all its derivatives) always captures great (well, as great as my cheap video capture thing gets), both NTSC and PAL. Whereas on my big ol' CRT TV, PAL always has diagonal stripes of hue-shift moving across the screen. Certainly viewable, but not very nice.

    Conversely, a non-TV.spin-derived driver may come out like this.

    Anyways, this is getting way off topic....
    rogloh wrote: »
    It looks like red is coming out green, and green is coming out red. Yellow is close but not perfect. Blue is right but that was set to 0 in the colour bursts so didn't play a part in its calculation. Magenta and cyan look pretty ugly too. Of course black and white work as they don't need to send the colour signal.

    Am I mistaken or does that sound like the burst color has it's V component inverted?

  • cgraceycgracey Posts: 13,610
    Rogloh, I accidentally messed up your post! I'm sorry. I thought I was quoting and responding, but I was editing it. It got pretty much wiped down to nothing. I'm sorry.
  • cgraceycgracey Posts: 13,610
    rogloh wrote:
    I noticed in some of your NTSC code for P2 you were shrinking the sync tips and black/blank levels when your SAT parameter reduces Chip. Was there a specific reason for that?

    I guess the math got applied to everything. Not exactly intended.
  • cgracey wrote: »
    Rogloh, I accidentally messed up your post! I'm sorry. I thought I was quoting and responding, but I was editing it. It got pretty much wiped down to nothing. I'm sorry.

    LOL, the power to censor by deleting posts! :lol:
  • So I have found some colour values that can setup the right colour burst levels (or at least close enough for now) for creating a 150mV amplitude colour burst, with the original attenuation settings for SAT=70.

    GREEN = 255 ($FF)
    RED = 77 ($4D)
    r=SAT * 1280/1646 <<--- this is also adjusted from 1000/1646 to boost the level sufficiently.

    However even with this the colours are still wrong. To me it roughly looks like red/green might be phase shifted by 45 degrees. I believe this makes sense as only the Q (V) component is being used to modulate the colour output not U.sin(wt) + V.cos(wt). The order of the colour bars from left to right is meant to be white, yellow, cyan, green, magenta, red, blue, black but the image shows something else.

    IMG_2575.jpg

    Notice how the TV seems to adapt part way down from the top and how the colours started out even uglier there. The colour bar change at the bottom is because my software intentionally shifts these bars to prove it is my video output not the TV displaying its own thing.

    I think the way to make it work for PAL might be to adjust both U and V signals per line, such that the colour bursts are situated along -U,0 and 0,-V axes instead of at -U, -V and -U, +V, i.e. introduce another 45 degree rotation. This may mean that I need to keep both cq and ci as well as the two xor flips for them unless there is a way to setup the co-efficients differently to achieve the same rotation thing but only flipping either U or V by itself during each scanline. However if turns out that I have to keep two more values and do two more instructions during hsync to flip etc I'm not sure it would all fit in the limited remaining longs. :frown:
    640 x 480 - 59K
  • Wuerfel_21 wrote: »
    Am I mistaken or does that sound like the burst color has it's V component inverted?
    The more I look at this and the YUV space below the more I think you are right and it is probably not a rotation of 45 degrees. But I don't know why it does this, and if I flip the odd/even starting parameters for CV_PAL, which should be like inverting V anyway, it doesn't change. So why else would red and green be swapped like this I wonder?

    yuv.png

    However what is weirder is that the colours change part way down the screen at the top once the TV "adapts" . I am not doing anything different in this portion of the screen in my code. All scanline's hsync colour bursts and flips are treated the same in the whole field.

    1013 x 988 - 258K
    yuv.png 257.5K
  • Wuerfel_21Wuerfel_21 Posts: 1,721
    edited 2019-12-04 07:02
    The top of the screen looks like the V component isn't being decoded at all (which in turn looks very similar to a colorblindness simulation filter).

    Have you got access to any older, more analog PAL TVs? Testing on such a set might give more insight

    EDIT: Another thing: does the color carrier line up properly with its 64µs-delayed self?
  • roglohrogloh Posts: 3,297
    edited 2019-12-04 12:01
    Wuerfel_21 wrote: »
    The top of the screen looks like the V component isn't being decoded at all (which in turn looks very similar to a colorblindness simulation filter).
    I wonder if changing the CQ parameter dynamically does anything nasty to the signal for a while? In the code I am just applying the new CQ in the hsync blanking period then flipping to the alternate value with the XOR mask for the next scan line.

    The code doing it is this:
    hsync                       xzero   m_sn, hsync1            'generate the sync pulse
     		 	    setcq   cq
                                wrlong  status, statusaddr      'update the sync status per line
    dobreeze                    xcont   m_br, hsync0            'do breezeway before colour burst
    doburst                     xcont   m_cb, colourburst       'do the PAL/NTSC colour burst
    flipref                     xor     cq, cqflip              'toggle PAL colour ref per scanline
    bp          _ret_           xcont   m_bv, hsync0            'generate the back porch
    

    I might try moving the setcq operation later after the breezeway streamer command is issued to be sure that the colour space converter change is not during any active portion of the previous scanline in case that might be upsetting things perhaps.
    Have you got access to any older, more analog PAL TVs? Testing on such a set might give more insight

    No nothing else at home to test with right now, just a plasma TV and that Dell LCD monitor taking PAL, no fancy PVM or old school CRT TVs here unfortunately.
    EDIT: Another thing: does the color carrier line up properly with its 64µs-delayed self?

    Not sure, can I test easily for this with an oscilloscope? Can a cheap dual input scope with delayed trigger do anything like this? I don't think the basic Rigol unit I use can do much like that. It's pretty basic and the trigger options are limited.

    Update: I thought the colour carrier phase should be advanced by 1/4 of its wavelength plus also negated 64 microseconds later. So more like 270 degree change or something. Why should it line up?
  • roglohrogloh Posts: 3,297
    edited 2019-12-04 13:05
    I also captured the colour bar scan line output I am sending from the P2 on my scope. Seems like the correct order being sent and generated here for Y. Hopefully this tells us if U, V might be getting computed correctly for this sequence as well. I haven't checked every value on the scope to match it up yet, but they seem to be decreasing in the expected order based on their colour contributions to Y which is a start. The excursions from the Y value may also tell us something perhaps.

    White (R+G+B) 0.3 + 0.59 + 0.11 = 1, Y=540mV above black
    Yellow (R+G) 0.3 + 0.59 = 0.89, [measured colour = ~280mVp-p, Y=480mV, 480/540 = 0.89]
    Cyan (B+G) 0.11 + 0.59 = 0.70, [measured colour = ~400mVp-p, Y=380mV, 380/540 = 0.70]
    Green (G) 0.59 [measured colour = ~380mVp-p, Y=320mV, 320/540=0.59]
    Magenta (R+B) 0.3 + 0.11 = 0.41 [measured colour = ~380mVp-p, Y=210mV, 210/540 = 0.39]
    Red 0.3 [measured colour = ~400mVp-p, Y=150mV, 150/540 = 0.28]
    Blue 0.11 [measured colour = ~300mVp-p, Y=60mV, 60/540 = 0.11]
    Black 0

    NewFile6.bmp

    Update: also measured the colour oscillation excursions overlayed on Y and added numbers above for each coloured bar.

    Update2: also measured the Y levels of each above (using S-video output to eliminate chroma making it easier to measure). They line up with theory pretty well too for SAT=70, certainly within measurement error from the scope.
  • potatoheadpotatohead Posts: 10,188
    edited 2019-12-04 12:24
    I have an analog PAL set and am doing training in Philly right now.

    I return end of week. Point me to some code and I will fire it up and report back.


  • Ok will get back to you later potatohead unless I solve it before then. Do remind me if I forget.
  • Will do. All I have right now is HDMI. I did take my P2 to jam on in the evenings. Good times.
  • If it were me, I would comment one of your features out and link the color parameters to some buttons.

    Tune it in close, then work backward to sort the math.
  • evanhevanh Posts: 11,045
    I've got a couple of old style analogue CRT PAL TVs. The newer one is a pokey little 12" I got about 15 years ago. The older one is my brother's 27" that ended up here when they got a plasma.

  • rogloh wrote: »
    EDIT: Another thing: does the color carrier line up properly with its 64µs-delayed self?

    Not sure, can I test easily for this with an oscilloscope? Can a cheap dual input scope with delayed trigger do anything like this? I don't think the basic Rigol unit I use can do much like that. It's pretty basic and the trigger options are limited.

    Update: I thought the colour carrier phase should be advanced by 1/4 of its wavelength plus also negated 64 microseconds later. So more like 270 degree change or something. Why should it line up?

    Looking at the block diagram of a PAL decoder, it seems to me that the carrier ought to line up with what comes out of the 64µs delay line for it to make sense. Maybe I'm wrong here, though.

  • A quick test for chip, P1 PAL and NTSC . I do not have a P2 yet.

    On a Tektronix WFM7100, waveform vector scoop (broadcast grade)

    TV.spin "v1.1 - 17 May 2006"
    Propeller project board, pin8...10 1k; 560; 270 resistors


    -The carrier is not stable to match the PAL norm.
    -The carrier is not exactly at 45° you have calibration marks on "WFM7100_1D0206_2019-Dec-04_16-20-21.bmp"
    "WFM7100_1D0206_2019-Dec-04_16-25-07.bmp" is in V+ mode, adding the phase together.


    I put all the pictures and used code in the zip

  • jmgjmg Posts: 14,676
    rogloh wrote: »
    Update: I thought the colour carrier phase should be advanced by 1/4 of its wavelength plus also negated 64 microseconds later. So more like 270 degree change or something. Why should it line up?

    My understanding of PAL was that the burst phase flips +/- 45 degrees each line, but averages to zero.
    It needs to average to zero, to have the PLL properly lock.
  • jmg wrote: »
    My understanding of PAL was that the burst phase flips +/- 45 degrees each line, but averages to zero.
    It needs to average to zero, to have the PLL properly lock.

    Yes according to the diagrams I've been looking at online the burst phase seems to alternate between 225 and 135 on the UV plane and the average is 180 degrees, as would be sent for NTSC. I've tried to solve for RGB values that give these vectors or close to them, maybe there is still some error from the scaling due to SAT and/or CORDIC stuff or my math is wrong.

    A difficulty or delay to lock a PLL might be the issue seen at the start of the frame on my plasma. Also on my Dell LCD I haven't been able to get it to sync up at all with the real swinging burst. So perhaps this burst phase average is still non-zero due to the parameters I am using not being 100% right yet. I do see some slight ringing on top of the white colour bar on the scope when I zoomed in, will have to compare that with NTSC output. Maybe quantisation error somewhere.

  • jmgjmg Posts: 14,676
    rogloh wrote: »
    A difficulty or delay to lock a PLL might be the issue seen at the start of the frame on my plasma. Also on my Dell LCD I haven't been able to get it to sync up at all with the real swinging burst. So perhaps this burst phase average is still non-zero due to the parameters I am using not being 100% right yet.

    Thinking about that, any lock should only happen once (as signal first arrives), and not be per-frame.
    Do you send a correct burst during the whole frame sync ?
  • Ltech wrote: »
    A quick test for chip, P1 PAL and NTSC . I do not have a P2 yet.

    On a Tektronix WFM7100, waveform vector scoop (broadcast grade)

    TV.spin "v1.1 - 17 May 2006"
    Propeller project board, pin8...10 1k; 560; 270 resistors


    -The carrier is not stable to match the PAL norm.
    -The carrier is not exactly at 45° you have calibration marks on "WFM7100_1D0206_2019-Dec-04_16-20-21.bmp"
    "WFM7100_1D0206_2019-Dec-04_16-25-07.bmp" is in V+ mode, adding the phase together.


    I put all the pictures and used code in the zip

    Nice work Ltech. If only you had a P2 you could compare the burst phase angle too to see what it is.

    In both your PAL and NTSC oscilloscope captures of three scan lines together, do you know why the middle lines are not showing a full colour burst? That looks strange to me.
  • roglohrogloh Posts: 3,297
    edited 2019-12-04 21:44
    jmg wrote: »
    Thinking about that, any lock should only happen once (as signal first arrives), and not be per-frame.
    Do you send a correct burst during the whole frame sync ?

    No colour burst sync is normally sent in the vsync portion with serration and equalization pulses. However there is the thing with burst blanking of the first scanline preceding and following that is meant to happen over 8 fields. Right now I am not 100% adhering to that due to not having space for coding all the logic required. If TVs are picky about this it might be something they wouldn't like.
    Eg. It looks like you are meant to send colour bursts according to the following table:
    field  first burst  final burst
            scan line    scan line
       1       7           309
       2       319         621
       3       6           310
       4       320         622
       5       7           309 
       6       319         621
       7       6           310
       8       320         622   
    

    Fields 1-4 have one type of U phase, while 5-8 have the reverse. This is due to the colour burst being related to 1135/4 * scanline frequency, so it takes 4 scanlines to complete the full cycle. Also the half line from interlacing and 625 lines/frame means the entire cycle to repeat the same phase takes 8 fields.

    In my case I think I still have the burst sent on lines 310 and 623 at the end of all fields and it begins on line 7 or 319 at the start of the fields. Perhaps some TVs are picky and need it to begin on line 6 in some cases. The code below shows the interlaced PAL sync logic (NTSC is a bit different but shares this code with some patches).
                testb   fieldcount, #0 wc       'field interlace state
    cy    if_c  call    #\hsync                 'deal with interlaced field lines
    ci    if_c  xcont   m_slim, hsync0          'send a slim half line
    cq
    bitmask
    ntsc1       rep #2, #5-0                    'defaults to PAL
    muxmask     xcont   sync_000, hsync1        'generate horizontal blanking/sync
    offset      xcont   sync_001, hsync0 
    
                decod   status, #31             'update status - in vertical sync
    bpp         setbyte status, fieldcount, #2  'update field counter in status
    writestat   wrlong  status, statusaddr
    
    ntsc2       rep #2, #5-0                    'defaults to PAL
                xcont   sync_002, hsync1        'generate horizontal blanking/sync
                xcont   sync_003, hsync0 
    
    ntsc3       rep #2, #5-0                    'defaults to PAL
                xcont   sync_000, hsync1        'generate horizontal blanking/sync
                xcont   sync_001, hsync0 
                                                'PAL variant below is the default 
                                                'while NTSC gets patched
    ntsc4 if_c  xcont   sync_000, hsync1        'generate horizontal blanking/sync
    ntsc5 if_c  xcont   sync_001, hsync0 
    ntsc6       xcont   m_half, hsync0          'remainder of interlaced line (PAL)
    
    
  • potatohead wrote: »
    If it were me, I would comment one of your features out and link the color parameters to some buttons.

    Tune it in close, then work backward to sort the math.

    Yes, I think this makes sense too and was almost about to start doing that yesterday. A mouse slider for some cq/ci parameters would be nice and might give me an excuse to finally add in garryj's USB code and use my mouse sprite.
  • There you go. Patch it together later, or maybe give in and start making it modular...
  • LOL, I don't really want to go invent a full blown GUI right now, I just want PAL to work.
  • jmgjmg Posts: 14,676
    edited 2019-12-04 22:19
    rogloh wrote: »
    jmg wrote: »
    Thinking about that, any lock should only happen once (as signal first arrives), and not be per-frame.
    Do you send a correct burst during the whole frame sync ?

    No colour burst sync is normally sent in the vsync portion with serration and equalization pulses. However there is the thing with burst blanking of the first scanline preceding and following that is meant to happen over 8 fields. Right now I am not 100% adhering to that due to not having space for coding all the logic required. If TVs are picky about this it might be something they wouldn't like.
    Eg. It looks like you are meant to send colour bursts according to the following table:
    field  first burst  final burst
            scan line    scan line
       1       7           309
       2       319         621
       3       6           310
       4       320         622
       5       7           309 
       6       319         621
       7       6           310
       8       320         622   
    
    Oops, yes, you are right, I was relying on memory, the archives here have this info (attached)
    (There must be a blanking-gate on the burst phase detector for no-burst cases)

    Maybe the phase matters - this shows resume burst is the same phase as the last-sent burst in all cases ?
    It does rather look like the TV is re-locking when it should not need to.

    Does the burst NCO run cleanly across the frame sync time ?
    The doc gives fLine = (Fsc-25)/(284-1/4), so I make a 10 line pause, equal to 2837.516 cycles of burst.
    rogloh wrote: »
    In my case I think I still have the burst sent on lines 310 and 623 at the end of all fields and it begins on line 7 or 319 at the start of the fields. Perhaps some TVs are picky and need it to begin on line 6 in some cases.
    Depends on their design I guess.
    In an analog burst-gated PLL, +/1 one burst will have little effect, but it will be vital that all bursts overlay on a locked ideal, with that -180' +/-45, to avoid disturbing lock.
    1750 x 1430 - 2M
  • Oh, I meant just in terms of driver features. Should PAL require a bit more...
  • cgraceycgracey Posts: 13,610
    If you make OUT high on the PAL video pin, it will enable the ADC which will report its bitstream on IN. Then, use a nearby smart pin in SCOPE mode with the shortest filter and set trigger levels low to trigger on the SYNC dip. Then, another cog can capture the 8-bit sample stream to hub RAM for display, like in the HDMI scope demo. Then, You won't need an oscilloscope. The P2 will do the job.
  • jmg wrote: »
    In an analog burst-gated PLL, +/1 one burst will have little effect, but it will be vital that all bursts overlay on a locked ideal, with that -180' +/-45, to avoid disturbing lock.

    Hmm, this is interesting especially given the fact that my plasma seemed to have difficulty at the top of the screen and that might be hinting at this being a problem. I need to see if the these overlap with my scheme. They may not right now.
Sign In or Register to comment.