Shop OBEX P1 Docs P2 Docs Learn Events
Been away...back into NTSC but it's killing me... — Parallax Forums

Been away...back into NTSC but it's killing me...

cbmeekscbmeeks Posts: 634
edited 2015-10-12 13:41 in Propeller 1
OK, being a little bit of a drama queen here. lol Oh, and my apologies on the long-winded post. I'll try to keep the future ones short-n-sweet (like me..lol).

I've been away from the whole world of "EE" for a while and managed to get back into it lately. Unfortunately, this happens for me from time to time.

Anyway, as you can expect, getting back into propeller, PLLA, VSCL, etc. after an absence can be a little overwhelming. So what I did was decide to write the simplest NTSC driver I could think of.
Or better yet, find the simplest one I know (NTSC Template) and modify it to do something a little different.

So what I did was take the NTSC Template by Eric Ball (http://obex.parallax.com/object/433) and modify it so that it was even more minimal. I removed the interlace part and I still have the NTSC color bars. In fact, it looks better on my TV without interlace. Seems to be no dot-crawl.

Here is the code I'm working from now (a watered down version of Eric's).

https://gist.github.com/cbmeeks/f66b8a9f096abd2ffc07

I have about 200 questions on "how" this works. I'm going to go back and read all my notes on how the PLLA, etc. works. But I thought I would focus on one small part at a time and, hopefully, if you guys have the time, help me understand how each section works.


Here goes....

1) In the active video section, the part that actually draws the color bars, can you help me understand "HOW" this works?
            movd        :loop, #colors      ' initialize pointer
            mov         count, #(17*6+2)/4  ' number of WAITVIDs
            mov         VSCL, vsclactv      ' PLLA per pixel, 4 pixels per frame
:loop
            waitvid     colors, #%%3210
            add         :loop, d1
            djnz        count, #:loop

....

d1                      long    1<<9

I get there are 26 WAITVIDS (which translates to 26 wide bars). But, what is that "add :loop, d1" doing?? 1<<9 is 512, right? It looks like it would be adding 512 to memory location of the WAITVID???
So ":loop" looks like a pointer that should hold the first "#colors" value. But, it's also a label? Sorry, this should be simple but it's not sinking in.



2) My other major question is how these values are determined. Just look at all of the "CONFIG DATA". I know that is a mixture of "short hand" in some places but take the example of the BACK PORCH calculation:
            mov         VSCL, vsclbp        ' backporch 9.2us OH to active video
            waitvid     sync, blank

....

vsclbp                  long    1<<12+(527-304-16*9)+213' NTSC back porch + overscan (213)


How in the world does that calculation translate to 9.2us? I just wonder if I knew how the numbers "12, 527, 304,.." were determined, it would make more sense.


I have so many more. Thanks again for any information you can provide. Oh, and a big thanks to Eric Ball for doing this in the first place. I'm just trying to understand it. ;-)

**EDIT**

BTW, I'm familiar with self-modifying code (especially on the 6502), so I *think* that might be what's happening on the main loop above. Especially since MOVD is used?? Is it overwriting the "colors" destination? Anyway....

Comments

  • kwinnkwinn Posts: 8,697
    But, what is that "add :loop, d1" doing?? 1<<9 is 512, right? It looks like it would be adding 512 to memory location of the WAITVID???

    It is incrementing the destination address of the waitvid instruction by 1 each time through the loop. The “movd :loop, #colors” line at the top of your snippet sets the initial destination address. An example of self modifying code.
  • cbmeekscbmeeks Posts: 634
    How is it by 1 if d1 = 1<<9 (512)?
    Thanks
  • jac_goudsmitjac_goudsmit Posts: 418
    cbmeeks wrote: »
    How is it by 1 if d1 = 1<<9 (512)?
    Thanks

    The destination field starts at bit 9 in the instruction word. So if you add 1 << 9, you add one to the destination. Obviously you have to be careful not to overflow but there's no danger of that, in this case.

    This kind of self-modifying code is very common on the Propeller, not just in video handling.

    ===Jac
  • potatoheadpotatohead Posts: 10,261
    I can do a longer write up, if you need it later.

    For now, look at the top of the program where PLLA is set. That frequency is a multiple of the ntsc colorburst, and all other values are derived from that one and are typically expressed in terms of PLLA cycles.

    There are some exceptions, like number of lines, etc...

    To replicate the numbers, calculate the time for one PLLA cycle. Then it's just simple math to derive any of the other numbers.

    The reason it is done this way is the pixels provide the signal, and the waitvid is based off PLLA.

    VSCL is set to an appropriate frame length, and is in multiples of PLLA. With VSCL set to 1, each pixel takes 1 PLLA. This is too fast, so it's often higher values. 8 PLLA means each pixel in the WAITVID will be 8 cycles of PLLA, and to know how long that is, you look at the frequency PLLA is running at.

    You should be able to repeat any calcs from there. If not, ask!
Sign In or Register to comment.