nesdev.org

I think I got the basic idea on how this works now. I think what I'll do is that when I call INIT or PLAY I'll push a return address to the stack, change the program counter to the routine's address and enable the CPU. The return address points to a part of the memory the program counter normally do...

What reason would you have not to implement this feature of JMP if you are aware of it? It's literally only a couple of extra characters on the line of code that would otherwise implement the address fetch. Technically there is no reason not to if I was making a full emulator, but since I'm making ...

So the program counter is already at the next opcode when it decides whether it should branch or not?

tepples wrote:...you need to wait for an rts instruction to move the stack pointer into the area of the stack that you have reserved for the player.

Can you explain this a bit further?

The NES CPU behaves as the MOS 6502 in this case and in all known others that do not involve use of the D flag. I see. Although since I'm not making a full emulator I don't think I need to emulate this feature anyway. I doubt there are cases where the Indirect JMP vector is intentionally placed on ...

Only for the experimental timer support in NSF version 2. Otherwise, the only thing resembling an interrupt is the one that calls the PLAY routine. Do I have to detect the ending of the PLAY (and INIT) routines somehow or is there a infinite loop at the end that waits until I call the PLAY routine ...

Somewhat off topic, but does the NES CPU fetch the address correctly for Indirect JMP if the first byte is on $xxFF or does it wrap around to the beginning of the page? I read that it happened incorrectly for the original 6502 processor, but since the NES CPU is not exactly same as the original 6502...

I'm not making a full emulator at least for now. I might try it later, so it's a good idea to understand how things work. It'll make things easier when I do. EDIT: Would pulling the return address from the stack be really any different than reading a word from the position of the stack pointer and t...

(*) Either that or your understanding of what they said is wrong. The reference said "...It pulls the program counter (minus one) from the stack.". I don't think there is any other way you can understand that. Either way, the way you explained the JSR and RTS function makes more sense. .....

According to few sites JSR subtracts 1 from the program counter before pushing it to the stack (should now point to the lower byte of the subroutine's address). Why? Additionally one site says that RTS subtracts 1 from the value taken from the stack (pointing the JSR instruction) and one says it add...

So here is a question about the carry flag. If I'm testing for overflow to set the carry flag, do I have to clear it if the condition to set it was not met (this might be relevant if carry was already set before the operation). Of course with ADC the carry flag would be used in the addition if it wa...

yaros wrote:...affect A (DEC A,...

Wait. DEC has Accumulator addressing mode? All references I looked at only listed Zero Page, Absolute and their X variants

While it is common to use instructions like STA, STX and STY to modify registers, are there other instructions that can affect them? For instance, does DEC and INC have any effect on registers and do they behave as expected?

About the all-in-NMI stuff though. Having your game logic at the end of your NMI, how is that different from having a regular main loop outside of it? Most of the time you only let your game logic run once after each NMI anyway so you would end up with the same behavior as an all-in-NMI approach ei...

Using .dll seemed to be useless effort. In what sense? the program didn't sort of know it is there. It did display in the project tree and it did recognize some information about it, but you couldn't use it for some reason. It just didn't recognize it when I tried to actually include it into a scri...