nesdev.org

though not archiving game music, http://www.2a03.org is a nice nsf site (maybe it can be linked to from the main page ? )

That's the WRAM protection bit, I don't think many games use it.

Kamen Rider Club (J): - disables nmi, reads 0x2002.7 (set at boot) - reads 0x2002.7 again (set at vblank) - initialize (banking and such) - while still in vblank: cpu prgbank3read ad: ef51(f51) data: a9 cpu prgbank3read ad: ef52(f52) data: c a9 LDA Immediate PC:ef51 A:c X:ff Y:f P:001B0100 ad:ef52 c...

Does the sprite address (0x2003) change during rendering like the bg address (0x2006) ? I'm currently simply reading sprites from address 0 and up, that doesn't seem to cause problems, except for Akira (J). It locks up because it uses the sprite zero bit for its splitscreen effect. If I hack in a sp...

blargg wrote:Reads of $2007 before 29657 put $00 into the internal buffer; at that time and after reads worked normally.

Kamen Rider Club (J) doesn't like that (locks up).

I've not encountered any problems yet with the NMI delay, or with 0x2002.7 being set at boot.

At power-up, the VBL flag ($2002.7) was set on each of several test runs. On reset, the VBL flag was usually clear. It was next set and readable by the CPU 27386 clocks later (sometimes one clock earlier). This fixes Ironsword/Cobra Triangle, while not causing extra problems (eg. Downtown Special, ...

Problem solved. On powerup, I started at the dummy scanline right after vblank. Starting at vblank instead, fixed this frame IRQ bug. As I kinda suspected, this broke some other games (ppu statusregister being 0x80 on boot). Could it be something undocumented is happening ? Like the pending frame I...

APU emulation without actual sound output is not hard to get running. I think the wiki ( http://nesdev.com/wiki/?page=nesdevWiki )covers it well, plus blargg's new information a few threads back (thanks blargg). The problem historic hap above you is blabbing about will be fixed with DMC implementati...

Thanks. Silly question: in your explanation, is the 1st cycle cycle 1 (1..341) or cycle 0 (0..340) ?

Interesting. But too bad for Stars SE: (pending frame IRQ) ... CLI LDA Immediate 0x07 something1 something2 something3 irq: RTI this translates as: CLI LDA.. RTI, RTI, RTI, RTI, etc. while this would fix Stars SE: CLI LDA.. RTI something1 RTI something2 RTI, etc. (Yeah, I know, kind of dumb to use S...

Problem solved. On powerup, I started at the dummy scanline right after vblank. Starting at vblank instead, fixed this frame IRQ bug. Something I thought of while searching for the cause of this bug: If an IRQ is pending, and you do a CLI, or PLP or RTI that clears the 'I' flag, does the IRQ happen ...

Perhaps you have addressing modes mixed up in one or more opcodes.

Not counting illegal opcodes, 0x19, 0x39, 0x59, 0x79, 0x99, 0xb9, 0xbe, 0xd9, 0xf9 use the absY addressing mode.

RAM set to 0 or 0xff has no effect on it (I have it set to 0xff). I saw wrong, my debugger is kind of confusing: the PLP gets 0x90, not 0 (the 0x90 is from a PHA a few instructions earlier, stupid game bug I guess). I'm almost certain the clearing of the 'I' flag is correct behaviour, and I've got a...

Yes, the frame IRQ happened when 0x4017 was 0 (1 frame after powerup). The IRQ line stays hot until it's acknowledged, right ? eg.: - pending frame irq and pending mapper irq - acknowledge mapper irq - don't acknowledge frame irq - rti - pending frame irq again (loop) Writing 0x80 to 0x4017 won't ac...

I'm having a bit of trouble getting Ironsword (W&W2) and Cobra Triangle to run with frame IRQs enabled on boot. At boot, after 1 frame, the frame IRQ line is set, then it writes 0 to the frame sequencer, and one frame later, it writes 0x80 to it. It never acknowledges the frame IRQ. Ironsword lo...