nesdev.org

tokumaru wrote:I remember someone saying that executing OAM DMAs repeatedly helps with preventing crashes. ... Can anyone confirm this?

I've tried it. I don't think it makes a big difference, really. I'll still get crashes occasionally even with a DMA loop, and due to the random nature of it's hard to say how much less it might crash.

IMO it probably helps a little, but there may be other factors involved in crashing when a cartridge is yanked that it doesn't affect.

Another useful thing would be to play audio constantly while waiting for the swap. That way it's possible to tell whether the program is still running. Probably easiest to do with the DMC DAC (run a couple of DMAs, toggle the DAC value, rinse and repeat).

I mirrored the rom to fit on a 512kb flash, stuck it on cpld unrom cart, then hotswapped. Worked fourth time! Here is the audio output.

That's strange, I only hear horizontal and vertical mirroring. Shouldn't there also be 1-screen mirroring?

Forgot to mention the cartridge used was Wai Wai World. Attached is a photo of the board.

The recording indicates that your VRC2 on your copy of Wai Wai World only supports H/V mirroring.

I thought I already tested that. But it turns out that the reason that I thought it was wrong is that NestopiaUE has a heisenbug that is somehow masked by using NMT_SWAP_VH01 instead of NMT_SWAP_VH, even though the game only ever writes 0 to $9000. But testing in plain ancient FCEU DTRT.

So it looks like my first guess was right: it is an incompatibility between VRC2 and VRC4.

Okay, so what have we learned exactly?

My initial conclusion is that, at least with the revision of VRC2 in Wai Wai World, the official Konami documents are correct (only H/V mirroring is supported -- there is no single-screen support).

1. But that conflicts with what was said here in the last paragraph. (My gut feeling is that by disabling H/V (bit 0) support altogether in that part of the game, of course the graphics ("computer") are going to be mangled -- because it needs either horiz or vert mirroring (not sure which)).

2. What does this say about the weird/odd code in FCEUX? (My gut feeling is that FCEUX tries to implement VRC2 and VRC4 using the same emulation code, and that V != $FF quirk is done as way to distinguish the difference between VRC2 vs. VRC4 mirroring capability).

Yes/no? :-)

"V != $FF" just sounds to me like a hack that solves a problem for the one game that writes that particular value.

(lidnariq already stated that only the bottom 5 bits even go to the mapper anyway, so at the very least testing for the full 8 bits of $FF is inaccurate and impossible for the mapper to do)

That code's been there since at least 2008, and the revision history runs dry at that point, so I couldn't find any insight in the revision logs.

Re: #1-
I've tested Wai Wai World with the reported correct VRC2 behavior in both FCEU-0.98 & FCEUX and both DTRT.
Nestopia does the wrong thing. Right now I can't summon any enthusiasm for tracing down that bug.
For whatever stupid reason, I can't get puNES to build right now, and I don't have a windows toolchain installed (not even in a VM) to test with Nintendulator.

Re: #2-
The most flattering thing I could say about "don't change mirroring if the game writes #$FF" code is that it's a run-time heuristic, because apparently all other games cleanly just write a number 0-3 there, achieving upwards compatibility between the VRC2 and VRC4. It apparently should probably be "treat it as 1" rather than "no change", though.

It wouldn't be entirely wrong to explicitly handle 0,1,2,3,#$FF and throw a fatal error if another value is written.

Regardless a comment in FCEUX about why the hack is present would be nice.

lidnariq wrote:Re: #1-
I can't get puNES to build right now

I already tried this out in puNES but you must have missed the post on page 1 with the large image?
Anyway, it's reported and documented on GitHub quite nicely with save states etc. etc.

https://github.com/punesemu/puNES/issues/9

I meant I can't get it to build with my fix.

Makes sense. Thanks everyone! I'll file a bug report/Issue with the NestopiaUE guy to have this rectified. I'll also see about updating the nesdev wiki (for VRC2).

As for FCEUX and its weird V != 0xff quirk: if the code there is purely for VRC2 and not VRC4, then I don't know why they don't just mask off bits 7-1 and only honour bit 0. In other words, something like this would be clearer:
Though the case statement isn't accurate -- the docs state clearly $9000-9FFF is mapped to the H/V toggle.

If the same code is used for VRC4, then I don't know what makes the V != 0xff quirk necessary; possibly there's some justification for it (maybe someone has official VRC4 documentation), but my gut feeling is there's probably a weird game that does something unexpected and it worked around whatever the oddity was. Too bad the commit history doesn't go back to when it was written -- thanks for digging into that, rainwarrior!

Edit: you summarise the situation beautifully well, lidnariq. Thanks for that. *thumbs up* :-)

P.S. -- I've run into my neighbour twice in the past 2 days, and he was supposed to come by last night to give me the translated results but didn't. I'll poke him tomorrow. He did say the Japanese wasn't hard and he more or less understood/got it all.

koitsu wrote:If the same code is used for VRC4, then I don't know what makes the V != 0xff quirk necessary

The same code is used for both (mapper 23), and it's there because $FF=1 on VRC2 and $FF=3 on VRC4.

It's a hack that happens to work for Wai Wai World. Seems like it's just "lucky" that the mirroring mode is redundantly set before the $FF, so ignoring it "works", and other mapper 23 games don't write $FF?

Like, if it's a heuristic hack to make a universal mapper 23, it should probably make $FF write a 1, not an ignore? (And for accuracy, it should get an NES 2.0 submapper.)

The issue is now fixed in puNES:
https://github.com/punesemu/puNES/commi ... 67f665cc9d

I'm eagerly awaiting a WIP build to try it out.

koitsu wrote:Though the case statement isn't accurate -- the docs state clearly $9000-9FFF is mapped to the H/V toggle.

Right, which is why right above that, it's switch (A & 0xF003) {

rainwarrior wrote:(And for accuracy, it should get an NES 2.0 submapper.)

I started writing a VRC2 / VRC4 set of validation ROMs after that discussion on the wiki ... and I after I got about 70% through I realized that I really needed the hardware to test against to be able to make something that wasn't just parroting what we said on the wiki.