Shop OBEX P1 Docs P2 Docs Learn Events
All PASM2 gurus - help optimizing a text driver over DVI? - Page 17 — Parallax Forums

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

1141517192029

Comments

  • potatoheadpotatohead Posts: 10,255
    edited 2019-11-26 04:30
    Thanks. I got this up next on deck. I will get to take a pass at it soon.

    Yeah, the slow beat does not impact much except text and thin lines. Sticks right out on both of those. The spiral is best case. It can be seen on the bird when color saturation is high.

    I may want to try both fixed phase change, and or a color burst created from pixels too.

    Have you viewed it on Svideo? This may not actually be a thing in that configuration.

    I suppose we can also just use a multiple of the color burst for a crystal input too.

  • roglohrogloh Posts: 5,222
    edited 2019-11-26 04:44
    S-video looks really solid now with this change. It does still have a strange blurriness to some colours/positions on the screen though which is weird. Might be my Dell LCD doing it, not sure.

    A colour burst from pixels may help if it locks it down. In my driver's case though I don't think I'll have much spare COG space to do repeated pixel streamer commands though unless it could be streamed out directly from memory perhaps with a single command?

    Update: The S-video blurriness seems to be particular colour combinations not the positions. It's more noticeable in 80 column mode vs 40 columns and it repeats when the same combinations are used. Simple green on black is very clean in 80 columns with S-video but has some slowly oscillating red/blue fringing with CVBS plus an annoying flicker frequency which would be nice to eliminate if possible.
  • roglohrogloh Posts: 5,222
    edited 2019-11-26 04:33
    potatohead wrote: »

    I suppose we can also just use a multiple of the color burst for a crystal input too.

    Yes that might be the best way to improve quality and lock things down.
  • Color really is low resolution. Red on blue, for example, when visualized as pixels, are 4 pixels apart, when there are 640 pixels per line.

    With phase shift, one, or the other are resolved nicely enough to make out.

    Really good circuits can interpolate. But, that 3.58Mhz is what it is.
  • Yeah light VGA red on dark VGA green is a bad one so is light VGA blue on the same green. It just can't be resolved. No matter, this is normal, certain colours don't work well together on TVs due to low resolution and I already knew this. I'm glad the S-video image is more stable now though. Before it was shimmering which was due to the xzero per scanline.
  • evanhevanh Posts: 15,278
    rogloh wrote: »
    ... On the scope I see the two colourburst phases and it is only slipping it's phase very slowly now (maybe 1 burst cycle in ~15 seconds).
    2**32 / 250M = 17.18 seconds

  • roglohrogloh Posts: 5,222
    edited 2019-11-26 09:18
    2**32 / 250M = 17.18 seconds

    Yes that'd probably be it. It's hard to know exactly when exactly it completes the full phase slip just by looking on the scope due to the thickness of the traces etc, but that would be it.

    I was wondering if you'd get a better picture if the NTSC line was set to exactly 455 pixels wide from the streamer perspective. This way in theory there are 227.5 colour burst frequency oscillations per line and it lines up exactly with two pixels per colour burst. Both oscillators (XFRQ+CFRQ) may be able to stay harmonically locked and slip synchronously then perhaps...?

    I'll give it a go.


    Update: gave it a go and saw the colour burst stay perfectly locked on each scan line on the scope with no slipping, but I couldn't get the monitor to show anything or sync to it, I suspect it was probably too far off the colour frequency for it to like it.

    I used the following settings:
    229MHz clocked P2
    XFRQ = 1<<26
    CFRQ = 1<<26

    Horizontal Front Porch = 10 pixels
    HSync = 34 pixels
    Breezeway = 7 pixels
    Colourburst = 18 pixels (9 cycles)
    Remaining H back porch = 51-18-7 = 26 pixels
    Active pixels = 360
    Total pixels = 455

    I'll keep trying perhaps with a colour frequency much closer to 3.579545MHz instead of 3.578125MHz.

    Update2: Yep that was it, I have a signal with a colour burst it likes now using XFRQ & CFRQ = 67135496 and all other parameters same as above. Colour phase seems locked and only flicker is showing up in the composite, no colour halo phasing, and the S-video is beautiful with a few blurry colour combinations but everything rock solid there by the looks of it. The 360 pixels seems like a better match for the colour resolution and any double wide text even better.

    Update3: Doubling everything for XFRQ but keeping CFRQ the same, also seemed to work and got it back to 720 active pixels but with 910 on the scan line instead of 858 and it showed 87 columns of the 90 on my LCD. You could trim this back to 80 with borders and/or adjustments to the porches. It probably brings the aspect ratio closer to 16:9 too which is helpful for widescreen monitors.
  • rogloh wrote: »
    I used the following settings:
    229MHz clocked P2
    XFRQ = 1<<26
    CFRQ = 1<<26

    Horizontal Front Porch = 10 pixels
    HSync = 34 pixels
    Breezeway = 7 pixels
    Colourburst = 18 pixels (9 cycles)
    Remaining H back porch = 51-18-7 = 26 pixels
    Active pixels = 360
    Total pixels = 455

    I'll keep trying perhaps with a colour frequency much closer to 3.579545MHz instead of 3.578125MHz.

    In case you haven't tried this,
    20 MHz * 126/11 = 64 * NTSC colour burst frequency (315/88 MHz) exactly.
  • Dang, you got to it faster than I can.

    The actual color frequency used should not matter too much. The TV will sync up to whatever got used and does so each colorburst. With NTSC, "never the same color" one can abuse just about any part of the signal. The most important thing is to do so consistently.

    With this problem, it's literally a beat frequency between the color system and the pixel clock. So long as that doesn't happen, whatever other error there is should play out just fine.



  • TonyB_ wrote: »
    In case you haven't tried this,
    20 MHz * 126/11 = 64 * NTSC colour burst frequency (315/88 MHz) exactly.

    Thanks! I was beginning to look for some such PLL ratio last night and was about to build a spreadsheet to see if I could come up with dividers/multipliers to try to get the perfect colour burst frequency, thanks for finding it.

    Even though this gets the frequency value spot on with no slips, It would be useful to try to let it run at other P2 frequencies. I know 229MHz already works which was pretty close but I think others should too. The key is probably in keeping the CFRQ/XFRQ integer related. However if they are not simple powers of two and one slips at say exactly 2x the other will the colour phase error accumulate over time I wonder? Perhaps we still need to keep them both the same value?

  • jmgjmg Posts: 15,149
    rogloh wrote: »
    I'll keep trying perhaps with a colour frequency much closer to 3.579545MHz instead of 3.578125MHz.

    Update2: Yep that was it, I have a signal with a colour burst it likes now using XFRQ & CFRQ = 67135496 and all other parameters same as above. Colour phase seems locked and only flicker is showing up in the composite, no colour halo phasing, and the S-video is beautiful with a few blurry colour combinations but everything rock solid there by the looks of it. The 360 pixels seems like a better match for the colour resolution and any double wide text even better.

    Update3: Doubling everything for XFRQ but keeping CFRQ the same, also seemed to work and got it back to 720 active pixels but with 910 on the scan line instead of 858 and it showed 87 columns of the 90 on my LCD. You could trim this back to 80 with borders and/or adjustments to the porches. It probably brings the aspect ratio closer to 16:9 too which is helpful for widescreen monitors.
    That makes sense, as TV's lock by pulling a crystal, usually trimmed to centre on the exact MHz.
    1-3.579545/ 3.578125 = -397ppm, which is rather too large to pull a crystal.


  • rogloh wrote: »
    TonyB_ wrote: »
    In case you haven't tried this,
    20 MHz * 126/11 = 64 * NTSC colour burst frequency (315/88 MHz) exactly.

    Thanks! I was beginning to look for some such PLL ratio last night and was about to build a spreadsheet to see if I could come up with dividers/multipliers to try to get the perfect colour burst frequency, thanks for finding it.

    What you need is a calculator that gives the Best Rational Approximations to Real Numbers, something just like this:
    http://www.maths.surrey.ac.uk/hosted-sites/R.Knott/Fibonacci/cfINTRO.html#section8

    Select denominators from 1 to 64 (P2 limit) of 315/88*64/20
    or some other expression

    I've been using an earlier version of this excellent aid for several years that I saved to a local drive.
  • Very cool Tony.
  • Do you guys know a good way to compute the colour burst RGB values for PAL?
  • I think I essentially need to rotate Chip's numbers by +/- 45 degrees to get the two burst values and alternate between them, but I'm not sure how Chip figured out those numbers ($50_70_00 for RGB) in the first place and also I'm not sure they yield the expected 40 IRE unit pk-pk amplitude, looks like quite a bit less on the scope.
  • The rotation should work. I am not where I can check the IRE values. NTSC won't care much, PAL definitely will.

  • potatoheadpotatohead Posts: 10,255
    edited 2019-11-27 04:36
    http://www.vsdsp-forum.com/phpbb/viewtopic.php?t=2206

    For PAL the proper hicolor yuv video palette is P:C4:B44:A44:Y84:N04, which results in colour burst amplitude 5.7, phase 135.0 degrees

  • The actual burst "color" is always the same - the phase of the color carrier is inverted on the entire line.
    (I think that you think that just the burst changes phase, if I'm not mistaken.)
  • Yes Wuerfel_21 I thought/hoped I could just flip the colourburst "colour" to a different set of RGB values on each alternating line to invert its phase just during the burst. Do I need to do something different or in addition to this for all the pixels on the line, and if so, how should it be done with the P2 modulator if you've taken a look at how it works?

  • cgraceycgracey Posts: 14,133
    I read a long time ago that these video acronyms have special meanings...

    NTSC - Never The Same Color (I don't know if that's true)
    PAL - Pay A Lot (no cheap TV's for the Europeans)
    SECAM - Something Essentially Contrary to the American Method (SECAM was a French thing)
  • potatoheadpotatohead Posts: 10,255
    edited 2019-11-27 05:50
    With PAL, it's 45 degree phase changes away from the reference color. That reference may well be the same as the NTSC one, or it can be, if you want it to be. I think it can be.

    If you've computed the phase changes, yes. Just different pixels. Nothing need be done for the other pixels. It's really all about phase changes every other line.

    And, when done properly, with the signal non-interlaced to make 50Hz frame rates, this allows for vertical color artifacting like NTSC allows for horizontal color artifacting. This was used in the demoscene to get more colors from the C64 regularly, and was also featured in some games.

    I have a PVM, PAL capable. Actually will do SECAM too.

    Is the driver code at top of thread current? Do we have an NTSC setup demo yet?



  • roglohrogloh Posts: 5,222
    edited 2019-11-27 06:00
    Lol Chip. I had heard the NTSC one, but not the others.

    Do you happen to know how you came up with the $50_70_00 RGB values for NTSC burst? If I saw how that was done I might be able to do one for PAL hopefully.

    @potatohead the stuff you added above doesn't help me that much with the colour burst RGB as it looks like it relates to someone's custom windows palette tool I don't have, when I took a quick look at your link.
  • Hmm, a cursory glance reveals that there seems to be no way of directly affecting the modulator's phase...
    Is this seriously the same old design flaw from the P1 video generator? How did that one fly past everyone's radar?

    Anyways, it should be possible to invert the chroma phase by flipping between two sets of colorspace coefficients. I think it's just a matter of inverting everything in CQ (except the lowest byte, obviously)
  • Yeah, I figured the degree was worth noting. But yes, after looking deeper, I see the same thing. Not a good resource.

    Re: Phase

    I am pretty sure that's what was done for PAL on the HOT edition. I no longer have that code, but someone did a color text driver NTSC, PAL...

    @rogloh I have a bit of time. Any chance you can point me to a simple, compile and display setup for NTSC? Right now, I'm working through the docs, but would be nice to have a confirmed known good setup.

  • roglohrogloh Posts: 5,222
    edited 2019-11-27 07:49
    Wuerfel_21 wrote: »
    Hmm, a cursory glance reveals that there seems to be no way of directly affecting the modulator's phase...
    Is this seriously the same old design flaw from the P1 video generator? How did that one fly past everyone's radar?

    Anyways, it should be possible to invert the chroma phase by flipping between two sets of colorspace coefficients. I think it's just a matter of inverting everything in CQ (except the lowest byte, obviously)


    Ok if so that is not ideal but maybe workable. It would require me to keep the CQ value around, and xor it and issue another SETCQ.

    I was already XORing the colourburst (with a register holding 0) in preparation for PAL, so I guess that goes away and I would do this now.

    not cq ' flip it
    xor cq, #$ff ' restore low byte
    setcq cq ' update it

    Plus I'd retain cq in a register from where it was loaded per frame. If I shuffle the display parameter order to put cq earlier I can avoid the added copy instruction it would otherwise need.



    So if this worked and was the way to do PAL basically I would:

    lose my colour flip reg (-1 long)
    lose the xor colourburst, colorflip operation (-1 long)
    then add in the above code plus the extra cq register (+4 longs)

    Maybe this only adds 2 more instructions in my spare 5 in the driver. I hope it is not more than that.


  • potatohead wrote: »
    Is the driver code at top of thread current? Do we have an NTSC setup demo yet?
    The driver code posted in the first post of my DVI driver thread is still the same beta code as originally posted. It is not the updated NTSC stuff I worked on last night and am still playing with that improves the output quality, but it is usable, you just enable the line in the complex demo that initializes the display to use the S-VIDEO output instead of the one for VGA or DVI etc. If you've been reading up what I posted in these threads since yesterday you might be able to make the same changes I did to improve it with Chip's timing etc. I think I've mostly documented what I changed.
  • Got it. That exceeds my time this evening. I'll come back for another pass in a bit. I may take Chip's simple one to experiment on too. I've got small bits of time to work with right now. PITA, but is what it is.

    :smiley:
  • cgracey wrote: »
    I read a long time ago that these video acronyms have special meanings...

    NTSC - Never The Same Color (I don't know if that's true)

    I think it refers to how the phase of the color carrier can shift in strange ways (dependent on the underlying luma, so drifting relative to the burst!) in an over-the-air RF transmission due to linearity problems both inside the TV (especially bad on pre-solidstate sets) and up the transmission chain, as well as conditions such as the weather (yes). PAL averages(?) the seperated chroma component over two lines, so ANY hue distortion is turned into a saturation distortion.
    SECAM doesn't suffer from that problem at all, with it only modulating one color channel per line. It does however suffer from significantly higher complexity (especially in encoding. Few computers ever directly generated it. The french versions of many a system often just came with RGB SCART cables...) and significantly worse quality.

    Anyways, when dealing with modern(-ish) TVs and baseband AV signals, NTSC colors are infact, often the same.
  • Wuerfel_21Wuerfel_21 Posts: 4,601
    edited 2019-11-27 06:37
    rogloh wrote: »
    I was alreadying XORing the colourburst (with a register holding 0) in preparation for PAL, so I guess that goes away and I would do this now.

    not cq ' flip it
    xor cq, $ff ' restore low byte
    setcq cq ' update it

    Plus I'd retain cq in a register from where it was loaded per frame. If I shuffle the display parameter order to put cq earlier I can avoid the added copy instruction it would otherwise need.
    NOT is off by one from a proper per-byte NEG. Should be fine, but not ideal.
    How about instead of
    not cq  ' flip it
    xor cq, $ff ' restore low byte
    
    have
    xor cq, some_constant
    
    where some_constant is the precalculated XOR of inverted phase and normal phase?

  • roglohrogloh Posts: 5,222
    edited 2019-11-27 06:41
    Sure we could do that, but if the CQ is dynamic it requires re-computing this some_constant per frame which adds another instruction. Perhaps CQ is not going to be allowed to be dynamic for PAL/NTSC anyway. From the high level application I mean. I still allow it to be changed dynamically for VGA use.
Sign In or Register to comment.