Suggestions to follow branch instructions

[dougeff]

rom memory in position 2000h or 8194d

I'm talking about $2002, which is hardwired directly to the PPU, a second chip on the motherboard.

Also, usually the ROM is "mapped" to the $8000-ffff region of memory. There will never be ROM mapped below $4020.

I suggest, spend some time reading the wiki.
http://wiki.nesdev.com/w/index.php/Nesdev_Wiki

[Quietust]

I have a feeling that there might be a language barrier here, and some machine translator is distorting not only the original question but our replies as well. Is English your native language?

[Zepper]

I have a feeling that there might be a language barrier here, and some machine translator is distorting not only the original question but our replies as well. Is English your native language?

That... or a bot. If human, yes, english isn't his mother-language, as far as I can tell ya.

[colt]

It might be a little easier to discuss if you provided more context. It's really hard to offer any helpful insight with such a tiny view of what you're looking at.

What ROM is this?

Or if you don't want to disclose that, at least show the LDA / BPL instruction you're talking about (i.e. what are the 5 bytes of code in this loop, and where are they loaded in memory). What mapper?

Here the first two lines:

[colt]

Unfortunately, I am still stuck with this issue. My program currently is trapped between an infinite loop between a absolute load instruction "AD" instruction and a BPL. This happens because: The LDA instruction loads a value from position 2002. This value happens to be 27, which means its seventh bit of the A register will be 0. Hence the seventh bit of the status register won't be changed. Since it already was zero, it will continue to be so. Then the BPL instruction starts to execute. It will check the seventh bit of the status register and see that its value is zero. Hence it will move backward three bytes, back to the LDA instruction. Then will do the same thing once again and forever, entering into an infinite "ping pong" between both instructions.

I was thinking into possible causes

1)I am loading the wrong value from memory, possibly because I am loading from the wrong position

2)There is some kind of logical error.

3)There is something else to be done that I do not have knowledge of.

So my questions are. How I can find out the reason behind of this?

[lidnariq]

The LDA instruction loads a value from position 2002. This value happens to be 27, which means its seventh bit of the A register will be 0.

No it is not. LDA $2002 means instruct the NES's CPU to ask something to put a value on the data bus when the CPU puts $2002 on the address bus.

But that's not ROM.

Instead, the NES uses what's referred to as Memory-mapped I/O to interact with other devices beyond its own RAM and ROM.

In the NES, $2002 means "ask the PPU what's up".

[tokumaru]

Your branching code appears to be working fine, games are supposed to get "stuck" reading $2002 when they're initializing. The problem here is that you're treating $2002 as a static memory location, but like dougeff told you in the previous page, this address is RAM or ROM, it's actually a communication port with the PPU. PPUSTATUS is a register that contains some information about what the PPU is doing - bit 7 in particular indicates whether the vertical blank (period between video frames) has started. Before vblank starts, bit 7 reads back as 0, so the BPL instruction will branch while this is the case, but as soon as vblank starts, bit 7 will become 1, and the CPU will get out of that loop.

If you're writing an emulator, now might be the time to start implementing a PPU, and have it signal the start of vblank via register $2002.

[colt]

Okay, so when v-blank is activated, the seventh bit of the ppu status register is changed to one, leading to the end of this loop. But what causes it? I found this:

The VBlank flag of the PPU is set at tick 1 (the second tick) of scanline 241, where the VBlank NMI also occurs. The PPU makes no memory accesses during these scanlines, so PPU memory can be freely accessed by the program.

So during the second "tick" (clock pulse?) of the scanline 241 the seventh bit of the PPU status register becomes one.

So I will have to:

1)Start to count ticks, both from the PPU and from the CPU
2)Start to count scanlines

Since there is about 113 cpu clocks per scanline, does that mean that at only 241*113.667 = a lot of clock cycles will the loop stops? I shall start the counting of the cpu cycles from the cpu's first instruction read? and the ppu?