Famicom/NES Remix emulation core?

I've hunted around the forums and haven't found much mention of the Famicom/NES Remix series Nintendo released last December (and followed with a sequel last month). Quick summary: players compete in a series of mini-games based on classic NES titles, which eventually unlock 'remixed' levels that play like polished ROM hacks (e.g. control Link in Donkey Kong).

I don't own a Wii U, but watching gameplay footage, it appears that Remix runs atop an emulation core, at least for the straightforward challenges. I'm wondering if anyone has looked at the game closely. What emulator is Nintendo using? Are they bundling ROMs in the game a la Animal Crossing?

Furthermore, are the remix challenges also emulated, albeit with some kind of overlay or scripting functions? A few clues suggest yes. The remix stages that erase portions of the screen during play, for instance, appear to adhere to hardware rules, as if they were toggling background tiles with $2001. OAM cycling and slowdown still appear to be in play.

Just curious if anyone had any better insight on Nintendo's in-house emulation development.

I'm guessing that the Virtual Console NES emulator is a Wii port of the "acNES" emulator used in the first Animal Crossing, and that the emulator in Super Mario All-Stars for Wii is the same as the Virtual Console Super NES emulator. You might want to compare the sound of touching a spark in Balloon Fight between VC and AC versions; I know the AC version is way off.

Now to your question: Donkey Kong was rereleased with the pie factory re-added, and this was coded in actual 6502. So yes, Nintendo has some people familiar with programming the Famicom either on staff or on contract. But until the Wii U is cracked, I don't know how to tell whether NES Remix games are true emulations or Mega Man 9-style recreations. Even with OAM cycling, it could just be a native program sending commands to an emulated PPU. That would be equivalent (emulation-wise) to desoldering the PPU from an NES and creating an interface similar to HardSID with which a PC program interacts with it.

I would bet money that it's using emulation in one form or another, and of course from that follows that you would find the game ROMs somewhere in there.

They obviously would have had to reverse engineer the ROMs enough to find out where certain variables in RAM are, but that's not too bad of a job, and there's a lot of information about many games freely available online. It's certainly easier than rewriting the games. Or they could've used docs from back in the day (but somehow I think that's more unlikely than the reverse engineering option).

As for the remixed levels, I have no real information about how they're doing it, but if I had to do something like that, I would overlay graphics on top of the emulated view based on the state of the game (which is accessible from RAM), so I'm going to guess they're doing that too since it seems like the easiest way.

I can't think of any reason they wouldn't do it as an emulation. It just seems the easiest / most cost-effective way to implement it.

With an emulator, it would be very easy to just run from a savestate and watch variables in RAM once per frame to check for the win condition, or even patch the code to trigger a special opcode that signals an event. If you needed special routines, your emulator could put some special code at $2000, like CopyNES, have custom opcodes, etc. When the target games are known and you can patch the ROMs if you like, you have a whole lot of leeway for implementation. You don't need to implement a fully NES compatible emulator, it just needs to be suitable for the small collection of ROMs you provide.

Old source code for the games isn't necessary at all. The romhacking community is ample proof of that, and it's mostly amateurs.

I seem to recall stories that that iNES headers were found when some recent nintendo games with in-game-emulation were dumped, proving that the professionals at Nintendo are paying at least some attention to the NES emulation dev community, but maybe someone else could say more about that because I don't remember the details.

Thanks for the feedback. Emulation seems to make the most sense, especially considering the quick turnaround time between the first Remix and its sequel (four months).

Another interesting observation: I see attribute glitches and flicker in SMB 3, but no MMC3 scanline glitch in the lower left. Was the latter fixed in later SMB 3 revisions?

I don't think there's a revision of SMB3 that eliminates the glitch, no.

They can just code their emulator in such a way that it is hidden. Probably they can get away with only emulating scanline splits, and have no need to bother with horizontal timing for PPU. There's no glitch if your emulator only updates scrolling per-scanline.

This page at Data Crystal claims this patch (I didn't try it) removes the glitch: http://datacrystal.romhacking.net/wiki/ ... cellaneous

Yes, with careful code timing you totally could patch it to remove the glitch, but there's absolutely no need to do that unless you're putting it on an NES (not relevant here) or very accurate NES emulator (possible, but I doubt it).

Which, of course, had already been done by Brian Provinciano of Retro City Rampage fame.

I'm very interested in how NES Remix is modifying the games to create this hybrid modern/classic approach to retrogaming. It seems like the same basic underlying idea that I've had to make a game-specific emulator allowing remastered 3D models with a 2D-style camera ensuring 100% accurate gameplay.

LocalH, I.m developing an emu in the same line. Have you done something yet? where are you at?

Just an example: if you take the Rockman 3 PRG data from the Complete Works PSX disc, it has a few differences in its code. I don't remember by heart, since I played/compare it a long time ago. So yes, I believe they're always using emulation with modified code/behaviour.