TASEmulators / BizHawk

BizHawk is a multi-system emulator written in C#. BizHawk provides nice features for casual gamers such as full screen, and joypad support in addition to full rerecording and debugging tools for all system cores.
http://tasvideos.org/BizHawk.html
Other
2.2k stars 385 forks source link

NESHawk: Famicom Jump 2 doesn't work until 2nd boot (same on fceux; is it normal?) #2139

Closed Yave-Yu closed 3 years ago

Yave-Yu commented 4 years ago

Couldn't run Famicom Jump II: Saikyou no 7 Nin with NesHawk core. (ROM in GoodNES 3.23b pack) BizHawkGreenScreen

Spikestuff commented 4 years ago

Can't replicate (Hawk 2.4.2): image

I guess make sure you're using the NESHawk core? Config > Cores > NES > NESHawk

RetroEdit commented 4 years ago

I can replicate. I tried it on every NES emulator on my hard drive with similar results. Weird.

Specifically, I tried BizHawk with NesHawk (of course), fceux 2.2.3, higan v106, and Mesen 0.9.9. Dark green screens for BizHawk and Mesen, and grey screens for fceux and higan. Nope, I'm mistaken; I retested and found a flaw with my previous testing methodology. BizHawk and Higan still have problems.

I guess make sure you're using the NesHawk core?

I mean, it shows NesHawk in the screenshot...

No actually, it just works now after explicitly selecting NesHawk as the core, even though that was already selected... definitely reproduced when I first tested, and it wasn't paused or anything like that. So I guess the preexisting configuration had problems, but toggling magically fixed them going forward?

RetroEdit commented 4 years ago

Intriguing; it looks like something's wonky with BizHawk's core selection. Although the emulator claims to be running with NesHawk, maybe it's not actually unless you select it? I just did a clean extraction of BizHawk 2.4.2, and same issue. (The issue is permanently fixed by selecting an NES core; presumably that applies some change to the configuration file that prompts BizHawk to actually validate cores properly).

And look at this:

QuickNES vs  NesHawk

The general UI presents NesHawk, but the menu selection shows QuickNES. From that, I think it's not properly applying core overrides with the default BizHawk configuration.

I have yet to test dev builds.

Yave-Yu commented 4 years ago

I'm sure it using NesHawk core, I never change it to terrible QuickNES core. Weird thing: non-good dump (without [!]) of this game could run well. BizHawkOneMoreScreenshot

RetroEdit commented 4 years ago

Have you retested with the good dump? The emulator needed a bit of prodding from me to select the right core, but after I selected it, the game worked fine.

Yave-Yu commented 4 years ago

Yes, it works fine with good dump, just click "Config - Cores - NES - NesHawk" one time.

zeromus commented 4 years ago

This game crashes (JAM opcode, $42?) when it first boots. Any time after the first boot, it will work correctly (due to an "initialized" state flag in the battery ram?). The emulator core selection is a red herring; it has nothing to do with this. You can set neshawk, then DELETE the saveram, and boot the game again and it will freeze one more time. The same thing happens in fceux.

Other possibilities

  1. The game is confused by our initial (all zero, probably) save ram contents. We have a crude system for specifying initial ram contents (see "Silva Saga" in the sources) so we could consider adding it -- IF we can prove different initial contents values fixes the game. I wasn't able to immediately prove it though (the 1st difference in execution was reading $6BBC but I tried changing the value of BBC at startup and saw no behavioural difference)
  2. This is the way the game is supposed to work.
  3. The game is confused by something else
  4. The game is broken due to a bug (most likely, the mapper?) and after you play it for a few minutes it will fall apart.

If anyone finds out more lore about this, they're welcome to write about it here. I'll leave it open til someone finds out more one way or the other

alyosha-tas commented 3 years ago

This does appear to be the same problem as silva saga (interpretting zeros as bad save data.) It looks like it 'loads' the save but then jumps to SRAM for execution but it has the wrong values so crashes.

Starting everything at 0xFF seems to work fine.