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.