Shop OBEX P1 Docs P2 Docs Learn Events
P2 VGA question — Parallax Forums

P2 VGA question

I've been looking at the VGA code again.

I cannot see how HSYNC is created???

Chips sample VGA code does not make reference to a pin used for hsync. Pin 0 is used for VSYNC.

For my VGA code, I looked as Ozprops code which has HSYNC on Pin 0 and VSYNC on pin 4. I can see VSYNC being created just fine for each frame.

Am I right to think that VGA does not require HSYNC and that it is indeed syncing on the RBG data? If so, I presume I can tie the HSYNC to the monitor to GND? Obviously I can test this out, but I just want to be sure this can be done, and I'm not missing something.
«1

Comments

  • cgraceycgracey Posts: 14,133
    Can you post the VGA code? There is a need for a VSYNC signal.
  • Cluso99Cluso99 Posts: 18,066
    Yes, VSYNC is required, and works correctly as I can see that.
    '*************************************
    '*  VGA 640 x 480 x 16bpp 5:6:5 RGB  *
    '*************************************
    
    CON
    
      intensity	= 80	'0..128
    
      fclk		= 80_000_000.0
      fpix		= 25_000_000.0
      fset		= (fpix / fclk * 2.0) * float($4000_0000)
    
      vsync		=	0	'vsync pin (all FPGA boards now)
    
    DAT		org
    '
    '
    ' Setup
    '
    		hubset	#$FF			'set clock to 80MHz
    
    		rdfast	##640*350*2/64,##$1000	'set rdfast to wrap on bitmap
    
    		setxfrq ##round(fset)		'set transfer frequency to 25MHz
    
    		'the next 4 lines may be commented out to bypass signal level scaling
    
    		setcy	##intensity << 24	'r	set colorspace for rgb
    		setci	##intensity << 16	'g
    		setcq	##intensity << 08	'b
    		setcmod	#%01_0_000_0		'enable colorspace conversion (may be commented out)
    
    		wrpin	dacmode,#0		'enable dac modes in pins 0..3
    		wrpin	dacmode,#1
    		wrpin	dacmode,#2
    		wrpin	dacmode,#3
    '
    '
    ' Field loop
    '
    field		mov	x,#90			'top blanks
    		call	#blank
    
    		mov     x,#350			'set visible lines
    line		call	#hsync			'do horizontal sync
    		xcont	m_rf,#1			'visible line
    		djnz    x,#line           	'another line?
    
    		mov	x,#83			'bottom blanks
    		call	#blank
    
    		drvnot	#vsync			'sync on
    
    		mov	x,#2			'sync blanks
    		call	#blank
    
    		drvnot	#vsync			'sync off
    
                    jmp     #field                  'loop
    '
    '
    ' Subroutines
    '
    blank		call	#hsync			'blank lines
    		xcont	m_vi,#0
    	_ret_	djnz	x,#blank
    
    hsync		xcont	m_bs,#0			'horizontal sync
    		xzero	m_sn,#1
    	_ret_	xcont	m_bv,#0
    '
    '
    ' Initialized data
    '
    dacmode		long	%0000_0000_000_1010000000000_01_00000_0
    
    m_bs		long	$CF000000+16		'before sync
    m_sn		long	$CF000000+96		'sync
    m_bv		long	$CF000000+48		'before visible
    m_vi		long	$CF000000+640		'visible
    
    m_rf		long	$2F000000+640		'visible rfword rgb16 (5:6:5)
    
    x		res	1
    y		res	1
    '
    '
    ' Bitmap
    '
    		orgh	$1000 - 70		'justify pixels at $1000
    		file	"birds_16bpp.bmp"	'rayman's picture (640 x 350)
    
  • Cluso99Cluso99 Posts: 18,066
    FWIW, I am designing a P2 board with..

    8 x COGs
    8 x VGA's (4 or 5 pins?)
    8 x PS2 keyboards (2 pins)
    8 x I/O pins free (1 or 2?)
    8 x 64KB Hub RAM

    Now I can demo 8 separate programs running on a P2 :smiley:
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-07-04 23:42
    BTW I wrote a 1pin PS2 keyboard code for P1 so I can save a pin here for general I/O.
    And I can always combine RGB for mono and save some more general I/o pins.

    I have yet to try sync on green ;)
  • cgraceycgracey Posts: 14,133
    Ok. That is code that runs on the Prop-123 FPGA board. P0 connects to VSYNC on the VGA connector.

    For the P2 Eval VGA board, I think the pinout goes like this:

    P0 = HSYNC (use 123-ohm 3.3V mode)
    P1 = BLUE (use 75-ohm 2.0V mode)
    P2 = GREEN (use 75-ohm 2.0V mode)
    P3 = RED (use 75-ohm 2.0V mode)
    P4 = VSYNC (use digital mode)
  • Cluso99Cluso99 Posts: 18,066
    But Chip,
    I cannot see where/how HSYNC is being generated. Is it being generated or is the monitor syncing on the RGB?
  • I think the streamer is controlling 4 pins: R, G, B, and HSYNC.
  • cgraceycgracey Posts: 14,133
    edited 2019-07-05 00:20
    Oh, sorry. I misread your post and thought your question was about VSYNC. HSYNC is controlled by the streamer via DAC channel 0. VSYNC gets controlled manually as a digital output.
  • Cluso99Cluso99 Posts: 18,066
    So how is the streamer actually controlling HSYNC as I cannot see any difference in the 5 instructions that get executed in the whole set of loops...
    		xcont	m_rf,#1			'visible line
    		xcont	m_vi,#0
    
    hsync		xcont	m_bs,#0			'horizontal sync
    		xzero	m_sn,#1
    	_ret_	xcont	m_bv,#0
    
    m_bs		long	$CF000000+16		'before sync
    m_sn		long	$CF000000+96		'sync
    m_bv		long	$CF000000+48		'before visible
    m_vi		long	$CF000000+640		'visible
    m_rf		long	$2F000000+640		'visible rfword rgb16 (5:6:5)
    
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-07-05 00:39
    Is it this instruction that writes "1" to Pin 0 for HSYNC ?
    		xzero	m_sn,#1      '<=====  #1 outputs $0001 to dacs 3-0 ie pins 3..0 ???
    m_sn		long	$CF000000+96		'sync
    

    If so, then I presume we cannot send negative hsync, only positive hsync?
  • Cluso99 wrote: »
    Is it this instruction that writes "1" to Pin 0 for HSYNC ?
    		xzero	m_sn,#1      '<=====  #1 outputs $0001 to dacs 3-0 ie pins 3..0 ???
    m_sn		long	$CF000000+96		'sync
    

    Yes, that's the key instruction, although the #1 means to write $00_00_00_01 to pins 3..0, so 0 to pins 3..1 and 1 to pin 0. That value is also modified by the color space converter (setcmod instruction). I think you can use the CMOD value to achieve negative hsync, or at least to have pin 0 high most of the time and low during hsync. My VGA tile driver tries to achieve that, although I haven't tested it extensively -- I know negative vsync works, my monitor needed it for one mode, but I'm not sure about negative hsync.
  • Cluso99Cluso99 Posts: 18,066
    Thanks Eric. Yes, when I realised the significance of the #1 I realised it was writing to all DAC pins.

    Since we enable the DAC pins with WRPIN perhaps it's possible to use the inversion at the pin interface since HSYNC is actually a digital signal ???
  • Cluso99Cluso99 Posts: 18,066
    So looking at the smartpins and dacs, I am guessing it is possible to disable the DAC output on Pin 0 and drive that pin directly???

    If this can be done, then HSYNC & VSYNC could be combined on the one pin, using Low, Tristate, and High and an external pair of XORs to decode the separate HSYNC & VSYNC.
  • cgraceycgracey Posts: 14,133
    edited 2019-07-05 02:01
    Cluso99 wrote: »
    Thanks Eric. Yes, when I realised the significance of the #1 I realised it was writing to all DAC pins.

    Since we enable the DAC pins with WRPIN perhaps it's possible to use the inversion at the pin interface since HSYNC is actually a digital signal ???

    You set HSYNC polarity via a bit in the colorspace converter, like Eric was saying. I'm pretty sure it's all in the Google Doc.
  • cgracey wrote: »
    Cluso99 wrote: »
    Thanks Eric. Yes, when I realised the significance of the #1 I realised it was writing to all DAC pins.

    Since we enable the DAC pins with WRPIN perhaps it's possible to use the inversion at the pin interface since HSYNC is actually a digital signal ???

    You set HSYNC polarity via a bit in the colorspace converter, like Eric was saying. I'm pretty sure it's all in the Google Doc.

    There is a lot in Google doc, but some of it is very - tense - if one can not follow your line of thought behind it, it is not easy to understand.

    Documentation really needs some improvement, my guess is that besides @cgracey and @ozpropdev nobody really understand all of this.

    But we will get there.

    Mike
  • cgraceycgracey Posts: 14,133
    msrobots wrote: »
    cgracey wrote: »
    Cluso99 wrote: »
    Thanks Eric. Yes, when I realised the significance of the #1 I realised it was writing to all DAC pins.

    Since we enable the DAC pins with WRPIN perhaps it's possible to use the inversion at the pin interface since HSYNC is actually a digital signal ???

    You set HSYNC polarity via a bit in the colorspace converter, like Eric was saying. I'm pretty sure it's all in the Google Doc.

    There is a lot in Google doc, but some of it is very - tense - if one can not follow your line of thought behind it, it is not easy to understand.

    Documentation really needs some improvement, my guess is that besides @cgracey and @ozpropdev nobody really understand all of this.

    But we will get there.

    Mike

    Just look up the 6 bits, I believe, set by SETCMOD.
  • evanhevanh Posts: 15,126
    edited 2019-07-05 06:09
    Mike/Cluso,
    Read this. It's verbatim from the doc but I've given it a title and formatted to its own page.
  • Cluso99Cluso99 Posts: 18,066
    Chip,
    Those docs were my first go-to, and I have been re-reading the sections with each post of this thread.
    But as we don't know the physical setup of the silicon, its hard to determine which part overrides which part.

    I missed the possible inversion in the colorspace converter. I did see that it might be possible to invert at the pins, but then again, since the output is coming from the dac, perhaps this switches out that section of the smartpin.

    The bit I missed (about where hsync comes from) when I first raised the question this morning was the S=#1 on the xzero instruction.
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-07-05 06:29
    DAC section pertaining to VGA only (other info removed for clarity)
    
    DACs
    Each cog outputs four 8-bit DAC channels that can directly drive the DAC's of pins.
    	DAC0 can drive the DAC's of all pins numbered %XXXX00.
    	DAC1 can drive the DAC's of all pins numbered %XXXX01.
    	DAC2 can drive the DAC's of all pins numbered %XXXX10.
    	DAC3 can drive the DAC's of all pins numbered %XXXX11.
    The background state of these four 8-bit channels can be established by SETDACS:
    SETDACS D/#		- Write bytes 3/2/1/0 of D/# to DAC3/DAC2/DAC1/DAC0
    The DAC values established by SETDACS will be constantly output, except at times when the streamer and/or colorspace converter override them.
    
    STREAMER
    Each cog has a streamer which can automatically output timed state sequences to pins and DACs.
    SETXFRQ D/#		- Set NCO frequency
    The NCO frequency may also be set/changed via a ‘SETQ D/#’ instruction immediately preceding an XINIT/XZERO/XCONT instruction.
    
    The streamer may be activated by a command from an XINIT/XZERO/XCONT instruction. For these instructions, D/# expresses the streamer mode and duration, while S/# supplies various data, or is ignored, depending upon the mode expressed in D/#.
    XINIT   D/#,S/#	- Issue command immediately, zeroing phase
    XZERO   D/#,S/#	- Issue command on final NCO rollover, zeroing phase
    XCONT   D/#,S/#	- Issue command on final NCO rollover, continuing phase
    For the XINIT/XZERO/XCONT instructions, D/#[31:16] conveys the command, while D/#[15:0] conveys the number of NCO rollovers that the command will be active for. S/# is used to select sub-modes for some commands:
     D/#[31:16]
     mode dacs pins base   S/#       description                   dac output
     ---- ---- ---- ----   ------    ---------------------------   --------------------
    %0001_dddd_eppp_xxxx   %01rgb    8-bit RFBYTE LUMA8            $RRGGBB00
    %0001_dddd_eppp_xxxx   %10xxx    8-bit RFBYTE RGBI8            $RRGGBB00
    %0001_dddd_eppp_xxxx   %10xxx    8-bit RFBYTE RGBI8            $RRGGBB00
    %0001_dddd_eppp_xxxx   %11xxx    8-bit RFBYTE RGB8 (3:3:2)     $RRGGBB00
    %0010_dddd_eppp_xxxx       %1    16-bit RFWORD RGB16 (5:6:5)   $RRGGBB00
    %0011_dddd_eppp_xxxx       %1    32-bit RFLONG RGB24 (8:8:8)   $RRGGBB00
    
    %1100_dddd_eppp_xxxx   <long>    32-bit immediate              $xxxxxxxx
    
    The streamer has four DAC output channels, X0, X1, X2 and X3, which can selectively override the four SETDACS values, on a per-DAC basis. The %dddd field selects which streamer DAC channels will override which SETDACS values. In the table below, “-” indicates no override and “!” indicates one’s-complement:
                      DAC
        dddd     3   2   1   0      description
        ----     --------------     ---------------------------------------------
        1111     X3  X2  X1  X0     output X3, X2, X1, X0 on all four DAC channels
    
    The streamer always deals with 32-bit, or 4 byte, data. When outputting to DACs, these 4 bytes are assigned, in descending order, to X3, X2, X1 and X0.
    
    All pure output modes (top nibble = %0001..%1100) can output to pins, as well as to DACs
    The %eppp field controls which pins are output to:
    	%eppp : 0xxx = disable pin output
    
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-07-05 06:21
    The color space converter is optional for VGA/

    COLOR SPACE CONVERTER
    Each cog has a color space converter which can perform ongoing matrix transformations and modulation of the cog's 8-bit DAC channels.
    The color space converter is configured via the following instructions:
    SETCY   {#}D		- Set color space converter CY parameter to D[31:0]
    SETCI   {#}D		- Set color space converter CI parameter to D[31:0]
    SETCQ   {#}D		- Set color space converter CQ parameter to D[31:0]
    SETCFRQ {#}D		- Set color space converter CFRQ parameter to D[31:0]
    SETCMOD {#}D		- Set color space converter CMOD parameter to D[6:0]
    It is intended that DAC3/DAC2/DAC1 serve as R/G/B channels. On each clock, new matrix and modulation calculations are performed through a pipeline.
    CMOD[6:5]   Mode             DAC3      DAC2      DAC1      DAC0
    00          <off>           (bypass)  (bypass)  (bypass)  (bypass)
    01          VGA/HDTV         FY        FI        FQ        FS
            (R-G-B)/(Y-Pb-Pr)   (R / Y)   (G / Pb)  (B / Pr)  (H-Sync)
    
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-07-05 06:45
    '*************************************
    '*  VGA 640 x 480 x 16bpp 5:6:5 RGB  *  (some code removed for clarity)
    '*************************************
    CON
      intensity     =       80      '0..128
      vsync         =       4       'vsync pin
      fset          =   (fpix / fclk * 2.0) * float($4000_0000)
    
    DAT             org
                    rdfast  ##640*350*2/64,##$1000  'set rdfast to wrap on bitmap
                    setxfrq ##round(fset)           'set transfer frequency to 25MHz
    
    'the next 4 lines may be commented out to bypass signal level scaling
                    setcy   ##intensity << 24       'r      set colorspace for rgb
                    setci   ##intensity << 16       'g
                    setcq   ##intensity << 08       'b
                    setcmod #%01_0_000_0            'enable colorspace conversion
    
                                                    'enable dac modes in pins 0..3
                    wrpin   dacmode_s,#0            '\ Hsync 123-ohm, 3.3V
                    wrpin   dacmode_c,#1            '| B:  75-ohm, 2.0V
                    wrpin   dacmode_c,#2            '| G:  75-ohm, 2.0V
                    wrpin   dacmode_c,#3            '| R:  75-ohm, 2.0V
                    setnib  dira,#$f,#0             '/ & enable output
    
    field           mov     x,#90                   'top blanks
                    call    #blank
    
                    mov     x,#350                  'set visible lines
    line            call    #hsync                  'do horizontal sync
                    xcont   m_rf,#1                 'visible line
                    djnz    x,#line                 'another line?
    
                    mov     x,#83                   'bottom blanks
                    call    #blank
    
                    drvnot  #vsync                  'sync on
                    mov     x,#2                    'sync blanks
                    call    #blank
                    drvnot  #vsync                  'sync off
                    jmp     #field                  'loop
    
    blank           call    #hsync                  'blank lines
                    xcont   m_vi,#0
            _ret_   djnz    x,#blank
    
    hsync           xcont   m_bs,#0                 'horizontal sync
                    xzero   m_sn,#1                 'pin 0 =1 hsync
            _ret_   xcont   m_bv,#0
    
    dacmode_s       long    %0000_0000_000_1011000000000_01_00000_0         'hsync is 123-ohm, 3.3V
    dacmode_c       long    %0000_0000_000_1011100000000_01_00000_0         'R/G/B are 75-ohm, 2.0V
    
    m_bs            long    $CF000000+16            'before sync
    m_sn            long    $CF000000+96            'sync
    m_bv            long    $CF000000+48            'before visible
    m_vi            long    $CF000000+640           'visible
    m_rf            long    $2F000000+640           'visible rfword rgb16 (5:6:5)
    
                    orgh    $1000 - 70              'justify pixels at $1000
                    file    "birds_16bpp.bmp"       'rayman's picture (640 x 350)
    
  • evanhevanh Posts: 15,126
    edited 2019-07-05 07:10
    Cluso,
    I think if you were to comment out those four lines without any other correction you'd lose hsync output. A sync pulse value would need added as a correction. Something like "v_sn long 255" for positive polarity. And "xzero m_sn,v_sn" as the assembly code change.

    EDIT: Heh, or still have it as #255 immediate and use a SETS #0 to change polarity. :)

    EDIT2: Oh no, maybe none of that works. Polarity has to be carried over the whole frame!

  • Cluso99Cluso99 Posts: 18,066
    edited 2019-07-05 07:05
    cgracey wrote: »
    msrobots wrote: »
    cgracey wrote: »
    Cluso99 wrote: »
    Thanks Eric. Yes, when I realised the significance of the #1 I realised it was writing to all DAC pins.

    Since we enable the DAC pins with WRPIN perhaps it's possible to use the inversion at the pin interface since HSYNC is actually a digital signal ???

    You set HSYNC polarity via a bit in the colorspace converter, like Eric was saying. I'm pretty sure it's all in the Google Doc.

    There is a lot in Google doc, but some of it is very - tense - if one can not follow your line of thought behind it, it is not easy to understand.

    Documentation really needs some improvement, my guess is that besides @cgracey and @ozpropdev nobody really understand all of this.

    But we will get there.

    Mike

    Just look up the 6 bits, I believe, set by SETCMOD.

    The current doc on github (last update 2019/04/11) only lists configuration bits CMOD[6:5] for off/VGA-HDTV/NTSC+SV/NTSC (NTSNTSC/PAL composite) :(

    https://docs.google.com/document/d/1UnelI6fpVPHFISQ9vpLzOVa8oUghxpI6UpkXVsYgBEQ/edit
  • evanhevanh Posts: 15,126
    edited 2019-07-05 07:21
    Cluso,
    It's all there, just missing the title and has a page break in the middle. I've posted a single page version above - https://forums.parallax.com/discussion/comment/1473192/#Comment_1473192

    EDIT: Err, bugger, CMOD[4] is in the prior page. Definitely could be easier to read all right.

    EDIT2: Ah, and CMOD[4] is where the verilog compiler bug got in in the ES chips.
  • Invert at the pin using the CIO bits when you do the initial pin configuration

  • evanhevanh Posts: 15,126
    Tubular wrote: »
    Invert at the pin using the CIO bits when you do the initial pin configuration
    Won't work because streamer feeds the four 8-bit channels that are directed at a group of four DACs. The digital CIO pin mode bits vanish when pin is configured as a DAC.

  • evanhevanh Posts: 15,126
    edited 2019-07-05 09:43
    I just realised that, I think, vsync timing occurs one line earlier than might be obvious in the numbers. Both the leading and trailing edges of the vsync pulse occur after an "XCONT m_vi,#0" instruction, which itself has simply filled the streamer command buffer, which in turn will be used after the active "XCONT m_bv,#0" which is still being clocked out.

    So, because the OUTNOT (DRVNOT) is a direct effect, the edges of vsync are slightly trailing the hsyncs ... and also a whole scanline ahead of the numerical line position.

    EDIT: Which might explain why some experiments I did last year didn't quite seem to work out as expected.
  • evanh wrote: »
    Tubular wrote: »
    Invert at the pin using the CIO bits when you do the initial pin configuration
    Won't work because streamer feeds the four 8-bit channels that are directed at a group of four DACs. The digital CIO pin mode bits vanish when pin is configured as a DAC.

    Ah yeah you're right

    I was thinking back to what we did. I don't think we worried about inverting Hsync, only inverting vsync and setting the v blanking to 8 lines to signal CVT RB2 timing. This worked fine on the monitors we tested.

    Are you going for reduced blanking timing Cluso? Or did you want pre-cvt standard VGA with the bigger blanking?

  • Cluso99Cluso99 Posts: 18,066
    What I started looking at was how to reduce the VGA pins down from 5. This led me to miss how Hsync was being generated. I could see Vsync fine.

    I think it would be possible to invert Hsync by having the idle value preset to output 1 on pin 0 (our current case), and for Hsync, outputting a 0.

    What I am looking at is two-fold. First, combine Hsync and Vsync on one pin, being pin 0, since I believe RGB is “fixed” to pins 3,2,1. Second, I would like to see if I can get GreenOnSync to work.

    From what I’ve read, I think it’s possible to manually operate pin 0, by not configuring it as a DAC output. I also think it might be possible to just override p0 at the appropriate Vsync time.

    If I drove p0 totally manually, then I could use H, L and T/S to reconstruct Hsync and Vsync externally with a pair of XOR gates and 3 10K resistors.

    What I am unsure about is how many monitors support GOS (green on sync), and if any support composition sync on the Hsync pin.
  • Ok, pin saving, nice.

    Sorry i didn't get that vga breakout to you this week. Will do that this weekend.
Sign In or Register to comment.