FS304 is the same mapper as Mapper162, although it appears to be an earlier attempt at implementing it, with it being less complete than Mapper162 (and not even having savestate code implemented). It even having the same UNIF mapper string used seems to also make it so there's some "randomness" in terms of which class gets used for a UNIF ROM of this mapper (in my experience, 2.10 resulted in Mapper162 being used, while my own dev builds resulted in FS304 being used). UNIF configuration from FS304 is needed for it to be functional in Mapper162 however, so that was ported over.
This is more just to reject more ROMs that quickerNES cannot run (as it runs under simple iNES assumptions and can't handle complicated cases)
Also resolves#4402 (quickerNES won't be accepting any NES 2.0 ROM indicating it needs PAL or Dendy timing)
iNES v1 doesn't have any way reliable way to detect the region. While there are bits for such, they were added late to the spec and thus no ROM bothers to set them. The only reliable way to detect the region with iNES (outside of gamedb) is to use iNES v2's region indicator.
Commit also fixes up the region detection for the case of Dendy (which later iNES v2 gives a bit for)
See #4402, doesn't completely fix it as quickerNES is still accepting the ROM (it doesn't support PAL, so it should be rejecting it outright)
This takes a more sledgehammer approach, as it seems even tiny minor difference in the NAND structure can cause sync issues. This is even the case if the entire directory tree and every file is identical (I guess order of files internally matters here or whatever). The entire partition will be recreated here with files manually readded as to minimize NAND differences (assuming system files are the same version anyways)
This reverts commit 83098604fa.
Caused EmuHawk to hang after some minutes of running emulation, on
Ubuntu (Mono 6.8.0.105) and I think NixOS (Mono 6.12.0.182).
The value will now be passed to the frontend for read callbacks and both read and write callbacks' values can now be changed in the callback.
execute would probably be possible but would require some additional code changes which I'm not sure about
- closes#4394
I assume this was meant as a sanity check expecting it to never be hit. Well, turns out if you break games hard enough this does get hit, so just remove it.
YoshiRulz