[GBA] Classic NES Series Anti-Emulation Measures

Enjoy: https://endrift.com/mgba/2014/12/28/classic-nes/

In case you're not familiar with the GBA architecture, here are some analogous tests of an NES emulator:

• Memory mirroring: Make sure writes to $1FFF are mirrored to $07FF.
• Execution from VRAM: Execution from MMC5 ExRAM, or JSR $2007 where VRAM data register holds a value $60 (RTS).
• Store multiple to DMA registers: Perhaps something involving open bus and read-modify-write on some port where writes have a side effect, such as OAM DMA.
• Save type masquerading: Enable battery RAM, check that it's the correct size, and check that the mapper disables it when asked to. Low G Man (for NES) and Earthbound (for Super NES) use this.
• Prefetch abuse: Not sure about this one, as the 6502 doesn't do memory accesses for an older instruction after opcode fetches for a newer one. Probably bank switching the second half of the next instruction, like a mix of Earthworm Jim 2 (which uses well-disguised bank switches in its init code) and The Magic of Scheherazade (which failed for a long time in PocketNES).
• Audio FIFO irregularities: Perhaps reliance on length counter or sweep or DMC prefetch behavior.

We previously discussed testing poorly emulated features before using them.

I talked to endrift about these before, though I haven't gotten NES classics working in my fledgling emulator myself (there is still 1,000+ other TODOs after all). I find the VRAM execution the most interesting. You can basically treat this area of memory like a supplement to the 32K WRAM during Forced Blank or VBlank (they'll even have the same access timings). If you're setting up the game and needs lots of fast memory, it seems like pretty cool technique to use. I never made the assumption that VRAM addresses couldn't be valid PC values, so I would have never discovered this in my own emulator unless something came up.

I've actually been meaning to do something similar on the GBC with some homebrew just because.

Very interesting. (I don't think executing code from VRAM is only specific anti-emulation measure, as it's the second-fastest RAM available.)

I really don't understand why they made all this trouble to emulate "Classic NES" games which were already emulated in their NES form anyway, and did not make this for native GBA games. This makes straight no sense. The opposite would have made quite some sense.

Also how does those games displays NES graphics on a screen with inferior X and Y resolution ? This has always bugged me. PocketNES used to look terrible but now that a NDS equivalent exists nobody'd use this anymore.

My thoughts exactly. NES games had been successfully emulated for years, why go through the trouble of making the GBA versions of those particular games tougher to emulate?

Perhaps Nintendo planned to use these in native GBA games but never got around to it.


I believe N used the same method as PocketNES, where every four lines of background are compressed to three through temporal AA (lines 0, 1, 3 in even fields and lines 0, 2, 3 in odd), but some problematic tiles are modified to look better at 8x6. Back when PocketNES was popular, Pocket Heaven board members would create CHR patches to make fonts look better in PocketNES. I don't own any to check, but perhaps the scale ratio is configurable at compile time to shrink games less if their graphics don't push as far into overscan. Something whose display fits into a 23-line-tall window, such as Dr. Mario, could run at 87.5% height (each tile 8x7 pixels, which replicates the authentic PAR) without problem.


It's been a decade and there's still no commercial solution to display DS games on a TV. The Game Boy Player and GBA flash carts existed before the PowerPak, which is in fact why I got into GBAdev before NESdev.

Nintendo clearly wanted to help GBA emulation become more accurate by subtly suggesting a couple of things that needed to be improved upon. Clearly.

My opinion/theory at the time -- which still remains the same today -- is that it was a combination of 1) attempting to "re-establish" the fact that these games still bring them money (i.e. in a legal case, they could argue that piracy of retro games does in fact impact them), and 2) their way of acknowledging that people still like to play classic console games (i.e. marketing knows there's money to be made off of people who want to play classic games on present-day systems).

Don't forget Virtual Console on the Wii/WiiU, and that one game (I can't remember its name, or for which Nintendo console) where in-game you could get Famicom carts of first-gen games and play them on your character's game console/TV.

TL;DR -- if something a large corporation does can't easily be explained, chances are marketing and/or IP (intellectual property) had some involvement.

"that one game" was Animal Crossing according to the wiki.

With the exception of Brain Age in Japan this is sadly still true. Nintendo said they were planning to offer more DS games as Wii U Virtual Console titles, but that's so far failed to materialize. Maybe they found out emulating the DS was harder than it looks



I agree with both points, but I'm kinda of the sneaking suspicion that at least a few of the things endrift listed are just "wtf?" programming decisions Nintendo did for whatever reason (e.g. someone thought they were being clever/cool/cute). Not all of the points are especially hard to implement in an emulator imo. I already hit half of the points in the article myself before I even looked at the NES Classics.

But then again, Game Freak programmed some of the later Pokemon games to detect pirate copies or emulators that weren't accurate enough, so it wouldn't surprise me if these were genuinely intended to thwart (at least temporarily) emulation of NES Classics.

Speaking of DS games on a TV, it occurred to me the other day that the 3DS's screen height of 240 pixels might mean its display timings are similar to that of NTSC, and a TV display solution might be possible in the analogue domain. Has anyone looked into 3DS to TV capture, other than that one proprietary solution?

I worked on one years ago, there wasn't any interest in it so I abandoned it. The vast majority of people looking for capture solutions want it for YouTube / Twitch so direct USB output is simpler. If you want TV out, you can always make the PC display full screen and use its HDMI output. (Same goes for DS to TV, by the way. Shameless plug )

Random tidbit: that one proprietary solution was also created by loopy here on the forum, AFAIK, so it's at least not some random garbage product. :)

NINJA'D BY THE AUTHOR haha

Mine is here. Screw that other guy. haha

Oh christ, I misread the damn domain names. *sigh* People these days...

3dscapture.com -- loopy's device
3dsvideocapture.com -- some ridiculous overpriced whatever

Wow, Loopy, I didn't know you did this kind of engineering. Very cool.

Got any adaptors that output 15khz RGB? (Y'know, simply for playing games?)

Loopy, do you have any timing information you'd be willing to share? Any chance of the LCD being pretty close to NTSC already? I've been on an FPGA high recently, making capturers / line doublers for classic consoles that expose a pixel bus, but if the 3DS could use something more direct (like throwing a DAC onto the parallel LCD interface) that would be nice.

The DS master clock is probably supposed to be 2^25 = 33554432 Hz. According to GBATEK, it generates one dot every 6 clocks (5.592 MHz), one line every 355 dots (15753 Hz), and one frame every 263 lines (59.89 Hz). These timings are very close to the System M on which NTSC and arcade standard resolution are based, and the pixels through a supergun would be wider than square pixels (135/22=6.136 MHz) but not as wide as NES/SNES pixels (945/176 = 5.369 MHz).

That covers the top screen on the original DS, DS Lite, and presumably DSi, but adding the touch screen to the video output would still need a frame buffer.

The LCD timing is not NTSC friendly on the 3DS, you'd need a frame buffer. It's rotated 90 degrees (scanned bottom to top, left to right).

Interesting, it looks like that is indeed very close to NTSC timings for the DS. Perhaps something can be done there, then.

Loopy, do you think they are using LCDs that were originally designed for some other device that normally operated in portrait mode? The only other device that I've been aware of scanning in that way is the Dingoo A320, which uses an LCD designed for a flip phone.

They might have gone that way because of how the 3D is drawn (alternating left/right pixels horizontally).

The GP32 had a similarly rotated screen; the framebuffer in memory represented a 240x320 screen that was physically rotated 90 degrees to the left. This stuff does indeed happen.

That would be awesome.

There's this, if you haven't tried it: http://community.arcadeinfo.de/showthre ... l-Overview

I've only tried it on one machine, and it said the drivers weren't supported. I'm going to have to try it on a desktop sometime soon. I have no way to hook up RGB to an analogue television, though, and it looks like that is a requirement.

Also, back to the original topic, there are IPS patches somewhere (they were very difficult to find) that defeat the copy protection. I used them to run the games on a GBA flash cart.



Yeah, same thing as PocketNES, I seem to recall Flubba mentioning at one point being upset that Nintendo stole his idea.

Every tile is redrawn (not sure if by hand, or if they used a program), not just the problematic ones. You can hack the graphics into the original NES ROM and load it into PocketNES, set the graphics to "scaled BG, unscaled sprites" (I think) and it'll look the same.

Nintendo didn't just use the PocketNES scaling method, they patented it after seeing it in action.

Yes, it may be an internal conspiracy I think that is some of what happens. It is probably not the only reason though; rather someone suggested such thing to cause it to be more difficult, even though they want to improve the emulation in a same way too.