Mapper 23: VRC4 rev E/F or VRC2 rev B?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176144)
I have recently implemented a VRC4 mapper. According to some of the documentation I found, this can be made to support mapper 21 via Rev A and C pinout variations, mapper 25 via rev B and D pinout variations, and apparently, mapper 23 via Rev E/F pinout variations (whose existence is disputed). Elsewhere, I have found that Mapper 23 is assigned to VRC2 Rev B (mapper 22 is used for BRC2 Rev A).

So far, ROMs with mapper id 23 that I have tried to run on VRC4 rev E/F do not seem to render the correct CHR tiles in some places. Perhaps it is because the CHR bank index for this case is supposed to ignore bit 0 of the index.

So my question is: how to best tackle mapper 23? My inclination now is to make a VRC2 mapper implementation that supports Rev A and B, assigning them to mappers 22 and 23 respectively (instead of trying to use VRC4 for 23).

Thoughts?
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176159)
colinvella wrote:
Perhaps it is because the CHR bank index for this case is supposed to ignore bit 0 of the index.
I don't know what problem you're having, but this behavior is only mapper 22.

Konami definitely used Variant E; Variant F appears to be for unlicensed games and pirate ports.


I'll point out that the original FCEU 0.98 does not distinguish between VRC2 and VRC4 and it seems to play Contra(J) just fine.
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176162)
Switching to VRC2 Rev B for mapper 23 seems to have worked better. Frankly, unless they are similar enough to keep the implementation of variants in one mapper simple, I rather prefer to have separate implementations. Now I just need to get VRC2 Rev A CHR rom working properly.
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176163)
VRC2 is supposed to be a strict subset of VRC4(when with RAM).

If you are not experiencing that, please provide more specifics about the specific VRC2b games that are not behaving compatibly. It's unkind to expect people to guess blindly as to what exact symptoms you're seeing, and "random CHR tiles are wrong" isn't specific enough.

The only instance where VRC4's upward compatibility doesn't work is due to a bug in Wai Wai World.
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176185)
You're right, I'll try to be a bit more specific, but I think it's best if I present specific examples one at a time, so as not to flood the thread.

For instance, the game Akumajou Special - Boku Dracula-kun (Japan), which uses mapper 23, seems to write to $8FFF and $AFFF in what seems to be an attempt to write to some PRG registers. After this, undocumented instructions get executed, which to me, seems as if an attempt to switch program banks has failed. Is it a case that the mapper should only take into consideration bits 0, 1 and 12-15 when the code attempts writes to the PRG Rom region, and thus always target the register addresses?

Code:
RelBrFCC6:
    $FCC6 $91 $00      STA ($00), Y
    $FCC8 $C8          INY       
    $FCC9 $D0 $FB      BNE $FB     ; branch to RelBrFCC6
RelBrFCC6:
    $FCC6 $91 $00      STA ($00), Y
    $FCC8 $C8          INY       
    $FCC9 $D0 $FB      BNE $FB     ; branch to RelBrFCC6
RelBrFCC6:
    $FCC6 $91 $00      STA ($00), Y
    $FCC8 $C8          INY       
    $FCC9 $D0 $FB      BNE $FB     ; branch to RelBrFCC6
    $FCCB $E6 $01      INC $01   
    $FCCD $E4 $01      CPX $01   
    $FCCF $D0 $F5      BNE $F5     ; branch to RelBrFCC6
    $FCD1 $A2 $0C      LDX #$0C   
    $FCD3 $8E $FF $8F  STX $8FFF 
VRC2: Unknown write of value $0C at address $8FFF
    $FCD6 $E8          INX       
    $FCD7 $8E $FF $AF  STX $AFFF 
VRC2: Unknown write of value $0D at address $AFFF
    $FCDA $20 $0A $9A  JSR $9A0A   ; call subroutine at SubRt9A0A
SubRt9A0A:
    $9A0A $3A          NOPu       
    $9A0B $1F $0C $0C  SLO $0C0C,X
    $9A0E $0F $01 $19  SLO $1901 
    $9A11 $32          KIL       
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176187)
Indeed, masking addresses by $F003 when writing to $8000 and higher seems to have solved the problem. Now I just have to deal with the incorrect CHR tiles, which for some reason are not working well. This is strange since, for instance, Wai Wai World is working fine.

Image
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176189)
colinvella wrote:
the game Akumajou Special - Boku Dracula-kun (Japan), which uses mapper 23, seems to write to $8FFF and $AFFF in what seems to be an attempt to write to some PRG registers.

Akumajou Special is a VRC4e.

It is not an "attempt", because VRC4 has CPUA14-12, /ROMSEL (effectively CPU/A15) and for the e-variant board, CPUA2-3 connected…not A0-1 nor A4-11. So, of the sixteen address bits in 16'h8fff (16'b1000_1111_1111_1111), it only cares about six of them (16'b1000_xxxx_xxxx_11xx), which is the same pattern that 16'h800c is (16'b1000_0000_0000_1100). And, as happens, the 8xxx region is agnostic to the two low address lines, it's all PRG-select-0.

Masking by $F003 for all of mapper 23 will make for other problems, because VRC4e would more-appropriately mask $F00C. (and masking $F00C would probably break the VRC2b, as they're using A1,A0.) So, if it writes the CHR-bank registers 1,3,5,7 ($B-Exx8/C), your mask is instead treating it as a write to CHR-bank registers 0,2,4,6 ($B-Exx0).

Real Solution: use submappers, or in their absence, checksums. (The link above includes those for known games.)

(edited, see bolded section for likely reason why CHR is now misbanked)
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176190)
Thanks for all the guidance guys. So Mapper 23 can be either VRC2 Rev B or VRC4 Rev E, and the "low" address bits of interest may thus be (A0, A1) or (A2, A3). Perhaps, short of resorting to checksums, I can try making the mask less restrictive (say, $F00F) and try to determine which bits in the range A0..A3 are being used, heuristically. I think this might work, if ROMs are well behaved and don't try to do anything funny with the "unused" bits.

I will keep you posted on the results of my experiments.
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176191)
colinvella wrote:
Thanks for all the guidance guys. So Mapper 23 can be either VRC2 Rev B or VRC4 Rev E, and the "low" address bits of interest may thus be (A0, A1) or (A2, A3). Perhaps, short of resorting to checksums, I can try making the mask less restrictive (say, $F00F) and try to determine which bits in the range A0..A3 are being used, heuristically. I think this might work, if ROMs are well behaved and don't try to do anything funny with the "unused" bits.

I will keep you posted on the results of my experiments.

An alternate solution (though I don't know where each game writes, so it might create problems!) would be to OR the two possible bits for each line together (so that a write to $9008 (expected on VRC4e)) works the same as a write to $9002 (expected on VRC2b)). But you'd want to be careful, as it means a game expecting VRC2b writing to 9ffc(=9000) would be getting what it would think is at 9fff (=9003).

I expect the wiring variations are anti-piracy; you might trip any of the numerous Konami anti-piracy checks in the games with however you handle it.
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176192)
My heuristic solution for determining the low bits seems to have worked, at least to the point where both Wai Wai World and Boku Dracula-kun show the correct tiles.

Obviously, because I am now trying to cater for VRC4 Rev 3 in my VRC2 mapper, I will need to add the IRQ counter - it seems that Boku uses this to split the screen in order to show a static game hud. I may have to reconsider whether to treat mapper 23 as a VRC4 mapper implementation variant or keep going this route.

Thanks for your help once again!
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176199)
With some class refactoring, I got the IRQ functionality working in both VRC2 and VRC4 mappers.

This is Boku Dracula-kun:
Image

One remaining mystery now is the title screen in Twinbee 3, which runs on VRC2 Rev A (mapper 22). Only the title screen is garbled - the game itself seems to render just fine.

Twinbee 3 Title Screen
Image
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176207)
Solved.

And once again it was all due to a stupid bug on my part. I was essentially modulating the character bank pages by the ROM's character bank count (a habitual precaution to ensure that out of range CHR bank numbers wrap around) and forgot to take into consideration that for Rev A, all bank registers are shifted to the left. I was thus corrupting the bank numbers for higher pages (which, incidentally are used by Twinbee 3's title screen).

I'n not aware of other games that use mapper 22, so I cannot really test this extensively, but it looks like my VRC2 mapper is now working correctly.
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176237)
We know of two games that used the A wiring variant of the VRC2: TwinBee 3, and Ganbare Pennant Race!
Similarly, we know of four games that used the E wiring variant of the VRC4: Tiny Toon Adventures, Akumajou Special, Parodius Da, and Crisis Force.


The reason multiple differently wired mappers were assigned to the same board was that, if the games are well-behaved, just conflating the address lines works.

Unfortunately, some games aren't well-behaved.
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176313)
lidnariq wrote:
We know of two games that used the A wiring variant of the VRC2: TwinBee 3, and Ganbare Pennant Race!
Similarly, we know of four games that used the E wiring variant of the VRC4: Tiny Toon Adventures, Akumajou Special, Parodius Da, and Crisis Force.

Unfortunately, some games aren't well-behaved.


I have tested the games you suggested.

Ganbare Pennant Race, Akumajou Special (Boku Dracula-kun) and Crisis Force seem to work fine.

Tine Toon Adentures (USA) and (Europe) both crash with a KIL instruction - however the ROMS I found have a mapper ID 4 (MMC3) assigned to them so perhaps they are badly mapped. My CRC32-driven NST databsse lookup doesn't alter this mapper ID either

Parodio Da almost works. The title screen looks fine but the scrolling level tiles are garbled for some reason. It could be that my bit selection heuristics are not working well in this case.
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176330)
Tiny Toon Adventures(J) is VRC4.
Tiny Toon Adventures(everyone else) is MMC3, because of Nintendo's CIC and licensing requirements.

This is also why Castlevania 3 is on MMC5(everyone else) instead of VRC6(J), even though it doesn't really use hardly any of the MMC5 features.


... seriously, though, is there a reason why you didn't read the link to the wiki the previous two times that Myask and I posted it?
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176335)
lidnariq wrote:
This is also why Castlevania 3 is on MMC5 instead of VRC6, even though it doesn't really use hardly any of the MMC5 features.


I did work on an MMC5 mapper mostly to get Castlevania III running. It uses the IRQ counter, ExRam page and fill mode. I really had to restructure my code to make mappers more flexible when it came to implementing Ex Graphics mode to run Rom City Rampage. It allows for tile-specific bank pages and attributes (improving on the coarse 16x16 pixel attribute limit).
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176338)
Congratulations on pedantically misinterpreting what I said as a request for details on how Castlevania 3(US) uses the MMC5.

Since you've chosen to be pedantic, I'll point out that you did not observe that it uses MMC5's CHR 8×1K banking, and especially the 16+8+8 PRG banking mode that is uniquely compatible with the VRC6.

Would have using the phrase "MMC5 exclusive features" have kept you from enumerating that list? It's not relevant to the point, which is that games often changed mapper when exported from Japan because NoA and NoE rarely OKed ASIC mappers that Nintendo hadn't made.

Before the pedants pile on: Yes, I know about MC-ACC, FME-7, and Namco's 108. Those don't negate my point.
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176378)
lidnariq wrote:
Congratulations on pedantically misinterpreting what I said as a request for details on how Castlevania 3(US) uses the MMC5.


I didn't mean any offence, perhaps I have an annoying habit of rambling off topic. To be honest I have never thought through the reason why different localisations of a game were released on different mappers. It initially occurred to me that it would be simpler to just change font characters and text strings. I appreciate the insights you've given me and I admit I failed to take proper note of the wiki links you posted, my apologies. :)
Re: Mapper 23: VRC4 rev E/F or VRC2 rev B?
by on (#176388)
A forum search for username "tepples" and word "certified" brought up several posts stating the conventional wisdom about why CV3 uses MMC5.