So, is this how WAITVID colors, pixels actually work?

cbmeeks

I'm not at my bench so I can't test this now. But I'm wondering if I just had an "ah ha" moment and wanted to ask while it was still fresh in my mind.

So assuming I'm using 16x2 colors (16 pixels with 2 bits each). Now, WAITVID is defined as:

INSTR   111111      (unique "id" of the waitvid command)
ZCRI    xxxx        (various flags)
CON     1111        (not sure what this is for)
DEST    ddddddddd   (9 bit destination.  The actual colors.)
SRC     sssssssss   (9 bit source.  The pixel pattern.

OK, so if I have a

waitvid colors, %%3210

That means we have '%%3210' which translates to 228 decimal and 0000_0000_1110_0100 in binary. Well, that is 16 bits but the SRC (pixels) is only 9 bits. So we truncate that to 9 bits and get 0_1110_0100. I'm not sure how 9 bits fits into this (other than giving 512 values and the COG memory has 512 words of memory...so maybe it's left over from that).

Anyway, we'll assume we ignore the MSB and end up with 1110_0100 for the pixels. Now, because we're in 4 color mode, and we want to allow any of the 4 colors to be used, we can divide that up like:

11_10_01_00

OK, that's starting to make sense. That is all 4 different values.

Now comes the colors. If I refer to this chart (http://www.rayslogic.com/propeller/Programming/TV_Colors.htm), I see for example that white is $07 and a nice red would be $38.

So now I need to describe how those 4 pixels look. For the first pixel (pixel %11), I still have 9 bits. Again, assuming we ignore the MSB and use bits 7:0.

Let's make that pixel red. $38 = %0011_1_000 = CCCC_M_LLL (C = Chroma, M = mode, L = Luma).
That color from the top line is some sort of "root" color. So the chroma and luma aren't really utilized. Anyway, it's red.

Now using this example:

waitvid $38, %%3210

Would draw RUUU. Where R=RED and U = "Unknown". 4 pixels with the first being RED and the other three undefined.

Of course you can't have three undefined colors so what is really happening is that it's streaming the values out like:

waitvid $38_$07_$38_$07, %%3210    ' RWRW_RWRW_RWRW_RWRW

Because we're in 16 color mode, 16 pixels will be rendered like above.

That's a little wasteful because we've defined only two colors when we're allowed four. But this is just for demonstration.

Now let's say I wanted to show the following pattern:

RRRR_RRRR_RRRR_RRRR then the following would work:

waitvid $38_$38_$38_$38, #255    ' %0_1111_1111 = 11_11_11_11 x 4

I hope I'm not totally off on all of this. Which I very well could be. :-)

This is how Eric Ball's NTSC Template is setup and uses 104 "colors" and 104 pixels across. 26 waitvids * 4 pixels each.

I haven't tackled 32x2 yet. That's next.

Wow...sorry about this long rant!

potatohead

Waitvid used like that simply turns colors into pixels. It is backward from ordinary use.

In 4 color mode, you get the 4 colors, and any number of two bit pixels, right? 32 bits of pixel data yields 16 pixels that can be any of the 4 colors in the colors operand.

Now, imagine a shorter 4 pixel waitvid. Still 2 bits per pixel, still 4 colors too.

What is different ? 4 pixels and 4 colors means any pixel any color, unlike the longer waitvid case.

So what we do is always output the same 4 pixels, in reverse order to avoid having to do that manually, and just specify new colors so any pixel is any color.

cbmeeks

Hmm. I'm re-reading my long post and wondering if I really just confused myself.

OK, so, let's take a step backwards.

What if I wanted to do something really simple like a 256 pixel resolution with only two colors. Foreground or background.

So 32 pixels per waitvid means 256/32 = 8 waitvids per line. PLLA per pixel would be 2560 / 256 = 10 PLLA per pixel. The waitvid frame would be 10X32 = 320 PLLA per waidvid. 320 x 8 = 2560.

Then what would waitvid be?

waitvid colors, %10101010_10101010_10101010_10101010
waitvid colors, %10101010_10101010_10101010_10101010
waitvid colors, %10101010_10101010_10101010_10101010
waitvid colors, %10101010_10101010_10101010_10101010
waitvid colors, %10101010_10101010_10101010_10101010
waitvid colors, %10101010_10101010_10101010_10101010
waitvid colors, %10101010_10101010_10101010_10101010
waitvid colors, %10101010_10101010_10101010_10101010

...

colors long %?????

Would that be one scanline ignoring border?

How would colors be defined if I wanted something like black/red pixels?

Thanks

potatohead

There are two use cases.

Waitvid colors, pixels is case one.

In this case, you put your two colors into the colors long. And if those are the only two for the whole screen, you are done. Each byte of the colors long provides 8 bits of colors data. Byte 0 is color 0 or background. Byte 1 is color 1 or foreground.

Then you specify number of pixels, frame, etc with VCFG and VSCL. I can give details letter tonight. But the frame bits in VSCL determine the number of pixels and the pixel clock. If you make your pixels something like 8 PLLA, then your frame needs to be 8 times the number of pixels you want waitvid to handle, up to 32 bits of pixel data.

Now you are set.

Write your pixel loop, fetch values from hub and put them into the pixels long of waitvid.

Case two is the any pixel any color case, and it only does 8 bits per pixel. The reason is only 4 pixels per waitvid are ever output. Because waitvid can take 4 color definition, you get any pixel any color.

So you write your loop, and fetch values from the hub and put them in the colors long. Colors become pixels. Like case 1, you supply the pixel data for the whole screen and do not need any more, just like you don't need anymore color data for a whole screen in case 1.

Smile, there is a third use case.

You write your loop to fetch both pixel and color data, resulting in tiles with sets of colors. Graphics_demo.spin does this.

potatohead

I need t look at your template to answer which values are which colors. This depends on how the signal gets made.

cbmeeks

Thanks. You've been a big help as always.

I didn't get a chance to do anything last night but hopefully tonight will be different.

What I want to do is create a basic driver that is similar to the ULA in the ZX Spectrum.

My original goal was to do one like the TMS9918 but with the multiple graphic modes, sprites, etc. it was a little too difficult for my first Prop driver.

The ULA is much simpler.

256x192 resolution. 16 colors. No sprites.
Each 8x8 block can have two colors max.
Flash mode (8x8 block alternates between foreground and background).
Reverse (swaps 8x8 block colors).

I think this is about as easy as you can get while having a driver that is actually useful. In fact, I wonder if that could be squeezed into one cog?

Also, I'm surprised no one has created a little spreadsheet or something that would allow you to input certain values and have all of the calculations generated for you.

If I understood the whole process a lot more I would create one.

potatohead

Speccy is a good target. You can use a waitvid with an 8 pixel frame, and supply colors and pixels for that frame. Nice fit for Propeller. Have fun!