VGA 1920x1080x4bpp @148.5MHz - Rock Stable and 240 chars x 135 lines :)

12346»

Comments

  • Cluso99Cluso99 Posts: 15,450
    edited 2019-01-31 - 01:19:02
    cgracey wrote: »
    Very nice, Ray! What PLL values are you using?

    I noted there is some slight jitter in the pics although I didn't notice on the monitor. The first row of samples are all 2 pixels wide high and 2 pixels wide low but I noticed the pic has some with 3 pixels high. The pic is from the P2-ES board IIRC. I believe this is to do with the pins changing state as they are being sampled - some pins seem to be more pronounced which is to be expected.

    Oh, and I checked... It uses just over a 1KB, but this could be shrunk to maybe 800B as it's not really optimised properly.
    'P2-EVAL
      _XTALFREQ     = 20_000_000                                    ' crystal frequency
      _XDIV         = 4             '\                              '\ crystal divider                      to give 5.0MHz
      _XMUL         = 29            '| 145 MHz                      '| crystal / div * mul                  to give 145MHz
      _XDIVP        = 1             '/                              '/ crystal / div * mul /divp            to give 145MHz
      _XOSC         = %10                                   '15pF   ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
    
    
    {{'P2D2
      _XTALFREQ     = 12_000_000                                    ' crystal frequency
    ''_XDIV         = 12  * 2       '\                              ' crystal divider to give 0.5MHz
    ''_XMUL         = 297           '| 148.5MHz                     ' crystal / div * mul
    ''_XDIVP        = 1             '/                              ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30)
      _XDIV         = 4             '\                              '\ crystal divider                      to give 3.0MHz
      _XMUL         = 99            '| 148.5MHz                     '| crystal / div * mul                  to give 297MHz
      _XDIVP        = 2             '/                              '/ crystal / div * mul /divp            to give 148.5MHz
      _XOSC         = %01                                   'OSC    ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
    }}
      _XSEL         = %11                                   'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms)
      _XPPPP        = ((_XDIVP>>1) + 15) & $F                       ' 1->15, 2->0, 4->1, 6->2...30->14
      _CLOCKFREQ    = _XTALFREQ / _XDIV * _XMUL / _XDIVP            ' internal clock frequency                
      _SETFREQ      = 1<<24 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2  ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00  ' setup  oscillator
      _ENAFREQ      = _SETFREQ + _XSEL                                             ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss  ' enable oscillator
    
    '' 1920x1080 60Hz mode @ 148.5MHz   from https://timetoexplore.net/blog/video-timings-vga-720p-1080p
    '' ----------------------------------------------------------------------------------
      PIXEL_CLK     = _CLOCKFREQ              '
      H_DISP        = 1920  
      H_FPORCH      = 88    
      H_SYNC        = 44    
      H_BPORCH      = 148   
      V_DISP        = 1080   
      V_FPORCH      = 4  +32  'tweek
      V_SYNC        = 5      
      V_BPORCH      = 36 -32  'tweek
    '' ----------------------------------------------------------------------------------
    
    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)
  • Would 150MHz work on the P2-EVAL? That's just a 1% error.
    'P2-EVAL
      _XTALFREQ     = 20_000_000                                    ' crystal frequency
      _XDIV         = 2             '\                              '\ crystal divider                      to give 10.0MHz
      _XMUL         = 15            '| 150 MHz                      '| crystal / div * mul                  to give 150MHz
      _XDIVP        = 1             '/                              '/ crystal / div * mul /divp            to give 150MHz
      _XOSC         = %10                                   '15pF   ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
    
    Formerly known as TonyB
  • Cluso99Cluso99 Posts: 15,450
    edited 2019-01-31 - 01:28:15
    150MHz (/4*30/1) has a little shimmering.
    150MHz (/2*15/1) is more stable.
    145MHz (/4*29/1) is more stable.

    BTW the P2-ES chip doesn't get as hot as the original P2 epoxy chip from OnSemi.
    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)
  • Has anyone tried VGA on a COG other than COG #0? I can't seem to get it to work on my P2-ES board -- I can take the exact same code and with "coginit #0, #@entry" it works, but coginit #N, #@entry" does not if N <> 0.

    If I recall correctly in the FPGA the DACs were only connected to COG #0. Did that restriction somehow carry over to the P2 eval silicon?
  • You need to put the number of the new video cog into bits 11..8 of the DAC pins' WRPIN value. Also, make sure you set their DIR bits high.
  • 	cogid	pa
    	setbyte	dacmode_s,pa,#1
    	setbyte	dacmode_c,pa,#1
    
    Melbourne, Australia
  • This isn't in the docs, right?

    Way I remember it, each cog is hardwired to one set of 4 pins.
    Why do you need to tell it what cog it is?
    Prop Info and Apps: http://www.rayslogic.com/
  • cgracey wrote: »
    You need to put the number of the new video cog into bits 11..8 of the DAC pins' WRPIN value. Also, make sure you set their DIR bits high.

    Thanks Chip! That did the trick.
  • It says each cog has 4 DAC channels which are restricted to pins with the same two LSBs, so
    DAC0 channel only drives pins %xxxx00, DAC only %xxxx01, etc. So any cog can drive any pin, but
    when a cog wants to drive several pins it has to choose pins with distinct lower two bits.

    Well that's my reading, and I'm not clear if this is restricted to streaming DAC modes or all...
  • Hmm, I guess things changed at some point and I missed it or forgot...
    That's good. Much better this way...
    Prop Info and Apps: http://www.rayslogic.com/
  • I deliberately waited for real silicon before learning Prop2 instructions :)
  • Yes, we don't have that constraint of cogs' DAC channels being tied to certain pins.
  • Mark_T wrote: »
    I deliberately waited for real silicon before learning Prop2 instructions :)

    And it did not work out, they are still changing …

    Enjoy!

    Mike

    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Ahle2Ahle2 Posts: 953
    edited 2019-02-17 - 09:18:53
    So I finally came around to try this (from the first post) out on my SyncMaster F2380. After realising that the crystal setup was for the P2D2 and then making the changes for the eval board, the screen finally synced to the signal and displayed graphics. :smile:

    After looking at the different "effects" for a while it started to shimmer (as you all have noticed), but the strange thing is that it breifly becomes rock stable whenever there is pixel manipulation taking place. Some effect transistions take longer time and that gives the time to notice it. Just an observation that may be giving some clues to the problem. Strange indeed!
    SIDcog - The sound of the Commodore 64 in a single cog: Thread, OBEX
  • Ahle2 wrote: »
    So I finally came around to try this (from the first post) out on my SyncMaster F2380. After realising that the crystal setup was for the P2D2 and then making the changes for the eval board, the screen finally synced to the signal and displayed graphics. :smile:

    After looking at the different "effects" for a while it started to shimmer (as you all have noticed), but the strange thing is that it breifly becomes rock stable whenever there is pixel manipulation taking place. Some effect transistions take longer time and that gives the time to notice it. Just an observation that may be giving some clues to the problem. Strange indeed!

    I've made a few changes to the PLL loop filter which should improve its operation quite a bit. Next silicon will be better.
  • evanhevanh Posts: 8,033
    edited 2019-02-17 - 13:22:14
    For those still trying to absorb pad-ring I/O pin config for driving the DAC from either SETDACS or the Streamers, the pin config needed is referred to as COG_DAC mode. Chip details it in the PAD I/O sheet and I've listed it in my write up - https://forums.parallax.com/discussion/comment/1452036/#Comment_1452036

    Namely
    		for %TT = %01 and %MMMMM = %00000, %101_VV_xxxxSSSS = COG_DAC mode
    			%SSSS = Cog/streamer select: sets DAC level (registered?)
    

    Place the desired cog number in %SSSS of each pin config that will have its DAC operated by that cog.

    EDIT: That is the %P...P and %TT bits shown there only. The rest of the WRPIN config bits will likely be all zero. %MMMMM has to be zero.
    "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."
  • jmgjmg Posts: 13,993
    cgracey wrote: »
    I've made a few changes to the PLL loop filter which should improve its operation quite a bit. Next silicon will be better.

    Do you have the 'before' and 'after' simulation run plots for that change ?
  • jmgjmg Posts: 13,993
    Ahle2 wrote: »
    So I finally came around to try this (from the first post) out on my SyncMaster F2380. After realising that the crystal setup was for the P2D2 and then making the changes for the eval board, the screen finally synced to the signal and displayed graphics. :smile:

    After looking at the different "effects" for a while it started to shimmer (as you all have noticed), but the strange thing is that it breifly becomes rock stable whenever there is pixel manipulation taking place. Some effect transistions take longer time and that gives the time to notice it. Just an observation that may be giving some clues to the problem. Strange indeed!

    What time frames are you talking here, for 'good' vs 'bad' ?
    Can you run the pixel manipulation so it always runs, but does not change the display, to see if it is processor activity that is driving the improvement ?
    COG activity does affect power, in current P2, but not by a great deal.
  • cgraceycgracey Posts: 11,734
    edited 2019-02-18 - 07:02:48
    jmg wrote: »
    cgracey wrote: »
    I've made a few changes to the PLL loop filter which should improve its operation quite a bit. Next silicon will be better.

    Do you have the 'before' and 'after' simulation run plots for that change ?

    I will make some plots as soon as I can.

    Straightening up the loop filter cleaned up a lot of bad behavior.
Sign In or Register to comment.