Hack working on FCEUX, but not on Nestopia/real console

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
tokumaru
Posts: 12106
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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.
User avatar
rainwarrior
Posts: 8062
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Post by rainwarrior »

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.
Pennywise
Posts: 70
Joined: Tue Jul 14, 2009 11:04 am

Post by Pennywise »

Switching PAL on Nestopia does not stop the text from glitching. Not sure how to disable the PPU on Nestopia though.
3gengames
Formerly 65024U
Posts: 2281
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

He means in code.
Pennywise
Posts: 70
Joined: Tue Jul 14, 2009 11:04 am

Post by Pennywise »

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.
3gengames
Formerly 65024U
Posts: 2281
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

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.
User avatar
Dwedit
Posts: 4470
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit »

Emulators initialize ram differently.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
tokumaru
Posts: 12106
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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.
Pennywise
Posts: 70
Joined: Tue Jul 14, 2009 11:04 am

Post by Pennywise »

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.
Karatorian
Posts: 76
Joined: Sun Sep 30, 2007 9:54 pm
Location: Corneria
Contact:

Post by Karatorian »

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.
Post Reply