Detecting a PS2 Emulator: When 1*X does not equal X

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 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.

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

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...

Emulators have to be pragmatic about accuracy, when emulating more modern systems it's generally not feasible to target 100% hardware accuracy and usable performance, so they tend to accept compromises which are technically deviations from the real hardware but usually don't make any observable difference in practice. Anything that uses a JIT recompiler is never going to be perfectly cycle-accurate to the original hardware but it usually doesn't matter unless the game code is deliberately constructed to break emulators.

Dolphin had to reckon with that balance when a few commercial Wii games included such anti-emulator code, which abused details of the real Wii CPUs cache behavior. Technically they could have emulated the real CPU cache to make those games work seamlessly, but the performance overhead (likely a 10x slowdown) would make them unplayable, so they hacked around it instead.

https://dolphin-emu.org/blog/2017/02/01/dolphin-progress-rep...

I tried to get into it many moons ago, and the guidelines were to start from something very simple and well documented, and build your skills from there. I still have the itch but lack the time :(

It depends what you mean by emulation.

For instance, I ported a 6502 interpreter from UNIX to Classic Macintosh back in the day. This was to play SID music files. So long as it ran fast enough, clock cycle accuracy wasn’t important.

It worked by calling C code from the interpreter.

Game Boy emulator tutorials are all over the web.

CPU's are emulated on a high level way. If you can shift bits, you can understand a Z80 or a 6502 in no time.

You start by reading hardware documentation and you don't need to understand the machine at an electronic level. It's not a simulation of digital circuits. It doesn't need to be that complicated. An 8-bit CPU is a simple state machine with only a few bytes of state (registers). You can read the program one byte at a time and simulate whatever operation the CPU would do after reading that byte. They are very simple operations like adding and subtracting numbers, loading and storing bytes.

http://www.6502.org/users/obelisk/6502/registers.html

http://www.6502.org/users/obelisk/6502/instructions.html

Your 6502 CPU emulator would read the next few bytes of the program, interpret the bytes as an instruction, execute the instruction, which involves updating a couple of registers/counters in the CPU, doing some arithmetic or bitwise operations, and possibly loading or storing a byte of data from one location to another. This process is then repeated in an endless loop.

It is a simulation of the fetch-decode-execute cycle.

https://en.wikipedia.org/wiki/Instruction_cycle

Like anything else, gradually.

You really don't have to understand any deep wizardry to get started (or, for the most part, even to finish). For the most part, you just look at a specification, and implement what it says. It requires some code architecting skill to not make a mess, but there are common patterns and it becomes a lot easier once you've built one or two emulators.

And you almost never need to understand electronics. You're only emulating behavior. When someone discovered bugs in the behavior of the original hardware, you usually just need to special-case it in your emulator. It might help to know some electronics to understand how those behaviors came to be, but that's more so of historical interest than actually practical.

There are certain unique challenges, but it's nothing too difficult. When there's an issue, you're usually debugging three things at once: Your understanding of the hardware, your implementation of the emulator, and the game you're emulating. It can be hard to pin down the exact problem. But here, I encourage you to just hack something together. It's not clean, but all emulators are full of special cases that try to somehow get popular games working. If a couple unclean hacks mean you can get a game working, just do so. You don't really need to exactly implement the original hardware's behavior. Just get the game working.

Shameless plug: I gave a presentation about this at last FOSDEM: https://fosdem.org/2024/schedule/event/fosdem-2024-2146-how-...

(otherwise @xcv123's sibling comment is very true).

Depends on whether the bug breaks games or not.

FPGA implementations are often implemented based on code or documentation from software emulation projects. An FPGA version of a PS2 has no guarantee of not implementing the same or similar bug.

Fixing this bug would be part of fixing a bunch of other floating point bugs, more specifically rounding and clamping.

Yes, software floating point would be slower, but the general solution would probably follow the PS4s PS2 emulator. Where each game can have whitelisted sections of code for the software floating point path.

Why would you want to emulate an old crappy MIPS CPU using a relatively expensive FPGA? The whole idea of emulating old consoles is to be independent of the hardware so you can play your old games on your computer or phone.

I came for this comment and there you are! Bravo

No, one is PS2, the other is PS/2.

To all the downvoters: Just because something is obvious to you doesn't mean that it is obvious to everyone else. Three character abbreviations can make context discovery really difficult as simply plopping the abbreviation into Google will quite often produce mostly unrelated results.