Jump to content

Photo

Session 12: Initialisation


75 replies to this topic

#1 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

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

Posted Tue May 27, 2003 10:33 PM

One of the joys of writing '2600 programs involves the quest for efficiency - both in processing time used, and in ROM space required for the code. Every now and then, modern-day '2600 programmers will become obsessed with some fairly trivial task and try to see how efficient they can make it.

If you were about to go up on the Space Shuttle, you wouldn't expect them to just put in the key, turn it on, and take off. You'd like the very first thing they do is to make sure that all those switches are set to their correct positions. When our Atari 2600 (which, I might point out in a tenuous link to the previous sentence, is of the same vintage as the Space Shuttle) powers-up, we should assume that the 6502, RAM and TIA (and other systems) are in a fairly uknown state. It is considered good practise to initialise these systems. Unless you really, *really* know what you're doing, it can save you problems later on.

At the end of this session I'll present a highly optimised (and best of all, totally obscure icon_smile.gif piece of code which manages to initialise the 6502, all of RAM *and* the TIA using just 9 bytes of code-size. That's quite amazing, really. But first, we're going to do it the 'long' way, and learn a little bit more about the 6502 while we're doing it.


We've already been introduced to the three registers of the 6502 - A, X, and Y. X and Y are known as index registers (we'll see why, very soon) and A is our accumulator - the register used to do most of the calculations (addition, subtraction, etc).

Let's have a look at the process of clearing (writing 0 to) all of our RAM. Our earlier discussions of the memory architecture of the 6502 showed that the '2600 has just 128 bytes ($80 bytes) of RAM, starting at address $80. So, our RAM occupies memory from $80 - $FF inclusive. Since we know how to write to memory (remember the "stx COLUBK" we used to write a colour to the TIA background colour register), it should be apparent that we could do this...

   lda #0            ; load the value 0 into the accumulator

   sta $80           ; store accumulator to location $80

   sta $81           ; store accumulator to location $81

   sta $82           ; store accumulator to location $82

   sta $83           ; store accumulator to location $83

   sta $84           ; store accumulator to location $84

   sta $85           ; store accumulator to location $85



; 119 more lines to store 0 into location $86 - $FC...



   sta $FD           ; store accumulator to location $FD

   sta $FE           ; store accumulator to location $FE

   sta $FF           ; store accumulator to location $FF


You're right, that's ugly! The code above uses 258 bytes of ROM (2 bytes for each store, and 2 for the initial accumulator load). We can't possibly afford that - and especially since I've already told you that it's possible to initialise the 6502 registers, clear RAM, *AND* initialise the TIA in just 9 bytes total!

The index registers have their name for a reason. They are useful in exactly the situation above, where we have a series of values we want to read or write to or from memory. Have a look at this next bit of code, and we'll walk through what it does...

   ldx #0

   lda #0

ClearRAM  sta $80,x

   inx

   cpx #$80

   bne ClearRAM


Firstly, this code is nowhere-near efficient, but it does do the same job as our first attempt and uses only 11 bytes. It achieves this saving by performing the clear in a loop, writing 0 (the accumulator) to one RAM location every iteration. The key is the "sta $80,x" line. In this "addressing mode", the 6502 adds the destination address ($80 in this example - remember, this is the start of RAM) to the current value of the X register - giving it a final address - and uses that final address as the source/destination for the operation.

We have intialised X to 0, and increment it every time through the loop. The line "cpx #$80" is a comparison, which causes the 6502 to check the value of X against the number $80 (remember, we have $80 bytes of RAM, so this is basically saying "has the loop done 128 ($80) iterations yet?". The next line "bne ClearRAM" will transfer program flow back to the label "ClearRAM" every time that comparison returns "no". The end result being that the loop will iterate exactly 128 times, and that the indexing will end up writing to 128 consecutive memory locations starting at $80.


   ldx #$80

   lda #0

ClearRAM

   sta 0,x

   inx

   bne ClearRAM

Well, that's not a LOT different, but we're now using only 9 bytes to clear RAM - somehow we've managed to get rid of that comparison! And how come we're writing to 0,x not $80,x? All will be revealed...

When the 6502 performs operations on registers, it keeps track of certain properties of the numbers in those registers. In particular, it has internal flags which indicate if the number it last used was zero or non-zero, positive or negative, and also various other properties related to the last calculation it did. We'll get to all of that later. All of these flags are stored in an 8-bit register called the "flags register". We don't have easy direct access to this register, but we do have instructions which base their operation on the flags themselves.

We've already used one of these operations - the "bne ClearRAM" we used in our earlier version of the code. This instruction, as noted "will transfer program flow back to the label "ClearRAM" every time that comparison returns "no". The comparison returns "no" by setting the zero/non-zero flag in the processor's flags register!

In atuality, this zero/non-zero flag is also set or cleared upon a load to a register, an increment or decrement of register or memory, and whenever a calculation is done on the accumulator. Whenever a value in these circumstances is zero, then the zero flag is set. Whenever the result is non-zero, the zero flag is cleared. So, we don't even need to compare for anything being 0 - as long as we have just done one of the operations mentioned (load, increment, etc) - then we know that the zero flag (and possibly others) will tell us something about the number. The 6502 documentation gives extensive information for all instructions about what flags are set/cleared, under what circumstance.

We briefly discussed how index registers, only holding 8-bit values "wrap-around" from $FF (%11111111) to 0 when incremented, and from 0 to $FF when decremented. Our code above is using this "trick" by incrementing the X-register and using the knowledge that the zero-flag will always be non-zero after this operation, unless X is 0. And X will only be 0 if it was previously $FF. Instead of having X be a "counter" to give 128 iterations, this time we're using it as the actual address and looping it from $80 (the start of RAM) to $FF (the end of RAM) + 1. SO our store (which, remember, takes the address in the instruction, adds the value of the X register and uses that as the final address) is now "sta 0,x". Since X holds the correct address to write to, we are adding 0 to that icon_smile.gif

I would *highly* recommend that you don't worry too much about this sort of optimisation while you're learning. The version with the comparison is perfectly adequate, safe, and easy to understand. But sometimes you find that you do need the extra cycles or bytes (the optimised version, above, is 256 cycles faster - more than three whole scanlines !! quicker). So you can see how crucial timing can be - by taking out a single instruction (the "cpx #$80") in a loop, and rearranging how our loop counted, we saved more than three scanlines - (very) roughly 1% of the total processing time available in one frame of a TV picture!

Initialising the TIA is a similar process to initialising the RAM - we just want to write 0 to all memory locations from 0 to $7F (where the TIA lives!). This is safe - trust me - and we don't really need to know what we're writing to at this stage, just that after doing this the TIA will be nice and happy. We could do this in a second loop, similar to the first, but how about this...

   ldx #0

   lda #0

Clear

   sta $80,x     ; clear a byte of RAM

   sta 0,x       ; clear a byte of TIA register

   inx

   cpx #$80

   bne Clear

That's a perfectly adequate solution. Easy to read and maintain, and reasonably quick. We could, however, take advantage of the fact that RAM and the TIA are consecutive in memory (TIA from 0 - $7F, immediately followed by RAM $80 - $FF) and do the clear in one go...

   ldx #0

   lda #0

Clear

   sta 0,x

   inx

   bne Clear

The above example uses 9 bytes, again, but now clears RAM and TIA in one 'go' by iterating the index register (which is the effective address when used in "sta 0,x") from 0 to 0 (ie: increments 256 times and then wraps back to 0 and the loop halts). This is starting to get into "elegant" territory, something the experienced guys strive for!

Furthermore, after this code has completed, X = 0 and A = 0 - a nice known state for two of the 3 6502 registers.

That's all I'm going to explain for the initialisation at this stage - we should insert this code just after the "Reset" label and before the "StartOfFrame" label. This would cause the code to be executed only on a system reset, not every frame (as, every frame, the code branches back to the "StartOfFrame" for the beginning of the next frame).

Before we end today's session, though, I thought I'd share the "magical" 9-byte system clear with you. There's simply no way that I would expect you to understand this bit of code at the moment - it pulls every trick in the book - but this should give you some taste of just how obscure a bit of code CAN be, and how beautifully elegant clever coding can do amazing things.

  ; CLEARS ALL VARIABLES, STACK

  ; INIT STACK POINTER

  ; ALSO CLEARS TIA REGISTERS

  ; DOES THIS BY "WRAPPING" THE STACK - UNUSUAL



   LDX #0

   TXS

   PHA           ; BEST WAY TO GET SP=$FF, X=0



   TXA

CLEAR PHA

   DEX

   BNE CLEAR



  ; 9 BYTES TOTAL FOR CLEARING STACK, MEMORY

  ; STACK POINTER NOW $FF, A=X==0




See you next time!

#2 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

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

Posted Wed May 28, 2003 5:40 AM

Here's the latest source code, with the initialisation inserted, and a few minor changes here and there...




                processor 6502

                include "vcs.h"

                include "macro.h"


;------------------------------------------------------------

                SEG

                ORG $F000



Reset



   ; Clear RAM and all TIA registers



                ldx #0 

                lda #0 

Clear           sta 0,x 

                inx 

                bne Clear



StartOfFrame



   ; Start of vertical blank processing



                lda #0

                sta VBLANK



                lda #2

                sta VSYNC



                sta WSYNC

                sta WSYNC

                sta WSYNC               ; 3 scanlines of VSYNC signal



                lda #0

                sta VSYNC           



   ; 37 scanlines of vertical blank...

            

                ldx #0

VerticalBlank   sta WSYNC

                inx

                cpx #37

                bne VerticalBlank





   ; 192 scanlines of picture... 



                ldx #0 

Picture

                SLEEP 20           ; adjust as required!

 

                inx 

                stx COLUBK 



                SLEEP 2            ; adjust as required!



                txa

                eor #$FF

                sta COLUBK 



                sta WSYNC 



                cpx #192

                bne Picture





    

 

                lda #%01000010

                sta VBLANK          ; end of screen - enter blanking



   ; 30 scanlines of overscan...



                ldx #0

Overscan        sta WSYNC

                inx

                cpx #30

                bne Overscan



                jmp StartOfFrame




;------------------------------------------------------------

            ORG $FFFA



InterruptVectors



            .word Reset          ; NMI

            .word Reset          ; RESET

            .word Reset          ; IRQ



      END





#3 EricBall OFFLINE  

EricBall

    Dragonstomper

  • 789 posts
  • Location:Markham, Ontario, Canada

Posted Wed May 28, 2003 10:43 AM

Just my C$0.03

Although Andrew's code is an optimal way to clear all of zero page RAM & TIA registers, in my experience is it's not always necessary to clear all of the TIA registers & RAM. The code will often set the TIA registers to different values or set them at specific times. Variables (RAM) get initialized to non-zero values, or calculated as required.

#4 DEBRO OFFLINE  

DEBRO

    Stargunner

  • 1,924 posts
  • Location:Atlanta, GA

Posted Wed May 28, 2003 12:13 PM


   ; CLEARS ALL VARIABLES, STACK

   ; INIT STACK POINTER

   ; ALSO CLEARS TIA REGISTERS

   ; DOES THIS BY "WRAPPING" THE STACK - UNUSUAL



    LDX #0

    TXS

    PHA           ; BEST WAY TO GET SP=$FF, X=0



    TXA

CLEAR PHA

    DEX

    BNE CLEAR



   ; 9 BYTES TOTAL FOR CLEARING STACK, MEMORY

   ; STACK POINTER NOW $FF, A=X==0



Andrew, I love this piece of code everytime I see it :lust:

#5 Contieri OFFLINE  

Contieri

    Space Invader

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

Posted Thu May 29, 2003 11:06 PM

Andrew...


Things are just great.

I was wondering if you could leave some exercises, in order to challenge US to find out how things work, specially "homework" that we will get answers in our following lesson. Stuff like: Why don't you try to, de-syncronize your kernel and see the color bars rolling (I've done that :) - Ok, it was an accident...)

Well, that's it!! Thanks!! Keep up the good work!!

Cheers,

Contieri

#6 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

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

Posted Thu May 29, 2003 11:24 PM

 I was wondering if you could leave some exercises, in order to challenge US to find out how things work, specially "homework" that we will get answers in our following lesson. Stuff like: Why don't you try to, de-syncronize your kernel and see the color bars rolling (I've done that  :)  - Ok, it was an accident...)


I've had a couple of people requesting exercises. I'll try and include some in future sessions. Meanwhile, grasshopper, try and take this nibble from my hand...

#7 Happy_Dude OFFLINE  

Happy_Dude

    River Patroller

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

Posted Fri May 30, 2003 5:17 AM

a nibble == 4 bits.

#8 Nukey Shay ONLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,639 posts
  • Location:The land of Gorch

Posted Fri May 30, 2003 7:51 AM

Close....a nybble is half a byte ;)

#9 Happy_Dude OFFLINE  

Happy_Dude

    River Patroller

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

Posted Fri May 30, 2003 8:05 AM

Close....a nybble is half a byte ;)

Funny :? I always thought 1 Byte was 8 bits :ponder:

#10 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

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

Posted Fri May 30, 2003 8:08 AM

Close....a nybble is half a byte ;)

Funny :? I always thought 1 Byte was 8 bits :ponder:


It was a joke, Happy.

Byte... eat... bite.... nibble... nybble... half a bite.
You are both correct. A byte = 8 bits and half a bite = a nibble (or nybble) which is 4 bits. Spelling is acceptable either way.

#11 Happy_Dude OFFLINE  

Happy_Dude

    River Patroller

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

Posted Fri May 30, 2003 11:06 AM

I think I'll have to have a "word" with you about Sarcasm.
Mabey even a "Long word" .... ;)

#12 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

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

Posted Tue Jul 1, 2003 6:20 PM


   ; CLEARS ALL VARIABLES, STACK

   ; INIT STACK POINTER

   ; ALSO CLEARS TIA REGISTERS

   ; DOES THIS BY "WRAPPING" THE STACK - UNUSUAL



    LDX #0

    TXS

    PHA           ; BEST WAY TO GET SP=$FF, X=0



    TXA

CLEAR PHA

    DEX

    BNE CLEAR



   ; 9 BYTES TOTAL FOR CLEARING STACK, MEMORY

   ; STACK POINTER NOW $FF, A=X==0



Andrew, I love this piece of code everytime I see it :lust:


Though the above was a truly magical piece of code, I've since developed an EIGHT byte solution to the problem of clearing RAM and initialising the stack and registers :)


        ldx #0

        txa

Clear   dex

        txs

        pha

        bne Clear


After the above, X=A=0, and all of RAM and the TIA has been initialised to 0, and the stack pointer is initialised to $FF. Amazing!

#13 Ze_ro OFFLINE  

Ze_ro

    Quadrunner

  • 8,512 posts
  • Things aren't different. Things are things.

Posted Fri Apr 23, 2004 2:21 AM

Since we're making sure to zero out all the RAM and TIA registers, shouldn't we also be doing a SEI and CLD, since we can't be sure of their state upon powerup? I noticed that Combat does this, as do most of the other "How to Draw a Playfield" type example programs I've seen. Disabling interrupts probably isn't important, but if we aren't sure that D is cleared, there's a chance all our ADC and SBC operations would be working in BCD.

--Zero

#14 Andrew Davie OFFLINE  

Andrew Davie

    Stargunner

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

Posted Fri Apr 23, 2004 2:28 AM

Since we're making sure to zero out all the RAM and TIA registers, shouldn't we also be doing a SEI and CLD, since we can't be sure of their state upon powerup? I noticed that Combat does this, as do most of the other "How to Draw a Playfield" type example programs I've seen. Disabling interrupts probably isn't important, but if we aren't sure that D is cleared, there's a chance all our ADC and SBC operations would be working in BCD.

--Zero


In short, yes. Well spotted.

The longer answer is... "sort of". Yes, clearing the decimal flag is a good idea. But since the 6507 in the '2600 doesn't *have* interrupts (except indirectly through the BRK instruction), it's not strictly necessary to set the interrupt flag. Unless, of course, you use the BRK to trigger interrups.

But the best answer to your question is.... don't worry about it, and use the CLEAN_START macro provided in macro.h -- it sets everything up, and you can assume that your 6507 is in a useable and 'safe' state once it's complete.

The macro.h file is provided as a part of the DASM machine-specific distributables at www.atari2600.org/dasm/

Cheers
A

#15 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,693 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Fri Apr 23, 2004 2:53 AM

Right. SEI isn't necessary, but CLD should be done.

EDIT: Damned browser cache! ;)

#16 xucaen OFFLINE  

xucaen

    Stargunner

  • 1,001 posts
  • Moving and enrolled in MCSD certification classes.
  • Location:Massachusetts

Posted Thu Jan 6, 2005 7:52 PM

The longer answer is... "sort of".  Yes, clearing the decimal flag is a good idea.  But since the 6507 in the '2600 doesn't *have* interrupts (except indirectly through the BRK instruction), it's not strictly necessary to set the interrupt flag.  Unless, of course, you use the BRK to trigger interrups.


I had read somewhere that the atari 7800 does use interupts and that a 2600 game should init them just in case it is played on a 7800. Is there any truth to this? I don't know, I'm just a beginner..

jim

#17 Nukey Shay ONLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,639 posts
  • Location:The land of Gorch

Posted Fri Jan 7, 2005 1:12 AM

No probs with SIdeluxe on a 7800 (which does neither)...and it's been through the Supercharger, CC, CC2, and an actual cart :? In fact...I can't recall them being part of Atari's Space Invaders' boot sequence.

So when exactly is a CLD necessary? Is the decimal flag an unknown on powerup?

#18 Cybergoth OFFLINE  

Cybergoth

    Quadrunner

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

Posted Fri Jan 7, 2005 5:30 AM

Hi there!

So when exactly is a CLD necessary?  Is the decimal flag an unknown on powerup?


Most systems have the CLD flag cleared on powerup, but there've been problems with Gunfight on the CC1 for example...

So it's state is not reliable, yes. If the first addition or subtraction in the code isn't handing the flag, the result is uncertain.

Once you do the first BCD addition though, it should be set to a defined state again from then on.

Greetings,
Manuel

#19 RedBeard OFFLINE  

RedBeard

    Chopper Commander

  • 179 posts
  • Location:Oregon, USA

Posted Thu May 26, 2005 7:15 PM

But the best answer to your question is.... don't worry about it, and use the CLEAN_START macro provided in macro.h  -- it sets everything up, and you can assume that your 6507 is in a useable and 'safe' state once it's complete. 


So if it (the CLEAN_START) isn't the 9 byte version, how much room does CLEAN_START take? Is it just the main lesson above with a couple of extra lines, perhaps?
...not that any programming I do would need the extra memory, but the discussion revolved around saving a bit of space...

-C.F.

P.S. Forgive my ignorance, but are the real Atari carts ('the olden days') 2k or 4k? I just don't remember. Are 4k versions I'm seeing just Supercharger / Emulator tricks or actual Atari games?

#20 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 22,693 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Fri May 27, 2005 1:18 AM

P.S.  Forgive my ignorance, but are the real Atari carts ('the olden days') 2k or 4k?  I just don't remember.

The very first carts where all 2K. A bit later 4K was the standard size (before bankswitching).

#21 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • 3,596 posts
  • CD C9 01
  • Location:San Antonio, TX

Posted Fri May 27, 2005 2:42 PM

So when exactly is a CLD necessary?  Is the decimal flag an unknown on powerup?

It's kind of real important on the 7800, which starts up 7800 carts with SED and S=$16, presumalbly just to make sure the programmers are paying attention. I've been bit by the S=$16 thing before.

#22 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,646 posts
  • begin 644 contest

Posted Fri May 27, 2005 3:07 PM

So when exactly is a CLD necessary?  Is the decimal flag an unknown on powerup?

It's kind of real important on the 7800, which starts up 7800 carts with SED and S=$16, presumalbly just to make sure the programmers are paying attention. I've been bit by the S=$16 thing before.

View Post

I wonder why nearly all games use SEI, when the 6507 doesn't even have interrupts? Some games don't (look at Human Cannonball for instance.) I've tried removing this and the games work fine.

#23 Kroko OFFLINE  

Kroko

    Moonsweeper

  • 408 posts
  • Location:Germany

Posted Fri May 27, 2005 5:09 PM

I wonder why nearly all games use SEI, when the 6507 doesn't even have interrupts?  Some games don't (look at Human Cannonball for instance.) I've tried removing this and the games work fine.

It doesn't have the pins, but some programmers fear that they might occur, even if the pins are not there. I don't know if it is documented in which way the interrupt lines are wired inside the 6507. I think they do exist, but they are not connected. If they are not connected, they might internally be connected to a fixed voltage level or they might float. If they float, interrupts might happen. But I guess they 6507 designers made a good job and you don't have to fear that an interrupt will accidentaly occur. I am not sure, though :D

Thats why I would probably also use a little SEI to be 100% safe.

#24 detays OFFLINE  

detays

    Combat Commando

  • 4 posts

Posted Sat Jan 26, 2008 4:05 AM

Hello,
I have tested this code using DASM and Stella but there is something that I don't understand. I've got light orange lines at the begining of the picture and at the end. I also used Z26 and these line remained the same. Is it normal ?
PS Sorry for my quite bad english, I hadn't practiced for a while ...

Attached Thumbnails

  • init.png


#25 Wickeycolumbus OFFLINE  

Wickeycolumbus

    Red Sea Crosser

  • 5,138 posts
  • Location:Michigan

Posted Sat Jan 26, 2008 11:59 AM

Hello,
I have tested this code using DASM and Stella but there is something that I don't understand. I've got light orange lines at the begining of the picture and at the end. I also used Z26 and these line remained the same. Is it normal ?
PS Sorry for my quite bad english, I hadn't practiced for a while ...


There are probably timing issues with your code. post it so i can try to help you.

BTW: Your english is fine :)




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users