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

Cluso99Cluso99 Posts: 15,080
edited 2018-12-08 - 01:32:21 in Propeller 2
Rock stable now :)

The screen buffer uses 506.25KB of HUB RAM which is 1/2 screen, so it is duplicated.
(see post 21-22 Nov 2018 below)



The visible portion is smaller than 1920x1080 (1440x540) as currently there isn't enough time to setup the full width pixels, nor enough hub ram for the full pixel display. These can all be worked on as we are not at the silicon limits.

FWIW I have just reduced the visible pixels and increased the front & back porches. This is not the right way to do it.

After some time, the P2 is somewhat hot to the touch - no fan, no heatsink, ambiant ~25C
(jmg: please don't ask for temperature, fans, heatsinks, etc)

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)
«13456

Comments

  • Nice, Cluso99.

    We need to make a tile driver. Then, we could have instant text, as well as graphical windows made from tiles.

    Was this demo 4 bits per pixel?
  • Good work so far Cluso. Keep pushing it.

    Hopefully there is also scope in the P2 for doing even more than 1080 including analog VGA@1920x1200 which happens to be the resolution of two of my 24 inch Dell monitors. I think the dot clock for that is about 193MHz or thereabouts (VESA) so it could require officially overclocking but you can always try to play about with the timings a bit.

    I know there is insufficient space in internal hub RAM for full graphics framebuffer (perhaps external RAM still has a chance), but sprites and text modes would be rather good to have at this high res.
  • jmgjmg Posts: 13,610
    Cluso99 wrote: »
    Rock stable now :)

    What happened to the shivers ? Did that have a software cure ?
    Can ozpropdev duplicate his loss of picture issue is also fixed ?

  • Cluso99Cluso99 Posts: 15,080
    edited 2018-11-17 - 01:26:56
    Further testing... Oops - I changed back to 180MHz

    I am using 150MHz 180MHz. As I said, moderately hot. After a number of minutes (perhaps more as I have been testing and then resetting so the chip etc may not have cooled properly) the display starts to quiver. Touching the chip cools it sufficiently as the quiver goes away almost immediately I touch the chip.

    The streamer is flat out, and there is quite a lot of maths going on in another cog.

    Now this problem. Here is the setup code for the sync & porches. I can center the screen top and bottom fine. I have adjusted to have the display full width but I only get around 2/3 width. Not sure what is happening. I am not out of hub ram. $753DF is last used and I have to <$7C000.
    '' 1920x1080 60Hz mode @ xxxMHz   from http://www.epanorama.net/faq/vga2rgb/calc.html
    '' ----------------------------------------------------------------------------------
      PIXEL_CLK     = _CLOCKFREQ              '
      H_DISP        = 1920          '-480      '- 240 '480 '960
      H_FPORCH      = 32            '+120      '
      H_SYNC        = 696                     '
      H_BPORCH      = 32            '+360      '+ 240 '480 '960 
      V_DISP        = 1080              -600  '- 540 
      V_FPORCH      = 22                +300  '
      V_SYNC        = 11                      '
      V_BPORCH      = 22                +300  '+ 540   
    '' ----------------------------------------------------------------------------------
      w             =  H_DISP           
      h             =  V_DISP           
      fpix          =  float(PIXEL_CLK) 
      top_blanks    =  V_FPORCH         
      sync_blanks   =  V_SYNC           
      bottom_blanks =  V_BPORCH         
      before_sync   =  H_FPORCH         
      sync          =  H_SYNC           
      before_visible = H_BPORCH         
    '' ----------------------------------------------------------------------------------
    
    Here is the streamer code... I've noticed we can use _ret_
                    rdfast  ##w*h/128,##@video_buffer       'set rdfast to wrap on bitmap
                    setxfrq ##fset                  'set transfer frequency to xxMHz
                    dirh    #vsync  'make vsync pin output
    
                    '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_s,#0            'enable dac modes in pins 0..3
                    wrpin   dacmode_c,#1
                    wrpin   dacmode_c,#2
                    wrpin   dacmode_c,#3
                    setnib  dira,#$f,#0
    
    ' Field loop
    field           mov     x,#top_blanks
                    call    #blank
    
                    mov     x,##h                   'set visible lines
    line            call    #hsync                  'do horizontal sync
                    xzero   m_rf,#0                 'visible line
                    djnz    x,#line                 'another line?
    
                    mov     x,##bottom_blanks
                    call    #blank
                    outnot  #vsync  'sync on
                    mov     x,#sync_blanks
                    call    #blank
                    outnot  #vsync  'sync off
                    jmp     #field                  'loop
    
    ' Subroutines
    blank           call    #hsync                  'blank lines
                    xcont   m_vi,#0
                    djnz    x,#blank
                    ret
    
    hsync           xcont   m_bs,#0                 'horizontal sync
                    xcont   m_sn,#1
                    xcont   m_bv,#0
                    ret
    
    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+before_sync
    m_sn            long    $CF000000+sync
    m_bv            long    $CF000000+before_visible
    m_vi            long    $CF000000+w             'visible
    m_rf            long    $6F000000+w             '4bit RFLONG LUT
    x               res     1
    y               res     1
    
    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)
  • jmgjmg Posts: 13,610
    Cluso99 wrote: »
    ... As I said, moderately hot. After a number of minutes (perhaps more as I have been testing and then resetting so the chip etc may not have cooled properly) the display starts to quiver. Touching the chip cools it sufficiently as the quiver goes away almost immediately I touch the chip.

    Do you notice any part of the chip is better/worse when touched ?

    ozpropdev reported almost the opposite effect - maybe he can test this new code too ?
    ozpropdev wrote:
    With my board running Cluso's code image is fine.
    The 'shiver' appears if I place a finger on the chip near the XO/Xi corber.
    The closer I get to the oscillator corner the worse it gets eventually losing video all together.
  • Here are results with my Acer X233H monitor
    165MHz= doesnt work
    168MHz=excellent, no shiver
    180MHz=single pixel shiver

    By single pixel shiver I mean that a vertical bar shows the edge to be varying by 1 pixel back and forth.

    I have to say that the P2 is getting quite hot to touch after it's been running a while. I am hoping the properly packaged chips do a better job.

    I am still not getting full screen width. I think the code should be generating color pixels to the edge of the display.
    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)
  • If you are running synchronously to the P2 clock then there should not be too much jitter unless the oscillator module is introducing it. Perhaps this is something coming from your LCD monitor sampling. If you have a high res analog CRT monitor you could possibly see if the jitter is noticeable on that. I've seen similar different behaviours on P1 between LCD and CRT but then again the P1 sometimes had more inherent jitter on it's output with the PLL divider method and the CRT monitor can sort of help blur it out, while the LCD has to put the pixel into a discrete cell on the panel making its movement noticeable.
  • jmgjmg Posts: 13,610
    Looks like that monitor can tolerate varying scans by sampling, but that can cause shivers...

    Monitor : Signal
    Internal Interface Analog/Digital
    Frequency Horizontal: 54.2-83.8KHz
    Vertical: 49-75Hz
    Sync Type Not Specified by Manufacturer
    Resolution 1920 x 1080

    I find this
    http://hamsterworks.co.nz/mediawiki/index.php/VGA_timings

    says

    1920x1080x60 (aka 1080p) 148.50MHz /2200 H /1125 V
    148.5M/2200 = 67500 Line scan, ans/1125 = 60 Hz Frame
    ( above Monitor tolerated H values are appx 67500 +/- 24% )

    Did you try exactly 148.5MHz, which should have no sampling errors ?
  • Ray
    Try changing this line of code.

    Depending on the mode one or the other seems to help.
    Change
                    xzero  m_rf,#0                 'visible line
    to
                    xcont  m_rf,#0                 'visible line
    
    Melbourne, Australia
  • I also tried two more LCD screens...
    Acer X233H:  165MHz= doesnt work                                      
                 168MHz=excellent, no shiver                              
                 180MHz=single pixel shiver                               
    Acer G246HL: similar results to above, but slightly off-screen to left
    Acer X233H#2: doesnt work (menu not wkg, VGA to laptop OK)            
    

    jmg: 148.5MHz doesnt work
    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)
  • Changing the sync/porch and using 148.5MHz gives a good picture, but not quite as stable ie vertical has a single pixel shiver.
      PIXEL_CLK     = _CLOCKFREQ = 148.5MHz 
      H_DISP        = 1920       
      H_FPORCH      = 32         
      H_SYNC        = 216        
      H_BPORCH      = 32         
      V_DISP        = 1080       
      V_FPORCH      = 27         
      V_SYNC        = 11         
      V_BPORCH      = 27         
    
    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)
  • Is it a single pixel shiver in a vertical line all the way down the screen on each scanline, or in multiple places along the scan line?
  • This seems to work nicely
    '' 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              -600 
      V_FPORCH      = 4                 +300 
      V_SYNC        = 5                     
      V_BPORCH      = 36                +300 
    '' ----------------------------------------------------------------------------------
    
    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)
  • jmgjmg Posts: 13,610
    Cluso99 wrote: »
    I also tried two more LCD screens...
    Acer X233H:  165MHz= doesnt work                                      
                 168MHz=excellent, no shiver                              
                 180MHz=single pixel shiver                               
    Acer G246HL: similar results to above, but slightly off-screen to left
    Acer X233H#2: doesnt work (menu not wkg, VGA to laptop OK)            
    

    jmg: 148.5MHz doesnt work

    What visible raster does this have.
    I've found the hi-res monitors can be a 'little too intelligent', and they look for a valid visible (non black) limit, to perform their centering and sampling calcs.
    If you are feeding less than 1920 visible, that could throw things ?
    I've also found pixels in the blanking time, can confuse LCDs intelligence sense, whereas CRTs simply ignore them (of course)
  • jmgjmg Posts: 13,610
    Cluso99 wrote: »
    Changing the sync/porch and using 148.5MHz gives a good picture, but not quite as stable ie vertical has a single pixel shiver.
      PIXEL_CLK     = _CLOCKFREQ = 148.5MHz 
      H_DISP        = 1920       
      H_FPORCH      = 32         
      H_SYNC        = 216        
      H_BPORCH      = 32         
      V_DISP        = 1080       
      V_FPORCH      = 27         
      V_SYNC        = 11         
      V_BPORCH      = 27         
    

    Sounding better - at least it works while meeting some spec. I see the V is out slightly there, with 1045L total , whilst the reference link says 1025L - I doubt that affects X-Lock, but you never can be certain...
    Does Acer X233H#2 now work at 148.5 ? - strange two with the same model # differ ?
  • Cluso,
    re: P2 chip temp. When the P2 is hot to the touch on top, what is the temp of the bottom of the board below the chip? I'm wondering if your particular board got a good solder connection from the chip ground pad to the PCB?

    Chip seemed to indicate that his setup was not getting that hot when running at 180Mhz, and even wasn't bad at 250Mhz. I know he drilled out the hole in the PCB and loaded up a lot of solder into that connection.
  • jmgjmg Posts: 13,610
    Cluso99 wrote: »
    I have to say that the P2 is getting quite hot to touch after it's been running a while. I am hoping the properly packaged chips do a better job.

    Unlikely, as the main thermal path is to the large copper pad under the die. The plastic above the die makes little difference.
    4 layer PCB should reduce the hot-spot temperatures significantly.

    Cluso99 wrote: »
    I am still not getting full screen width. I think the code should be generating color pixels to the edge of the display.
    That suggests the monitor is not seeing a full raster, or decided it is different for some reason ?

  • I think we have a similar monitor at work, Cluso, we could try this on monday. I believe its an Acer x232h rather than x233h. From memory Rayman might have something similar

    Also when running the frequency vs temperature tests recently, we might have seen a bit of "frequency slippage" on the dmm. This occurred many seconds after the test started and we had been deliberately heating the chip by running at 350 MHz for many seconds, without fan. I'll revisit this and see what we can deduce. If the frequency slips, one would also expect current to drop correspondingly, and we'll watch this closely

  • YanomaniYanomani Posts: 850
    edited 2018-11-17 - 04:20:24
    Hi Tubular

    To achieve that frequency (350 MHz), what value was used at the crystal or clock oscillator?
    And the divisor and multiplier? What values were used?
  • jmgjmg Posts: 13,610
    edited 2018-11-17 - 04:25:54
    Just spotted this - this forum has some quite strange pipeline effects, and non-linear time....
    Cluso99 wrote: »
    This seems to work nicely
    '' 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              -600 
      V_FPORCH      = 4                 +300 
      V_SYNC        = 5                     
      V_BPORCH      = 36                +300 
    '' ----------------------------------------------------------------------------------
    

    Ah, so that's exactly on spec - great. No shivers, at any temperature ?
    Does it work nicely on all Monitors you have ?

    1920+88+44+148 = 2200
    1080+4+5+36 = 1125

    Did the change in V (from above) fix this ? Or did the H changes, around the porch settings, (same totals) fix this ?

  • jmgjmg Posts: 13,610
    Tubular wrote: »
    Also when running the frequency vs temperature tests recently, we might have seen a bit of "frequency slippage" on the dmm. This occurred many seconds after the test started and we had been deliberately heating the chip by running at 350 MHz for many seconds, without fan. I'll revisit this and see what we can deduce. If the frequency slips, one would also expect current to drop correspondingly, and we'll watch this closely

    You mean it slips at 350MHz ? Not really suprising, as the counters stop dividing properly as they heat up....

  • Yanomani wrote: »
    Hi Tubular

    To achieve that frequency (350 MHz), what value was used at the crystal or clock oscillator?
    And the divisor and multiplier? What values were used?

    its a 12MHz osc like on all the P2D2s. I think it was
    /1 divisor (works best at high freq)
    * 29 to give 348MHz

    However, I'll double check this because I was pretty sure I saw 350 not 348 MHz, and it would pay be to be sure. At the time, we were really just trying to heat things we didn't care exactly what frequency.
  • jmgjmg Posts: 13,610
    Cluso99 wrote: »
    .. After a number of minutes (perhaps more as I have been testing and then resetting so the chip etc may not have cooled properly) the display starts to quiver. Touching the chip cools it sufficiently as the quiver goes away almost immediately I touch the chip.

    Another test idea for anyone that see's a temperature-related quiver...
    Did you try disconnect and re-connect of the monitor, to force a readjust ?

    If things are exactly lined up, and it locks to a native resolution, then the sampling tolerance over 1 H line of 2200 units, is 454ppm, or ±227ppm, which should be inside Xtal tolerances.
    ( Hopefully that latest 148.5MHz settings, shows no effects and it is well margined and aligned )

    Now, imagine things are not quite lined up, and it selects some 'best match' sampling, it may be that it is more on one edge and now perhaps 50ppm of drift is enough ?
    The oscillator is physically quite close to the P2 - do you have an exact part number for that ?
  • Thanks Tubular

    It'll be very good if you can confirm it latter.

    When you say that a division by 1 works better, in order to achieve consistent results at high frequencies, is it due the fact you are using a clock oscillator, not a crystal?

    Also, when you have time, please try multiplying by 27 and 28, while keeping the same basic division ratio (÷1).

    It would be also interesting to verify what are the limits (divisor/multiplier) that could be achieved, if a crystal is used instead.

    Henrique
  • jmgjmg Posts: 13,610
    Yanomani wrote: »
    It would be also interesting to verify what are the limits (divisor/multiplier) that could be achieved, if a crystal is used instead.

    Why would you expect a crystal to be any different, in Digital divider choices, from an Oscillator module ?
    The VCO range & counter ability, is what sets the divider choices, and the Fin value, so the MHz matters, not if a Xtal is used.
    There is likely some upper limit where the Xtal oscillator is unreliable starting, but that not a PLL Divider issue.

  • I tried 1920x1200 @ P1silicon (worked!) so P2 should have no problem with this.

    Using 2-color mode you need 256 kB for your FB and it will fit in P2 hub. Use good old Commodore/Atari/Amiga tricks - display list, attribute memory, reducing horizontal res while adding colors, doing HAM - my P1V retromachine uses al these kind of tricks.

    This should make colorful (with some restriction) picture @ full HD mode possible without a tile driver.
  • Yanomani wrote: »
    Thanks Tubular

    It'll be very good if you can confirm it latter.

    When you say that a division by 1 works better, in order to achieve consistent results at high frequencies, is it due the fact you are using a clock oscillator, not a crystal?

    Also, when you have time, please try multiplying by 27 and 28, while keeping the same basic division ratio (÷1).

    It would be also interesting to verify what are the limits (divisor/multiplier) that could be achieved, if a crystal is used instead.

    Henrique

    This came from the early overclocking tests. I don't know why exactly, but we found we could push further with the /1 divider than the other divisor options. The /1 just let us push the furthest (372 MHz OK with coolant, 384 not). But everything is a bit marginal up there

  • jmgjmg Posts: 13,610
    Tubular wrote: »
    This came from the early overclocking tests. I don't know why exactly, but we found we could push further with the /1 divider than the other divisor options. The /1 just let us push the furthest (372 MHz OK with coolant, 384 not). But everything is a bit marginal up there

    Maybe the /1 just allows a lower division from the VCO ?
    eg 372 MHz is /31 to get to 12MHz, which is right on a 5 bit threshold - lower PFD frequencies, mean higher dividers, and the carry chain in the counter will run out of time...

    eg maybe 384MHz is ok, with a 48MHz Oscillator, as that only expects the counter to /8. ?

    I'm not sure how much a reload counter speeds up with lower reloads ?
  • The PLL's crystal÷1 setting gives the strongest/fastest voltage-adjustment feedback to the VCO. At ÷2 it halves, and halves again at ÷4, and so on. So, keeping a low crystal-divider value may result in less jitter.
  • Chip,
    I vaguely remember you and JMG discussing adding extra inverters into the crystal/PLL circuits, for the purpose of slowing it down, after the test die came back from the shuttle run. I don't remember anything particular though.

    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
Sign In or Register to comment.