List of games not working in NESHawk

[alyosha-tas]

3-D Block (Asia) (Hwang Shinwei) (Unl)
Chinese KungFu (Asia) (Unl)
Chuugoku Taitei (Asia) (Unl) - Black Screen
AV Soccer (Japan) (Unl)

Super Mario Bros. 25 Shuunen Version (Japan) (En) (Promo, Virtual Console)
Mahjong (Japan)
Miracle Piano Teaching System, The (Germany)

AV Soccer (Hacker)
Olympic IQ (Sachen) [U][!]
Poker II (Sachen) [U][!]
Strategist (With Intro) (Sachen) [U][!]
Tasac (Sachen) [U][!] - 1
Ultimate Air Combat (E) (Beta) (M3)
Ninja Jajamaru - Ginga Daisakusen (J) (Beta)
Crystalis (U) (Prototype) - not sure
Playbox BASIC (Prototype V0.0) [!]

Licensed ones:

Dragon Quest II - Akuryou no Kamigami (J-VC)
Dragon Quest III - Soshite Densetsu e... (J-VC) (PRG1)
Gradius II (J) (VC) - Grey Screen
Kage no Densetsu (J) (VC)
Street Gangs (E) (VC)
Captain Skyhawk (1989)(Rare)(PlayChoice-10) - Tosec
Mario's Open Golf (1991)(Nintendo)(PlayChoice-10) - Tosec

pirate boards / mappers:

iNES # 124 (Super Game Mega Type 3 Pirate arcade board)
https://www.youtube.com/watch?v=re9O388mtJU
http://blog.kevtris.org/blogfiles/Super%20Game%20Mega%20Type%20III.rar

[ThunderAxe31]

Add these games to the list: http://tasvideos.org/ThunderAxe31/NesPokemonBackports.html

Some freeze when starting a new game, some others don't start at all.

[alyosha-tas]

removing aladdin games since they seem to work.

@ThunderAxe31 I randomly tried pokemon gold (SHA1: 981B0D9112FD870407E4657CA98BB884C88CFF53) and it worked fine (with some graphics glitches.) So maybe not all of them are bad.

[ThunderAxe31]

I forgot to mention that some games can't save, including the one you tried. However, I'm not sure if they are supposed to have actual SRAM functionalities (you can expect anything with bootlegs). I'll come back after doing some more researches.

For now I can tell you in which games you can't start a new game. Some freeze right when you press "new game", others give corrupted graphics and freeze after the intro dialogue is completed. The following are all different games, so emulation should be fixed and confirmed for every one of them. I only included good dumps here:

     File: Pokemon Platinum Alt title 2 (KT-008 PCB)(Ch)[!].nes
           Pokemon Platinum (Jncota) (KT-1070) (Ch).nes
           口袋怪兽 - 白金版 [晶科泰].nes
    SHA-1: 84e90f711e9082d612b3abb00130738003ce2f00

     File: Pokemon Platinum Alt title 1 (KT-008 PCB)(Ch)[!].nes
           Pokemon Pearl (Jncota) (KT-1071) (Ch).nes
           口袋怪兽 - 珍珠版 [晶科泰].nes
    SHA-1: 0e07154265d01d3a3338d5a04041109ad21f546a

     File: Pokemon Platinum (KT-008 PCB)(Ch)[!].nes
           Pokemon Diamond (Jncota) (KT-1072) (Ch).nes
           口袋怪兽 - 钻石版 [晶科泰].nes
    SHA-1: 14f2ee5e646c288308f8a05d17eaf93378738d62

     File: Pokemon HeartGold (KT-008 PCB)(Ch)[!].nes
           Pokemon Crystal (Jncota) (Ch).nes
    SHA-1: 8d07f249f4f52bf27d5055a1fa1e9769e4180a5c

     File: Kou Dai Guai Shou - Fei Cui Ban (C) [KT-1063].nes
           Pokemon Emerald (Jncota) (KT-1063) (Ch).nes
    SHA-1: 4d3bd5997f50678e20d3473724495964e21faf4a

     File: Pokemon - White Jade Version (China) (Unl) [CHS](0834).nes
           Pokemon White Jade (Jncota) (KT-1065) (Ch).nes
    SHA-1: 1c748bdbecae572168e40ab515f1489ec84f24b6

[alyosha-tas]

So it looks like at least some of those hacks are using an mmc3 variant with a register at 0x5000 that swaps out 512 kB banks.

@ThunderAxe31 can you post the headerless SHA1 hashes for the ones that don't work so I can make DB entries for them? (NESHawk gives this on rom load if you open the log window.) Finding these hacks seems to be rather tedious. I don't see an existing mapper that matches this description so I'll put one together and put all these in there and hope for the best.

[ThunderAxe31]

corrupted graphics when starting a new game, crash after finishing the intro dialogue:

     File: Pokemon Platinum Alt title 2 (KT-008 PCB)(Ch)[!].nes
           Pokemon Platinum (Jncota) (KT-1070) (Ch).nes
           口袋怪兽 - 白金版 [晶科泰].nes
headerless rom hash: SHA1:CA7F528C5AD73596961CFCE30194592FDBCF4505

corrupted graphics when starting a new game, crash after finishing the intro dialogue:

     File: Pokemon Platinum Alt title 1 (KT-008 PCB)(Ch)[!].nes
           Pokemon Pearl (Jncota) (KT-1071) (Ch).nes
           口袋怪兽 - 珍珠版 [晶科泰].nes
headerless rom hash: SHA1:6668AF3F57BB776629AB512E87C202614ABF41CA

crashes when starting a new game:

     File: Pokemon Platinum (KT-008 PCB)(Ch)[!].nes
           Pokemon Diamond (Jncota) (KT-1072) (Ch).nes
           口袋怪兽 - 钻石版 [晶科泰].nes
headerless rom hash: SHA1:5010EA0CD5E94B9E2F13A9C1E03AF66FFBD09832

corrupted graphics when starting a new game, crash after finishing the intro dialogue:

     File: Pokemon HeartGold (KT-008 PCB)(Ch)[!].nes
           Pokemon Crystal (Jncota) (Ch).nes
headerless rom hash: SHA1:B11D65F508AD5E72274F049F6DDAEFC6188250FC

corrupted graphics when starting a new game, crash after finishing the intro dialogue:

     File: Kou Dai Guai Shou - Fei Cui Ban (C) [KT-1063].nes
           Pokemon Emerald (Jncota) (KT-1063) (Ch).nes
headerless rom hash: SHA1:EB97C94DDA0EC647418B05C4E2CAB61CA0AF0380

crashes when starting a new game:

     File: Pokemon - White Jade Version (China) (Unl) [CHS](0834).nes
           Pokemon White Jade (Jncota) (KT-1065) (Ch).nes
headerless rom hash: SHA1:82323E1CD27EC434843AA1B44E3D89A09860F430

[alyosha-tas]

Ok I added a new mapper variant for these. I didn't check all of them but it definitely at least fixes KT-1063. Please check the others.

[ThunderAxe31]

They work now, however they don't save/load, every one of them. That is, I tried saving the game with the relative in-game feature, then used the hard-reset command, but then the games behaved like if there was never saved any game file. Also, there is no "Battery RAM" memory domain in the Hex Editor, I wonder if that's why.

[alyosha-tas]

OK i added SRAM to those. Let me know if any others need it too (with the headerless ROM hash for the db)

[ThunderAxe31]

Thank you, I will tell you later which ones still need it.

By the way, why don't you make BizHawk being made able to figure out on its own if a NES game uses this mapper? FCEUX can do that just fine with both recognizing the mapper and recognizing the presence of battery RAM, even for games that where made years after that FCEUX 2.2.3 was released. So why relying on hacks for BizHawk? Just so you know, we're not talking about few games, there are more than 70 different titles using this mapper (maybe more): https://bootleggames.fandom.com/wiki/Shenzhen_Jncota_Technology_Co.,_Ltd.

[alyosha-tas]

The ines header that comes with the games (first 16 bytes of the file) send them to mapper 4, generic MMC3. This mapper doesn't have a register at 0x5000, which these games use. Presumably FCEUX has a heuristic of what to do if a games does this unexpectedly. I'd rather just send them to their own mapper. And all of that aside, there is only so much effort I'm willing to put into chinese bootleg pokemon games.

[ThunderAxe31]

Ok, here is the next game.

Pokemon Gold (Mars) (Ch) [!].nes
Pokemon Gold (Unl) [!].nes
headerless rom hash: SHA1:51ADF18C682111902B91BF8F3B18E9AADF418D48

The issue is that it doesn't save the game. In order to save, you have to reach the next town, enter the Pokemon center, use the PC in the top right, pick the second-last option, confirm. It will take about 10 seconds to save the game, as denoted by the lag frames. Then, the game is supposed to be load from the title screen, by picking the second option, however the game does start a new game instead, as it doesn't find the save file.
Someone on Discord said that this game saves to EEPROM, wich only NintendulatorNRS and libretro-fceumm in recent builds emulate properly.

Oh and by the way, I noticed you named the chip as MMC3_Pokemon, but that's not much indicative as most games with that chip aren't Pokemon. I think something like MMC3_Jncota should work better, in order to avoid confusion.

[alyosha-tas]

Well, I'm not going to put together a whole EEPROM just for that, so that will need a PR I guess or someone else taking an interest.

Good point on naming though, re-named.

[ThunderAxe31]

All right, I'll ask to someone else then.

Here is the last Pokémon backport that needs to be fixed:

Kou Dai Bao Shi - Lan (NJ001) (Ch).nes
Pokemon Sapphire (NJ001) (Ch).nes
headerless rom hash: SHA1:EE4F0F0E38F54D173C7202A3F0E917438FDC19ED

The only issue I found is that the graphics are corrupted during the intro dialogue right after starting a new game. It works on FCEUX. It doesn't use the MMC3_Jncota chip, as it was produced by a different company.

By the way, I'm trying to add the CoreForce setting to the gamedb_nes.txt but it's not working, no matter what I do. Am I missing something or is this functionality broken?

[alyosha-tas]

Fixed that game. Haven't had a chance to look at CoreForce yet.

[ThunderAxe31]

White Jade still doesn't work. The screen gets all gray when you start a new game.

     File: Pokemon - White Jade Version (China) (Unl) [CHS](0834).nes
           Pokemon White Jade (Jncota) (KT-1065) (Ch).nes
headerless rom hash: SHA1:82323E1CD27EC434843AA1B44E3D89A09860F430

[alyosha-tas]

I don't see that hash associated with that game. I see this one:

Sha1:4E8FF0F79199D721175D5774267C9221346555EB

With this hash in the DB and using the Jncota mapper, the game works. Is this correct?

[ThunderAxe31]

Yes, it's correct. It's working now.

But I'm still unable to set the CoreForce setting in the DB. Does it even work?

[alyosha-tas]

I don't think that flag has any effect. There is no code for it in EmuHawk.

[ThunderAxe31]

All right then, I've opened a specific issue for that: #3131

All right, here comes my very last request: implementing the Waixing mapper. First off, here is a sum up of the problem, explained by Taizou, the person who decrypted those games:

(Incidentally these encrypted roms also have their own header format, I havent figured it out exactly but it is at least somewhat based on iNES - it has PRG and CHR sizes in the same place for example. instead of "NES" it starts with "mfc", and I have found old listings for a PSP-lookalike MP4 player which claims to play "MFC" games among others, so maybe this format has been used elsewhere at some point?)
anyway I wrote a program to decrypt them and i've now decrypted all 198 of the damn things. only 43 of those games will run in emulators as is - some are normal NES games, some are VT03 so theyre in EmuVT .bin format.
As for the remainder, there are basically two different problems that occur with them - some don't display the proper graphics, they seem to be failing to switch banks when they should (and this applies for VT03 too). Others don't run at all, especially the larger RPG games. I'm not sure if these are mapper issues or if there's something wrong with the way I'm decrypting them, or the Subor console's emulator does something unusual, or what. in the case of the VT03 games it's quite likely that I'm not converting them to .bin format properly though.

And here is an example of a Waixing game that is not currently emulated by anything, despite being a relatively good game (it's the game that inspired the Lawn Mower homebrew game for NES):

  File: lawn purge.wxn.nes
CRC-32: e9c9bbd3
   MD4: 9bc194cbf6016a114fc39c9aadf71a3e
   MD5: e7253541023df3f1c3ffb1a643eb5a17
 SHA-1: 2cfd6f707e44f15b0bf482b6c856b20cfe122969

headerless rom hash: SHA1:A692739112F07643FC35A43B2F6330A9067917B5
headerless rom hash:  MD5:34068247246E7AE663128BB06092962C

[YoshiRulz]

The headerless checksums @ThunderAxe31 gave are actually for the roms with the last 16 octets removed, instead of the first 16.
SHA1:B11D65F508AD5E72274F049F6DDAEFC6188250FC should be SHA1:6545611C3704B8624343F4BDAB7C1096523A1AC9, and SHA1:EB97C94DDA0EC647418B05C4E2CAB61CA0AF0380 should be SHA1:8E783D45D05E4A30DB3355D8AD1AE4A2F5385530.

Initially reported on Discord by @jatedec.

[YoshiRulz]

As per this movie's submission notes, level 4 of Action 52's second game, Star Evil, is inaccessible: the screen turns a solid magenta and the music doesn't play correctly. (Idling for a while on the magenta screen leads to a crash, which I have a fix for.)

[YoshiRulz]

Magic Floor https://problemkaputt.de/magicflr.htm
Both NES variants fail to load in NesHawk with:

System.Exception: unhandled wram size of 8
  at BizHawk.Emulation.Cores.Nintendo.NES.NesBoardBase.Assert (System.Boolean test, System.String comment, System.Object[] args) [0x00010] in <89a76fa0953c4739bc5ced574d6c360d>:0 
  at BizHawk.Emulation.Cores.Nintendo.NES.NesBoardBase.AssertMemType (System.Int32 value, System.String name, System.Int32[] valid) [0x0004e] in <89a76fa0953c4739bc5ced574d6c360d>:0 
  at BizHawk.Emulation.Cores.Nintendo.NES.NesBoardBase.AssertWram (System.Int32[] wram) [0x0000c] in <89a76fa0953c4739bc5ced574d6c360d>:0 
  at BizHawk.Emulation.Cores.Nintendo.NES.Mapper218.Configure (BizHawk.Emulation.Cores.Nintendo.NES.EDetectionOrigin origin) [0x00043] in <89a76fa0953c4739bc5ced574d6c360d>:0 
  at BizHawk.Emulation.Cores.Nintendo.NES.NES.FindBoard (BizHawk.Emulation.Cores.Nintendo.NES.CartInfo cart, BizHawk.Emulation.Cores.Nintendo.NES.EDetectionOrigin origin, System.Collections.Generic.Dictionary`2[TKey,TValue] properties) [0x0006d] in <89a76fa0953c4739bc5ced574d6c360d>:0 
  at BizHawk.Emulation.Cores.Nintendo.NES.NES.Init (BizHawk.Emulation.Common.GameInfo gameInfo, System.Byte[] rom, System.Byte[] fdsbios) [0x008c2] in <89a76fa0953c4739bc5ced574d6c360d>:0 
  at BizHawk.Emulation.Cores.Nintendo.NES.NES..ctor (BizHawk.Emulation.Common.CoreComm comm, BizHawk.Emulation.Common.GameInfo game, System.Byte[] rom, BizHawk.Emulation.Cores.Nintendo.NES.NES+NESSettings settings, BizHawk.Emulation.Cores.Nintendo.NES.NES+NESSyncSettings syncSettings, System.Boolean subframe) [0x001bc] in <89a76fa0953c4739bc5ced574d6c360d>:0 
  at (wrapper managed-to-native) System.Reflection.RuntimeConstructorInfo.InternalInvoke(System.Reflection.RuntimeConstructorInfo,object,object[],System.Exception&)
  at System.Reflection.RuntimeConstructorInfo.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00005] in <65a38edf81fe405bb4fb28e56b25f9d8>:0 
--- End of stack trace from previous location where exception was thrown ---

  at BizHawk.Emulation.Cores.CoreInventory+Core.Create (BizHawk.Emulation.Cores.ICoreInventoryParameters cip) [0x0002a] in <89a76fa0953c4739bc5ced574d6c360d>:0 
  at BizHawk.Client.Common.RomLoader.MakeCoreFromCoreInventory (BizHawk.Client.Common.RomLoader+CoreInventoryParameters cip, System.String forcedCoreName) [0x00102] in <cc05245d692e4d36941cd6feba5c1c79>:0 

(They then crash in quickerNES per #4186.)

[nattthebear]

@YoshiRulz Looks like some heuristics or something gone off the rails. The real board really has no wram. For non-DB roms, I think we guesstimate wram but the iNES format is garbage. I've played the rom in Bizhawk so I know it worked at some point (12 years ago, apparently).

Can we force Cart.WramSize = 0 instead of asserting it?

[YoshiRulz]

It seems there's already a mechanism for that, enabled only in this specific call path:

BizHawk/src/BizHawk.Emulation.Cores/Consoles/Nintendo/NES/NES.cs

Lines 547 to 563 in 8309860

	if (choice == null)
	{
	if (unif != null)
	{
	LoadWriteLine("Using information from UNIF header");
	choice = unif.Cart;
	//ok, i have this Q-Boy rom with no VROM and no VRAM.
	//we also certainly have games with VROM and no VRAM.
	//looks like FCEUX policy is to allocate 8KB of chr ram no matter what UNLESS certain flags are set. but what's the justification for this? please leave a note if you go debugging in it again.
	//well, we know we can't have much of a NES game if there's no VROM unless there's VRAM instead.
	//so if the VRAM isn't set, choose 8 for it.
	//TODO - unif loading code may need to use VROR flag to transform chr_size=8 to vram_size=8 (need example)
	if (choice.ChrSize == 0 && choice.VramSize == 0)
	choice.VramSize = 8;
	//(do we need to suppress this in case theres a CHR rom? probably not. nes board base will use ram if no rom is available)
	origin = EDetectionOrigin.UNIF;
	}

BizHawk/src/BizHawk.Emulation.Cores/Consoles/Nintendo/NES/NES.BoardSystem.cs

Lines 115 to 119 in 8309860

	//unif demands that the boards set themselves up with expected legal values based on the board size
	//except, i guess, for the rom/chr sizes. go figure.
	//so, disable the asserts here
	if (origin == EDetectionOrigin.UNIF)
	board.DisableConfigAsserts = true;