[POC] most useless piece of code ever, The

kuroneko

A while back I figured out a way to generate samples at a rate of one system clock/sample. Problem is that you can't really control the sequence other than hard-wire it into the loop (no time for hub access). OK, take a step back and look at two and four clocks/sample (@80MHz that's 40MB/s and 20MB/s respectively). Turns out this is doable provided you can generate enough data. To demonstrate this I created two video drivers using 800x600 VGA timing (40MHz pixel clock). They are of not much use except for showing the generated data stream. Resolution is 800x600 for the 40MB/s stream and 400x600 for the 20MB/s stream.

Right now both drivers show a repeating sequence of 8 differently coloured pixels. Have fun!

Errata for waitvid.div2.reader.2048.spin:

' Next WHOP hits during first cycle after ADD so we can update vscl without re-sync. [COLOR="blue"]Note that this[/COLOR]
' [COLOR="blue"]results in a 4 cycle waitvid but as long as vscl is resampled we're OK. Longer values would pose[/COLOR]
' [COLOR="blue"]a problem as the frame adjustment is then added more than once. In our case we could get away with[/COLOR]
' [COLOR="blue"]just the ADD and the SUB insn. Important bit is that reload happens exactly once *between* stretch[/COLOR]
' [COLOR="blue"]and restore.[/COLOR]

AntoineDoinel

kuroneko wrote: »

A while back I figured out a way to generate samples at a rate of one system clock/sample. Problem is that you can't really control the sequence other than hard-wire it into the loop (no time for hub access). OK, take a step back and look at two and four clocks/sample (@80MHz that's 40MB/s and 20MB/s respectively). Turns out this is doable provided you can generate enough data. To demonstrate this I created two video drivers using 800x600 VGA timing (40MHz pixel clock). They are of not much use except for showing the generated data stream. Resolution is 800x600 for the 40MB/s stream and 400x600 for the 20MB/s stream.

Right now both drivers show a repeating sequence of 8 differently coloured pixels. Have fun!

hmmm... not pretending to fully understand your code ("WHOP!" is more like what's crossing my mind when I read it ) but... consider the 400x600 example, which is 2 COGs.
If used as 400x300 double scanned (leading to more relaxed timing for input bandwidth?), and coupled this with your "DMA" code for HX512 card (5 COGs IIRC), still one COG left for talking with an external controlling entity (another prop or PC).

Q.E.D. thread title is wrong LOL

kuroneko

AntoineDoinel wrote: »

hmmm... not pretending to fully understand your code ("WHOP!" is more like what's crossing my mind when I read it ) but... consider the 400x600 example, which is 2 COGs.

WHOP stands for Waitvid Hand-Off Point.

AntoineDoinel wrote: »

If used as 400x300 double scanned (leading to more relaxed timing for input bandwidth?), and coupled this with your "DMA" code for HX512 card (5 COGs IIRC), still one COG left for talking with an external controlling entity (another prop or PC).

Yes, 800x600 is insane bandwidth-wise (I'm actually generating 80MB/s and throw away half of it). A 400x300 solution is what I intended to look at later.

AntoineDoinel

I'm mostly interested in higher res at lower depth, and with 1bpp or 2bpp probably other streaming SRAM solutions (such as Rayman's RamPage) could be used too... yet being "useful" when they're beyond the propeller internal RAM limitations.

Two questions:
- does the technique scale with clock (i.e. 640x480 at 100Mhz)?
- does the waitvid->cmp thing apply with 1bpp and 2bpp video shifter modes as well?

Rayman

kuroneko, what do you get for a vertical refresh rate?

I've had trouble getting sync with the Parallax 800x600 examples...

kuroneko

Rayman wrote: »

... what do you get for a vertical refresh rate?

The official timing states 60Hz with 40MHz pixel clock. My monitor shows 60.3Hz so I guess that qualifies. I noticed that the Parallax Hires text driver uses 50MHz pixel clock but the 40MHz timing (front/sync/back). Maybe that's the issue here (try adjusting one or the other). It works for me though (LCD 1280x1024 native).

kuroneko

AntoineDoinel wrote: »

- does the technique scale with clock (i.e. 640x480 at 100Mhz)?

I haven't tried that resolution (wasn't the primary focus). One important prerequisite here is that the system clock is a power-of-two multiple of the PLL clock. Otherwise the WHOP starts drifting^A and then you're better off with waitvid. So if you can get away with 25MHz pixel clock you should be OK. Another issue is the WHOP position relative to the hub window, i.e. if your timing is tight and said position becomes important then you don't have many choices.

My closest crystal makes for 104MHz. I suggest you grab a known working 640x480 driver, adjust the pixel clock to 25MHz and see if the monitor can take it (it's only 0.7% off, not sure what the mandated tolerance is).

AntoineDoinel wrote: »

- does the waitvid->cmp thing apply with 1bpp and 2bpp video shifter modes as well?

Don't see a problem with that. It's more about clock timing than bit depth, i.e. if you - as a programmer - can predict where a waitvid would be unblocked then this technique can be used.


^A Admittedly there may be other (working) ratios, i.e. non-power-of-two. But I'd argue that keeping track of the NCO (phsa) history & Co just to get the right spot is stretching it a bit

kuroneko

kuroneko wrote: »

A while back I figured out a way to generate samples at a rate of one system clock/sample. Problem is that you can't really control the sequence other than hard-wire it into the loop (no time for hub access).

For your viewing pleasure, a 1 clock/sample fragment which can be controlled through hub memory (a full wave would need 4 interleaved cogs, cogid 2n[+1]). The WHOP is placed at 4n+3, f_PLL = clkfreq.

rdlong  colours, par
ones    colours, #%%3210
jmpret  colours, #$-2 nr

• colours starts as 0, so rdlong latches a zero palette (active for 2 waitvid periods)
• ones latches the real palette:%%3210 and clears colours
• jmpret latches a zero palette again and closes the loop

If one feels uncomfortable with undocumented instructions this will do as well:

rdlong  colours, addr      ' colour index (addr[7..0]) must not contain %%0
and     colours, #%%3210   ' clear palette entries 3, 2 and 1
jmpret  zero, #$-2 nr