emulation-articles

It's really difficult. Unlike floppy disks, where you tell the drive to seek and get back raw magnetic pulses (so you can produce raw flux images), or hard disks where you tell the drive to read an arbitrary sector and get a blob of data (so you can produce sector-level images), the protocol for talking to a CD ROM involves asking for track/sector addresses, which means you have to trust the drive to interpret all the track metadata and error-correction for you - you generally can't just dump the "raw" data and do the interpretation yourself. That's why the most robust CD image format is the BIN/CUE format. The BIN file contains all the sectors the drive allows us to read, the CUE file contains the disc metadata as interpreted for us by the drive firmware. There are some drives which support extra "raw read" commands, but they're incredib

Correct. If I had access to a reasonably priced 1000Hz monitor, I would use it, for exactly this reason. It's not just this one thing in isolation, it's the whole tool chain, and latency is cumulative. So, for a simplified example, if I have a bluetooth keyboard in the mix, and it adds 50ms, then with your numbers, I'd have 52ms total, which is indeed better than 55ms. It all adds up, and with enough links in the chain adding their own little bit, it can easily add up to be perceptible and meaningful. I wish I could link you to byuu's deep dive on emulator latency so you could see where I'm coming from, but their site is now offline and has been excluded from the Wayback Machine. This is the old link, in case anyone knows of a mirror: byuu.org/articles/latency/ Edit: found a mirror: https://github.com/higan-emu/emulation-articles/tree/mas

Super Mario World and many other SNES (and later) games spends two frames after a controller jump input sending unchanged frames on-screen, before showing a frame where the player is jumping (tested in slow-motion camera). Emulators (and possibly FPGAs) can use run-ahead to skip past one or more of these "no change" frames, reducing input latency to match or surpass console latency (https://github.com/higan-emu/emulation-articles/tree/master/...). Another strategy is to delay polling input computing the next frame until the end of the previous frame being drawn (RetroArch frame delay). This does not rely on the game not responding immediately to controller input, but is more prone to dropping frames if your CPU gets occupied and can't run your emulator for a few milliseconds. It is possible to compute and display images in near-real-time