VSCL register question

Agent420

I'm having some trouble understanding the VSCL register and determining timing on the driver mentioned above.· Below is some of the code in question·(obtained from the driver in this thread)·...· From the Prop manual, it mentions the VSLC register as defining the pixel clocks in bits 19..12 and the frame clocks in bits 11..0, but the code below seems to simply use the VSCL to load the number of pixels to output?· Is the VSCL register really just the pixel count?

Also, for the application at hand, the driver is set for a 65Mhz pixel clock with 1 clock per pixel.· It then writes 3 blank lines to buy some processing time, which totals to 3872 pixels.

Would a good way to calculate the available time be to use the pixel clock / system clock ratio?· So I get 80/65 instruction clocks for every pixel written, = ~1.2307 * 3872 = ~4765 system clock cycle window to perform my processing?

CON
' 1024 x 768 @ 60Hz settings
  hp = 1024                     'horizontal pixels
  vp = 768                      'vertical pixels
  hf = 24                       'horizontal front porch pixels
  hs = 136                      'horizontal sync pixels
  hb = 160                      'horizontal back porch pixels
  vf = 3                        'vertical front porch lines
  vs = 6                        'vertical sync lines
  vb = 29                       'vertical back porch lines
  pr = 65                       'pixel rate in MHz at 80MHz system clock (5MHz granularity)
  ht = hp + hf + hs + hb        'total scan line pixels
 
vscl_three_lines_mhb    long    ht * 3 - hb  'total pixels per three scan lines minus hb
 
movi    frqa,#(pr / 5) << 2     'set pixel rate (VCO runs at 2x)
 
'Do three lines minus horizontal back porch pixels to buy a big block of time
                        mov     vscl,vscl_three_lines_mhb
                        waitvid ccolor,#0

edit -

I note that the 3872 value written to the VSCL in the example above works out to 111100100000 in binary, which is 12 bits in size and so equates to the 11..0 frame clock parameter, making the pixel clock parameter 0.· So, is using the frame clock parameter the method of setting the pixel count to output?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Post Edited (Agent420) : 8/31/2009 1:24:49 PM GMT

ericball

VSCL is really two entities - a COG accessible register, and a pair of PLLA driven counters. And the pixel data is also two entities - a latch loaded by WAITVID and a shifter. When the frame counter rolls over it triggers a load of the VSCL counters from the VSCL register, a load of the pixel data shifter from the latch, and releases the COG if it's halted on WAITVID.

So the frame part of VSCL defines the number of PLLA clocks before the next reload sequence.· Frame clocks / pixel clocks gives the number of pixels. So if the PLLA frequency is the pixel frequency then the pixel clocks will be 1 and the frame clocks is the number of pixels.

Correct, # of system clocks per WAITVID interval is frame clocks * PLLA frequency / CLKFRQ (rounded down).· However, while the manual says WAITVID takes 5 clock cycles, in my testing I've found it needs 7 clock cycles.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

Agent420

Thanks for the clarification

I must say that some of this video programming takes me back my earliest 6502 days on the Vic20/C64...· There were quite a few tricks you could do in manipulating the video signal on a line by line basis.· I understand that even the lowly Atari 2600 did much of it's video by working on the video lines being drawn, as it had very limited ram and no frame buffer.· In many ways, what I'm trying to do with the Prop is similar, only magnified by the increased frequency that higher resolution vga displays work on.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔