Emulation catching up to real hardware responsiveness


Bob at Retro RGB was supposed to do a shoot-out between the best options for this. I have yet to make my Arcade Pi yet and I was waiting for his thoughts. I liked Bob’s videos and hopefully he will update his site with his findings.


I’m waiting in line for that thing, currently delivered only in France. Once they get in touch with me and I know how many I can order, I’ll make an announcement on Discord to give you guys the option to buy it through me. I doubt it will be more than a couple though.


It’s fully Scart compliant and does controller input via the Pi GPIO (not USB). So far the feedback has been very good and I have very high expectations for it. I’ll use it as a bare board all purpose machine for a while but I intend to put it in the CRT bartop that I will make (someday).


The RetroTINK seems to be the front runner right now from what I gather, if you care about Component/S-video output and 8-bit color. I’m on the fence about it right now because they are pricey.


Otherwise there are a few (much) cheaper options for RGB via VGA. RetroRGB did a brief overview of some of them, like @Kawika said there was supposed to be more detailed comparisons in the works, but with Bob taking a step back from content creation for now, I’m not sure when that will be.

Here’s the video with the overviews.


I have this setup,works great. I use it for MAME on one of my blast cities and sometimes on the PVM. You need the VGA adapter for the pi and a VGA to SCART adapter,then just have the pi boot into 240p. I dont know the exact name but I had to import it from Europe. It works fantastic. Not sure if there is a better method now but its what I used a couple years ago.


What do you use for controls? Does the scart connector have an audio amp?

I’m guessing you can do 240 through the VGA on the Blast?


This seems like the natural progression for emulation ever since VRR displays hit. I still use my original hardware when possible and will continue to do so as long as I’ve got a working CRT setup, but for the future? I’m extremely on board with them. They’re much more appealing to me than dedicated scaler hardware.


Yeah 240p through VGA into the Nanao board which autoswitches so it can be used for the “newer” games that ran higher res,for the older blast cities you needed to manually switch. Yeah the connector has audio out.

I just use a usb adapter for the controls. Pretty much any will do,have Xinmo’s in a couple of the others.


So, don’t windows/emulators poll controllers at a slower rate than native hardware though? I could have sworn I read something by Byuu that explained this at some point.


Brunnis addresses that in his post, quoted below. Elsewhere in that thread he also says his findings suggest that lag incurred from PC overhead (USB, OS) is completely overblown – basically anecdotal/outdated/baseless information that continues to be passed on and on as the truth despite improvements in emulators.

Before we dive into the results, let’s take a quick look at the Raphnet Technologies Classic Controller to USB Adapter V2151. This is a pretty serious adapater that is configurable via a Windows/Linux application and features upgradable firmware. One of the things that is configurable is how often the adapter polls the controller for input. Please note that this is not the same as the USB polling (more on that below). We have two components here: 1) How often the adapter polls the controller itself and 2) How often the computer polls the adapter (i.e. USB polling rate). On the single player version of the adapter, the adapter can be set to poll the controller with a period as low as 1 ms (2 ms for the 2-player version).

As for the USB interface, one of the things that makes this adapter so good is that it is hard coded to use the fastest polling frequency the USB standard allows: 1000 Hz (as opposed to 125 Hz, which is the default used by pretty much all gamepads). This means that you don’t have to fiddle with operating system or driver hacks to use the faster polling rate. It just works. This fast polling rate more or less eliminates input lag caused by the USB interface, cutting the average input lag from 4 ms to 0.5 ms and the maximum from 8 ms to 1 ms.

If we combine the 1 ms USB polling rate with the 1 ms controller polling rate, we get a maximum lag of just 2 ms and a blistering average of 1 ms.


If we combine the 1 ms USB polling rate with the 1 ms controller polling rate, we get a maximum lag of just 2 ms and a blistering average of 1 ms.

So does this mean that emulation controller input is actually faster than real hardware?


No. Real hardware uses interrupts, as in when the button is pressed, a trace is shorted and a pin on the CPU changes states (is grounded or is given +5V, aka 0 or 1). Which in turns provokes a cascade of events depending on how the code is written. The process in virtually instantaneous and the processor is completely passive, doesn’t waste resources checking the current status of the button.

This USB adapter seems to bridge the gap in terms of speed, relatively to older, slower technologies: 125Hz is 8ms, or half a frame. It can inconvenience some players on timing-sensitive games.

What we need to be concerned with is how does the machines deal with that input. On a real hardware, the physics engine is usually updated in between frames, when the electron beam is dragged back up. Some consoles can do their computation while the screen is being drawn and display the result in the following frame, but it’s the same delay of less than a frame between your input and the result on the monitor.

In emulation, it’s a bit more complex. In order to have a fast result on moderately powerful computers, the software takes shortcuts and do operations out of order, computes the whole frame then display it. As a result, your input in on hold until the following frame at best. It’s a limitation inherent to the emulation process, your input as at minimum one frame of delay.

All this explained in that lengthy byuu interview


Uh not quite, well at least with NES/SNES it works like this:

Every 16.67ms (or about 60Hz), the SNES CPU sends out a 12us wide, positive
going data latch pulse on pin 3. This instructs the ICs in the controller
to latch the state of all buttons internally. Six microsenconds after the
fall of the data latch pulse, the CPU sends out 16 data clock pulses on
pin 2. These are 50% duty cycle with 12us per full cycle. The controllers
serially shift the latched button states out pin 4 on every rising edge
of the clock, and the CPU samples the data on every falling edge.

Each button on the controller is assigned a specific id which corresponds
to the clock cycle during which that button's state will be reported.
The table in section 4.0 lists the ids for all buttons. Note that
multiple buttons may be depressed at any given moment. Also note
that a logic "high" on the serial data line means the button is NOT

At the end of the 16 cycle sequence, the serial data line is driven low
until the next data latch pulse. The only slight deviation from this
protocol is apparent in the first clock cycle. Because the clock is
normally high, the first transition it makes after latch signal is
a high-to-low transition. Since data for the first button (B in this
case) will be latched on this transition, it's data must actually be
driven earlier. The SNES controllers drive data for the first button
at the falling edge of latch. Data for all other buttons is driven at
the rising edge of clock. Hopefully the following timing diagram will
serve to illustrate this. Only 4 of the 16 clock cycles are shown for


                        -->|   |<--

                            ---                               ---
                           |   |                             |   |
        Data Latch      ---     -----------------/ /----------    

        Data Clock      ----------   -   -   -  -/ /----------------   -  
                                  | | | | | | | |                   | | | |
                                   -   -   -   -                     -   -
                                   1   2   3   4                     1   2

        Serial Data         ----     ---     ----/ /           ---
                           |    |   |   |   |                 |
        (Buttons B      ---      ---     ---        ----------
        & Select        norm      B      SEL           norm
        pressed).       low                            low
                             -->|   |<--


So it’s more like the CPU polls the controller


Didn’t know that. I’d say the NES is the outlier here, and I was speaking more generally of consoles that have one line per button, or a multiplexer, like Atari VCS and any console using that standard, like SEGA consoles and non-IBM computers.


Pretty well all wired nintendo controllers work similar to that, like the controller has a shift register and once a frame the system polls it. I know genesis and compatible operate differently, not sure about saturn/dc, etc.


Makes an interesting cheap build. I am wondering if this has an enough power to make it a worthy emulation box.

I mean with freesync being almost a free upgrade you could stick a PC monitor right next to your pvm.


If you want an emulation focussed build then you should always go with Intel.

Only $15 more gets you an i3-7100 that has significantly better single thread performance than the 2200G, which will be very important if you want to make the most of latency reducing features like frame delay. I can guarantee that the 2200G will struggle with some of the the more demanding games in Dolphin like The Last Story and a lot of games when using software mode in PCSX2.


I didn’t know about that. I stopped using emulation years ago. I just thought it would be nice to have a cheap way to get freesync instead of going the nvid route. the price of the intel machine would go up considerably if you wanted to pair it with a freesync monitor and have to buy a gpu.


If you already have a Freesync monitor then yeah it’s a very good deal, quite incredible how capable integrated graphics are nowadays.


I ordered the Raphnet Classic Controller to USB adapter mentioned in the link in order to get the lowest possible controller lag. With the recommended Retroarch settings I’m expecting not to notice any input delay.


It looks like it’s been released. Anyone try it out?

Wait, nvm this is something different. Says lag can match, or be less with issues, than og hardware