nesdev.org

I've been doing a bit of debugging on this one. It seems to use four-screen mode (not documented anywhere and the bit is currently not set in the INES header in the GoodNESs ROMset..). I've been trying to convert it from mapper 99 to mapper 1 (with four-screen set in the header).
However the issues starts here. Is there anything stopping a mapper1 game working with four-screen layout? I haven't tried my code on real hardware but emulators behave
really odd here (Latest FCEUX shows nothing in the Nametables-debug view, it's blank). Nintendulator doesn't seem to support four-screen properly either when the ROM is set to mapper 1 (no issues with mapper 99 however). Is the mirroring-settings in MMC1 conflict with the four-screen layout?
Can anyone shed some light on this?
Thanks.

I imagine the problem is that emulators note that the game is using MMC1 and thus only support V or H mirroring -- meaning writes to $2800-2FFF result in V/H mirroring being applied and not external on-cartridge RAM. References:

http://wiki.nesdev.com/w/index.php/PPU_nametables
http://wiki.nesdev.com/w/index.php/Mirr ... creen_VRAM
http://wiki.nesdev.com/w/index.php/INES_Mapper_004

Note this quote from that last URL:

4-screen mirroring for these boards is hardwired! When in 4-screen mode, your emu must ignore writes to the
mirroring reg.

You have to kind of "read between the lines" to conclude what I did above about 4-screen. If you converted the game to use mapper 4 (MMC3) you'd be able to use 4-screen.

Whether or not 4-screen on MMC1 on actual hardware would work, I don't know -- hardware guys here can surely tell you if that's the case. However it's safe to say no one would be able to play the game in any emulators.

I'll never get why Nintendo didn't make mirroring a bit in the PPU registers rather than hardwiring it in the cartridge... And yeah, I know, looking at the registers it seems like they ran out of bits, but I think I'd have rather hardwired the EXT setting and given the mirroring setting that bit instead.

Sik wrote:I'll never get why Nintendo didn't make mirroring a bit in the PPU registers rather than hardwiring it in the cartridge

The problem isn't register bits; there are 8 available bits in $2002.W. I'd guess pin count. It already has to interleave address and data. And that's probably also why sprite 0 doesn't assert /IRQ.

tepples wrote:The problem isn't register bits; there are 8 available bits in $2002.W.

$2002 is already used for reading and it's very likely that making it read/write would have made it a tad worse.

tepples wrote:I'd guess pin count. It already has to interleave address and data.

Aren't there more bits above already? I recall elsewhere being mentioned that it's possible to point the nametable to CHR-ROM (and Afterburner does it - I guess it makes sense, it'd need to completely rewrite it otherwise, which is too slow).

tepples wrote:And that's probably also why sprite 0 doesn't assert /IRQ.

Actually, not asserting anything on sprite collision was very common on video hardware (i.e. it isn't just a Nintendo thing), it seems that merely providing the status bit was considered enough =P That the collision test in hardware went almost universally ignored probably didn't help - in the NES it's more heard of only because of the complete lack of a proper way to do mid-screen timing without custom hardware. If there was a scanline counter or something nobody would have touched it.

The "four screen" bit should be an override in all mappers. But most emulators don't seem to treat it that way: hence the problem I fixed in Vs. Goonies. If the game actually uses 4 screens of data, your best hope is to switch the mirroring control register as time goes on.

Tangentially related, why do you keep targeting MMC1 instead of simpler mappers like CNROM?

tepples wrote:And that's probably also why sprite 0 doesn't assert /IRQ.

I thought I remember reading that that was avoiding infringing some patent? Maybe US4423870?

Sik wrote:$2002 is already used for reading and it's very likely that making it read/write would have made it a tad worse.

Doubtful; it's not like reads to write-only registers cause weird values to be written or and we're pretty certain that writes to read-only registers don't cause a bus conflict. It'd just be a little more die area.

lidnariq wrote:Tangentially related, why do you keep targeting MMC1 instead of simpler mappers like CNROM?

Flashcarts? (guessing here)

lidnariq wrote:

Sik wrote:$2002 is already used for reading and it's very likely that making it read/write would have made it a tad worse.

Doubtful; it's not like reads to write-only registers cause weird values to be written or and we're pretty certain that writes to read-only registers don't cause a bus conflict. It'd just be a little more die area.

That "little more die area" is exactly what would have made it a tad worse. Don't underestimate how much it could have costed (or what else may have needed to be sacrificed in order to get it there).

Really, if this wasn't a problem chances are they'd have made the status register overlap some of the write-only registers in the first place (much like how the TMS9918-based chips have a port as control port when writing and status port when reading).

I've probably used mapper1 by habit.. However it's pretty neat to have expansion RAM available and battery aswell.
However this title might work better with CNROM so I might check that out..

I've released a patch now for Hogan's Alley for people to try... Can't get it to run properly in any emulator so it will be exciting to see if it works on PowerPak/EverDrive..

This game almost will work correctly with hardwired vertical mirroring (horizontal arrangement). You'll need to patch it to use the nametable at $2400 instead of $2800 if so. Alternatively, if you use MMC1, you could flip the mirroring control register at the appropriate times.

AFAICT, most Vs system games don't actually use all 4 KiB of nametable memory—they just treat as 2 screen mirroring, arranged however they want. Hogan's Alley apparently expects "whenever they want" too.

Looks 99% correct on FCEUX 2.2.0 but not on hardware for intro animation.


When you shoot there is no white screen so can't play.


Some palettes not correct on hardware for targets but look ok on FCEUX 2.2.0.


Was only able to catch on camera a few times and not for all instances.

Thanks for the screenshot. The titlescreen indicates that four-screen doesn't work properly on hardware either, and the other screenshots is a result of that..

Emulators that uses checksums to optimize ROMs.. Sorry but I don't like it.
I can't test "Vs Zapper" emulation properly unless checksum fits on of the available ROMs released. Frustrating? Yep!

I've submitted a request to the FCEUX team to add "Vs Zapper" as selectable input, let's hope they listen.

oRBIT2002 wrote:I've submitted a request to the FCEUX team to add "Vs Zapper" as selectable input, let's hope they listen.

What's the SourceForge bug number of this request so that the rest of us can follow?

I'm a bit stuck with this patch. I'm using the same code I previously used in "VS Duck Hunt", but no luck. It's like the sense-bit never gets triggered and I don't get it..

I think I've located the code that causes the problem. If I set the sensebit always to zero in the code below (in the unpatched version of the game) I get the same behaviour as my patch (never gets pass the player select screen). The subroutine above gets called with X either 7 or 8. Which means, get trigger-bit if X=8 or get sense-bit if X=7.
I insert a JMP to my own code at $A1F7 and inserts the following code: The result is EOR'd because the sense-bit is inverted on the VS-system. However it still never gets a sense-hit with this code..
Can anyone spot something obvious I've missed? As I mentioned, I've used this code in "VS Duck Hunt" successfully.