Stuck with my CPU implementation and nestest.nes

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
alexwy
Posts: 5
Joined: Fri Dec 14, 2012 5:58 am
Location: Australia
Contact:

Stuck with my CPU implementation and nestest.nes

Post by alexwy » Wed Jan 09, 2013 4:24 am

This question is similar to my earlier question. It'd be good to read it for some background on this one.

I've gotten stuck at another instruction in nestest.nes which doesn't seem to work in my implementation as per the sample nestest.nes output.

That instruction is 0xCFF2. It's meant to load the Accumulator with 0xFD, pulled from 0x400. From my understanding, my emulator should read bytes at 0xFF (the instruction's operand) and 0x100 (it's a 16bit read, so the following byte to 0xFF), then combine the bytes there to get a 16bit address, which should be 0x400. In my implementation, it is pulling out 0xFF00, the lower byte being correct, but the high one being incorrect (I set all memory to 0xFF on initial start up). It's worth noting in my emulator, the address 0x400 does contain the right piece of memory (0xFD).

I've logged as much as I can, but only found two writes to memory with the value 0x4, which are short lived stack write and a write to 0x0, which doesn't seem to be relevant. I've also tried to step through as much of the instructions by hand as possible, trying to figure out what I'm missing.

Is anyone able to point out where 0x4 is written to 0x100, or what I may have done wrong? Thanks.

tepples
Posts: 22017
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Stuck with my CPU implementation and nestest.nes

Post by tepples » Wed Jan 09, 2013 6:31 am

Indirect addressing modes involving zero page, such as (d,X) and (d),Y modes, wrap within $00xx instead of overflowing to the stack. Are you taking that into account?

alexwy
Posts: 5
Joined: Fri Dec 14, 2012 5:58 am
Location: Australia
Contact:

Re: Stuck with my CPU implementation and nestest.nes

Post by alexwy » Thu Jan 10, 2013 3:39 am

Of course! Why didn't I think of that? Then the next read at 0x0 would indeed grab the correct value.

Thanks.

Post Reply