 |
|
|
| 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. |
|
| 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. |
|
| 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... |
|
| You assume an anti-piracy attempt when GP, from my reading, made no such statement. More of a mystery, but who cares because the problem hardware wasn’t what they shipped on. |
|
| Bingo! Didn't want someone running new product's app on old product's hardware. Company was new to building non-RTOS devices which were tightly hardware bound, wanted similar type restrictions. |
|
| >but it usually doesn't matter
When it comes to speedrunning: Some speedrunners do, though, to ensure their speedrun tech are reproducible on both emulators and real hardware. |
|
| Mainframes typically execute batch processes on a CPU. Much simpler than a game console with a GPU. Cycle-accurate emulation is less relevant for mainframes. |
|
| How do people get into emulation? It seems like an incredibly challenging niche within software.
You basically have to understand electronics and deep programming wizardry |
|
| 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. |
|
| You're welcome.
I learned about the basics here http://www.emulator101.com Then I read the docs at NESdev Wiki and eventually wrote my own NES emulator. https://www.nesdev.org/wiki/Nesdev_Wiki If you have good documentation then you're just following the specs and turning that into code. Next level difficulty is reverse engineering the hardware, figuring out how it works when there isn't any documentation. These guys did that for NES back in the 90s and early 2000s, writing little test ROMs to see what the hardware does, in addition to whatever official or unofficial developer docs they could find. |
|
| 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 :( |
|
| 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. |
|
| > There's a pretty decent chance it's simply too expensive!
I doubt the 24 year old, 300Mhz RISC, 32MB Ram, PS2 instruction set is too expensive to do a cycle perfect replication. |
|
| The CPU yes but you want to emulate every piece of hardware in the console. The audio chips, the GPU, they way video memory works and so on. |
edit: described in more detail here, among other emulation-busting measures from 2004 https://mgba.io//2014/12/28/classic-nes/