P2 VGA question
Cluso99
Posts: 18,071
in Propeller 2
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.
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.
Comments
'************************************* '* 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)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
And I can always combine RGB for mono and save some more general I/o pins.
I have yet to try sync on green
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)
I cannot see where/how HSYNC is being generated. Is it being generated or is the monitor syncing on the RGB?
If so, then I presume we cannot send negative hsync, only positive hsync?
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.
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 ???
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.
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.
Read this. It's verbatim from the doc but I've given it a title and formatted to its own page.
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.
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 outputCOLOR 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)'************************************* '* 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)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!
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
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.
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.
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?
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.
Sorry i didn't get that vga breakout to you this week. Will do that this weekend.