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

11011121416

Comments

  • roglohrogloh Posts: 1,446
    edited 2019-10-30 - 04:15:17
    I got the component colour working now (in SD resolution) on my Dell LCD with my driver. It looks rather nice. I used the coefficients Wuerful_21 mentioned. When mapped to a 0.7Vpp Y signal and 1Vp-p Pr Pb signals I believe you get this...
    Y  =  (27/128) x R +  (53/128) x G +  (10/128) x B
    Pb = (-22/128) x R + (-42/128) x G +  (64/128) x B
    Pr =  (64/128) x R + (-53/128) x G + (-10/128) x B
    
    Offset for Y is 76 in CY[7:0] to leave -0.3V headroom for sync.
    Offset for Pb/Pr is 128, in CI[7:0] and CQ[7:0]

    Looks somewhat colour saturated on my monitor so I might like to scale the colour difference signals down just a little bit. In the link below I read that PAL component signals uses 700mVp-p, while NTSC uses 933mVp-p both for 100% colour bars, not the full 1Vp-p range but this is only one source and it's likely there'll be other values used.

    https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/1184.html

    I think I'll make the 3 colour space registers updatable per frame in my driver so there are ways to adjust it dynamically.

    I looked at Chip's HD component video stuff too, the sync for that looks a bit trickier with its 3 levels. I'll have to figure out how to do it right in the driver in time, but for now a least we can have some SD component support (tested at VGA resolution on one device so far).
  • roglohrogloh Posts: 1,446
    edited 2019-10-30 - 05:19:55
    Here's a picture of Rayman's bird pic, on my LCD monitor in Picture By Picture mode. One input is the component on the left, the other is DVI on the right. I spawned two COG's outputting the same frame, one in DVI mode and the other in component mode. I should spawn another COG in VGA mode and feed it to my Sony.

    The DVI input does look quite bright but the colours seem nicer nicer on the component input now I adjusted it a bit. I dialled them back to 75% or so. I don't know what the LCD is doing to these images internally, it's probably doing something different there anyway.

    UPDATE: Just tried 1280x720p60 timing on my LCD and it worked in component mode, along with on my Plasma, so you many not need that fancy HD triple level sync on all devices for it to work. Photo's looks really amazing on the plasma. Now need to test full HD...

    IMG_2560.png
    1280 x 829 - 1M
  • That's intriguing, I can select 576i on HDMI with my DVR and the plasma TV reports it as 576i on the HDMI input.

    Then the question becomes: What is the HDMI clock rate in this case? Is it lower than 250 MHz or is there massive blanking times?

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • roglohrogloh Posts: 1,446
    edited 2019-10-30 - 10:25:23
    @evanh, No massive blanking for 576i over HDMI. It does pixel repetition to get the pixel transfers up over the minimum 250MHz, actually using 270MHz HDMI timing I believe. The TV then throws away half the pixels.

    I wasn't able to get 1920x1080p recognised by my Plasma over component with the P2. Not sure what gives there. I am reading it's specs and it says it can do 1080p it but it's listed under the HDMI section and I can't find any component only specs in the manual. I do have a PVR that upscales it's TV source to component 1080i so if I can yank it out and move it over from another room I might be able to try that too. Perhaps the Pioneer plasma's component input would be limited to 1080i which probably makes sense given the age of this thing (mid-late 2000's).

    Was 1080p over component ever really a thing?
  • evanhevanh Posts: 8,072
    edited 2019-10-30 - 10:23:54
    rogloh wrote: »
    @evanh, No massive blanking for 576i over HDMI. It does pixel repetition to get the pixel transfers up over the minimum 250MHz, actually using 270MHz HDMI timing I believe. The TV then throws away half the pixels.
    Really?! Boy, does that sound like a hack. Reiterates the blindness of the 30 kHz minimum spec.

    Was 1080p over component ever really a thing?
    Dunno, presumably just not supported. Probably considered too fast for analogue to carry cleanly.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Chip's 1080 component example code didn't work either. When I run it looks like the TV is about to show something then it blanks out. Input status detects something but nothing shown on screen. I noticed Chip's code was doing something weird with the number of vertical sync pulses, and I changed it to something I read online for 1080 progressive (from Figure 12A in Rec ITU-R BT.709-4) where you do 4 front porch blank lines, then 5 lines of negative sync, then 36 lines of back porch blanks then your 1080 active lines, still using tri-level hsync pulses. Still didn't help unfortunately. Might be just my TV's limits.

  • evanh wrote: »
    Every 50 Hz capable TV can do that. It's just interlaced with both interlaced fields from the same frame in time.

    Well, maybe that is true. I do have a 50/60 hz capable LCD that do
    evanh wrote: »
    Every 50 Hz capable TV can do that. It's just interlaced with both interlaced fields from the same frame in time.

    Well, 48 hz is different from 50. The 24hz is to eliminate the odd jitter in motion caused by timing mismatch. My high end plasma does 24p and my other sets will do 50/60, but not 24p specifically. One can tell on slow, grand camera dolly in scenes easily, along with the mode indicator not showing 24p.

    To get it, a specially mastered blue ray is needed. 24p is shown in the modes list on the back of the packaging. Not all players appear to offer it either.

    I mentioned it because there may be signal options available that are not otherwise.

    Can't wait to join the fun!

    Re: 1080p analog

    Not all sets will take it in my experience. Official support ends at 1080i. Thank the movie studios for that one.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • roglohrogloh Posts: 1,446
    edited 2019-10-31 - 01:56:49
    Got the scope out today to see exactly what the P2 was outputting and played with sync pulses accord to some HDTV timing information found in this pdf...

    https://www.appliedelectronics.com/documents/Guide to Standard HD Digital Video Measurements.pdf

    I then tweaked Chip's demo code to support 1080i. I now have it working both on my Pioneer plasma and Dell LCD via component at 74.25MHz pixel rate, with the upside down birds due to the reversed bmp file order. Happy now. Chip's code I modified for 1080i is also attached below.

    IMG_2564.jpg
    '***************************************************
    '*  HDTV 1080i component Y-Pb-Pr, 16bpp 5:6:5 RGB  *
    '***************************************************
    
    CON
    
      s = 60	'scales DAC output (s = 0..128)
    
      sync_color1	= $000000_00
      sync_color2	= (-105*s/128) & $FF	'sync- on all three outputs
      sync_color3	= (+105*s/128) & $FF	'sync+ on all three outputs
    
    BASEPIN     = 8
    
    DAT		org
    '
    '
    ' Setup
    '
    		hubset	clkinit1		'set clock to 148.5MHz
    		waitx	clkwait
    		hubset	clkinit2
    
    		'rdfast	##640*350*2/64,##$1000	'set rdfast to wrap on bitmap
    
    		setxfrq ##$4000_0000		'set transfer frequency to clk rate/2
    
    		setcy	cy_			'Y	set colorspace for Y-Pb-Pr
    		setci	ci_			'Pb
    		setcq	cq_			'Pr
    		setcmod	#%01_1_111_0		'enable colorspace conversion
    
    		wrpin	dacmode_rgb,#(2<<6) + BASEPIN + 1	'enable dac modes in pins 3,2,1 for Y,Pb,Pr
    		drvl	#(2<<6) + BASEPIN + 1		'enable dac outputs
    '
    '
    ' Field loop
    '
                    mov     odd, #1         'odd/even field
    field	
    
        	        mov	x,#14 			'top blanks
    if_c            add     x,#1
    		call	#blank
    
    		rdfast	##640*350*2/64,##$1000	'set rdfast to wrap on bitmap
    
    		mov     x,##540         	'set visible lines
    line		call	#hsync			'do horizontal sync
    		xcont	m_60,#sync_color1	'porch
    		xcont	m_1920v,#1		'visible line
    		djnz    x,#line           	'another line?
    
                    xor     odd, #1 wc
    
    		mov     x,#2	     	'bottom blanks
    		call	#blank
    
    if_c            call    #hsync
    if_c	        xcont	m_880,#sync_color1      ' high vsync 1/2 width
           
    		mov	x,#10 			'low vertical syncs 1/2 width
    .vsync1		call	#hsync
    		xcont	m_880,#sync_color2
    		djnz	x,#.vsync1
    
    		mov     x,#1            'high vertical syncs 1/2 width
      if_nc         add     x,#1
    .vsync2		call	#hsync
    		xcont	m_880,#sync_color1
    		djnz	x,#.vsync2
    
                    jmp     #field                  'loop
    '
    '
    ' Subroutines
    '
    blank		call	#hsync			'blank lines
    		xcont	m_1980,#sync_color1
    	_ret_	djnz	x,#blank
    
    hsync		xcont	m_44,#sync_color1	'horizontal sync
    		xcont	m_44,#sync_color2
    		xcont	m_44,#sync_color3
    	_ret_	xzero	m_88,#sync_color1
    '
    '
    ' Initialized data
    '
    clkinit1	long	%1_100111_0100101000_1111_10_00		'20MHz / 40 * 297 * 1 = 148.5MHz
    clkinit2	long	%1_100111_0100101000_1111_10_11
    clkwait		long	25_000_000 / 200
    
    dacmode_rgb	long	%0000_0000_000_1011100000000_01_00000_0	'75-ohm 2.0V
    
    cy_		long	((+27*s/128) & $FF) << 24 + ((+92*s/128) & $FF) << 16 + (( +9*s/128) & $FF) << 8 + 80
    ci_		long	((-15*s/128) & $FF) << 24 + ((-49*s/128) & $FF) << 16 + ((+64*s/128) & $FF) << 8 + 128
    cq_		long	((+64*s/128) & $FF) << 24 + ((-58*s/128) & $FF) << 16 + (( -6*s/128) & $FF) << 8 + 128
    
    m_44		long	$7F010000+44		'syncs/blanks
    m_88		long	$7F010000+88
    m_60		long	$7F010000+60
    m_880		long	$7F010000+880
    m_1920		long	$7F010000+1920
    m_1980		long	$7F010000+1980
    
    m_1920v		long	$BF050000+1920		'visible rfword rgb16 (5:6:5)
    
    x		res	1
    odd             res 1
    
    '
    '
    ' Bitmap
    '
    		orgh	$1000 - 70		'justify pixels at $1000
    		file	"birds_16bpp.bmp"	'rayman
    
    1280 x 960 - 167K
  • Ah thats more like it! So good that you got that sorted.
  • Yeah, if I can squeeze the interlaced part and three level sync into my driver I will, as 1080i may be popular over component for (older) HDTVs. Since I restructured some init code and made more use of LUT RAM I have about 30 COGRAM longs left and I still want a couple of things (sprite/pass through mode, and sync status) to put in before then but its almost complete. I keep saying that, then adding more :lol: .

    On the P1 in the past I've found it's also handy/kind to not fill COGRAM 100% so you can leave a little space for later experimenting/debug etc. But it is a precious commodity so if I need it I use it.

    In time people may like other capabilities like NTSC composite, Y/C outputs, HDMI framing etc, but they might require slightly different codebases to be initialized at startup time, which should now be possible by the way I do things. I like the idea that one driver could pretty much support any type of video output, selectable at COG startup time, so your application code can mostly remain the same while still supporting different outputs, unlike the P1 where you mostly had to locate a specific driver for a given output type or resolution.

    One question, will SD PAL be 100% supportable by the P2, given the way the chroma signal is done? I know PAL requires phase reversals which might have been why the P1 had some problems with it, but I'm not sure as I never really played with composite that much on the P1, predominantly it was just VGA.
  • The problem with PAL on P1 seems to be twofold:
    - P1 counter PLLs seem to have difficulty generating 4.43MHz*16 from 80MHz master clock. Not a problem on P2?
    - Some TVs seem picky about horizontal timing (due to using a fixed-length analog delay line to correlate chroma from the previous line with the current line)

    The phase reversal basically just means inverting the V (or in P2 terms, Q) coefficient's sign every line, as far as I understand.
  • roglohrogloh Posts: 1,446
    edited 2019-11-02 - 23:57:05
    So I was wondering this morning, what do you do on the P2 to generate a colour burst? Do you just send a single value with the I and Q fixed and let the colour modulator oscillator cycle through its values at its own SETCFRQ programmed rate thereby generating a counting pattern output in IQ[7:0], or is there some other special burst pattern you need to construct and output?

    I am presuming the former approach would apply as you'd probably want a pure reference colour "tone", though perhaps it also gets flipped for PAL every two lines. I still need to dig into how it all works a bit more.
  • jmgjmg Posts: 14,019
    rogloh wrote: »
    So I was wondering this morning, what do you do on the P2 to generate a colour burst? Do you just send a single value with the I and Q fixed and let the colour modulator oscillator cycle through its values at its own SETCFRQ programmed rate thereby generating a counting pattern output in IQ[7:0], or is there some other special burst pattern you need to construct and output?

    I am presuming the former approach would apply as you'd probably want a pure reference colour "tone", though perhaps it also gets flipped for PAL every two lines. I still need to dig into how it all works a bit more.
    The ideal would be to adjust phase only on each line, so that the average frequency (which the TV's crystal PLL-lock to) stays correctly precise.
    I'm not sure if the Smartpins support phase adjust ?
  • I think the colour space converter and modulator needs to do it by the looks of the P2 video output design. I guess you could mix in signals from another pin but that is not ideal.
  • roglohrogloh Posts: 1,446
    edited 2019-11-03 - 00:38:46
    Just read this on Wikipedia...related to PAL.

    "Since the carrier is not transmitted with the video information it has to be generated locally in the receiver. In order that the phase of this locally generated signal can match the transmitted information, a 10 cycle burst of colour subcarrier is added to the video signal shortly after the line sync pulse, but before the picture information, during the so-called back porch. This colour burst is not actually in phase with the original colour subcarrier, but leads it by 45 degrees on the odd lines and lags it by 45 degrees on the even lines. This swinging burst enables the colour decoder circuitry to distinguish the phase of the R-Y vector which reverses every line."

    So for PAL it looks like we need to modify the colour burst output phase every second line and so we don't use the SETCFRQ phase, but something phase leading or lagging from it by 45 degrees. I would think that is just a matter of altering the I/Q input values used, hopefully.

  • rogloh wrote: »
    ...So for PAL it looks like we need to modify the colour burst output phase every second line and so we don't use the SETCFRQ phase, but something phase leading or lagging from it by 45 degrees. I would think that is just a matter of altering the I/Q input values used, hopefully.

    Yes, you'd output some RGB color to cause the colorburst to be the appropriate phase and amplitude. You could, also/instead, alter the YIQ coefficients that are applied to the RGB input values.
  • Thanks Chip. I'll hoping to try to have a play around with composite and/or Y-C output soon, then I'll have them all covered.

    After we caught up Friday I'm also trying out some of ozpropdev's hyperRAM test code too to see if I can't get a full screen high colour output from my video driver using external memory. That's sort of what I've been striving towards achieving for most of this time. So far it's at least proven my HyperRAM board is functional and I'm getting some data back, but I need to spend more time on it with some integration work. Single file for sharing code is not ideal....does flexgui support multiple input files to build a project? I'll have to check it out if it does.

  • roglohrogloh Posts: 1,446
    edited 2019-11-03 - 08:25:36
    I've been trying to use this table below to control the streamer sending analog composite/Y+C video output to different DAC pins. I am seeing strange behaviour and wonder if the P2 documentation is accurate or not, or if there is some P2 or code issue...
               DAC Channel
        dddd     3   2   1   0      description                                          .
    
        0000     --  --  --  --     no streamer DAC output
        0001     X0  X0  X0  X0     output X0 on all four DAC channels
        0010     --  --  X0  X0     output X0 on DAC channels 1 and 0
        0011     X0  X0  --  --     output X0 on DAC channels 3 and 2
        0100     --  --  --  X0     output X0 on DAC channel 0
        0101     --  --  X0  --     output X0 on DAC channel 1
        0110     --  X0  --  --     output X0 on DAC channel 2
        0111     X0  --  --  --     output X0 on DAC channel 3
        1000    !X0  X0 !X0  X0     output X0 diff pairs on all four DAC channels
        1001     --  -- !X0  X0     output X0 diff pairs on DAC channels 1 and 0
        1010    !X0  X0  --  --     output X0 diff pairs on DAC channels 3 and 2
        1011     X1  X0  X1  X0     output X1, X0 pairs on all four DAC channels
        1100     --  --  X1  X0     output X1, X0 on DAC channels 1 and 0
        1101     X1  X0  --  --     output X1, X0 on DAC channels 3 and 2
        1110    !X1  X1 !X0  X0     output X1, X0 diff pairs on all four DAC channels
        1111     X3  X2  X1  X0     output X3, X2, X1, X0 on all four DAC channels
    

    My code does this...and I'm trying the case with syncoptions bit2:0 = 101
    '       Use of this syncoptions field in the HDTV/SDTV analog submode:
    '           bit5 = select HD tri-level (1) or standard SD sync (0) timing
    '           bit4 = select Interlaced (0) or Progressive(1) video frame
    '           bit3 = select NTSC (0) or PAL (1) colour system for composite video
    '           bit2:0 = select video output type and DAC(s) used in the pin group
    '            000 = Composite video output on DAC0 pin
    '            001 = Composite video output on DAC1 pin
    '            010 = Composite video output on DAC2 pin
    '            011 = Composite video output on DAC3 pin
    '            100 = Y-C output on DAC0(Y) & DAC1(C) pins
    '            101 = Y-C output on DAC2(Y) & DAC3(C) pins
    '            110 = Y-C output on DAC0(Y) & DAC1(C) pins, Composite on DAC2 pin
    '            111 = Component video output on DAC1(Pb), DAC2(Y), DAC3(Pr) pins
    ...
                getnib  a, pb, #5               'extract pin group 
                getbyte b, pb, #3               'get syncoptions field
                testb   b, #2 wc                'test for composite (0), other (1)
        if_nc   jmp     #compositevideo
                rczr    b wcz                   'convert two lsb's into flags
    if_z_and_c  jmp     #componentvideo
    
    svideo
                mov     cmodval, #%00_10_1000_0 'enable Y/C video generation
                mul     a, #4                   'convert pin group to pin base
        if_z    add     a, #2                   'high DAC pair output selected
        if_z    setnib  m_bs, #%1011, #6        'output X0 and X1 on upper pins
        if_z    setnib  m_sn, #%1011, #6        'output X0 and X1 on upper pins
        if_z    setnib  m_bv, #%1011, #6        'output X0 and X1 on upper pins
        if_z    setnib  m_vi, #%1011, #6        'output X0 and X1 on upper pins
        if_z    setnib  m_rf, #%1011, #6        'output X0 and X1 on upper pins
                add     a, #(1<<6)              'setup two pins (Y+C)
        if_c    add     a, #(1<<6)              'setup three pins (Y+C+Composite)
                wrpin   dacmode_c, a            'enable DAC modes on pins
                dirh    a                       'enable pin output
                mov     sync_003, #1            'idle hsync, idle vsync
                mov     sync_002, #2            'active hsync, idle vsync
                mov     sync_001, #1            'idle hsync, active vsync
                mov     sync_000, #2            'active hsync, active vsync
    ...
    
    ' these modes get patched with the driving cog ID too
    dacmode_s   long    %0000_0000_000_1011000000000_01_00000_0 'hsync 123-ohm 3.3V
    dacmode_c   long    %0000_0000_000_1011100000000_01_00000_0 'R/G/B 75-ohm 2.0V
    
    m_bs        long    $7fb10000 + H_FP        'before sync
    m_sn        long    $7fb10000 + H_SYNC      'sync
    m_bv        long    $7fb10000 + H_BP        'before visible
    m_vi        long    $7fb10000 + H_VISIBLE   'visible
    
    m_rf        long    $7fb60000 + H_VISIBLE   'visible 8x4b for LUT lookup
    

    I've tried setting both %1011 and %1101 into the streamer command's dddd field to get the Y/C X0 and X1 output on the high pair of the 4 bit pin group and it behaves differently in each. %1101 seems to give a diminished output with clipped off negative sync pulses and the other value looks like the inverse of normal as my sync pulses come down from the top, so it's like some type of complemented output. So I am wondering if the DAC channel table above is accurate or not? I'll also need to check that this isn't another p2asm opcode bug too. My setci, setcq, setcy values also remained the same in all cases tested.

    Update: p2asm output opcodes look okay:

    setnib D,#/S, #n encoding is EEEE1000_00NN_NIDD_DDDDDDD_SSSSSSSSS
    10e8c 313 a837080d     if_z    setnib  m_bs, #%1101, #6        'output X0 and X1 on upper pins
    10e90 314 a8370a0d     if_z    setnib  m_sn, #%1101, #6        'output X0 and X1 on upper pins
    10e94 315 a8370c0d     if_z    setnib  m_bv, #%1101, #6        'output X0 and X1 on upper pins
    10e98 316 a8370e0d     if_z    setnib  m_vi, #%1101, #6        'output X0 and X1 on upper pins
    10e9c 317 a837100d     if_z    setnib  m_rf, #%1101, #6        'output X0 and X1 on upper pins
    

    Update2: Here are my YIQ parameters for this experiment...
        mov b,##(27 << 24) + (53 << 16) + (10 << 8) + 76
        setcy b
        mov b,##((((64*SAT)/100) & $ff)<<24)+((((-53*SAT)/100) & $ff)<<16)+((((-10*SAT)/100) & $ff)<<8) + 74
        setci b
        mov b,##((((-22*SAT)/100) & $ff)<<24)+ ((((-42*SAT)/100) & $ff)<<16)+ ((((64*SAT)/100) & $ff)<<8) + 0
        setcq b 
    ' colour saturation depth SAT was set to 70
    
  • roglohrogloh Posts: 1,446
    edited 2019-11-03 - 10:38:30
    Here's some captures to show what I mean in the previous post. Each video signal was captured unloaded so you will see it should be 2Vp-p instead of 1Vp-p into 75ohms and is so in the first image.

    First picture below is a good output of a composite signal when X2 is sending out composite. The Y signal on X0 is essentially the same. This is pretty much what I expected to see.

    NewFile2.bmp

    This second picture below is the diminished Y output on DAC channel 2 pin mapped to X0 with streamer dddd nibble set to %1101. I first thought perhaps this could have been the Chroma channel, but the C channel amplitude is much bigger if I look at it on DAC1 when Y+C is mapped to the lower two pins of the 4 pin group.

    NewFile0.bmp

    Third picture below is possibly complemented? Y output on DAC channel 2 pin mapped to X0 with streamer dddd nibble set to %1011. Though if were were complemented the front and back porch levels should be inverted too and they do not appear to be.

    NewFile1.bmp

    Not sure why I am getting these 2 bad video outputs unless possibly the DAC channel mapping is broken with the colour space converter + streamer output, or the P2 documentation is different to reality.

    Update: I'm also seeing some video output on DAC2+DAC3 pins when the streamer nibble 6 "dddd" is set to %1100. It should not be sending out on those pins in that mode from what I can tell. So something is messed up here.
               DAC Channel
        dddd     3   2   1   0      description                                          .
        1100     --  --  X1  X0     output X1, X0 on DAC channels 1 and 0
    
  • Rogloh, the colorspace converter is AFTER the streamer. It expects R:G:B:SYNC data on the four DAC channels.
  • Thank Chip. I'd misunderstood how and where this channel mapping takes effect. Very glad there is no P2 issue. :smile:
  • So with help from looking through Chip's 480p demo I was able to add in NTSC video (interlaced 480i) to my driver. Right now it's partially hacked up but soon to be permanent, and it is showing good signs of life on my LCD.

    So we soon should be able to target VGA, SD/HD component, composite, S-video and DVI over HDMI from the same video driver at various resolutions all with the same control interface and graphics capabilities. That's the plan anyway.

    Doing PAL might be tricky with it's special burst flips. I am also not really adhering to any of the rules regarding blanking out the colour burst on particular line sequences over 4/8 frames either due to a lack of COGRAM, but I'll still give it a crack to see how it goes.

    I now have 9 COG RAM registers left. With this I want to try to add that pass through sprite mode plus tri-level HD component syncs if I can squeeze it down any further...hopefully the tri-level things shouldn't add any more COGRAM as I set it up at init time. It's becoming a bit of a puzzle to make it all fit now.


  • rogloh wrote: »
    I am also not really adhering to any of the rules regarding blanking out the colour burst on particular line sequences over 4/8 frames either
    Don't worry, NTSC/PAL is not an exact science. 99% of displays won't care about minor differences from a proper broadcast signal (most don't even care about quite major differences, such as refresh rate / line count, which is why PAL60 works on almost everything that supports regular PAL50 (some need a V-HOLD adjustment though...). And let's not forget good old 240p/288p progressive scan.)
  • rogloh wrote: »
    So we soon should be able to target VGA, SD/HD component, composite, S-video and DVI over HDMI from the same video driver at various resolutions all with the same control interface and graphics capabilities. That's the plan anyway.
    One Driver to rule them all, ..., and in the lightness bind them.

    What about all of us with RGB TTL monitors?
    rogloh wrote: »
    I now have 9 COG RAM registers left. ... It's becoming a bit of a puzzle to make it all fit now.
    Has the code been optimized to death? SKIPFed to the max??
    Formerly known as TonyB
  • TonyB_ wrote: »
    rogloh wrote: »
    So we soon should be able to target VGA, SD/HD component, composite, S-video and DVI over HDMI from the same video driver at various resolutions all with the same control interface and graphics capabilities. That's the plan anyway.
    One Driver to rule them all, ..., and in the lightness bind them.

    What about all of us with RGB TTL monitors?
    rogloh wrote: »
    I now have 9 COG RAM registers left. ... It's becoming a bit of a puzzle to make it all fit now.
    Has the code been optimized to death? SKIPFed to the max??
    Also: aliasing variables that are never relevant at the same time to the same register
  • roglohrogloh Posts: 1,446
    edited 2019-11-04 - 23:05:54
    TonyB_ wrote: »
    What about all of us with RGB TTL monitors?

    Arrggh, you're killing me! Maybe the video DACs could be set into 3.3V output and something could sort of work with the LUT modes, but I'm not sure I'll officially try to support that (yet). Now that's really retro, CGA style. :smile:
    Has the code been optimized to death? SKIPFed to the max??

    Yeah I'm on the hunt for places to try more SKIPF after we had so much success with it with our pixel doubling.
    Wuerfel_21 wrote: »
    Also: aliasing variables that are never relevant at the same time to the same register

    Yes I've starting finding a few of those, and a couple of days back I gained 4 longs in the process for the mouse registers. I am on the hunt for more and there will be some left. I know of 3 more COG RAM regs I can gain over what I have already by doing this, and I think I can map more state flags/counters into a common register instead of separate. What I don't like is having to save/restore the two pointer registers ptra/ptrb. That needs 4 longs each time, either 2 push/pop or 4 moves to/from temp regs. I do this twice as the auto-incrementing pointers are so useful for both LUT and HUB read/writes, so that is 8 longs.

    I know I will need 1 more instruction for doing the PAL colour burst flip (XOR) every scan line. I already have the second long allocated for the XOR mask in my existing budget.

    HD-Sync should be able to hopefully just squeeze in place (with a code overlay at cog setup time).

    I will need some more regs for sprite mode (not sure how many, hopefully just a small number), plus any other things I've missed. I could always start to use HUB RAM for code, but it will prevent me from doing ping/pong LUTRAM in 256 colour mode for operating at lower power 1:1 pixel clock:P2 clock ratios.

    Interlacing input source data is a problem. Right now in my interlaced NTSC output mode I am sending the same source data each field so it's really more like seeing 240p instead of getting proper 480i source data. Ideally I should offset every second field reading out of the source data. I might be able to do this with my second screen source reg, though that is intended for wrapping. We'll see how best to do it...

    Wuerfel_21 wrote: »
    Don't worry, NTSC/PAL is not an exact science. 99% of displays won't care about minor differences from a proper broadcast signal (most don't even care about quite major differences, such as refresh rate / line count, which is why PAL60 works on almost everything that supports regular PAL50 (some need a V-HOLD adjustment though...). And let's not forget good old 240p/288p progressive scan.)

    I'm glad to hear it. I don't think I'll manage to match every single rule. The HD/SD video modes have been added in right at the end and I just don't have enough resources to be 100% compliant. This driver just started out as DVI text only intended for VGA resolution only operating at 252MHz (it came from some early HDMI+audio experiments), but has grown and grown since then with features and it really does a whole lot more now.
  • Don't worry, NTSC/PAL is not an exact science. 99% of displays won't care about minor differences from a proper broadcast signal (most don't even care about quite major differences, such as refresh rate / line count, which is why PAL60 works on almost everything that supports regular PAL50 (some need a V-HOLD adjustment though...). And let's not forget good old 240p/288p progressive scan.)

    Hey you are right about some displays not caring about the standards so much. I am sending the PAL colour burst frequency with Chip's NTSC phase angle colour instead of PAL's 135/225 degree version, and not alternating it and my LCD is showing a reasonable colour picture (albeit quite saturated) and recognizing it as 50Hz "PAL". LOL.

    I've certainly seen some quite interesting old school video effects showing while debugging this thing. Reminds me so much of old worn out videotapes flagging at the top etc. Very retro.

  • roglohrogloh Posts: 1,446
    edited 2019-11-06 - 11:04:58
    So I was able to squeeze the different types of sync code into the same COGRAM footprint, and come up with versions for SDTV PAL/NTSC interlaced/progressive and HDTV interlaced/progressive. All variants are coded now on a spreadsheet and interlaced ones have been tested in my working driver however the actual sync code is very unlikely to expand into needing more COGRAM so I am highly confident it will fit okay even though not all is tested out yet. Sync type is selected at COG boot time and the code gets configured accordingly.

    I did some more hunting and found some low hanging fruit and now have about 20 free COGRAM registers. There might be a few more but it is starting to become slim pickings now.

    With this extra scrounged RAM I hope to do the following...

    1) allow a simple sprite mode, passing through from external COG rendered data buffers directly instead of copying
    2) interlaced source address offset in graphics regions (allows page flipping and/or independent field source for 50/60 fields/sec video)
    3) better palette handling (see below)
    4) a proper status frame counter, right now it is sharing a counter that only counts to 16 for flashing the cursor (may need 2-3 extra regs)
    5) option for a shared set of mouse co-ordinates over all regions to help the user out (this would need 3 regs)
    6) (eventually) support a low power 1:1 pixel/P2 clock mode for basic "transparent" frame buffer pass through. In this mode no text/mouse/pixel doubling is possible and it would work a bit like the sprite mode but not really have any other capabilities. This mode would not take more register space as it would be patched at boot time, but it would be good to have as it could allow decent NTSC/PAL frame buffer output at 13.5MHz P2 rates, or VGA at 25MHz etc. I think this will come after the initial release.

    The 256 entry palette load approach I started out with VGA is now becoming an issue, due to the different hsync options taking more CPU time, with different tri-level and colour bursts etc needing more streamer commands and not leaving large contiguous blocks of CPU time to load the palette. You need over 256 clock cycles to load a 256 entry palette and for low pixel clock ratios and small blanking intervals it may not load in time. So what I think I will have to do is to keep any 256 entry palette in low LUT RAM, and reload it in place on region changes during the active portions on the scanline after the text/graphics scanline has been rendered. This may mean that two sequential regions with different 256 colour palettes changing in the middle of the frame could see colours disrupted towards the end of the scanline. To alleviate this issue I think I will keep the smaller 2/4/16 entry palette in high LUT RAM so this potentially can be hidden if you change different 256 colour regions via the 16 colour palette first - e.g. insert a single black (or other coloured) scanline between two 256 colour regions to avoid noticing it. You could also use a direct colour mode region too instead of one using the 16 colour palette. Both should work.

    Unfortunately I don't think I can do any double buffering of 256 entry palettes in my normal operating mode because I need the LUTRAM for my text buffer/pixel doubler (though it may be possible to do this doubling buffering in a future cut-down transparent mode). I think this is all I can do about it right now. I may have similar issues with rendering the mouse in some cases, though only for external RAM sourced data with lower P2 pixel clock ratios. I'm hoping there will be sufficient time available to display one but can't guarantee it over all operating conditions.
  • Sounds pretty interesting, Roger!

    I've updated my VGA ANSI driver to support 2 bytes/char (using the standard VGA format that you also use) and 1 byte/char (7 bit ASCII plus 1 bit blinking effect for the cursor). It should be pretty straightforward to adapt the ANSI character output code in vga_text_routines.spinh to your driver.

    The source code is in github at:
    https://github.com/totalspectrum/p2_vga_text
  • Great news Roger. Your options are really impressive!
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
Sign In or Register to comment.