Per MAME and Nocash, we know of six (seven) total games that use the Vs. System's ability to communicate between the two CPUs:
* Balloon Fight ("balonfgt")
* Baseball ("vsbball", "vsbballj", "vsbballja", "vsbballjb")
* Ice Climber ("iceclmrd")
* Mahjong ("vsmahjng")
* Tennis ("vstennis", "vstennisa", "vstennisb")
* Wrecking Crew ("wrecking")
** (
Raid on Bungeling Bay ("bnglngby"))
All of these run directly on the MDS mainboard without extra bankswitching hardware; they're all technically mapper 99. Of these, five are 32K PRG and 16K CHR on each side. Mahjong has 24K PRG and 8K CHR; Raid on Bungeling Bay has 8+32K PRG and 0+16K CHR.
Earlier in this thread, NewRisingSun suggested packing both CPU's PRG and both PPU's CHR into a single file.
This is not quite entirely unambiguous. I am uncomfortable with defining 16K CHR to mean two different things depending on the size of PRG. Additionally, this naive concatenation rule runs into problems between Raid on Bungeling Bay (0+16) and Vs. Mahjong (8+8). Since defining either of these as the "correct" definition only allows a single game to be emulated, and requires that the other be padded up to 32K CHR in the file, I'm inclined to say that
both should require padding CHR, and the 64K PRG+16K CHR configuration shouldn't be allowed in a mapper 99 DualSystem image.
(Vs. Mahjong does not use the CHR bankswitching ability, but it is directly on the MDS mainboard and so is technically mapper 99, not mapper 0. Additionally, I'd like to keep this logic all confined to mapper 99, if practical, rather than defining an alternative behavior in another mapper to handle a single game.)
I'm also a little uncomfortable with having something that looks like an ordinary NES file but suddenly pops up two screens and requires four controllers, but whatever.
As a final worry, mapper 185 was explicitly defined because people didn't like baked-in padding in the corresponding NES images. (All of the games would run if dumped and emulated as 32K CHR CNROM). So defining padding into the encapsulation—at least for the instances where the padding isn't an artifact of the limited precision of the ROM size fields in the header—is directly contrary to the goals that lead to the definition of mapper 185.
Does anyone else have any thoughts on this matter?