Shop OBEX P1 Docs P2 Docs Learn Events
VGA 1920x1080x4bpp @148.5MHz - Rock Stable and 240 chars x 135 lines :) - Page 2 — Parallax Forums

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

2456

Comments

  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    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.

    The crystal oscillator is a single inverter. This keeps the gain low enough that the crystal doesn't go into an overtone mode. There is a string of 4 inverters, I think, that are fed by the XI pin, that sharpen up the incoming edges for clocking usage.
  • jmgjmg Posts: 15,140
    evanh wrote: »
    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.

    That may have been related to not having the VCO range, miss-match the counter ability ?
    ie you do not want the VCO feedback loop, to have a peak f while settling, that is too fast for the counter, otherwise it will never settle.
  • Cluso99Cluso99 Posts: 18,066
    Roy Eltham wrote: »
    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.
    The bottom of the pcb gets hot too, so I don't think there is any problems with the soldering of the ground pad.

    With the new settings at 148.5MHz (12MHz osc then /24 then *297) it looks good and full screen width.

    Now just need to play with the streamer to replay the hub twice to get full screen. Need to remove the 16x16 font for this to fit.

    img: the Acer #2 doesn't display a pic at all. Complains invalid setting. Unfortunately I e discovered I cannot enter the menu (maybe push button faulty) so I don't know what setttings are there. It works fine on my laptop tho. Not going to waste time on this.
  • Cluso99Cluso99 Posts: 18,066
    1920x1080 @ 2bpp 148.5MHz is running. It needs 506.25KB of Hub ram. Just enough in P2 :)
    I loaded up the cogs and then used Hub as the video buffer.

    Does some graphics. Some gets a bit jittery depending on the bitmap though coloured lines seems fine. Need more testing and adjustments as I suspect I am not seeing every pixel on screen Sotheby's sync and porches need adjusting.
  • cgraceycgracey Posts: 14,133
    Cluso99, I bet if you had a scope, you could spot the problem right away.
  • Cluso99 wrote: »
    1920x1080 @ 2bpp 148.5MHz is running. It needs 506.25KB of Hub ram. Just enough in P2 :)

    640kB is simply fanciful, 5.75kB ought to be enough for everybody. LOL! Great work.

    Actually I think mono 1080p might be quite useful.
  • I do too. And, when done using component signalling, it is just one pin. (Y)
  • Cluso99Cluso99 Posts: 18,066
    Chip,
    My scope is too slow. I haven’t used it in 20 years.
    However, I haven’t been trying to fix any jitter. I have just been getting it to run and move things around so I can load up the cogs and then I can use all 512KB of HUB for buffers :smiley:
    Now I’ve done that but had to remove all text and font from the graphics. Next I will put an 8x8 font into LUT and I have 5.75KB of HUB for a text buffer section. I have a font I used in P1.
    Unfortunately will not have much time the next 3 days :(
    Now I have a full screen I can check I can see all edges with a rectangle outline of pixels and adjust accordingly.
    Then I can post for Peter or Lachlan to check temperatures. I am only running 2 cogs at 148.5MHz and it gets hot and starts to jitter fairly quickly which isn’t good. I need to check current etc.
  • What about current, Cluso? Does your meter display current consumption at 5v? We can always match current consumption, then take thermal photos or measurements.

    OzProp and I have added DS18B20 temperature sensors to our R2D2s, to log ambient temperature.

  • roglohrogloh Posts: 5,122
    edited 2018-11-19 00:28
    Tubular wrote: »
    OzProp and I have added DS18B20 temperature sensors to our R2D2s, to log ambient temperature.
    This is a great idea Tubular. I was thinking of adding a one wire interface for one of these to my carrier board for this purpose, but your idea of simply modding/attaching on the P2D2 directly makes far more sense and avoids some additional connectors and wiring. Did you use true one wire (parasitic) operation or did you use its separate powered form?

    Also I wonder if it is possible to dual purpose a serial port pin or flash pin for this somehow. Will have to dig into one wire protocol to see if this is doable. It might not be. Another possibility is to use a simple analog temp sensor and put a pin of the P2 into ADC mode.
  • Cluso, have you tried testing with different monitors? I wonder if the jitter is a feature of the monitor. When you send VGA to a flat screen monitor it has to digitize the video signal to be able to display it. If the timing is off a bit it can end up digitizing the signal right a the transition between adjacent pixels instead of in the middle of a pixel. This will cause the image to jitter as noise causes it sample at the end of a pixel versus the beginning of a pixel. When you touch the P2 you may be changing the clock frequency slightly, which will remove the jitter.

    If you still have an old CRT monitor it would be interesting to see if it jitters. Or try other flat screen monitors.
  • Cluso99Cluso99 Posts: 18,066
    Dave Hein wrote: »
    Cluso, have you tried testing with different monitors? I wonder if the jitter is a feature of the monitor. When you send VGA to a flat screen monitor it has to digitize the video signal to be able to display it. If the timing is off a bit it can end up digitizing the signal right a the transition between adjacent pixels instead of in the middle of a pixel. This will cause the image to jitter as noise causes it sample at the end of a pixel versus the beginning of a pixel. When you touch the P2 you may be changing the clock frequency slightly, which will remove the jitter.

    If you still have an old CRT monitor it would be interesting to see if it jitters. Or try other flat screen monitors.
    I want to complete the code before I delve into the jitter too much. I did have it stable before. But when it gets hot it does cause jitter.

    I'll have to find my multimeter temp probe. It's a bimetal joint that you press onto the surface. Probably a P2 ADC could be setup to use it.
  • cgraceycgracey Posts: 14,133
    Cluso99, I think you may be running the VCO too fast.

    If you are clocking the chip at 100MHz+, bypass the VCO post-divider by using %1111 and run the VCO at the desired chip frequency.

    For a 12MHz crystal, divide it by 24 to get 0.5MHz, then multiply that frequency in the VCO by 297, in order to get 148.5MHz.

    Right now, you may be running the chip at 148.5MHz, but the VCO is going 297MHz. The whole thing is heating up and the 10-bit VCO divider is bumping into its limits at that frequency and temperature.
  • Just to confirm @cluso99 ozprop and I were also able to see shivers/shimmers today

    @rogloh for the DS18B20 we are taking advantage of the external pullup on P58 that fixes the boot glitch. So the DS18B20 is on that pin (OzProp's idea, works well, but we're not using SPI nor MicroSD at this point). We've been joking about gluing an array to the top of the Prop so we can work out which pizza wedge corresponds to which cog



  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    Cluso99, I think you may be running the VCO too fast.

    If you are clocking the chip at 100MHz+, bypass the VCO post-divider by using %1111 and run the VCO at the desired chip frequency.

    For a 12MHz crystal, divide it by 24 to get 0.5MHz, then multiply that frequency in the VCO by 297, in order to get 148.5MHz.

    Right now, you may be running the chip at 148.5MHz, but the VCO is going 297MHz. The whole thing is heating up and the 10-bit VCO divider is bumping into its limits at that frequency and temperature.

    Yes. I have a 12MHz oscillator (not xtal). When I was using 168 or 180MHz I was dividing by 12, then multiplying by 168 or 180, then %1111.
    When I changed to 148.5MHz, I am dividing by 24, then multiplying by 297, then %1111.
    CON
      _XTALFREQ     = 12_000_000                                    ' crystal frequency
      _XDIV         = 12  * 2                                       ' crystal divider to give 0.5MHz
      _XMUL         = 297 '148.5MHz '168 * 2                        ' crystal / div * mul
      _XDIVP        = 1                                             ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30)
      _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                 
      V_SYNC        = 5                 
      V_BPORCH      = 36                
    '' ----------------------------------------------------------------------------------
    
    DAT             org     0
    video_buffer                                            ' $00000 (hub ram 506.25KB) half screen 4bpp [w * h / 2]
    '+-------[ Set Xtal ]----------------------------------------------------------+ 
                    hubset  #0                              ' set 20MHz+ mode
                    hubset  ##_SETFREQ                      ' setup oscillator
                    waitx   ##20_000_000/100                ' ~10ms
                    hubset  ##_ENAFREQ                      ' enable oscillator
    '+-----------------------------------------------------------------------------+
    
  • jmgjmg Posts: 15,140
    Tubular wrote: »
    Just to confirm @cluso99 ozprop and I were also able to see shivers/shimmers today

    Is that running the same code ?
    Previous ozprop report was shimmers needed a hand near the osc corner and it could stop totally. Is that still the case ?
    Or do these shimmers more match Cluso99 reports of 'appear when hot' & 'can remove on touch'
  • cgraceycgracey Posts: 14,133
    edited 2018-11-19 07:22
    Cluso99, when the crystal divider is large, you get more jitter, due to less frequent feedback. Try this, instead:

    Crystal divide = 4 (%000011)
    VCO multiply = 99 (%0001100010)
    VCO post-divide = 2 (%0000)

    That will produce 12/4*99/2=148.5MHz.

    And here are the timings for 1080p/60:
    Name        1920x1080p60
    EDID Name          1080p
    Aspect Ratio        16:9
    Pixel Clock        148.5 MHz
    Pixel Time         6.734 ns
    Active Pixels  2,073,600 total
    8-bit Memory      16,200 Kbits
    32-bit Memory     64,800 Kbits
    Data Rate           3.56 Gbps
    
    Horizontal Timings
    Active Pixels       1920
    Front Porch           88
    Sync Width            44
    Back Porch           148
    Blanking Total       280
    Total Pixels        2200
    Sync Polarity        pos
    
    Vertical Timings
    Active Pixels       1080
    Front Porch            4
    Sync Width             5
    Back Porch            36
    Blanking Total        45
    Total Pixels        1125
    Sync Polarity        pos
    

    https://timetoexplore.net/blog/video-timings-vga-720p-1080p

    Note the horizontal sync of 44 clocks.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Cluso99, when the crystal divider is large, you get more jitter, due to less frequent feedback. Try this, instead:
    ....

    Yes, but that sort of jitter is not likely to degrade with temperature so much ?
    The code in #1 does not appear to use any post-vco divide, but it does not seem to have been updated ?

    There is also a solution at 12/8*99 = 148.5MHz which is a change in operating point from /24 * 297, (PFD is 3x) but keeping VCO the same.

  • Cluso99Cluso99 Posts: 18,066
    Chip,
    yes those timings for 1080p are what I am using and posted above.
    I'll give those xtal settings a go.
  • Cluso99Cluso99 Posts: 18,066
    Hey Chip,
    This looks to be much better. It has been running longer too. The P2 and pcb is hot still, but doesn't lose sync like it did before. :smiley:

    There are a few bugs in the display cog, but i've posted the code anyway.

    Note the graphics that display the "c" moniker does have some horizontal flutter. Bars and lines are quite stable (not perfect).

    I believe the field display is not perfectly synchronised to the syn pulses, so this needs some work to scope it out. I am not getting the edges of the display either so some porch adjustments are required. But hey, it works :smiley::smiley::smiley:
  • cgraceycgracey Posts: 14,133
    Good, Cluso99. Your old scope would instantly show you if your HSYNC was consistent. That needs to be determined.
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-11-19 10:40
    It's still going some 5 or more minutes later. Never got this far before without losing sync.

    Chip, what I think is that the vertical sync is not specifically timed with respect to the horizontal sync due to it being written directly with OUTNOT while the streamer is running somewhere in the background. I would like to try and get some actual timing relationship between the streamers xcont and the outnot.

    While 2bpp is not working properly for me yet although the new settings may help (or its a bug of mine but too late tonight, maybe in the morning), I want to get the streamer logging pins to hub, then re-working the received stream into pixels to show on the VGA.

    To have fun, you have to have an objective to your code ;)

    So I should be able to stream 512KB of 8 I/O at full clock speed, so that's 512K samples @ 148.5MHz (6.7ns) = ~3.53s of samples :smiley:

    Yes, I might have to go searching for my scope box. It's burried in the garage since the last move :(
  • Cluso99Cluso99 Posts: 18,066
    Still running >30 mins later. Hot but fine :smiley:

    Attached is a video of the screen. Its not very good tho :(
  • cgraceycgracey Posts: 14,133
    I would imagine your VSYNC would be accomplished via 'DRVNOT #vsync_pin' and it would come right after a blank line. I suppose the monitors register VSYNC on HSYNC. I wish we knew if your HSYNC is consistent.
  • Cluso99Cluso99 Posts: 18,066
    I am sure the HSYNC is consistent as it comes out the same as the rgb does. VSYNC on the other hand, while it will be consistent, it's the relationship to HSYNC that concerns me more. I am just not sure how to time the streamer with the generation of VSYNC.
    Anyway, all will be revealed when I get the LA working on it :)
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    It's still going some 5 or more minutes later. Never got this far before without losing sync.
    You did not mention losing sync before, just shimmers.
    The attached code seems to be 180MHz, is that an old copy ?
  • jmgjmg Posts: 15,140
    Tubular wrote: »
    Just to confirm @cluso99 ozprop and I were also able to see shivers/shimmers today
    Are you able to check this on a CRT monitor ?

  • Cluso99Cluso99 Posts: 18,066
    No CRT monitors left here. I don't even have any monitors <23" any more (laptop excluded)
  • We still have old some old monitors, wonder if we can drive a NEC Multisync...
  • Cluso99Cluso99 Posts: 18,066
    jmg wrote: »
    Cluso99 wrote: »
    It's still going some 5 or more minutes later. Never got this far before without losing sync.
    You did not mention losing sync before, just shimmers.
    The attached code seems to be 180MHz, is that an old copy ?

    When the chip got too hot the pic started to break up. Putting my finger/thumb cooled sufficiently to fix. Now I can run >30 minutes (not tested longer) without problems.

    BTW I am fairly sure I posted the correct code. Did you check the CON section and not comments? Sorry cannot check on my phone.
Sign In or Register to comment.