Ensuring I don't violate constraints of a mapper subset

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Ensuring I don't violate constraints of a mapper subset

Post by tepples »

I'm developing a game for a subset of the MMC3 that fits on a particular CPLD. I'm trying to ensure that the game doesn't accidentally do anything that the subset can't handle. Is there a way to tell any stable NES emulator to log or stop if any of the following inadvertently occur?
  • Writes to $8000 with a value greater than 7, no matter from which register the write came
  • Writes to $8001 with bit 4 = 1 while $8000 is 0 or 1
  • Writes to $8001 with bit 4 = 0 while $8000 is 2, 3, 4, or 5
The answer to "Then just don't do that!" is "We did not budget for formal verification."

Or would it be better to modify an emulator's source code to support the subset directly?
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Ensuring I don't violate subset constraints

Post by thefox »

Lua scripting in FCEUX should be able to handle that.

Modifying the emulator source code shouldn't be too hard, either.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Ensuring I don't violate subset constraints

Post by Memblers »

If you wanted to go NES-code-only, you could track it in your code (and I suppose remove the checks when you're done testing). Since mapper registers generally aren't readable I like to keep a shadow copy in RAM. If you did that, you could use a macro or subroutine for all mapper writes and check for whatever conditions you want by reading those shadow copies. Though I guess that solution falls apart if your code timing is so tight that adding anything will completely break everything.
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: Ensuring I don't violate constraints of a mapper subset

Post by Myask »

Don't forget to set a breakpoint on writes $8002-9FFF to trap possible unintended writes to these as well.

Curious how this is credited.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Ensuring I don't violate constraints of a mapper subset

Post by Dwedit »

Is this like DxROM (mapper 206), or does it have more features/bits?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Ensuring I don't violate constraints of a mapper subset

Post by tepples »

It's sort of like mapper 206 (Namco 108/Tengen MIMIC-1) in lacking mirroring, WRAM, and CP bits, and having a reduced CHR capacity. It's also sort of like 88 in that PPU $0xxx (BG) is always the first half of CHR and PPU $1xxx (sprites) is always the second half. But it has the full MMC3 PIT at $C000-$E001 because levels use lots of parallax splits.

Mapper 88: 128K PRG, 128K CHR (CHR A16 = PPU A12)
Mapper 4: 512K PRG, 256K CHR (all bits switchable), CP, variable mirroring, WRAM, PIT
Our MMC3 subset: 512K PRG, 32K CHR (CHR A14 = PPU A12), PIT
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: Ensuring I don't violate constraints of a mapper subset

Post by Myask »

"PIT" = programmable interrupt timer, I expect, but "CP bits"?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Ensuring I don't violate constraints of a mapper subset

Post by lidnariq »

The "CP bits" are [$8000] & $C0 , using the terminology from the wiki (and meaning "Chr" and "Prg" reordering)
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: Ensuring I don't violate constraints of a mapper subset

Post by Myask »

…Banking modes.
Post Reply