[Bob789]

Hello,

I just started learning 6502 Assembly and I would like to ask a few dumb questions.

1. What does the .hex instruction do? I've been looking over the source code for the original Legend of Zelda on the NES and it uses this command quite often. Is it similar to the .byte instruction?

2. Can someone explain the BRK(break) command to me? All the documentation I've looked at does not explain it well.

3. I'm having a bit of trouble understanding Zero Page Indirect Indexed with Y. Ex. (ZeroPageAddress), Y

I will update this post as I continue to learn and my IQ gets lower.

[Psyklax]

1. .hex? .byte? I don't understand any of that. Are you sure they're instructions?
2. BRK usually stops the program, in my experience. Try putting it in a game in place of a regular instruction and see what happens.
3. It just means that the program looks at a 16-bit address at that location in zero page, then adds whatever is in Y to what it finds there. So let's say Y has $08 and address $C0 and $C1 have $75 and $B3 respectively. Doing LDA ($C0),Y (or 'B1 C0' in the code) will first go to $C0 and find $B375 (because it's little-endian, ie the less significant byte goes first), then adds Y to what's at $B375 (let's say $24), and loads it into the Accumulator. Now we have $2C in the Accumulator ($24 + $08).

[Bob789]

.hex? .byte? I don't understand any of that. Are you sure they're instructions?

My bad, they're directives. Sorry 'bout that.
I'm not too sure what they are, but here are some examples:

https://stackoverflow.com/questions/28803143/what-does-the-byte-directive-do-in-6502-assembler

https://stackoverflow.com/questions/28811986/byte-directive-in-6502-where-it-is-stored

[Disch]

1.

Anything that starts with a dot (.) or an octothorp (#) is probably an assembler directive.  Directives are special commands that are used to tell the assembler to do something besides actually assembling code.  Each assembler has their own directives and they all vary slightly.  I'm unfamiliar with ".hex", but it might be the same thing as ".byte" or ".db" (both of which are much more common).

.byte/.db (and I assume .hex) let you insert individual values in the middle of your code.

Example:

Code: [Select]

; this...
LDA #$45
.byte $11, $22
NOP

; will assemble to this...
A9 45 11 22 EA
^     ^     ^
|     |     |
|     |     NOP
|     .byte values
LDA

2.

BRK performs a software interrupt.  It is almost never useful -- especially on the NES.  My advice is don't worry about it.

But if you really want to know what it does, read up on what happens during an IRQ.  Most games that use IRQs use them to be signaled when a certain external event is happening (like when you've reached a particular scanline during drawing).  These IRQs are generated by hardware when those events are happening to notify the code.

BRK is the exact same thing -- it does an IRQ.  Only instead of it being triggered by an external event, it's triggered by code.

Like I said ... practically useless.  Don't worry about it.

3.

Psyklax covered this pretty well.

[KingMike]

Psyklax got it wrong.
If $C0 = 0xB375 and Y = 0x08,
then LDA ($C0),Y would read from ($B375 + 8 ) or $B37D.

I'm positive as LDA ($xx), Y is probably THE most common instruction used to read text. (reading text by either incrementing Y after every character or else keeping Y zero and increment whatever is stored at xx.)

[Psyklax]

Hmm, I wasn't sure which one, whether to add to the indexed address or to the value found there. There are two different ones. I went for the latter, but I'll accept if I got it the wrong way round.

[Disch]

I thought that's what Psyklax said... but in re-reading it, yeah he seems to be saying you add Y to the final value, rather than to the final address.  Whooooop.  S'all good.   

[Bob789]

Ok, I get it all now, except for one thing. Since .byte simply adds data in the program, (Ex. .byte 12 simply inserts 12 into the memory address where the program currently is, if that makes sense) and .hex looks like it does the same thing, does the byte of hex you put in the program get executed?
For example:
Consider the following.

 

Code: [Select]

LDA #$03      ; Let's say the hexadecimal equivalent of LDA #$03 is A9 03.

Could I do this to reach the same end?

Code: [Select]

.hex A9 03

Either way it is quite weird, because the first 1000 lines or so of Zelda's source code are .hex ff ff ff.
But the disassembler does put a comment of invalid opcode, just to throw information out there.

[Disch]

does the byte of hex you put in the program get executed?

It puts the byte in the ROM.  That's all that really matters.

Whether or not it gets executed as code depends on whether or not program execution happens to run over that particular byte.  Remember the 6502 doesn't have any concept of "code" vs. "data".  It's all just bytes.  If you tell it to start running code at address $C000, it's going to start reading bytes from that address and interpreting it as if it were code, even if it isn't.  When the 6502 sees the byte 'A9', it thinks "oh, that's LDA immediate" -- even if it's just some random piece of data.

For example:
Consider the following.

 

Code: [Select]

LDA #$03      ; Let's say the hexadecimal equivalent of LDA #$03 is A9 03.

Could I do this to reach the same end?

Code: [Select]

.hex A9 03


Yes.  Both of those will produce the same binary output:  the bytes 'A9 03'

Either way it is quite weird, because the first 1000 lines or so of Zelda's source code are .hex ff ff ff.

That's not that weird.  That's either padding or graphic data or some other kind of information used in the game somewhere.  It's just not code.

Code doesn't have to start at the beginning of the ROM.  The entry point for the game is wherever the "reset vector" points to.  In LoZ, this is address $FF50 (in bank 7).

[Psyklax]

the 6502 doesn't have any concept of "code" vs. "data".  It's all just bytes.

Exactly, bytes are bytes. Could be graphics, code, levels, text, music, filler, anything. It's like how when you get glitches in games, the wrong bytes are being read (Super Mario Land 2 is a great example where a certain series of actions can get Mario jumping through sections of code instead of the actual level). The only assembly I've done has been hacking the bytes directly instead of using an assembler, so I'm not familiar with things like .byte and what have you.

[Bob789]

It all makes sense now. Life....Death....Everything..... jk but I finally understand it thanks for the help.