Jump to content

Photo

Session 11: Colourful Colors


34 replies to this topic

#1 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • 1,574 posts
  • Dr.Boo
  • Location:Tasmania

Posted Tue May 27, 2003 12:38 AM

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.c...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!

#2 Happy_Dude OFFLINE  

Happy_Dude

    River Patroller

  • 4,212 posts
  • Forum Slacker
  • Location:Sydney, Australia

Posted Tue May 27, 2003 1:31 AM

Alright then :D NOP = waste 1 cycle
1 6502 cycle = 3 TIA clocks

Is 160 cycles resolution the 6502 time or TIA time?

#3 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • Topic Starter
  • 1,574 posts
  • Dr.Boo
  • Location:Tasmania

Posted Tue May 27, 2003 3:31 AM

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 :)

#4 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • Topic Starter
  • 1,574 posts
  • Dr.Boo
  • Location:Tasmania

Posted Tue May 27, 2003 6:26 AM

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

Attached Thumbnails

  • kernel11.png

Attached Files



#5 Happy_Dude OFFLINE  

Happy_Dude

    River Patroller

  • 4,212 posts
  • Forum Slacker
  • Location:Sydney, Australia

Posted Tue May 27, 2003 7:56 AM

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

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

#6 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,585 posts
  • This is Sparta!
  • Location:Bavaria

Posted Tue May 27, 2003 8:09 AM

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

#7 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • Topic Starter
  • 1,574 posts
  • Dr.Boo
  • Location:Tasmania

Posted Tue May 27, 2003 8:10 AM

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.

#8 Happy_Dude OFFLINE  

Happy_Dude

    River Patroller

  • 4,212 posts
  • Forum Slacker
  • Location:Sydney, Australia

Posted Tue May 27, 2003 8:22 AM

just curious :D


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

#9 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

  • Topic Starter
  • 1,574 posts
  • Dr.Boo
  • Location:Tasmania

Posted Tue May 27, 2003 8:29 AM

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.

#10 NE146 OFFLINE  

NE146

    Dumbass Atari Fan

  • 13,297 posts
  • Location:Seattle, WA

Posted Tue May 27, 2003 6:42 PM

I gotta say.. you are a writing machine to do this every day. :o

Looking forward to the next one :D

#11 Contieri OFFLINE  

Contieri

    Space Invader

  • 16 posts
  • Location:São Paulo, Brazil

Posted Tue May 27, 2003 10:01 PM

Hi!

Anyone has this code commented?? I've messed up mine and I'd like to get a copy of it with the up to date lesson. Mine has got creepy since I've messed it a lot... :sad:

Cheers,


Ricardo

#12 Serguei2 ONLINE  

Serguei2

    Moonsweeper

  • 411 posts
  • Location:Canada

Posted Sun Oct 19, 2003 1:20 PM

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

#13 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,726 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Sun Oct 19, 2003 1:55 PM

Your code is too large to fit inside 4K.

Instead of repeating the same code over and over (192 * 21 bytes = 4032 bytes!) you should use a loop.

#14 Serguei2 ONLINE  

Serguei2

    Moonsweeper

  • 411 posts
  • Location:Canada

Posted Sun Oct 19, 2003 3:01 PM

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

#15 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash

  • 18,726 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany

Posted Sun Oct 19, 2003 3:59 PM

Do something like this:



  ldx #0 



  ldy #192; scanlines 



.loop:



  nop 



  ...







  inx 



  stx COLUBK 







  nop 



  ...







  dey 



  sty COLUBK 







  sta WSYNC



  bne .loop; loop until Y == 0


#16 xucaen OFFLINE  

xucaen

    Moonsweeper

  • 386 posts
  • Streaming Atari Jaguar/2600 twitch.tv/xucaen
  • Location:Massachusetts

Posted Thu Jan 6, 2005 7:12 PM

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....pic.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

Attached Thumbnails

  • kernel1.jpg
  • firstkernel.jpg


#17 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,585 posts
  • This is Sparta!
  • Location:Bavaria

Posted Fri Jan 7, 2005 5:13 AM

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

#18 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 20,974 posts
  • Location:The land of Gorch

Posted Sat Jan 8, 2005 1:30 AM

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 ;)

#19 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,585 posts
  • This is Sparta!
  • Location:Bavaria

Posted Sat Jan 8, 2005 3:07 AM

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:

[code=auto:0]
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[/code]

#20 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 20,974 posts
  • Location:The land of Gorch

Posted Sat Jan 8, 2005 3:50 AM

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.

#21 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,585 posts
  • This is Sparta!
  • Location:Bavaria

Posted Sat Jan 8, 2005 4:07 AM

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

#22 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

  • 8,585 posts
  • This is Sparta!
  • Location:Bavaria

Posted Sat Jan 8, 2005 4:12 AM

Hi there!

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


My SFX driver for Seawolf will start any of 11 sound effects any time just with

LDY #EFFECT
JSR DoSFX

for example :-)

Greetings,
Manuel

#23 xucaen OFFLINE  

xucaen

    Moonsweeper

  • 386 posts
  • Streaming Atari Jaguar/2600 twitch.tv/xucaen
  • Location:Massachusetts

Posted Sun Jan 9, 2005 12:01 AM

- 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

#24 xucaen OFFLINE  

xucaen

    Moonsweeper

  • 386 posts
  • Streaming Atari Jaguar/2600 twitch.tv/xucaen
  • Location:Massachusetts

Posted Sun Jan 9, 2005 12:21 AM

p.s. I don't see a vsync anywhere in your example.. yet it compiles and runs! just when I thought I was beginning to grasp things...
So, when is vsync not needed? :ponder:

jim

#25 xucaen OFFLINE  

xucaen

    Moonsweeper

  • 386 posts
  • Streaming Atari Jaguar/2600 twitch.tv/xucaen
  • Location:Massachusetts

Posted Sun Jan 9, 2005 12:27 AM

p.p.s. never mind. I found where you're setting vsync.. in macro.h.
:dunce:

jim




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users