Can someone please explain PixelClocks and FrameClocks and how they relate to VSCL?

cbmeeks

I think I get the basic idea. The VSCL is used to affect the timing of how the video generator streams the pixels and colors to the output pins.

And for things like blank lines, HSYNC, borders, etc. the timing is consistent.

The active display (the useful pixels the user actually sees) has the timing dynamically altered so that the resolution, sprites, etc can be utilized.

But I'm just not getting how all of this fits together. Especially how the manual talks about PLLA clocks, etc.

Is there a layman's explanation to these?

Thanks!

potatohead

Can you link to the driver you are using? I'll explain generally with the NTSC Template linked above. I can break out the lines of code, if you want. Just gotta get to another machine.

In general, the PLLA frequency is the fundemental unit of timing for the whole driver. It's either set to the colorburst frequency, or some multiple of it.

The colorburst, in the active display area, repeats X number of times. For NTSC, and a standard "safe area" display having an overscan border, that will be 160 cycles. For reference, many old computers synchronized their pixel clock to the color burst. This is what made artifact colors work, for example. On an old Atari computer, that colorburst cycle was referred to as a "color clock"

Pixels clocked out at the colorburst frequency, are longish, and there are 160 of them for a standard, safe area display, and they can be any color without any significant artifacts. This is because there is time to fully describe the color information for that pixel.

The TMS chip, Tandy color computer, and other 256 pixel computers made each pixel less than the color burst, which is overdriving composite video color somewhat. You can see the color artifacts in this TV screen shot: http://mit-a.com/Images/Actual/TI%2099-4A%20screen%20shot.jpg

Look at the "H" and other letters with vertical elements. The pixel is "thinner" and faster than the colorburst cycles are on the scan line.

VSCL works in PLLA cycles. There is the frame count, and the individual pixel count. An individual pixel is expressed in terms of PLLA, and the size of that pixel on the screen can be thought of in terms of how many PLLA / color burst. In Eric's NTSC template code, PLLA is 16 * color burst, meaning there are 16 PLLA cycles per "color clock" and to get one pixel per color clock, the pixel count would need to be 16 for VSCL, and to get 8 pixels per waitvid, the frame count is 128.

Multiply the number of waitvids, and their frame count, and you get PLLA / active video area.

For the NTSC Template I've linked above, that's 2560 PLLA / scan line.

When you adjust the pixels in the active display area, you gotta keep the number of PLLA cycles consistent, or your scan line won't be the right amount of time.

In the example I gave above, assuming standard NTSC borders, there are 160 pixels. If you wanted 320 pixels, you would set the VSCL for the waitvids in the active area to 8 for the pixel count and 64 for the frame count. This makes the pixels twice as fast, and they take up the same amount of time.

If you wanted 256 pixels, do a little math: 160 color clocks / line * 16 PLLA per pixel default = 160 pixels = 160*16 = 2560 PLLA for the active area.

You can do that computation for any working driver, not know a whole lot about the rest of the signal timings, and modify the pixel counts in the active area safely. Just count up the active waitvids, look at their frame timing, multiply, and that's how many PLLA you have to work with on that active area. And you can take the PLLA frequency, divide by color burst to understand how many PLLA you have per color clock, or colorburst cycle on that active area scanline.

So for 256 pixels, take the 2560 pixels in the active area being used right now, divide by 256, and that comes out to 10 PLLA per pixel, and for 8 pixels, a frame count of 80.

Now, more pixels = more waitvids! So you take the 2560 PLLA / 80 PLLA per waitvid, and you get 32 waitvids, and since each waitvid will have 8 pixels, because 80 PLLA total / 8 PLLA per pixel = 8.

Does that help?

Edit: And that number of PLLA per scanline impacts resolutions possible. Say you want something odd like 290 pixels.

You do that math

2560 PLLA per active line / 290 pixels = 8.827

This won't work. The fractional result will mean your scan line timing is off.

So, what to do?

You make up for it by changing the border size, to change PLLA / active area!

Take the whole value of the pixel division rounded up (9), multiply by number of pixels (290) and that is 2610 PLLA per active area. A bit wider active area. Or you could round down, and do the same, for a narrow one.

Subtract either and you get the number of PLLA you need to steal from or add to the border to make it all work. Divide that by 2, modify the border waitvids, and then you have the PLLA needed for your scan line to work properly.

cbmeeks

Wow. Once again, you amaze me with your attention to detail. You really should write a book on this subject.

Anyway, I haven't read your entire reply but I will read it (completely) a little later when I have some time. But the driver I am working off of is the one I found in the forums:

http://forums.parallax.com/showthread.php/138254-TEXAS-INSTRUMENTS-TMS9918-9928-VDP-Emulation-on-Propeller?p=1108224&viewfull=1#post1108224

I am documenting it now and I hope to expand on it (and hopefully get his permission to use it).

THANKS!

potatohead

Thanks. It's nice to read that. Maybe I will. There is this GitBook thing I've been stuffing some test docs into. It has limits, and I need to explore using images more, but it's kind of awesome. Lots of the hard, drudge work is taken right out of the task now.

As for the details, they simply have to be there, or the drivers don't work, or work poorly. One of the things I really liked about the Prop was the software video, getting to make the signals, etc... I did a lot of my early learning without a scope too. Thinking through the details is tough that way. Now I've got one, and many things are easier.

Just change one thing at a time as much as you can when modifying things. It's easiest to understand what happened that way. Also, check your finalized driver on a real TV. Capture cards will accept things real displays will not. Found that out the hard way a few times.

Way back in the day, I had ideas for displays and optimizations that more or less got to play out on the Prop. NTSC TV displays are very hackable, and quite tolerant, meaning one can exploit them in lots of ways. Cool stuff!

cbmeeks

I've had a chance to read through that. Yes, that's very helpful. I feel, however, that many of these numbers are a "chicken or egg" problem. For example, you must know one before you can calculate the other.

I know what you mean about the "color clocks". I remember that from reading the De Re Atari (AWESOME material). And, I've seen the 160 clocks many times in the past. Seems like that's about the best you can get where each pixel can be any color.

Now, thinking about the TMS. You have 256 pixels and any 8x1 area can be two colors (well, 8x8 for text but graphic mode 2 allows 8x1). Now, let's say I made a checkerboard pattern of two colors (black and light red). Wouldn't that mean 256 different color clocks per active scanline? How is that possible if the 160 color clocks is a "standard"?

Also, look at the mighty Commodore 64. :-) So, one mode it has is high-res where a scanline can also have two colors per 8x1 (high res). Now, the C64 can show 320 pixels in the active scanline and, if you remember, it had pretty wide margins on the sides. You couldn't put chars in the margins but there were tricks to put sprites in there and the sprites where high-res too. So, technically, you could have probably close to 400 pixels across in a checkerboard pattern.

I'm not sure how that could work (or if the prop could do that).

Anyway, I'm only concerned with the specs of the TMS9918 at the moment. So I can stick with 256x192.

Now, going back to the TMS and my checkerboard pattern. I could overlay four 1-pixel sprites in that same 8x1 area and have 6 different colors in that 8x1. I'd only be able to do that one time though. But still, that would be 6 color changes in a 6 pixel (fast) mode.

I'm mostly rambling at this point. But, I have a few questions.

potatohead wrote:

An individual pixel is expressed in terms of PLLA, and the size of that pixel on the screen can be thought of in terms of how many PLLA / color burst

OK, so assuming one PLLA/color burst would mean a pretty fat pixel? Would that be the "default" of 160 pixels?

potatohead wrote:

In Eric's NTSC template code, PLLA is 16 * color burst, meaning there are 16 PLLA cycles per "color clock" and to get one pixel per color clock, the pixel count would need to be 16 for VSCL, and to get 8 pixels per waitvid, the frame count is 128.

But what does it mean to have "16 PLLA cycles per color clock"? More PLLA/color clock means more the prop can do per pixel, right? How does that relate to system clocks? So if the prop takes 4 cycles to do anything, how will I know how much I can do per pixel/color clock?

I get how the frame count should be the PLLA * pixel count (8 * 16 = 128). But how did you get "8 pixels per waitvid" from 16 PLLA cycles per color clock?


Sorry for the obscure questions. I'm getting to the point where some of this is sinking in a little but I'm trying to apply it to real world scenarios.

Thanks again for your help. And, is there a link to your GitHub stuff? I'd be happy to check that out and buy your first propeller/video book. :-)

cbmeeks

Wait, I think I get it a little....I found this post where you also did a great job explaining.

http://forums.parallax.com/showthread.php/119301-Video-squashed-sprite?p=874874&viewfull=1#post874874

OK, so assuming we have 256 pixels and we have 32 pixels in a long, that means we have 256/32 = 8 waitvids for the active area.

My graphics loop (that will fetch pixels) will need to execute 8 times for the active area.

So now to calculate VSCL. We have 2560 PLLA per scanline. 2560 / 256 pixels = 10 PLLA per pixel. This "10 PLLA per pixel" is called the color clock.

We now have 10 * 32 = 320 PLLA per WAITVID. 320 PLLA / WAITVID * 8 WAITVIDS = 2560. Bam. It all matches.

Using those numbers, what is my pixel clock and what is my frame clock? Or, to cheat, what would the VSCL actually be?

Sinking in a little more....lol

potatohead

Nothing good in Git Book yet. I got a lot of help from others on this stuff. Same things you are asking.

I'll supply some detail later, but the short answer to cycles per pixel is to convert every thing to seconds.

1/80Mhz equals 0.0000000125. That is a cycle on the 80 Mhz Prop. Instructions take 4 of those, and for now, assume a waitvid takes 6

Do the same for your color burst 1/3.57Mhz Is 0.0000002801

I'm on mobile, so that isn't quite right, but you get the idea.

For a PLLA that is 16 x colorburst, 1/57.12mhz.0.0000000175

Now multiply to get PLLA per pixel in seconds, and multiply again for the pixels per frame.

Think in terms of instructions per waitvid. At high pixel counts, you only have a couple of instructions or maybe a few per waitvid.

This is why we use scanning buffers. The signal COG has te to grab data, stiff it into waitvid and not much else. Another COG preps data before the display gets there.

potatohead

You got it while I was writing!

The VSCL has the frame and pixel numbers packed into one long. Look at the dataset or Prop manual.

You shift one of the values left, add the other one and write that into VSCL.

cbmeeks

potatohead wrote: »

You got it while I was writing!

The VSCL has the frame and pixel numbers packed into one long. Look at the dataset or Prop manual.

You shift one of the values left, add the other one and write that into VSCL.

Yes, sorry. LOL

I even was thinking that you were probably replying with a long, detailed answer just as the light came on in my head. That other post you did really helped too.

The logic is starting to set in some. I am now looking at different drivers and starting to understand the why's. You have been very helpful.

There are still a few things that are confusing. Like why is the background color $02? So, the colors is a long that defines 4 colors (2 if 2 color). But, out of each 8bit, how is "red" defined? Etc.

I can save those for another thread. But thanks again.

cbmeeks

Also, going by an example I have, does this seem right?

https://gist.github.com/cbmeeks/8b8aaa2877f024943adc

39 pixel clocks and 628 frame clocks doesn't seem right.

ericball

For color the output of PLLA needs to be 16 times the colorburst frequency to give 16 different colors via phase shifting. (Note: the frequency controlled by FRQA may be different than PLLA in order to hit the lock-in of the PLL.) For NTSC the colorburst is 3,579,545 Hz thus PLLA is 57,272,727 Hz and there are 3,640 PLLA clocks per line.

The Propeller uses a 3 bit DAC for output. If 0 = sync @ -20 IRE and 7 = white @ 100 IRE, then black @ 0 IRE = 2.

Colors are relative to the phase of the colorburst portion of the horizontal sync. So depending upon what color value is used to create the colorburst sets what the other color values produce.

potatohead

In simple terms, some "colors" are sync levels. The Prop makes the whole signal out of colors and pixels. 00 an 01 are signal levels, 02 is black.

potatohead

cbmeeks wrote: »

Also, going by an example I have, does this seem right?

https://gist.github.com/cbmeeks/8b8aaa2877f024943adc

39 pixel clocks and 628 frame clocks doesn't seem right.

I don't think I quite understand this example... Hopefully the chatter got you there. If not, well. Post something up and we can take a look at it.

cbmeeks

Here is the entire TV OUT driver I am using.

It isn't mine, I'm just cleaning up the source code and learning from it. I do plan on extending it though. Once I get better at understanding it.

https://gist.github.com/cbmeeks/9b3303d128b6a8cf0174


AUTHOR: Francesco de Simone, www.digimorf.com