P2 Invaders/Cordic Crickets VGA demo for P2 Eval boards

ozpropdevozpropdev Posts: 2,370
edited 2018-12-26 - 10:37:00 in Propeller 2
Here's a VGA demo for the P2 Eval board.
Crickets wander around the screen with some simple autonomous intelligence.
It uses the Cordic solver extensively for graphics and movement functions.
An earlier version of this for P2-Hot was called "Cordic Bugz".
The name was changed because it caused "alarm" amongst fellow testers.
Just a bit of fun. :)

Edit:
P2 Inavders
Also here's the latest version for the P2 Eval board.
Supports analog joystick, sound and now has demo mode.


Melbourne, Australia

Comments

  • Really nice Brian.
    For those with a P2D2 & VGA on pins P0-4, here is the version for P2D2 :smiley:
    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)
  • RaymanRayman Posts: 9,126
    edited 2018-12-26 - 12:24:52
    Just had to change basepin to 0 and works for me.

    But, screen was a hair shaky.
    Changed dv to 15 and mlt to 135 and it's better.

    My P62 led is flashing for some reason...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Just had to change basepin to 0 and works for me.

    But, screen was a hair shaky.
    Changed dv to 15 and mlt to 135 and it's better.

    My P62 led is flashing for some reason...

    Debug data on P62
    Melbourne, Australia
  • jmgjmg Posts: 12,884
    Rayman wrote: »
    But, screen was a hair shaky.
    Changed dv to 15 and mlt to 135 and it's better.
    Sounds like another indication PFD=0.5MHz, is just a bit too low for Displays, even 640x480 ? (what monitor did you use ?)

    It may be better to target 25.175 more directly ? /11 and *97 is 786ppm, and /16 * 141 is 142ppm



  • Rayman wrote: »
    But, screen was a hair shaky.
    Changed dv to 15 and mlt to 135 and it's better.

    Oops!
    Forgot to set caps in the HUBSET instructions in both programs.

    Results from frequency counter show differences.

    CC = %01 No caps, 180_022_625 Hz
    CC = %10 15pF caps, 179_995_616 Hz
    CC = %11 30pF caps, 179_987_727 Hz

    15pF seems to be the best choice from my testing.
    		hubset	##clk | %1111_10_00
    		waitx	##20_000_000/100	'wait ~10ms
    		hubset	##clk | %1111_10_11	'15pf caps,PLL
    

    BTW a div=57, mul = 287 for 100.701 MHz divides closer to 25.175 MHz pixel clock.
    Frequency counter shows 100_699_335 Hz



    Melbourne, Australia
  • jmgjmg Posts: 12,884
    ozpropdev wrote: »
    Results from frequency counter show differences.

    CC = %01 No caps, 180_022_625 Hz
    CC = %10 15pF caps, 179_995_616 Hz
    CC = %11 30pF caps, 179_987_727 Hz

    15pF seems to be the best choice from my testing.
    		hubset	##clk | %1111_10_00
    		waitx	##20_000_000/100	'wait ~10ms
    		hubset	##clk | %1111_10_11	'15pf caps,PLL
    

    How did you measure the 180.022625 MHz ? Was that calculated from another measurement ?
    ozpropdev wrote: »
    BTW a div=57, mul = 287 for 100.701 MHz divides closer to 25.175 MHz pixel clock.
    Frequency counter shows 100_699_335 Hz
    What is the jitter like with /57 ?

  • Thinking about basepin, I don't think it can work as written...
    This sets video cog to #0:
    #0
        video_cog
    

    Well, not really as it just winds up being #0 by default.

    But, cog #0 can only output video on basepin=0
    Prop Info and Apps: http://www.rayslogic.com/
  • RaymanRayman Posts: 9,126
    edited 2018-12-28 - 19:42:56
    What works well is to set clock to 200 MHz and then this:
    fpix = 25_000_000.0
    

    BTW: I like your other clock setting code better... Spliced it in here:
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Thinking about basepin, I don't think it can work as written...
    This sets video cog to #0:
    #0
        video_cog
    

    Well, not really as it just winds up being #0 by default.

    But, cog #0 can only output video on basepin=0

    For video on different cogs the cog number needs to be set in the dacmdoe.
    	cogid	pa
    	setbyte	dacmode_s,pa,#1
    	setbyte	dacmode_c,pa,#1
    
    Here's the VGA bird demo running om a selectable cog.
    Melbourne, Australia
  • jmg wrote: »
    How did you measure the 180.022625 MHz ? Was that calculated from another measurement ?

    I simply put the cog in a loop outputting f/1000 on a pin, then measure with a frequency counter.
    Frequency counter is a Agilent 5318A, temp stabilized and very accurate.
    	rep	#2,#0
    	drvnot	#24
    	waitx	#496
    


    Melbourne, Australia
  • I think you could check PLL drift by connecting XO to a pin, while keeping Fsys above 20MHz and using the smart pin to count edges for some fixed number of clocks. Then, subtract a constant from the reading to make it equal $80 if everything is expected, then output it to a DAC pin.
  • jmgjmg Posts: 12,884
    edited 2018-12-29 - 05:51:22
    cgracey wrote: »
    I think you could check PLL drift by connecting XO to a pin, while keeping Fsys above 20MHz and using the smart pin to count edges for some fixed number of clocks. Then, subtract a constant from the reading to make it equal $80 if everything is expected, then output it to a DAC pin.

    I'm not sure that will work, but another mode might.
    Once the PLL is locked, it is not really going to have long term frequency changes, and the phase noise that does appear, will be within 1 cycle.
    ie with Higher PFD the 'eye' diagram worsens, but the frequency remains locked.

    What you need is a means to measure phase, or a time interval XO (-> Pin) to another pin (PLL/8) - I think the Smart Pins can do that ?

    The phase eye worsens to be maybe 15ns at highest PFD, which I think a 180~200MHz sysclk could capture.

    The DOCs title is vague, but this text is promising :
    (My Counter calls this mode Time interval A-B
    X[31:0] establishes how many A-input rise/edge to B-input rise/edge periods are to be measured.
    
    Y[1:0] establishes A-input and B-input rise/edge sensitivity:
    
    %00 = A-input rise to B-input rise
    %01 = A-input rise to B-input edge
    %10 = A-input edge to B-input rise
    %11 = A-input edge to B-input edge
    
    Note: The B-input can be set to the same pin as the A-input for single-pin cycle measurement.
    
    Counting 20 periods would give a 1us capture rate, 40 is 2us etc, 100 is 5us, so X can set the jitter sample window.

    Choose whatever rate P2 can read and dump, and then slow from there for more precision ?

    With a nominal skew of 3 sysclocks per sample, that will accumulate to 300 in us. If the variations are random, that starts to resolve toward picosecond numbers (50ps).

    Addit: I think using the Threshold DAC should work at 20MHz, and that applied to the XO coupled Pin, would allow some phase-shift on the XO Sine signal.
    Above 160MHz Sysclk, at least 2 Sysclks will appear in a 45' phase shift window.


    Two smart pins could operate in Time interval mode, one doing Xtal _/= and one doing Xtal =\_, sampled from the higher SysCLK.
    DOCs are sparse on the Threshold mode, but maybe that cannot apply at the same time as Time Interval A-B.
    In that case, maybe Pin-In -> Pin-Out mode could be selected, ans than that hop pin applies Time INterval A-B ?
  • Jitter Free P2 invaders for ES Board attached.
    Feel the need for speed between your PC's com port and Prop?
    Try the FTDI 245 and the FullDuplexParallel Object.

    Check out my spin driver for the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087
  • jmgjmg Posts: 12,884
    ke4pjw wrote: »
    Jitter Free P2 invaders for ES Board attached.

    Did you try a forced heating/cooling run, to confirm that /2 then *25 has no visible temperature jitter zones ?

    Curious, at these lower VGA rates ( 25.175MHz 31.5MHz) has anyone tried fine adjust of the H-Sync signals when jitter does occur ?
    At the very high VGA settings, there is not much scope to move, but these lower rates have many sysclks per pixel, giving more 'eye' choices ?
    250M/31.5M = 7.936 SysCLK / pixel
    250M/25.175M = 9.9304 SysCLK/pixel
  • jmg wrote: »
    ke4pjw wrote: »
    Jitter Free P2 invaders for ES Board attached.

    Did you try a forced heating/cooling run, to confirm that /2 then *25 has no visible temperature jitter zones ?

    No not really. My P2 is pretty much close to ambient. I highly suspect the issue has everything to do with the VCO locking properly. VCO locking would be affected by extreme changes in temperature.

    I can take some readings with an IR thermometer and compare, if you think that would be beneficial.


    Feel the need for speed between your PC's com port and Prop?
    Try the FTDI 245 and the FullDuplexParallel Object.

    Check out my spin driver for the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087
  • jmgjmg Posts: 12,884
    ke4pjw wrote: »
    No not really. My P2 is pretty much close to ambient. I highly suspect the issue has everything to do with the VCO locking properly. VCO locking would be affected by extreme changes in temperature.

    I can take some readings with an IR thermometer and compare, if you think that would be beneficial.

    Tubular got some good external counter readings here, that nicely show the jitter zone effect as he externally heated the board.
    That external heating forces it to cross a range of test conditions.

    There is also raw data here https://forums.parallax.com/discussion/download/125029/DATA_wob2.zip which zooms out more
    The steps in that zoomed data are the counter LSB's and the slope is the crystal tempco variation, so the jitter has mostly averaged over the gate time, but just enough remains, to be quite visible.

    Indications of how much that behaviour varies across P2's and what seems to be a high-enough PFD to render it not noticeable will be useful.
  • Ke4pjw, what I'd suggest is first getting acquainted with what the wobbles (jitter, shivers, shimmers) look like by using
    DIV = 14 (instead of 2), and correspondingly MUL = 175 (x7, instead of 25) to still give 250 MHz.
    Then, use a heat lamp of some kind (incandescent lamp, old style floodlight, halogen worklight etc, but not led/cfl) to get it active
    I found temperatures around 45~53C was where things 'happened'

    I think operating at 250 MHz, temp rise might be of the order of 20 C above abient, so unless you're in a hot ambient room to start with you may not see it happening with self-heating. This is good - its basically an overclocking issue (but may start affecting users when they put P2's into enclosures too, so best to scout it out in advance)

    Using divs of 2 or 3 certainly are better

  • So here are my test results, using P2 Invaders as the subject.

    Ambient Room temp = 60F

    Jitter is visible in all cases.
    Div = 40
    Mult = 360
    Ambient P2 = 85.6F
    Heated test = 100.4 F (Rework iron set to 100F)
    Cold test = 46.4 F (Canned Air for many seconds)

    No noticeable jitter in all cases.
    Div = 2
    Mult = 25
    Ambient P2 = 94.7
    Cold test = 45.2 F (Canned Air for many seconds)
    Heat test = 110.7 F (Rework iron set to 100F)

    I see no visible difference based on external temperature. The jitter does seem to come and go in the configuration where it is visible, but I see not correlation to temperature.

    I can make a video, if you think this is a valid testing methodology.
    Feel the need for speed between your PC's com port and Prop?
    Try the FTDI 245 and the FullDuplexParallel Object.

    Check out my spin driver for the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087
Sign In or Register to comment.