Re:Classic NES Series Anti-Emulation Measures
by monocasa on Monday December 29, 2014 @02:16PM
(#8811271)
#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).
Re:Classic NES Series Anti-Emulation Measures
by smosher_ on Monday December 29, 2014 @11:40PM
(#8813363)
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.
Re:Classic NES Series Anti-Emulation Measures
by vardump on Monday December 29, 2014 @04:47PM
(#8811978)
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.
Re:Classic NES Series Anti-Emulation Measures
by raldi on Monday December 29, 2014 @02:41PM
(#8811412)
#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;
}
#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