nesdev.org

Pennywise wrote:I checked PAL emulation in FCEUX and the game runs fine aside from a slowdown.

Err... I was asking you to test the game on PAL mode on the emulators where it doesn't work, not the one where it works. I should have made this clear.

Apart from the slowdown (which is caused by the fact that PAL video has 50 frames/sec while NTSC has 60), other things might screw up, such as the pitch of the music and raster effects, all because of the different CPU/PPU frequencies. If the text looks right though, that's proof that VRAM writes are extending past VBlank time in NTSC mode, since the vertical blank is much shorter in NTSC.

As an alternative to trying PAL you could also try disabling the PPU before your code runs, and restoring it after. If the problem is that you're over, you'll black out part of the top of the screen, but at least the text should show up.

Switching PAL on Nestopia does not stop the text from glitching. Not sure how to disable the PPU on Nestopia though.

He means in code.

I don't think the problem is with the PPU though. The names are stored separately and are triggered in the text with a control code. So it should just pass by the DTE checks and continue on normally. The problem is probably that I altered the code that changes the text offsets in RAM. I should probably rework it and see if it fixes the problem.

I doubt it myself, HIGHLY. Think about it, that's just a code backend. Why would emulators have CODE run differently? Plus, there's letters in the right place on the trashed version too. It's bad PPU writes. I know it. FCEUX does emulate those and I've seen it, but something weird is going on deeper than that.

Emulators initialize ram differently.

If nothing is different on PAL, I bet on RAM initialization too. How are you initializing $07F0?

EDIT: I just checked, and it seems that both FCEUX and Nintendulator initialize $07F0 to $00, while Nestopia sets it to $ff. So yeah, this is looking like the programmer forgot to initialize the variable and is relying on a startup value of $00.

Yeah, that's the problem alright. I'm not initializing it all and just assuming it's automatically $00 when I load it. I guess was supposed to never assume it was already initialized and to initialize myself, but well that little fact slipped past me when I was learning this stuff on my own.

Well, you'll have to initialize it for it to function correctly on hardware. Real SRAM is essentially random on a cold boot and keeps the old value (probably) on a warm boot.