the RESET

[Zepper]

After setting the CPU and PPU to something "default" or described in the wiki, I set my emulator to run the CPU for the RESET call. The first thing that runs is the RESET:

Code: Select all

- set I_FLAG to 1;
- fetching two dummy bytes (2 cycles);
- decrement S three times, but nothing is written to the stack (3 cycles);
- fetch low byte of PC (1 cycle);
- fetch high byte of PC (1 cycle).

TOTAL: 7 cycles.

I wonder if there's an error, since my emu "fails" by 1 cycle in the APU reset timing (test suite 2005) and recently the SPR DMA and DMC DMA test.

Is this correct?

[cpow]

Code: Select all

- decrement S three times, but nothing is written to the stack (3 cycles);

This actually *does* cause memory cycles to occur, so you need to account for three READ cycles [the stack writes occur but the write signal is not asserted].

Reference: http://www.pagetable.com/?p=410 [about half-way down the section titled RESET is *very* descriptive].

[Zepper]

This actually *does* cause memory cycles to occur, so you need to account for three READ cycles [the stack writes occur but the write signal is not asserted].

Reference: http://www.pagetable.com/?p=410 [about half-way down the section titled RESET is *very* descriptive].

Such dummy reads aren't really required for emulation, like those other cases. I just clock the PPU in each cycle, anyway.

If the RESET isn't time-critical, why is this making difference for the reset_timing.nes APU test?

[cpow]

Such dummy reads aren't really required for emulation, like those other cases. I just clock the PPU in each cycle, anyway.

If the RESET isn't time-critical, why is this making difference for the reset_timing.nes APU test?

I guess I wasn't clear...since a CPU cycle occurs, an APU cycle also occurs. From that perspective, it is time-critical, or you will fail the test as you are so doing. Thanks, though, you pointed out an omission in my emulator; I was not emulating the first two instruction fetch cycles of the RESET.

It is very much like the other cases, don't be dismissive. The memory cycle *does* occur, the CPU does a READ instead of a WRITE when going through the BRK/IRQ/NMI/RESET cycles. The evidence for what I am saying is all in the page I referenced.

Did you read the page I referenced, or just hurry back with a reply to force me to say RTFM?

[Zepper]

I guess I wasn't clear...since a CPU cycle occurs, an APU cycle also occurs.

Heh, I wasn't clear. The APU is clocked right before clocking the PPU in my emulator; so, when I said about "clocking the PPU", I forgot to say such detail, sorry. In other words, yes, the APU is being clocked.

Yup, of course I read that page.

Well, regarding the dummy read, I'm giving an example: STA $4000,X (X=15) will do a dummy read at $4015. Now, for a stack read, it wouldn't imply any kind of change, *as far as I know*, of course.

[cpow]

Well, regarding the dummy read, I'm giving an example: STA $4000,X (X=15) will do a dummy read at $4015. Now, for a stack read, it wouldn't imply any kind of change, *as far as I know*, of course.

You mean $4000?

But, is the CPU also being clocked along with the APU? What CPU cycle after reset do you do the fetch of the first executed opcode?

[Zepper]

You mean $4000?

Nope. It's a dummy read at $4015.

But, is the CPU also being clocked along with the APU?

Every read or write means a CPU clock. Personally, I don't use any kind of cycle counter for the CPU; only for APU and PPU. So, the quick answer is yes.

What CPU cycle after reset do you do the fetch the first executed opcode?

The first one, right after fetching the high byte of PC.

[cpow]

You mean $4000?

Nope. It's a dummy read at $4015.

Right, my mistake, I was thinking of the high-byte update which doesn't happen until the next cycle but is irrelevant in this case because there is no high-byte update required.

What CPU cycle after reset do you do the fetch the first executed opcode?

The first one, right after fetching the high byte of PC.

Be more specific...note how in the page I referenced the fetch of the first instruction is on CPU cycle 8. If I vary this by a cycle or two my results on the test ROM in question vary by an equivalent number of cycles.

[Zepper]

Be more specific...note how in the page I referenced the fetch of the first instruction is on CPU cycle 8. If I vary this by a cycle or two my results on the test ROM in question vary by an equivalent number of cycles.

I already did a pseudo diagram of my RESET; the first instruction fetch occurs at cycle #8, where #0~7 is RESET.

EDIT: wait a minute. Looks like you're right, I'm doing 0~6 cycles, not 0~7, but I'm quite confused about the first 3 cycles. Does this match the NES CPU?

EDIT 2: my final word. Unless someone else confirms that diagram, I'm ignoring it and accepting this one as "the most correct" for NES emulation. I wonder why nobody else is interested here lately...

[cpow]

EDIT 2: my final word. Unless someone else confirms that diagram, I'm ignoring it and accepting this one as "the most correct" for NES emulation. I wonder why nobody else is interested here lately...

Sorry...somehow I missed all these edits.

So...you're going to trust a document written in 1994 that says:

Code: Select all

RESET does not push program counter on stack, and it lasts
probably 6 cycles after deactivating the signal. Like NMI, RESET
preserves all registers except PC.

<shudder>PROBABLY</shudder>

Versus a document written on 9/29/2010 and based on the Visual6502 model, arguably the most accurate CPU simulation ever done?

It even states:

Code: Select all

The following trace was created with the transistor data from the Visual 6502 project and shows the first nine cycles after letting go of RESET:

Much more believable, in my opinion, than PROBABLY.

[Zepper]

I couldn't find a more descriptive document regarding each instruction, cycle by cycle. All my 6502 emu was based in this document.

[HJRodrigo]

A bit OT, but I think you both you guys rock. I love the dedication you show to your emulators. I used to use RocknesX as my sole NES emulator till it was discontinued, then I used Rocknes, but then I had to switch to Nestopia when my new computer couldn't use it .

Of course I am also eagerly/patiently awaiting for NESICIDE to be mature for mainstream use. That has to be one of the most ambitious NES projects I have ever heard of. I wish both of you well in your endeavors .