They'll be considered internally "DSiWare" for purposes of save management and the movie header (although they aren't technically DSiWare, just system DSi NAND apps)
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.
- closes#4387
Those overloads try to imitate lua's "a.b" parsing by navigating tables recursively, e.g. `table["a.b"]` == `table.a.b`. This is not what's intended by 100% of the use cases of these overloads, so I've removed them.
CasualPokePlayer