Hacker News Reader

I'm interested to know why it breaks all the emulators. Certainly I wouldn't expect emulators to reproduce all the graphical glitches that this takes advantage, but what is it doing that actually crashes them?

View on HN

The emulator I was mostly using for development (DOSBox) doesn't actually crash itself, but here's a nice example of how it goes wrong. In the final part of 8088MPH there is an instruction that modifies the instruction after it, but then (on the real hardware) the old version of the instruction is executed (because it's already in the CPU's prefetch queue when the modification is made). DOSBox executes the modified instruction because it doesn't simulate the prefetch queue. I tried moving the to-be-patched instruction above the patching instruction but that made the code take longer to execute and it no longer met the precise timing requirements necessary for the best audio quality.

Modifying code in the prefetch queue was a well-known anti-debugging/emulation trick in the pre-Pentium days but this is probably the first time I've heard it being used as an optimisation - seriously amazing work.

This is just a guess, but one thing that could do it would be cycle-exact self-modifying code using interrupts. Modify the code too early or too late and the CPU will execute the wrong instructions.

I see this demo as somewhat of a challenge to the emulator authors.

Reply on news.ycombinator.com