New Project

NESASM3 uses some very weird terminology for things. It really would help if you were using an assembler that the rest of the community commonly used (asm6, ca65, or qasm); it would make helping you a lot easier, and we wouldn't be fighting over assembler idiocy like this. :-)

I STRONGLY suggest avoiding using .RSSET and .RS. These pseudo-ops are confusing as hell; I've read the documentation (and its examples) 4 or 5 times now, and although I think I get it, they really don't make any sense. Awful awful awful.

Please use something like this instead:



Let's talk about the Kites stuff first. Sure, adding 4 to Kites works fine, because we're adding 4 to 0, which makes 4. But what if Kites had been initialised with value 254 and we wanted to add 4 to that (258 kites)? We'd have a big problem.

254 + 4 = 258. But an 8-bit value can only hold from 0 to 255... so guess what gets written to Kites in that case? 258-256 = 2. You expected 258 kites, but you suddenly have 2.

Welcome to 6502 and 8-bit architectures! :-)

If you actually want to see or validate this in real-time, you can do so by using the virtual 6502 simulator over at 6502asm.com. Put this code into the text box, compile it, then run it. You'll see a dark red dot in the middle of the screen (dark red = $02). Try messing around with the initialisation value for Kites to see what happens.



Next, note that I explicitly did not mess with Rocks here, meaning I did not show how to, say, add 455 rocks to the existing value. The reason is that working with 16-bit values is a little tricky on the 6502 since all registers are 8-bit. You have to "split up" a 16-bit value into two 8-bit portions and handle them/treat them separately.

In the case of the initialisation routine, for example, if we wanted to have 378 rocks instead of just 8, we'd have done this instead:



This might be an easier way of looking at it:

Decimal value 378 is written $17A in hexadecimal -- or, to pad things out, written as $017A in hexadecimal. The "lower byte" (e.g. Rocks) would therefore be $7A, and the "upper byte" (e.g. Rocks+1) would therefore be $01.

Doing real-time (e.g. not static/pre-calculated numbers) 16-bit arithmetic gets a little tricky at times, but you'll have to learn that as you go.

My advice right now: try to keep everything within 8 bits (range 0 to 255) if you can. It'll make learning a lot easier. When I say "everything", I mean your counters/variables (number of lives, ships, X/Y offsets, etc.). You're still learning, so keep it simple. :-)