Classic NES Series

Classic NES Series
Also known as: Famicom Mini (JP), NES Classics (EU/AU) Developer: Nintendo Publisher: Nintendo Platform: Game Boy Advance Released in JP: February 14, 2004 Released in US: June 2, 2004 Released in EU: July 9, 2004 Released in AU: 2004 This game has anti-piracy features.

The Classic NES Series is a series of Game Boy Advance cartridges with emulated ROMs slapped onto them. The carts are infamous for the fact that the games' graphics have been resized to account for the GBA's screen resolution, making the sprites look rather ugly, with the most prominent example naturally being "Hunchback Super Mario Bros."

Still, at the time, they were a decent official way to play Famicom and NES games on the go (certainly less cumbersome than the e-Reader in that regard).

Anti-Piracy

If the cartridge detects that it is pirated, the above error screen appears on bootup. Lower-accuracy emulators can also trigger this screen. Among emulator developers, the Classic NES Series is believed to be the earliest examples of measures specifically against emulation.

The game does this by performing five different checks, which all pass on real hardware but will likely fail somewhere on less-accurate emulators or flashcarts. Failing any of the below checks will cause the game to lock up on the error screen.

Memory Mirroring Check

The GBA uses an ARM chip that uses a 32-bit address space, however the device itself has only enough RAM to require an 18-bit address space. The GBA architecture uses the top 8 bits to signal what device should have access to a memory address, and the bottom 18 for the actual memory address. This leaves 6 bits in the middle that are technically unused, and due to a quirk in the GBA's processor, these bits are ignored when determining the address being accessed. The Classic NES Series uses this quirk to detect and confuse some low-accuracy emulators and flashcarts: memory addresses with those middle 6 bits set would effectively "mirror" the memory addresses of those without those bits set. The Classic NES Series would then write to one section of memory and then try to read from one of the "mirror" addresses. If this read fails, this check fails.

VRAM Code Execution Check

The Classic NES Series copies executable code to VRAM (video RAM) and tries to execute the code directly from video RAM. The GBA's architecture on real hardware allows the execution of VRAM code, but many emulators did not allow this to prevent arbitrary code execution. If the attempt to execute code from VRAM fails, this check fails. Explained in more detail in the Prefetch Abuse Check section.

STM to DMA Register Check

The Classic NES Series has three consecutive registers in memory that is checked for a mismatch. This is done via the use of STMIA and STMDA instructions to perform a DMA transfer, which writes all three registers at once in incrementing and decrementing order, respectively. The STMDA instruction previously confused many low-accurate emulators due to writing values to the registers in the wrong order, usually opposite of what is expected. If the game detects a mismatch, this check fails.

SRAM Check

Although the Classic NES Series uses EEPROM for saving, they attempt to write to SRAM anyway, prior to trying to save to EEPROM as normal, which will fail on real hardware due to the lack of an SRAM chip. If the write succeeds (very likely if an emulator has blindly created an SRAM region or if a flashcart was used; GBA carts are only allowed one type of save medium (Flash, EEPROM, or SRAM), which is not indicated in the header of the ROM), this check fails.

Prefetch Abuse Check

The VRAM code does something very clever that requires a rather technical understanding of how processors actually work in order to understand fully. The brief version of this is that processors have a queue, called a pipeline, into which instructions are fetched and placed prior to execution, and after some processing and decoding, are executed in order. The VRAM code has instructions that modify a MOV instruction after, on an accurate emulator or real hardware GBA, it would've already moved into the pipeline, at which point changing the instruction would have no effect, as it's already being preprocessed (as an analogy, this would be like modifying a document after you've already sent it to a printer; while the actual document (memory location) is updated, the printout (instruction in the pipeline) is not). The instruction to modify the code in-memory is two instructions before the MOV instruction: on real GBA hardware or an emulator that accurately reproduces a GBA's 3-stage pipeline, the instruction that changes the MOV to store a 255 to storing a 0 will be executing just after the MOV enters the pipeline, and thus the instruction that's actually executed will be unchanged and will store a 255. If an emulator collapses some stages of the pipeline (for performance and code simplicity reasons), the instruction that changes the MOV will execute just before the MOV enters the pipeline, and the instruction will store a 0, which means the check will fail.

(Source: Endrift, mGBA)