Comment by AshleysBrain | Hacker News Reader

Comment by AshleysBrain | Hacker News Reader

This doesn't seem to me to be evidence of deliberate anti-emulation features - just imagine a hastily written port by relatively inexperienced developers who don't know about these quirks, and then it could be said:

#1 - memory mirroring - accidental bug that doesn't matter since hardware ignores those bits

#2 - code in vram - possible technique to save memory in another memory area?

#3 - STM to DMA - shortcut to DMA that "just worked" without the original developers knowing the CPU write ordering

#4 - save type faking - just a library bug that breaks the emulator heuristics?

#5 - prefetch abuse - idk, maybe a legit attempt to prevent reverse engineering? Don't really know enough to comment if there's a reasonable purpose for it

#6 - audio FIFO irregularities - just a bug in the emulator?

How many C/C++ devs accidentaly rely on undefined behavior or specific x86 quirks? It's really easy to do, and doubly so if you're targeting a single exact hardware configuration. I'm sure it's easy to see these as hostile attempts to make emulator developer's lives harder, but I think they could just as easily be accidents, especially with a complex project like porting NES games to GBA hardware.

On the other hand, I dunno, maybe Nintendo pull out all the stops to try to prevent reverse engineering and deliberately use these kind of tricks, but really, they'd go the extra mile for old NES game ports?

Having said that, still a great article for covering some fascinating hardware quirks and the challenges of writing a bug-compatible emulator!

It's not as if it's a defense against emulating the consoles on a PC: That's not really a problem worth investing time into. However, those tricks also work against bootleg hardware, which can be seen as emulation. It even works against counterfeit cartridges, in the case of the save game trick.

DS games also come with copy protection to stop people from running it in cartridges that run gmaes off of images, like the R4. In that case, the product the pirates offered was actually better than buying an original cartridge: I could buy 20 games and carry a case of games, or keep them al in a single micro SSD card, and switch games at will from the boot menu.

> This doesn't seem to me to be evidence of deliberate anti-emulation features - just imagine a hastily written port by relatively inexperienced developers who don't know about these quirks

If it were one thing, maybe, but six things done in almost no or no other games repeated across (presumably) thirty ported games? Infinitesimally unlikely.

Also, these were done by Nintendo Japan - how likely is it that they're "relatively inexperienced developers writing hasty ports". These tricks would seem the hallmark of very experienced developers who know the hardware intimately.

Nintendo Japan doesn't have interns?

Some of these are definitely deliberate.

#1. The memory mirroring is IIRC a normal part of the hardware involved. Executing mirrored code? I can't think of a good reason to do it other than to trip someone up.

#2. You might do this in earnest, but only if you're decompressing the code or otherwise generating it and just can't stick it in main RAM. GBA ROMs make up part of the global address space. There's simply no need to copy existing code around.

#3. I'm not familiar with it enough to comment. Sounds like it could be innocent.

#4. Seems unlikely you would include an unnecessary code path, and then intentionally kill the game if it happened to work. This is actually your typical anti-debugging technique: trick the environment into to doing something you can detect, then disable.

#5. Prefetch games usually combine the detect and disable steps mentioned in #4. #1 and #2 are also related. This is a good contender for "oldest trick in the book."

#6. Probably a bug.

Source for GBA-specific stuff: http://problemkaputt.de/gbatek.htm

Totally agree that #5 is deliberate.

#2 For tight loops on the GBA you wanted 32bit ARM instructions in an area of RAM with 32bit accesses. There was a performance penalty both for using thumb and for running non thumb out of ROM (the bus to ROM was only 16bits). If there was a lack of WRAM for some reason it would totally make sense to put a tight loop into VRAM. (And for whatever reason Nintendo is really into putting random stuff into VRAM. On the DS, one of the ARM7 images would put WLAN packet buffers into an unused VRAM bank to reduce pressure on other RAM banks).

Putting WLAN buffer into VRAM is a good idea. Incoming packet probably generates DMA and packets arrive in an non-deterministic fashion. Less risk of DMA/bus saturation to main RAM.

That's fair. I had been assuming you'd use ITCM for tight loops regardless but I can't recall whether you can do that on GBA now that I think of it.

As for copying data around, yeah, if your emu can't copy data to/from VRAM in a sensible manner it's just not going to work out.

#4 could be as innocent as:

    /* Returns a bitwise-OR'ed number showing
       all the possible places you can save to */
    int get_available_save_locations();

    [...]

    int save_locations = get_available_save_locations();
    if (save_locations != SAVELOC_NVRAM) {
      goto FATAL_ERROR;
    }

#3 seems like it could even be a legitimate optimization.

#4, If they did a SRAM write, then a EEPROM write and only raised an error when the EEPROM write failed, your suggestion would seem plausible, but since they do an SRAM write, then raise an error because the SRAM write worked, it is hard to believe this isn't an intentional protection feature.

Reply on news.ycombinator.com