Can you write to the same location with $2006/$2007 during the same NMI routine without any ill effects? My attribute tables always get written twice and it would be really messy to change it, but I will if I have to.

-Pulper

Well after you write to $2007 once you'll have to reset the address with $2006 if you want to write to the same area (since it auto-increments).

But other than that... yeah, shouldn't cause any problems.

OK thanks.

-Pulper

One more thing, what is the difference in defining a variable and using that to store data, or just doing it directly to an address. I notice on some tutorials, people say:

lda whatever1
sta $10
lda whatever2
sta $11

How do you know you are not overwriting some random data that happens to be stored in those locations? Is there a predefined address space which the cpu does not use? If so, where is it?

I see in Nestech that he says from $0 to $800 is RAM. Does this mean the cpu will not use this space unless you specifically tell it to?

-Pulper

0000-07FF is RAM available for use for YOUR program. If you do a "STA $10" command, you won't be overwriting anything unless it's your own variable stored at that location.

Some assemblers might "hide" the actual address from the user by just having you define variable names (like "STA some_var" instead of "STA $10"). But once the file is assembled... all the variable names are just given a value to somewhere in RAM (0000-07FF range... or maybe the 6000-7FFF range)

While 0000-07FF is totally free for you to use, you might want to steer clear of the 0100-01FF area ;) One could argue that the cpu DOES "use" that part.

Ah great, that totally clears it up, thanks!

-Pulper

Ah yeah... that slipped my mind. =)

Unless your program uses recursion, using $0100-$01BF for variables should be safe. Here's why: On 6502, $0100-$01FF is the stack. Each game's reset code initializes the stack pointer to $FF, and the stack grows downward (toward $0100). Many 6502 programs don't use more than about 16 bytes of stack ($01F0-$01FF).

To check how much stack your program actually uses, put this code at the beginning:

ldx #0
@loop:
lda #$65
sta $100,x
inx
lda #$02
sta $100,x
inx
bne @loop
dex
txs

This code fragment 1. initializes the stack to an easily recognizable pattern and 2. initializes the stack pointer to $FF. Then when running the program, turn on FCE Ultra's memory viewer to see how much has in fact been modified over the course of a run, and plan on 16 or so bytes more for safety.

To reduce your program's stack footprint, look for subroutines called only from one place and replace the jsr/rts with a jmp/jmp or just inline them.

To reduce your program's stack footprint, look for subroutines called only from one place and replace the jsr/rts with a jmp/jmp or just inline them.

You can also convert a subroutine call at the end of another routine to a jump:

    routine:
        ; ...
        jsr another_routine
        rts

can be changed to

    routine:
        ; ...
        jmp another_routine

A 'jsr' followed by an 'rts' is called a "tail call."

Believe it or not, there exist some languages, such as Scheme, for which a conforming interpreter or compiler will always optimize tail calls into jmps. Such languages also typically invite a lot of recursion, which brings me to the next point:

If you have to use more-than-tail recursion, such as in a flood filler or a quicksort, you often know that a routine will always be calling itself, so you can often just push the registers on the stack and 'jmp' around, omitting the return address.