|
Yeah, putting tight loops into fast RAM for extra speed is a very old trick --- I've done it myself. Likewise multiple stores. Using a non-standard copy of the address --- well, it's an emulator, on a slow system; the ARM requires 32-bit constants to be read from a constant pool. If it can use certain addresses that are cheaper to construct, somehow, that'd be a performance boost. Can't tell without knowing which addresses, though. My first thought on the save type masquerading and the pre-fetch queue testing is that it's testing for particular hardware. e.g. if it's running on a cart with SRAM, do the SRAM thing, otherwise do the flash thing. Likewise, testing the pipeline size might be trying to figure out what processor there is. That doesn't explain why it just crashes rather than following some other code path --- if the code to do the SRAM thing was there, and the emulator tells the game that there's SRAM, then the emulator should see the game doing the SRAM thing. It might be something as trivially stupid as that the game contains the code to check for development hardware, but that the run-time support for the development hardware isn't present and instead the game is just crashing. There may not be anything malicious here. If I wanted some sort of antipiracy or antiemulation feature, I wouldn't put a big obvious crash up front. Instead I'd introduce some sort of random failure elsewhere in the game, so it superficially looks like it's working, but isn't any fun to play... |
This isn't mentioned in the article, since one of the anti-piracy/-emulation techniques I didn't discover at the time of writing it (due to my dump being an overdump) is that many of the games do this. They screw up input so it either boots but you can't play it at all, or input is unplayably slow. It detects it by having an interesting memory mirroring quirk in the cartridges that no other GBA carts have.