Jump to content
IGNORED

Session 11: Colourful Colors


Recommended Posts

Even our language treats "color" differently - here in Oz we write "colour" and in the USA they write "color". Likewise, '2600 units in different countries don't quite speak the same language when it comes to colour.

 

We have already seen why there are 3 variants of '2600 units - these variations (PAL, NTSC, SECAM) exist because of the differences in TV standards in various countries. Specifically, the colour information is encoded in different ways into the analogue TV signal for each system, and the '2600 hardware is responsible for inserting that colour information in the data sent to the TV.

 

Not only do these different '2600 systems write the colour information in different ways, they also write totally different colours! What is one colour on a NTSC system is probably NOT the same colour on PAL, and almost certainly not the same colour on SECAM! Here's some wonderful colour charts from B. Watson to show the colours used by each of the systems...

 

http://www.urchlay.com/stelladoc/v2/tia_co...colorchart.html

 

 

Colours are represented on the '2600 by numbers. How else could it be? The colour to number correspondence is essentially an arbitrary association - so, for example on a NTSC machine the value $1A is yellowish, on PAL the same colour is grey, and on SECAM it is aqua (!). If the same colour values were used on a game converted between a NTSC and PAL system, then everything would look very weird indeed! To read the colour charts on the above URL, form a 2-digit hex number from the hue and the lum values (ie: hue 2, lum 5 -> $25 value -> brown(ish) on NTSC and as it happens a very similar brown(ish) on PAL.

 

We've already played with colours in our first kernel! In the picture section (the 192 scanlines) we had the following code...

 

 


      ; 192 scanlines of picture... 



       ldx #0 

       REPEAT 192; scanlines 



         inx 

         stx COLUBK 

         sta WSYNC 



       REPEND 

 

 

We should know by now what that "sta WSYNC" does - and now it's time to understand the rest of it. Remember the picture that the kernal shows? A very pretty rainbow effect, with colour stripes across the screen. It's the TIA producing those colours, but it's our kernal telling the TIA what colour to show on each line. And it's done with the "stx COLUBK" line.

 

Remember how the TIA maps to memory in locations 0 - $7F, and that WSYNC is a label representing the memory location of the TIA register (which happens, of course, to be called WSYNC). In similar fashion, COLUBK is a label which corresponds to the TIA register of the same name. This particular register allows us to set the colour of the background that the TIA sends to the TV!

 

A quick peek at the symbol table shows...

 


COLUBK          0009       (R ) 

 

In fact, the very best place to look is in the Stella Programmer's guide - for here you will be able to see the exact location and usage of this TIA register. This is a pretty simple one, though - all we do is write a number representing the colour we want (selected from the colour charts linked to, above) and the TIA will display this colour as the background.

 

Don't forget that it also depends on what system we're running on! If we're doing a PAL kernel, then we will see a different colour than if we're doing a NTSC or SECAM kernel. The bizarre consequence of this is that if we change the number of scanlines our kernel generates, the COLOURS of everything also change. That's because (if we are running on an emulator or plug a ROM into a console) we are essentially switching between PAL/NTSC/SECAM systems, and as noted these systems send different colour information to the TV! It's weird, but the bottom line is that when you choose colours, you choose them for the particular TV standard you are writing your ROM to run on. If you change to a different TV system, then you will also need to rework all the colours of all the objects in your game.

 

Let's go back to our kernel and have a bit of a look at what it's doing to achieve that rainbow effect. There's remarkably little code in there for such a pretty effect.

 

As we've learned, the 6502 has just three "registers". These are named A, X and Y - and allow us to shift bytes to and from memory - and perform some simple modifications to these bytes. In particular, the X and Y registers are known as "index registers", and these have very little capability (they can be loaded, saved, incremented and decremented). The accumulator (A) is our workhorse register, and it is this register used to do just about all the grunt-work like addition, subtraction, and bit manipulation.

 

Our simple kernel, though, uses the X register to step a colour value from 0 (at the start), writing the colour value to the TIA background colour register (COLUBK), incrementing X by one each scanline. First (outside the repeat) we have "ldx #0". This instruction moves the numeric value 0 into the X register. ld is an abbreviation for "load", and we have lda, ldx, ldy. st is the similar abbreviation for store, and we have stx sty sta. Inside our repeat structure, we have "stx COLUBK". As noted, this will copy the current contents of the x register into the memory location 9 (which is, of course, the TIA register COLUBK). The TIA will then *immediately* use the value we wrote as the background colour sent to the TV. Next we have an instruction "inx". This increments the current value of the X register by one. Likewise, we have an "iny" instruction, which increments the y register. But, alas, we don't have an "ina" instruction to increment the accumulator (!). We are also able to decrement (by 1) the x and y registers with "dex" and "dey".

 

The operation of our kernel should be pretty obvious, now. The X register is initialised with 0, and every scanline it is written to the background colour register, and incremented. So the background colour shows, scanline by scanline, the colour range that the '2600 is capable of. In actual fact, you could throw another "inx" in there and see what happens. Or even change the "inx" to "dex" - what do you think will happen? As an aside, it was actually possible to blow up one early home computer by playing around with registers like this (I kid you not!) - but you can't possibly damage your '2600 (or emulator!) doing this. Have fun, experiment.

 

Since we're only doing 192 lines, the X register will increment from 0 to 192 by the time we get to the end of our block of code. But what if we'd put two "inx" lines in? We'd have incremented the X register by 192 x 2 = 384 times. What would its value be? 384? No - because the X register is only an 8-bit register, and you would need 9 bits to hold 384 (binary %110000000). When any register overflows - or is incremented or decremented past its maximum capability, it simply "wraps around". For example, if our register had %11111111 in it (255, the maximum 8-bit number) and it was incremented, then it would simply become %00000000 (which is the low 8-bits of %100000000). Likewise, decrementing from 0 would leave %11111111 in the register. This may seem a bit confusing right now, but when we get used to binary arithmetic, it will seem quite natural. Hang in there, I'll avoid throwing the need to know this sort of stuff at you for a while.

 

Now you've had a little introduction to the COLUBK register, I'd just like to touch briefly on the difference apparent between the WSYNC register and the COLUBK register. The former (WSYNC) was a strobe - you could simply "touch" it (by writing any value) and it would instantly halt the 6502. Didn't matter what value you wrote, the effect was the same. The latter register (COLUBK) was used to send an actual VALUE to the TIA (in this case, the value for the colour for the background) - and the value written was very much important. In fact, this value is stored internally by the TIA and it keeps using the value it has internally as the background colour until it changes.

 

If you think about the consequences of this, then, the TIA has at least one internal memory location which is in an uknown (at least by us) state when the machine first powers on. We'd probably see black - which happens to be value 0 on all machines), but you never know. I believe it is wise to initialise the TIA registers to known-states when your kernel first starts - so there are no surprises on weird machines or emulators. We have done nothing, so far, to initialise the TIA - or the 6502, for that matter - and I think we'll probably have a brief look at system startup code in a session real-soon-now.

 

Until then, have a play with the picture-drawing section, and see what happens when you write different values to the COLUBK register. You might even like to change it several times in succession and see what happens. Here's somtehing to try (with a bit of headscratching, you should be able to figure all this out by now)...

 


    





       ; 192 scanlines of picture... 



       ldx #0 

       ldy #0

       REPEAT 192; scanlines 



             inx 

             stx COLUBK 



             nop

             nop

             nop



             dey

             sty COLUBK



             sta WSYNC 



       REPEND 

 

 

 

Try inserting more "nop" lines (what does nop do, again?) - can you see how the timing of the 6502 and where you do changes to the TIA is reflected directly onscreen because of the synchronisation between the 6052 and the TIA which is drawing the lines on-the-fly?

 

Have a good play with this, because once you've cottoned-on to what's happening here, you will have no problems programming anything on the '2600.

 

See you next time!

  • Thanks 1
Link to comment
Share on other sites

Alright then :D  NOP = waste 1 cycle

1 6502 cycle = 3 TIA clocks

 

Is 160 cycles resolution the 6502 time or TIA time?

 

 

Almost. NOP = waste 2 cycles.

 

160 is the number of clocks of visible pixels. That's TIA clocks, one clock per pixel. But on each scanline there's 228 clocks. Divide by 3 to get the number of 6502 clocks per scanline = 76.

 

We covered this earlier, so time for a bit of revision I think :)

Link to comment
Share on other sites

 

Until then, have a play with the picture-drawing section, and see what happens when you write different  values to the COLUBK register.  You might even like to change it several times in succession and see  what happens.  Here's somtehing to try (with a bit of headscratching, you should be able to figure all  this out by now)...

 


    





       ; 192 scanlines of picture... 



       ldx #0 

       ldy #0

       REPEAT 192; scanlines 



             inx 

             stx COLUBK 



             nop

             nop

             nop



             dey

             sty COLUBK



             sta WSYNC 



       REPEND 

 

 

 

Try inserting more "nop" lines (what does nop do, again?) - can you see how the timing of the 6502 and  where you do changes to the TIA is reflected directly onscreen because of the synchronisation between  the 6052 and the TIA which is drawing the lines on-the-fly?

 

Have a good play with this, because once you've cottoned-on to what's happening here, you will have no  problems programming anything on the '2600.

 

See you next time!

 

 

The above may not have been so obvious, because ALL of the code inside our REPEAT... REPEND section is happening in the first 68 colour-clocks of the line, when the TV is doing its horizontal retrace. If you replace the code with the following (with more NOPs inserted) the effect I was trying to show will become WAY more apparent! The sample image shows what we're looking at.

 


              ; 192 scanlines of picture... 



               ldx #0 

               ldy #0 

               REPEAT 192; scanlines 



                   nop

                   nop

                   nop

                   nop

                   nop

                   nop

                   nop

                   nop

                   nop

                   nop

                    

                   inx 

                   stx COLUBK 



                   nop 

                   nop 

                   nop 



                   dey 

                   sty COLUBK 



                   sta WSYNC 



               REPEND 

 

 

One caution: as the above code is wrapped inside a repeat structure which creates 192 copies of the enclosed code, we're actually running short of ROM space! With the above code installed, there's only 10 bytes free in our entire ROM! Clearly, using REPEAT in this sort of situation is wasteful, and the code should be written as a loop. We covered looping for scanline draw early on - but because both X and Y registers are in use at the moment, it's a bit more tricky.

 

So for now, we'll just have to accept that we can't add any more code - but at least you can see what effect adding/removing cycles can have on the existing code.

 

 

The bold changes above were corrections made 27/6/2003 - AD

post-214-1054038377_thumb.png

kernel11.zip

Link to comment
Share on other sites

Hi there!

 

I just used the Sleep macro to kill some cycles :D

 

How many cycles does the "bit VSYNC" used in macro.h waste ?

 

Actually it's supposed to work just the other way round. You say

 

Sleep X

 

And then it wastes X cycles. No need to worry what the macro does...

 

But to still answer your question: 3 cycles. :)

 

Greetings,

Manuel

Link to comment
Share on other sites

I just used the Sleep macro to kill some cycles :D

 

How many cycles does the "bit VSYNC" used in macro.h waste ?

 

It uses 3. There are various ways of 'efficiently' wasting time (ie: the most cycles used for the least number of bytes of ROM spent doing it). We'll cover that in a later tutorial.

Link to comment
Share on other sites

just curious :D

 

 

.....'efficiently' wasting time? :lol:

 

 

If you *have* to waste time, then do it in as few bytes as possible. :)

 

The following contrived code snippets all waste the same amount of time - but the cost of the 2nd (in ROM bytes used) is double.

 


   jsr _rts   ; 12 cycles, 3 bytes

 


   nop

   nop 

   nop

   nop

   nop

   nop   ; 12 cycles, 6 bytes

 

We will see in later tutorials where, even if you DO have lots of ROM space, it is often necessary to keep code size to a minimum - because of constraints on how far the 6502 can "see" to get to other bits of code. We'll cover all of this in future sessions.

Link to comment
Share on other sites

  • 4 months later...

Hi

 

I got

segment:  fffa                    vs current org: 10063

test2.asm (142): error: Origin Reverse-indexed.

Aborting assembly

 

when trying a new code:

 

           processor 6502  

           include "vcs.h"  

           include "macro.h"  

 

           SEG  

           ORG $F000  

 

Reset  

StartOfFrame  

 

   ; Start of vertical blank processing  

 

           lda #0  

           sta VBLANK  

 

           lda #2  

           sta VSYNC  

           

               ; 3 scanlines of VSYNCH signal...  

 

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

 

           lda #0  

           sta VSYNC            

 

               ; 37 scanlines of vertical blank...  

 

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

           

 

 

; 192 scanlines of picture...  

 

               ldx #0  

               ldy #0  

               REPEAT 192 ; scanlines  

 

                   nop  

                   nop  

                   nop  

                   nop  

                   nop  

                   nop  

                   nop  

                   nop  

                   nop  

                   nop  

                     

                   inx  

                   stx COLUBK  

 

                   nop  

                   nop  

                   nop  

 

                   dey  

                   sty COLUBK  

 

                   sta WSYNC  

 

               REPEND  

 

           lda #%01000010  

           sta VBLANK                      ; end of screen - enter blanking  

 

               ; 30 scanlines of overscan...  

 

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

               sta WSYNC  

 

           jmp StartOfFrame  

 

 

           ORG $FFFA

 

           .word Reset           ; NMI  

           .word Reset           ; RESET  

           .word Reset           ; IRQ  

 

      END  

 

Another thing. Do I need how the C++ works when using DASM?

 

Serguei

Link to comment
Share on other sites

I used Andrew Davie's code with the code from lesson 8 to get the screenshot see above by myself.

 

Andrew's code:

; 192 scanlines of picture...  

 

               ldx #0  

               ldy #0  

               REPEAT 192 ; scanlines  

 

                   nop  

                   nop  

                   nop  

                   nop  

                   nop  

                   nop  

                   nop  

                   nop  

                   nop  

                   nop  

                     

                   inx  

                   stx COLUBK  

 

                   nop  

                   nop  

                   nop  

 

                   dey  

                   sty COLUBK  

 

                   sta WSYNC  

 

               REPEND  

 

So. How do I use a loop to make this thing to work?

 

 

Serguei

Link to comment
Share on other sites

  • 1 year later...

Hi, I'm not sure if any follows this thread anymore, but I figured I'd give it a shot. I'm using dasm V2.20.09 compiled for linux, and I have z26 (2.13) -- May 23, 2004 also compiled for linux. When I load kernel1.bin included in kernel1.zip from session 8 http://www.atariage.com/forums/viewtopic.php?t=27194

and it doesn't look like the screen shot included in that article. I get a solid green bar across the top and a solid black bar at the bottom. I made the changes outlined in session 11 above and still get these. I tried to fix it but I couldn't. Are these examples written for PAL or NTSC?

 

I'm including my modified source file as well as my screen shots.

;first kernel

           processor 6502

           include "vcs.h"

           include "macro.h"



           SEG

           ORG $F000



Reset

StartOfFrame



  ; Start of vertical blank processing



           lda #0

           sta VBLANK



           lda #2

           sta VSYNC

          

              ; 3 scanlines of VSYNCH signal...



               sta WSYNC

               sta WSYNC

               sta WSYNC



           lda #0

           sta VSYNC

           ldx #37

vblankloop

              ; 37 scanlines of vertical blank...

               sta WSYNC

               dex

               bne vblankloop

endvblankloop

               



           lda #2

           ldx #192

           ldy #0

drawpictureloop

              ; 192 scanlines of picture...

                   iny

                   sty COLUBK

                   sleep 20

                   stx COLUBK

                   sleep 10

                   sty COLUBK

                   sleep 10

                   sta WSYNC

                   dex

                   bne drawpictureloop

enddrawpictureloop



           lda #%01000010

           sta VBLANK                     ; end of screen - enter blanking



           ldx 30

overscanloop

              ; 30 scanlines of overscan...

               sta WSYNC

               dex

               bne overscanloop

ebdoverscanloop



           jmp StartOfFrame





           ORG $FFFA



           .word Reset          ; NMI

           .word Reset          ; RESET

           .word Reset          ; IRQ



      END



thanks!

 

Jim

post-6228-1105060329_thumb.jpg

post-6228-1105060330_thumb.jpg

Link to comment
Share on other sites

Hi there!

 

There's been numerous little flaws with the code, so first I fixed all of them (including the formatting...):

 

;first kernel 

   processor 6502 

   include "vcs.h" 

   include "macro.h" 



   SEG 

   ORG $F000 



Reset 

StartOfFrame 


; Start of vertical blank processing 



   VERTICAL_SYNC



   ldx #37    ; 37 scanlines of vertical blank... 

vblankloop 

   sta WSYNC 

   dex 

   bne vblankloop 



   ldx #192   ; 192 scanlines of picture...

   ldy #0 

   STY COLUBK

   STY VBLANK 



drawpictureloop 

   sta WSYNC 

   iny 

   sty COLUBK 

   sleep 20 

   stx COLUBK 

   sleep 10 

   sty COLUBK 

   sleep 10 

   dex 

   BNE drawpictureloop 



enddrawpictureloop 

   lda #%01000010 

   sta VBLANK                     ; end of screen - enter blanking 



   ldx 30     ; 30 scanlines of overscan... 

overscanloop 

   sta WSYNC 

   dex 

   bne overscanloop 



   jmp StartOfFrame 



   ORG $FFFA 



   .word Reset          ; NMI 

   .word Reset          ; RESET 

   .word Reset          ; IRQ 



   END

 

Well, the major points were

 

- you disabled VBLANK too early

 

It should be the last thing to do before your display code starts. It was already enabled before the VBLANK period was even started.

 

- VERTICAL_SYNC should happen before the VBLANK period

 

- Your drawing loop should start with a write to WSYNC, so all lines get the same timing.

 

- The last color your loop sets is 192, so you should set COLUBK to 0 again, before disabling VBLANK, or you'll get to see 192 again.

 

Greetings,

Manuel

Link to comment
Share on other sites

just curious :D

 

 

.....'efficiently' wasting time? :lol:

 

 

If you *have* to waste time, then do it in as few bytes as possible. :)

 

The following contrived code snippets all waste the same amount of time - but the cost of the 2nd (in ROM bytes used) is double.

 


   jsr _rts   ; 12 cycles, 3 bytes

 


   nop

   nop 

   nop

   nop

   nop

   nop   ; 12 cycles, 6 bytes

 

Actually, the cost of the first example would be half the amount of rom...but in addition to 2 bytes of ram (taken to store the return address...right?). At least it would be if the rest of the program has no need of JSR'ing or stack manipulation. With only 128 bytes of user ram, it could be an advantage doing it the long way instead.

 

Hackers take note: that's how you get water from an empty well in some cases ;)

Link to comment
Share on other sites

Hi there!

 

Actually, the cost of the first example would be half the amount of rom...

 

That's what Andrew said :)

 

You sound like you didn't understand it fully. Maybe this is better:

 

     JSR AnyROMLocationWithAnRTS
     ...
     ... Other Code
     ...
 
     SUBROUTINE BLA
     ...
     ... Other Code
     ...
AnyROMLocationWithAnRTS
     RTS
[code]
 
See? No RAM required at all. And it's only 3 bytes for "JSR abs", as an RTS is _somewhere_ in your code. Even if you're not using subroutines at all, there should be a byte containing $60 somewhere, maybe in the data 
 
Greetings,
Manuel

Link to comment
Share on other sites

Hi there!

 

Isn't the stack in ram? :ponder:

Seems that once I eliminated all subroutine JSR's and stack instructions like PHA from a program, the upper ram locations were no longer corrupted...leaving all 128 bytes $80-$FF free to be assigned as variables.

 

Uihjah! Didn't think someone would get so desperate to need those last two bytes as well.

 

Subroutines are such a nice thing to have. Though I usually avoid nesting them on the VCS :)

 

Greetings,

Manuel

Link to comment
Share on other sites

- you disabled VBLANK too early

 

It should be the last thing to do before your display code starts. It was already enabled before the VBLANK period was even started.

 

- VERTICAL_SYNC should happen before the VBLANK period

 

- Your drawing loop should start with a write to WSYNC, so all lines get the same timing.

 

- The last color your loop sets is 192, so you should set COLUBK to 0 again, before disabling VBLANK, or you'll get to see 192 again.

 

Greetings,

Manuel

 

Hi Manuel, thanks for the code review. :)

I noticed Andrew's example begins with vertical sync, but yours begins with vertical blank. I've seen other examples that begin with overscan. That's enough to confuse me. :? So my biggest misunderstanding at the moment is... how do I know where to begin? Do I control the tv or do I try to keep up with it? For instance, if I move #2 into VSYNC in the middle of drawing the playfield, does the electron beam return to the top of the screen? I just did a test and that's what it looks like is happening. And is it the same for VBLANK and RSYNC as well?

 

Jim

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...