Hacker News Reader

Comment by mcronce | Hacker News Reader

I can't speak to the Genesis specifically, but in general software emulation introduces tiny inaccuracies, in the form of missed inputs (because of things like context switches - it's important to note that, while these old consoles were hilariously slow compared with modern hardware, they were single-threaded), slightly incorrect emulation speed, things like that.

For most people, myself included, this doesn't matter at all.

For people looking for an extremely "pure" original experience, this is the closest you can get to original hardware - which is getting both more expensive and lower quality with time.

For the competitive speedrunning scene, incorrect emulation speed is a non-starter in some categories, and dropped inputs are a huge problem when they happen.

View on HN

How do context switches cause dropped inputs? My understanding is that input in modern OSes works like this: the kernel reads the input device or handles an interrupt from it, it passes the input event to the window manager, which puts it into the queue of the relevant app. The UI thread of the app then eventually picks it up and processes it. I see how this can cause delayed inputs, but dropped?

I don’t think the old gaming hardware really ran an OS in the way you think of it.

IIRC the cartridges were effectively just PROMs (I could be wrong and maybe they were fabbed / silicon and didn’t get programmed) which held the application code.

Video game cartridges were typically mask ROMs, but the effect is the same. There was virtually no software resident in the console; everything the user interacted with was running from the cartridge.

(The Genesis had a tiny ROM for the TMSS licensing check, but that was only 2KB, most of it image data -- and it was only used during system startup.)

Yes yes everyone here gets that. The question is why would emulation on a modern OS lead to dropped inputs.

If running under Ubuntu, even some of the native software can't handle keyboard events properly. For example, open 'Text Editor', try to open a file, and in the dialogue search for 'hello world'. Notice that if the system is under load, you will in fact search for 'hdlrow olle'.

This feels like a problem with the Linux desktop stack. Never had this problem neither on macOS nor on Windows. When the system is under heavy load, the events are usually buffered and the app processes them in a quick succession as soon as its UI thread gets to run.

It's clearly just a bug that the event order gets reversed somewhere.

Yes, console games of that era ran on bare metal. My question is how running an emulator of such a console on a modern preemptive-multitasking OS could cause dropped inputs.

In a modern application on a modern OS, USB events are buffered. You don't get hard guarantees about how quickly they reach your application. But they will get there albeit often with multiple frames of latency.

On 8/16bit consoles everything was tied to the video chip. You essentially have to do your CPU work (including polling the controllers) during the vblank interval, a short time window that occurs 60 times per second on NTSC systems. This is essentially a zero-lag arrangement (max latency is 1/60th of a frame, average is 1/30th of a frame) but if you miss a controller input it's gone forever.

I'm not entirely sure how emulators handle this. They could deliver buffered controller inputs to the emulator on successive input polls for guaranteed delivery, but then the emulated software is going to see a lot of inputs with wacky timing that may or may not screw with game logic (think of a fighting game where you need to input specific things in sequence in specific time windows) so simply dropping inputs may be preferable to delivering a log jam of inputs.

As you are intuiting, this isn't generally an issue on modern hardware. Emulated games play fine. But, also... if you have a chance to sit down with real hardware connected to a CRT... it feels different. 1/30 frame of lag vs. multiple frames.

I _think_ the argument is that the emulator runs on a per-frame basis, and the treatment of very short sub-frame-duration button presses may be different?

Afaik no emulator runs at frame granularity.

Emulators have tons of sync points, less than real hardware, but still plenty. The more sync points you add the slower emulation gets most of the time. Do we emulate transferring x length of bytes to a buffer in another part of hardware (video ram for example) one system bus wide word at a time or do we just cope it all at once and move on? etc.

> Do we emulate transferring x length of bytes to a buffer in another part of hardware (video ram for example) one system bus wide word at a time or do we just cope it all at once and move on? etc.

Syncing aspects of the emulated hardware with each other is easy. You still have to count clock cycles somewhere. So you just execute the necessary number of CPU cycles while your DMA is running, then set the flag that it's done or whatever. And you have to do the same thing with hardware timers anyway — you trigger an interrupt after X clock cycles.

It's syncing the emulator itself to real time that's tricky.

Don't most games of the era basically only poll inputs once per frame anyway? The Mega Drive six button controller basically relies on that behaviour, and the list of games that need to be forced into 3 button mode is quite short.

For starters, you can't run this kind of emulator on a per-frame basis (i.e. run all the game code for one frame, then wait for vsync on the host system, then repeat) if you want sound. Games rely on running at a certain clock speed and they generate sound by writing to the registers of the sound chip. They sometimes do it more frequently than the refresh rate of the screen. You have to sync with real time much more often than once per frame for everything to work as intended.

That doesn't make sense. You're confusing inside-emulation time with outside-emulation time. It's entirely possible to run an emulator for a frame at a time and get the sound right; the emulator just needs to run things in the right order or with the right internal synchrony.

It's also entirely possible to run an emulator at many times real-time and get the sound output correct, however you use it. You can use this to quickly get wav/mp3 copies of game music, for example.

Can’t you just queue up a frame of sound and then play it?

Reply on news.ycombinator.com