Shop OBEX P1 Docs P2 Docs Learn Events
VGA from P2 silicon — Parallax Forums

VGA from P2 silicon

I just found an older VGA routine that was done for FPGA and made a couple of changes to get it running on silicon. Next thing I want to do is duplicate all this from TAQOZ.
'******************************
'*  VGA 640 x 480 x 8bpp-lut  *
'******************************

CON

  intensity	= 120	'0..128

  fclk		= 200_000_000.0
  fpix		= 25_000_000.0
  fset		= (fpix / fclk * 2.0) * float($4000_0000)

  vsync		=	4	'vsync pin (all FPGA boards now)

DAT		org
'
'
' Setup
	hubset	##%1_001011_0011000111_1111_11_00
	waitx	##20_000_000/100			'wait ~10ms for crystal+PLL to stabilize
	hubset	##%1_001011_0011000111_1111_11_11 	'now switch to PLL running at 200MHz


		rdfast	#0,##$1000-$400		'load .bmp palette into lut
		rep	@.end,#$100
		rflong	y
		shl	y,#8
		wrlut	y,x
		add	x,#1
.end
		rdfast	##640*480/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 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

		wrpin	dacmode,#0		'enable dac modes in pins 0..3
		wrpin	dacmode,#1
		wrpin	dacmode,#2
		wrpin	dacmode,#3
		drvh	#0
		drvh	#1
		drvh	#2
		drvh	#3

'
'
' Field loop
'
field		mov	x,#33			'top blanks
		call	#blank

		mov     x,#480			'set visible lines
line		call	#hsync			'do horizontal sync
		xcont	m_rf,#0			'visible line
		djnz    x,#line           	'another line?

		mov	x,#10			'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
		xcont	m_sn,#1
	_ret_	xcont	m_bv,#0
'
'
' Initialized data

'			%AAAA_BBBB_FFF_DACxxDDDDDDDD_TT_MMMMM_0
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	$7F000000+640		'visible rlong 8bpp lut

x		res	1
y		res	1
'
'
' Bitmap
'
		orgh	$1000 - $436	'justify pixels at $1000, pallete at $1000-$400
		file	"bitmap2.bmp"	'640 x 480, 8pbb-lut
«134

Comments

  • jmgjmg Posts: 15,144
    Impressive.
    Does that need 200MHz SysCLK to work ?
    What SysCLK can that drop down to, and still work ok ? 25MHz ?
  • RaymanRayman Posts: 13,851
    I’m not sure the feet are supposed to be blue
  • Yep
    All my P2 VGA stuff shows incorrect colors too on the real P2,
    Modulator bug related I assume?

  • ozpropdevozpropdev Posts: 2,791
    edited 2018-10-19 10:39
    @Peter
    Does your "adaptor" have the RGB grounds connected as well ?
  • Birds true colors
    353 x 525 - 60K
  • TonyB_TonyB_ Posts: 2,120
    edited 2018-10-19 11:11
    Is video streaming possible in the background, allowing you to run other instructions at the same time in the same cog?
  • Video can be interrupt driven.
  • cgraceycgracey Posts: 14,133
    edited 2018-10-19 13:12
    You've got your R/G/B wires mixed up. Try swapping them around.

    Pin %xxxx11 = Red
    Pin %xxxx10 = Green
    Pin %xxxx01 = Blue
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-10-19 13:33
    cgracey wrote: »
    You've got your R/G/B wires mixed up. Try swapping them around.

    Pin %xxxx11 = Red
    Pin %xxxx10 = Green
    Pin %xxxx01 = Blue

    Oh yeah, that's better. To tell the truth I didn't even look at the colors at all, I was just happy to see it running :)
    btw - I can run the P2 at 25MHz and it still works
    CPUHZ		= 25_000_001
    CLKDIV		= 12
    CLKMUL		= CPUHZ/1000000
    CLKCFG		= 1<<24+(CLKDIV-1)<<18+(CLKMUL-1)<<8+%1111_11_00
    
    3349 x 2168 - 1M
  • cgraceycgracey Posts: 14,133
    VGA takes 5 pins: R, G, B, H, V.
    HDTV takes 3 pins: Y, Pb, Pr.
    Composite takes 1 pin: YIQ.

    I love that we have 2ns 75-ohm DACs on every pin.

    I'm thinking about how the Goertzel can be used to resolve time-of-flight for signals. Goertzel, fast low-Z DACs, oversampling, and CORDIC, all together, should make really interesting measurements possible. It may be possible to achieve micrometer-scale resolution for light and electrical phenomena.
  • RaymanRayman Posts: 13,851
    I was just going to ask how fast the DACs can update. Sounds like can go at clock freq...

    250 MHz opens up a lot of resolutions: http://tinyvga.com/vga-timing
  • RaymanRayman Posts: 13,851
    Only need 150 MHz for 1080p at 60 Hz...
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    Only need 150 MHz for 1080p at 60 Hz...

    Yes, 148.5MHz, to be exact.

    With a 20MHz crystal, use the PLL to divide it by 40 to get 0.5MHz, then set the VCO multiplier to 297 and select undivided VCO output and you've got 148.5MHz.
  • RaymanRayman Posts: 13,851
    edited 2018-10-19 14:19
    I don't think it has to be exact...
    I was signaling 1080p with 80 MHz clock on P2V:
    https://forums.parallax.com/discussion/163719/how-to-do-1080p/p2

    TVs didn't care, but some monitors didn't like it...
  • It's amazing how good even 8-bit VGA graphics can look. I've got a tiger in my room!


    tiger.jpg
    2872 x 2176 - 1M
  • That looks superb, Peter!
  • cgraceycgracey Posts: 14,133
    Yes, that looks great. Is that 640x480?
  • jmgjmg Posts: 15,144
    btw - I can run the P2 at 25MHz and it still works
    CPUHZ		= 25_000_001
    CLKDIV		= 12
    CLKMUL		= CPUHZ/1000000
    CLKCFG		= 1<<24+(CLKDIV-1)<<18+(CLKMUL-1)<<8+%1111_11_00
    

    Thanks - great ! With P2's power aspects, lowest possible functional MHz will be important. Lucky it has that wide-range PLL ;)
  • jmgjmg Posts: 15,144
    cgracey wrote: »
    ...

    I love that we have 2ns 75-ohm DACs on every pin.
    I'm thinking about how the Goertzel can be used to resolve time-of-flight for signals. Goertzel, fast low-Z DACs, oversampling, and CORDIC, all together, should make really interesting measurements possible. It may be possible to achieve micrometer-scale resolution for light and electrical phenomena.

    Certainly an interesting area. I revisited some time-of-flight work Bean did on P1 following a question in another thread.
    There, Bean changes the Counter-PLL faster than it can lock, in order to modulate the timing samples across a linear range.
    Multiple samples and some means to shift edges in a sub-ns manner looks to be useful for time-of-flight.
    P1 has multiple PLLs and async pins, not sure how to emulate those in P2 ? - possibly a DAC and LPF+external comparator (logic 1G14 schmitt should do) ?

    Or, a DAC could modulate the supply rail of a AHC14, or maybe a dual-supply translator like 74AVC1T45 ?
  • cgraceycgracey Posts: 14,133
    edited 2018-10-19 20:06
    jmg wrote: »
    cgracey wrote: »
    ...

    I love that we have 2ns 75-ohm DACs on every pin.
    I'm thinking about how the Goertzel can be used to resolve time-of-flight for signals. Goertzel, fast low-Z DACs, oversampling, and CORDIC, all together, should make really interesting measurements possible. It may be possible to achieve micrometer-scale resolution for light and electrical phenomena.

    Certainly an interesting area. I revisited some time-of-flight work Bean did on P1 following a question in another thread.
    There, Bean changes the Counter-PLL faster than it can lock, in order to modulate the timing samples across a linear range.
    Multiple samples and some means to shift edges in a sub-ns manner looks to be useful for time-of-flight.
    P1 has multiple PLLs and async pins, not sure how to emulate those in P2 ? - possibly a DAC and LPF+external comparator (logic 1G14 schmitt should do) ?

    Or, a DAC could modulate the supply rail of a AHC14, or maybe a dual-supply translator like 74AVC1T45 ?

    It can be more subtle than that. The Goertzel accumulates SIN and COS sums, based on the ADC readings (+/-1) on every clock, which can be converted to polar coordinates. The super resolution comes from the angle reading. Imagine you are outputting a 20MHz reference sine wave and inputting the same on another pin's ADC, after the signal has traveled a bit. The longer you measure the input, the bigger the accumulations get, and the more precise the final angle reading becomes. The phase resolution can be in the millionths of a revolution, down into the femtoseconds. This will take some experimentation to develop, but we have all the needed parts in the chip.
  • jmgjmg Posts: 15,144
    cgracey wrote: »
    It can be more subtle than that. The Goertzel accumulates SIN and COS sums, based on the ADC readings (+/-1) on every clock, which can be converted to polar coordinates. The super resolution comes from the angle reading. Imagine you are outputting a 20MHz reference sine wave and inputting the same on another pin's ADC, after the signal has traveled a bit. The longer you measure the input, the bigger the accumulations get, and the more precise the final angle reading becomes. The phase resolution can be in the millionths of a revolution, down into the femtoseconds. This will take some experimentation to develop, but we have all the needed parts in the chip.
    Perhaps, tho I really doubt the ADC numbers we are seeing, are going to allow phase-extract at 20MHz.
    Be interesting to see what can be achieved with P2 silicon.
    cgracey wrote: »
    I love that we have 2ns 75-ohm DACs on every pin.
    What is the step size error on the DACs ?
    Seems with a modest DAC generated slew, 5ns SysCLKs can give maybe 390ps~100ps region time resolve, using external buffer threshold.
    MOSFET drivers usually have schmitt buffers, so some sub-ns PWM could be possible in P2 ? (allows you to compete with the better TI/Microchip parts)
  • cgraceycgracey Posts: 14,133
    Why could we not extract phase at 20MHz? I haven't tried it, yet, but I don't see why we couldn't get near-32-bit phase resolution if we stared long enough.

    The DAC step size is 3.3V/256 = 12.9mV. Smart pin modes can toggle between two adjacent steps to push 16-bit resolution.
  • roglohrogloh Posts: 5,151
    edited 2018-10-19 22:52
    cgracey wrote: »
    VGA takes 5 pins: R, G, B, H, V.
    HDTV takes 3 pins: Y, Pb, Pr.
    Composite takes 1 pin: YIQ.

    For fewer than 5 pins and assuming your VGA monitor supports it I take it that P2 internal HW has nothing stopping it being implemented using SyncOnGreen (3 pins) or RGBS (4 pins) as well? The S signal being some form of composite sync, potentially also DAC driven at 0.7V pp like RGB, or a raw TTL level form.

    From when I looked at the P2 docs it seems like that should be perfectly doable but I'm currently laying out a board and only really want to wire 4 pins into VGA from the P2 if possible. I guess I should try to run a separate signal for the extra Vsync pin with a non-populated resistor just in case...
  • jmgjmg Posts: 15,144
    rogloh wrote: »
    For fewer than 5 pins and assuming your VGA monitor supports it I take it that P2 internal HW has nothing stopping it being implemented using SyncOnGreen (3 pins) or RGBS (4 pins) as well? The S signal being some form of composite sync, potentially also DAC driven at 0.7V pp like RGB, or a raw TTL level form.

    From when I looked at the P2 docs it seems like that should be perfectly doable but I'm currently laying out a board and only really want to wire 4 pins into VGA from the P2 if possible. I guess I should try to run a separate signal for the extra Vsync pin with a non-populated resistor just in case...

    I think I read somewhere that most monitors accept composite sync fine, behaving like they internally XOR'd V,H lines before processing anyway.
  • Yeah I'm confident I have monitors that support a combined sync form (XOR), and also a composite sync signal at video levels. Just checking that P2 video generating HW etc would be able to do this too, ideally just from the DACs using 4 wire RGBS. I could always toggle the HSync pin independently at 3.3V I guess but it might be nice to have the 4th DAC channel do it already synchronously with the colour channels perhaps. Trying to avoid the 5th pin.
  • rogloh wrote: »
    Yeah I'm confident I have monitors that support a combined sync form (XOR), and also a composite sync signal at video levels. Just checking that P2 video generating HW etc would be able to do this too, ideally just from the DACs using 4 wire RGBS. I could always toggle the HSync pin independently at 3.3V I guess but it might be nice to have the 4th DAC channel do it already synchronously with the colour channels perhaps. Trying to avoid the 5th pin.

    This may really be more of a driver question rather than P2 HW. I guess I'm not familiar enough with any existing video drivers on P2 yet to have full confidence in what is possible there. May have to try to write one when I get a chip to play with.
  • cgraceycgracey Posts: 14,133
    edited 2018-10-19 23:37
    SETCMOD D/# - is used to set up the video outputs.

    Bit 0 of D/# inverts the HSYNC signal. So, you would flip that bit at the beginning and end of your VSYNC period, HSYNC would be inverted for that duration. I didn't know that VGA monitors let you get away with that. That's great!!!
  • rogloh wrote: »
    rogloh wrote: »
    Yeah I'm confident I have monitors that support a combined sync form (XOR), and also a composite sync signal at video levels. Just checking that P2 video generating HW etc would be able to do this too, ideally just from the DACs using 4 wire RGBS. I could always toggle the HSync pin independently at 3.3V I guess but it might be nice to have the 4th DAC channel do it already synchronously with the colour channels perhaps. Trying to avoid the 5th pin.

    This may really be more of a driver question rather than P2 HW. I guess I'm not familiar enough with any existing video drivers on P2 yet to have full confidence in what is possible there. May have to try to write one when I get a chip to play with.

    That could be arranged. I need to travel to at least Syd and Adl this coming week.
  • cgracey wrote: »
    SETCMOD D/# - is used to set up the video outputs.

    Bit 0 of D/# inverts the HSYNC signal. So, you would flip that bit at the beginning and end of your VSYNC period, HSYNC would be inverted for that duration. I didn't know that VGA monitors let you get away with that. That's great!!!

    Yeah this can be very handy to save 1 pin (or even 2 with RGB SyncOnGreen). I know my older Sony CRT monitors support sync like this, should really try the range of Dell/Samsung LCDs I have as well. I think they also are meant to work but best to try to be sure.

    https://en.wikipedia.org/wiki/Component_video_sync
  • Tubular wrote: »

    That could be arranged. I need to travel to at least Syd and Adl this coming week.

    Thx, will let you know if I've got any time for one - still busy on this PCB design and component selection etc so a P2D2 right now might actually be a distraction and yet another context switch.
Sign In or Register to comment.