3 ms·
> I understand a lot of it is the process of translating machine code from, say, the GB processor to x86, but I’d love to learn more! You don't really need to
by akdas 8y ago
> I understand a lot of it is the process of translating machine code from, say, the GB processor to x86, but I’d love to learn more!
You don't really need to translate to x86 per se. You can start off with an interpreter that takes in the 6502 or Z80 instructions (as represented by the binary data in the input ROM), then immediately perform operations based on those instructions. For example, if you're holding onto an in-memory representation of the GB registers, and you encounter an "add" instruction, you would perform the addition and update the registers.
And if you're writing the emulator in a high-level language, you never really think about x86 instructions.
The hard part, then, is timing. You need to make sure the different operations that would be happening in hardware--namely performing the CPU instructions, alongside audio and video operations that would normally happen "in the background"--happen in sync. But that's a later step after you start on your first prototype!
- CobrastanJorji 8y agoI have a question there. CPU instructions and what they do are highly documented and easy to replicate, but I'm guessing that timing is significantly less slo. How do you get that right?
- akdas 8y agoTimings are usually documented as well, usually at the clock cycle level. Beyond that, you have to worry about hardware peculiarities that happen to affect maybe a few games, and at that point, you might start reverse engineering the behavior of those games! Take a look at this article talking about exactly those thinking issues: https://www.tested.com/tech/gaming/2712-why-perfect-hardware-snes-emulation-requires-a-3ghz-cpu/ https://www.tested.com/tech/gaming/2712-why-perfect-hardware...
- Narishma 8y agoWhy not link to the original article? https://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/ https://arstechnica.com/gaming/2011/08/accuracy-takes-power-...
- akdas 8y agoOops! I searched for the article, then picked one of the results. I didn't realize the one I linked wasn't the original because I only looked through it enough to make sure the right content was present. Thanks for the correction!
- flohofwoe 8y agoOne way is to keep track of the emulated CPU clock cycle count, and each emulated instruction adds to this count. In each host system frame, run the emulation for the number of cycles the 'real' emulated system would be able to run in that time. The number of cycles per instructions can be either looked up from a table, hardwired into the emulation code, or if your emulated CPU is working on a "sub-instruction" granularity, the cycles per instructions "fall into place" automatically. For instance if your host system's frame duration is 16.6ms (for a 60Hz framerate) and your emulated CPU needs to run at 1 MHz you compute the number of clock cycles as (1000000 / 60), that's about 16k cycles per second. Run the system emulation until the accumulated cycle count is >= that number each frame, and if you're emulation is fast enough you still have plenty of time left in the host system frame to render the emulator's video output, audio and an UI on top.