I've tried digging through the source to see if the problem was easily fixable, but the amount of abstraction is making it difficult. Was hoping someone else (lidnariq?) might have insights or know what's busted:
* https://github.com/rdanbrook/nestopia/b ... miVrc2.cpp
* https://github.com/rdanbrook/nestopia/b ... miVrc2.hpp
References for the NmtSwap stuff:
* https://github.com/rdanbrook/nestopia/b ... tBoard.cpp
* https://github.com/rdanbrook/nestopia/b ... tBoard.hpp
I've looked through commits between October 2014 and present and don't see anything relevant to fixing this. On the other hand, I do see other issues with NestopiaUE and VRC2 discussed but that's CHR page swapping and not mirroring.
I'm happy to file a ticket/Issues request with rdanbrook for getting this fixed, but like I said, it's convoluted (for me anyway).
FCEUX 2.2.3 (devel/svn build, date 2015/10/13) gets this right (at least the vertically-scrolling gameplay portion, haven't tested the ending), so it's definitely specific to at least NestopiaUE.
All three emulators use the same mapping of 0,1,2,3 to "VH01".
The NMI handler of Wai Wai World always copies the byte at $07FF to $9000.
For the vertically scrolling portion in the demo there, the chunk of code at $8064 through $8068 writes $FF to $07FF, which is parsed as 1-screen mirroring by Nintedulator and Nestopia.
FCEUX, on the other hand, contains this gem:
Code: Select all
case 0x9000: case 0x9001: if (V != 0xFF) mirr = V; Sync(); break;
(P.S. to anyone else: if you have a Wai Wai World cartridge, would you mind testing?)
FYI, I do have a a Wai Wai World cartridge and original Famicom hardware, but I'm not exactly sure how to go about testing anything related to what's been posted. I can assure you the game visually looks like what FCEUX shows, but what's going on hardware-wise is a different question.
We do have VRC2 documentation now (all in Japanese), but I can get that translated by my neighbour. $9000/$9001 does have special handling according to the VRC2 docs (see file 0012.jpg, bottom) pertaining to H/V mirroring (docs seem to imply only bit 0 is honoured, and 0 = H, 1 = V). I don't know what V or mirr are in FCEUX code. There's no mention of a special $FF value in the docs, but maybe there's something in native Japanese I'm missing. The $07FF write may be what's most relevant though (same document), as there's some kind of correlation between those two things.
Really need to get that VRC2 document translated. I'll ask my neighbour.
The trivial test is wait for the vertical-scrolling shmup section of the attract mode. If it looks correct, then writing $FF has to do something funny. If there's an obvious seam as in Nestopia, then it's a game bug.koitsu wrote:FYI, I do have a a Wai Wai World cartridge and original Famicom hardware, but I'm not exactly sure how to go about testing anything related to what's been posted. I can assure you the game visually looks like what FCEUX shows, but what's going on hardware-wise is a different question.
... Oooh, or maybe the VRC2 only supports H/V, and the VRC4 is what supports H/V/0/1, and this entire bug is another instance of the conflation of the VRC2 and VRC4?
It's interesting that all the documentation available (Disch vs. Goroh vs. the Wiki vs. Firebug vs. emulator code) have somewhat conflicting information about how mapper 23 behaves in this regard. The wiki is, well... the way I'd describe it is "all fucked up" for the H/V bits (for both VRC2 and VRC4). You'll just have to look to see what I mean. It looks like someone half-assed something.
Possibly this confusion stems from multiple revisions (2a vs. 2b) and the fact that VRC2/VRC4 were considered in early days to be the exact same? Not really sure.
Spoke with deadbody some more and I mentioned that this may be a good opportunity to have someone like Tepples make a test/exploration ROM for these types of features. There is obviously behaviour of this chip which we either don't understand, aren't documented, or stem from different revision behaviours. Possibly the official documentation we have doesn't match the exact revision of chip used in the cart? If you look at Goroh's document, you'll see that he ended up testing the behaviour on a per-game basis and the behaviour changes.
What's the documentation you're translating, though?
Just get somebody to do a hardware test. You can hotswap some test code in RAM, no need to do any hardware mods. All a tester needs is a famicom, a relevant cartridge, and something to run the test program from. (I don't have any VRC2/4 games, personally, so I can't help as a tester at the moment.)
and the issue have been reported on GitHub.
As for the ending + sound select in puNES I'm not sure about that but I can definitely say that this is not occurring on original hardware at all as I own both a Famicom and a copy of the game.
* It'll beep when it's ready to remove the original cartridge.
* Press A to start the test
* It'll play a 30-second long "song", corresponding to
- The 32 different values that can be written to the mirroring control register (the VRC2 isn't connected to CPU D5,6,7 so those cannot change things)
- Each of which consist of five notes, each 183ms long, which are Upper Left, Upper Right, Lower Left, Lower Right, Spacer.
+ 874 Hz = nametable A
+ 437 Hz = nametable B
+ 218 Hz = spacer
- (2.87 KiB) Downloaded 496 times
Otherwise, yeah, you got it.
I remember someone saying that executing OAM DMAs repeatedly helps with preventing crashes, because that means the CPU spends most of the time doing something that doesn't involve reading opcodes from memory, I believe. Can anyone confirm this?rainwarrior wrote:Hotswaps often crash during the insertion/removal
English translation of a couple pages from the VRC2 docs will be coming later tonight.