A question for Chip about the video LUT

Baggers

Hi Chip,

My question is this...

If when using the video output locks the cog, and it only has a 256 long LUT, does that mean we won't be able to re-fill the LUT for a second span of 256 individual colours, for if we wanted to do a 640x480 true colour display or even a 320x240?

Or have I misread how it works? Yeah ok, that's two questions lol

Cheers,
Jim.

jmg

Chip wrote the below as the latest Streaming opcodes
- the HUB2LUT would seem to be the fastest way to update a LUT

cgracey wrote: »

Here are the streaming instructions, not including video:

RDINIT	D/#19bit	- reset read FIFO and begin reloading from address D[16:0] with byte offset D[18:17]
RDLONG	D		- read next long from read-FIFO
RDWORD	D		- read next word from read-FIFO
RDBYTE	D		- read next byte from read-FIFO
HUB2REG	D/#,S/#		- read S[8:0]+1 longs from read-FIFO starting at reg D[8:0]
HUB2LUT	D/#,S/#		- read S[7:0]+1 longs from read-FIFO starting at LUT D[7:0]

WRINIT	D/#19bit	- wait until write-FIFO written and then reset to address D[16:0] with byte offset D[18:17]
WRLONG	D/#		- write long to write-FIFO, optional filter mode doesn't write bytes when they are $FF
WRWORD	D/#		- write word to write-FIFO, optional filter mode doesn't write bytes when they are $FF
WRBYTE	D/#		- write byte to write-FIFO, optional filter mode doesn't write bytes when they are $FF
REG2HUB	D/#,S/#		- write S[8:0]+1 longs to write-FIFO starting from reg D[8:0]
LUT2HUB	D/#,S/#		- write S[7:0]+1 longs to write-FIFO starting from LUT D[7:0]

Baggers

Thanks jmg, I did see that, but wasn't sure that was for a single setting of it, as it I thought I read that the video out locked the cog up?

So in that case, I guess the video out doesn't lock up the cog anymore then?

jmg

Baggers wrote: »

Thanks jmg, I did see that, but wasn't sure that was for a single setting of it, as it I thought I read that the video out locked the cog up?

So in that case, I guess the video out doesn't lock up the cog anymore then?

Video out is usually burst triggered, so you have all the blanking time to do COG stuff & your LUT update
At 200MHz fSys, a bock refresh of LUT will be ~1.28us, which can fit in most blanking

Video out at fSys/1, will claim all possible slots, while it is running, and need 100% LUT access, so COGs during fSys/1 display cannot do much at all.

At lower speeds tho, say fSys/3 and below, there are spare slots between the DMA + LUT times, that a COG could use for HUB access, at a more modest speed. (no bursts, and likely > 16 for a slot-match)
I would expect most designs to use blanking time updates to LUT.

JRetSapDoog

Baggers wrote: »

So in that case, I guess the video out doesn't lock up the cog anymore then?

That's right, as Chip mentioned that a motivation for the separate LUT's was to avoid locking up the cogs (such that they could, for example, operate on the LUT's.

If changing color sets between scan lines, there would be 256 unique colors per line available, where as one might have, for example, 320 or 640 or 800 pixels/line.

Although it falls short of "true color," it might be hard to tell the difference. And if taking advantage of that for an image, one would likely have to interleave the color set data after each scan line of pixel data. I guess that's doable, but it seems likely that switching color set between scan lines will be used more for getting more colors on the screen for text and graphics when one wants to save memory. For example, even at only 2 bits/pixel, a title at the top of the screen could be in one color, the body or graphics in another, and something at the bottom in a third color (of course, the background colors could be different, too, if desired). Anyway, all that is obvious.

cgracey

There will be a video output mode which just takes longs from the hub and outputs them directly to the DACs.

Bill Henning

I like that.

cgracey wrote: »

There will be a video output mode which just takes longs from the hub and outputs them directly to the DACs.

Baggers

cgracey wrote: »

There will be a video output mode which just takes longs from the hub and outputs them directly to the DACs.

Why did I ever doubt it? especially with it being you Chip!

Cheers,
Jim.

JRetSapDoog

cgracey wrote: »

There will be a video output mode which just takes longs from the hub and outputs them directly to the DACs.

Thanks, Chip. I started to type a post reply the other day asking if the LUT might be bypassed. But then I canceled it, as I wasn't even sure if the LUT's were a go.

If feeding DAC's directly from hub, there's of course not enough hub memory for true color for VGA (640x480), but there would be for QVGA (320x240).

potatohead

At 256 pixels, we get true color anyway. Pixels = LUT.

Since it appears a COG can do something while pixels are moving, we may well just sort the colors and update the lut per line, making true color possible and or more possible with limits as resolution goes up.

At significantly higher resolutions, a dither scheme, combined with potential updates can deliver very good results, as can image processing to do things like reduce the blue resolution of an image to cut down on color entries needed.

If we use two cogs, running 8 bit luma on one, with a fixed color difference palette in the other two channels could yield very good pictures without dynamic updates when component video is being used.

Finally, using three COGS will deliver full color anyway.

The DAC per COG limit means providing options on the PCB, perhaps jumpers to get the signals to the right place. No big deal IMHO.

Baggers

potatohead it's a 32bit LUT, so component won't need three cogs, or I assume not, as VGA will be able to be driven on one cog anyway won't it Chip? so, Component would be like VGA just going to RGB and sync will be on G anyway.

potatohead

Yes. One COG will drive all the stuff we do.

I was mostly thi king of true color alternatives and a trick or two I have in mind

Baggers

potatohead wrote: »

Yes. One COG will drive all the stuff we do.

I was mostly thi king of true color alternatives and a trick or two I have in mind

Oooooo, sounds ominous!

Tubular

You know, part of me likes the fact we'll still have a couple more video programming challenges with this new version of the chip, compared to the previous incarnation.

It can get a bit boring if everything is too easy to do. I've learned more about video systems since the FPGA images first appeared 18 months ago, compared with any other time

Baggers

It's always fun playing around with the video stuff