Shop OBEX P1 Docs P2 Docs Learn Events
Will counters stay in sync at rollover? — Parallax Forums

Will counters stay in sync at rollover?

BasherBasher Posts: 25
edited 2013-09-21 11:34 in Propeller 1
I've got a cog generating VGA video at 312 scan lines per frame (for PAL video through a ad273)

I want a second cog to be able to tell which scan line the video cog is producing at any point.
My idea for doing this is to set up both counters of the second cog.

counter a would add one count every time the hsync pin goes low
counter b would add 312 to its count every time the vsync pin goes low

then I read both counters subtract b from a and be left with the scan line the video cog is presently on.

Frame 0 : counterA = 5 counterB = 0 result scanline = 5

Frame 1 : counterA = 317 counterB = 312 result scanline = 5

etc

I'd have to make sure the vsync doesn't change inbetween reading the two counters but other than that the result of a SUB counterA,counterB instruction should, as far as I can see, be the scan line that the video cog is presently on.

What I can't work out is what will happen when one or both of the counters fill up and rollover.

What I want and hope will happen is that the numbers will stay in sync and the sub instruction will continue to produce the scan line number.

But I've got a funny feeling that something odd might happen, either a tempory glitch or a new sequence will start.
Can anybody tell me if this will work and if not why not and possibly point me towards a better solution.
Thanks

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-09-19 14:42
    There's time during HSYNC for the VGA driver to update the value of a hub variable with the current scan line info. Why not do it that way?

    -Phil
  • BasherBasher Posts: 25
    edited 2013-09-19 15:35
    My project is a video add on for the old sinclair spectrum 8bit micro that reads the writes to video memory from the edge connector and then recreates the display with some enhancments through an RGB scart connector. It's working well as it is with most games.

    There are some games and demos for the spectrum that count z80 machine cycles to workout where the scanline has reached to produce multicolour effects by changing a colour attribute byte just ahead of the scan. I'm trying to get my interface to respond more accuratly to these programs.

    If I can get the counter idea working the next step would be to increase the resolution even further to divide the scanlines up into the equivilent of the z80 t-states.
  • AribaAriba Posts: 2,690
    edited 2013-09-19 16:34
    I don't see a problem with the rollover. The counters are 32 bits and the SUB instruction also calculates with 32 bits so the difference should always be the scanline also after rollover. If you use the POSEDGE or NEGEDGE mode to count the lines and frames, then it's important that you have clean H- and Vsync pulses with a fast edge, otherwise the counters can count more pulses because of overlaying noise.

    Can you use only the counters of the second cog? A software solution with PASM code seems easier and more reliable, if you use anyway a second cog.

    Andy
  • Mark_TMark_T Posts: 1,981
    edited 2013-09-21 08:55
    Ariba wrote: »
    If you use the POSEDGE or NEGEDGE mode to count the lines and frames, then it's important that you have clean H- and Vsync pulses with a fast edge, otherwise the counters can count more pulses because of overlaying noise.

    Perhaps putting those signals through a 74HC14 schmitt-trigger inverter might be a useful precaution....
    Can't really see 1980's hardware being able to generate a fast enough edge (besides doesn't there have to be
    a level-shifter anyway - if that has schmidt-trigger inputs all should be well).
  • Ahle2Ahle2 Posts: 1,179
    edited 2013-09-21 11:34
    I guess you have got some cogs left?!
    Why not throw in an AY-3-8910 in a cog for the full "spectrum 128" sound experience?

    /Johannes
Sign In or Register to comment.