nesdev.org

AWJ wrote:if it's between $00 and $7F it's a forward branch, if it's between $80 and $FF it's a backward branch.

Just to be clear, $80 is -127 and $FF is -1, right?

Ah, thanks for that. Will fix now!

From which program is this disassembled? I'm testing using the Japanese version of Donkey Kong. What makes you say that $000f shouldn't be zero? This code comes from the very beginning of the ROM during the startup procedure, before a frame has even passed. So if $000f isn't 0, it's probably a star...

So I've been having trouble implementing subroutines because of this strange problem. Supposedly its implied that the stack shouldn't be written to during subroutines, right? Since JSR writes the address of the next instruction to the stack and RTS reads that address to return, the stack shouldn't b...

rainwarrior wrote:(On the first test it will be $FF = -1, on the 256th test it will be back down to 0.)

[/quote]

So you're saying that all numbers in RAM are unsigned bytes? I completely forgot about that lol.

After the BEQ I have the following instructions: LDY 07, imm STY 01, zp LDY 00, imm STY 00, zp LDA 00, imm STA 00, indY DEY BNE fb, imm DEC 01, zp BPL f7, imm This still results in an infinite loop for me. If I'm getting it right, the following happens: 7 is stored in Y Y is stored in $0001 (value o...

Hold on nevermind it's usually set at powerup. I'm dumb lol

Right. Nothing seems to be writing anything to bit 7 of $2002 though.

I'm looking at the PPU documentation and I'm a bit confused. STA writes 0x10 (16 in decimal and 00010000 in binary) to address $2000. The byte that controls vblank is the first one, byte 7, yet it seems to be set to 0. What am I missing?

The first instructions in the rom for Donkey Kong are the following: SEI CLD LDA 10 STA $2000 LDX ff TXS LDA $2002 AND 80, imm BEQ f9, imm Since BEQ branches if the zero flag is set, and $2002 is 0 initially, LDA sets the zero flag when it executes. BEQ then branches 7 bytes back to the LDA command,...

How would I go about doing this? Is there a way to distinguish between data and machine code? Run the program. Anything that gets executed is code. That's basically it. (Self modifying code and/or code copied to RAM is an exception, though.) FCEUX has a "code data log" feature that does t...

Nope. Unlike modern operating systems and program containers, which bother to distinguish between "stuff that the CPU will execute" and "read only data that the CPU will refer to", the NES shoves it all into a single chunk of data. The only ways to way to handle this is to eithe...

You're missing "relative" mode …no, you just call branch instructions' mode "immediate" for some reason. The following lines of your opcode table appear messed up: '0d':['ORA', 'abs', '4+'], //should be 4 '1d':['ORA', 'absX'], //should be 4+, has nothing '3d':['AND', 'absX'], //...

Where do I set the cutoff for where the last opcode is then? I know where the first one is based on the reset vector at offset $FFFC, but is there another one for the end of the machine code?

I've been mapping out hex opcodes to instructions for the last couple of days. When I check my rom, though, the last opcode seems to be cut off. It's the last byte of the rom, but accepts a 2 byte address as an argument. Did I make an error somewhere in mapping out the modes for each opcode? Here's ...