VS Daughterboard compatible to their NES mapper counterpart?

[lupin3rd]

So I had posted recently about converting a no-mapper game (NES Balloon Fight) to run on real VS hardware. Mapper 0 games seem to be a breeze, since ROM mirroring isn't an issue and there aren't any additional complexities introduced by adding CHR-RAM or other strange add-on hardware.

The next logical step is to try to tackle some of the games that use actual mappers. I'm trying to help a small group of VS owners get some better quality games on their machines, and I was asked to give Contra a shot. This is the second UNROM(2) game that I've tried, the first was Skate or Die! Neither "worked", because it appears to be using incorrect tile data (presumably from addressing incorrect name tables) anytime that scrolling is introduced. I'm using the VS Castlevania daughterboard for both of these games, and I'm operating under the assumption that because the NES version is UNROM(2) so must be the VS version (well, that and it has CHR-RAM on the board, and a single PRG ROM on it).

Can anybody clue me in to potential ways of solving this behavior? Am I right about the cause, or is it something more nefarious, like the RAM size difference between the VS/NES systems? I'd like to work this out, because the VS library is somewhat limited, and there's just a couple of games I'd like to have available to make better use of the 2-players per side functionality of the cabinet.

Album of NES Contra on VS (2 images)

[tepples]

Vs. System uses 4-screen VRAM. Try setting the 4-screen bit in your ROM's header and seeing if it makes the same garbage in an emulator.

[lupin3rd]

Vs. System uses 4-screen VRAM. Try setting the 4-screen bit in your ROM's header and seeing if it makes the same garbage in an emulator.

That's a good suggestion. Do you know if OpenEmu (for Mac) will honor the mirroring bit in the header? My Windows machine is at a friend's house currently, so I only have access to Raspberry Pis and Macs at the moment. Also, if it's determined that the 4-screen VRAM of the VS system makes these games impossible to run; what do you think about the idea of modding the motherboard by cutting some of the traces and installing toggles to change the mirroring schemes? Or is that just crazy talk?

[tepples]

NovaSquirrel has a Raspberry Pi and may be able to help you get an emulator running.

I'm pretty sure FCEUX (SDL version) supports 4-screen, and you can probably compile that yourself on your Mac. If you want, I can test FCEUX's 4-screen support using my Linux box once I get home from work.

You wouldn't necessarily need to modify the system board itself if you can ROM hack the games to respect 4-screen.

[lupin3rd]

NovaSquirrel has a Raspberry Pi and may be able to help you get an emulator running.

No worries, there. I can get something up and working later on, I was just asking because I'm at work currently.

I'm pretty sure FCEUX (SDL version) supports 4-screen, and you can probably compile that yourself on your Mac. If you want, I can test FCEUX's 4-screen support using my Linux box once I get home from work.

If you don't mind checking it tonight, I'd appreciate it. I've got some family business going on this evening, so it may take me longer to get around to it. If not, I'll get to it sometime tomorrow.

You wouldn't necessarily need to modify the system board itself if you can ROM hack the games to respect 4-screen.

I was hoping that would be the case, but I wasn't sure how trivial it would be to modify those routines. My understanding was that the mirroring usually served a purpose, which was to facilitate scrolling in a specific direction, by allowing access to a buffer of VRAM. Maybe I need to revisit the purpose of mirroring to understand it better. At any rate, wouldn't the 4-screen mirroring be both cases simultaneously? And ultimately, isn't that the reason the VS system has double the VRAM on both sides of the board (compared to the NES)?

[lidnariq]

I really quickly modified the header in a copy of Contra (U) [!] to indicate 4-screen nametables ... and, yes, it breaks. Apparently it sets the Y scroll value to show the lower nametables but draws the first stage (at least) to the upper nametables.

[lupin3rd]

I really quickly modified the header in a copy of Contra (U) [!] to indicate 4-screen nametables ... and, yes, it breaks. Apparently it sets the Y scroll value to show the lower nametables but draws the first stage (at least) to the upper nametables.

Thanks for checking on that, Lidnariq. So now I guess I need to work out the best way to handle the problem. Has anyone worked with this problem before, that is, modifying a ROM to use a different mirroring scheme? Is anyone interested or up to the challenge of helping me modify the ROM to work? Or was my original idea of modifying hardware probably a little more tangible in terms of effort/results?

I'm a programmer by trade, but my low-level skills are really rusty. Combine that with my inexperience on the 6502, and this could take me a long time. I'd like the satisfaction of working it out on my own, but I might have questions. A lot of them.

[tepples]

I have confirmed that FCEUX 2.2.3 indeed supports UNROM + 4-screen. Change byte 6 of the header from $21 to $28.

How to mapper hack: Trap all writes to $2001 in the debugger and see where the data is loaded for those writes. If they're wrong, you'll want to either change the data at the source or EOR #$02 before writing to $2001.

[Dwedit]

Contra would need quite a bit of hacking to make the vertical scrolling levels work correctly on 4-screen mode.

I wonder if it's possible to wire switches to disable address selection pins on the nametable memory, thus getting mirroring?

[lidnariq]

Yeah, modifying either mainboard or daughterboard to limit the portion of the nametable RAM seen wouldn't be hard.

[tepples]

A daughter modification would be the most "accurate" in the spirit of NES mirroring controlled by the Game Pak.

[lupin3rd]

A daughter modification would be the most "accurate" in the spirit of NES mirroring controlled by the Game Pak.

I'm starting to think that's really the way to go. Can't I just run A10 from CIRAM to either the PPU's A10 (vertical) or A11 (horizontal) pins? If so, that seems like it would be very easy to just throw a switch in the circuit to control that behavior, especially being isolated on the daughterboard like that.

[lidnariq]

Unfortunately(?) the Vs. System uses a 4K RAM for its nametables, so there isn't really something equivalent to the NES's CIRAM A10 signal.

Although some of the mappers could have runtime selected mirroring (MMC1, VRC, and SUNSOFT-3), the rest seem to all use hard-wired mirroring (UNROM, m99≈NROM/CNROM/m87, N108). For these latter ones, you should be able to add a pair of SPDT switches such that PPU A10 and/or PPU A11 are passed through to the mainboard (where it will then connect to the NTRAM, 2C/8C TC5533), or are replaced with a constant signal (e.g. ground).

However, the tricky bit is that the CHR ROM (or CHR RAM in the case of UNROM) on the daughterboard still needs to retain access to both signals. What do the sockets look like on the underside? Are they a combination socket-and-pin-header? Or might it be possible to get something in between the two?

[lupin3rd]

However, the tricky bit is that the CHR ROM (or CHR RAM in the case of UNROM) on the daughterboard still needs to retain access to both signals. What do the sockets look like on the underside? Are they a combination socket-and-pin-header? Or might it be possible to get something in between the two?

The daughterboards remain completely separated from the system, barring the pin headers that pass the CPU and PPU pins to the mainboard. Is that what you were asking?

[lidnariq]

I think I'm asking specifically about the headers that pass through to the system.

If the whole thing is a sandwich with these layers:

PPU
socket
daughterboard
pins
mainboard

this would need to interpose between the daughterboard and the mainboard ... but if the socket and pins are one and the same, the only way I can think of to do this would be to add another set of sockets between the pins and the mainboard.