Hacker News Reader

Comment by mattbee | Hacker News Reader

The simplest trick for detecting old ARM emulation - ISTR was used on some Gameboy Advance copy protection: store a booby-trap instruction at PC+4 (i.e. the very next one). A real ARM has a pipeline that reads PC+8, while decoding PC+4 and while executing at PC. So the newly-stored instruction should have no effect. An emulator (which didn't emulate the hardware pipeline) would execute it.

edit: described in more detail here, among other emulation-busting measures from 2004 https://mgba.io//2014/12/28/classic-nes/

View on HN

The Texas Instrument TI320C40 digital signal processor had even weirder pipeline issues:

- Branch delay slots (https://en.wikipedia.org/wiki/Delay_slot), where one or more instruction(s) after a branch would be executed before the branch actually occurred.

- Load delay slots, where values stored into registers weren't guaranteed to appear until some later instruction. I believe the the value in the register was undefined for several cycles?

Writing tightly-optimized assembly code for these chips was pretty horrible, sort of like playing an unusually tasteless Zachtronics clone.

It was also kinda awesome because, as long as you were willing to spend days to optimize one page of code, you could get so much performance out of it.

Things like deliberately using the fact that multiplies only write the results into a register ~6 cycles later, means you can use that register for a bunch of other stuff in the meantime, and then on the 6th cycle the results would magically appear.

Basically, for those 6 cycles, you had no registers in-use for either the source operands or destination of the multiplication.

Obviously this is also pipelinable - you can start more multiplies while the first is running, using the same source and destination registers, but meanwhile you've used other instructions to load more data into the inputs and do something else with the outputs.

The MIPS-I chip also had load delay slots along with branch delay slots.

Another sibling comment here references it obliquely but on x86 the prefetch queue produces similar behaviour, until Intel decided to detect SMC on the Pentium and newer CPUs so that modifying the instruction about to be executed will always have an effect.

However, someone much later found another undetected edge-case: a self-overwriting repeated string instruction.

https://silviocesare.wordpress.com/2009/02/02/anti-debugging...

Some pipelined CPUs have retained compatibility with self-modifying code and detect when you overwrite an instruction that is on the pipeline and flush it.

X86 has that machinery although I'm not sure if they dropped it eventually on the 64-bit variant.

The rules and mechanisms for SMC detection are essentially the same in both modes as far as I am aware.

Both Intel and AMD implement SMC detection that is a bit stronger than required by the specification as well.

Is this why my ROM for Dragon Ball Z: The Legacy of Goku II didn't work sometimes with visualboy advance?

VisualBoyAdvance was (and is) absolute garbage in terms of accuracy and is loaded with delicious code execution exploits from boobytrapped roms

Use mGBA instead if you want to play Gameboy games in 2024

Mednafen it's fine too. Altough VBA... there's VBA-M which is much better than the original one, where the audio code for it was very bad and it glitched under GNU/Linux and BSD a lot.

Reply on news.ycombinator.com