Seriously?
So looking at the document at this link
https://www.cs.cmu.edu/~chuck/infopg/segasix.txt
And reading up how the 3 button and 6 button Sega Genesis/ Megadrive controllers work.
The Genesis 6 button controller is one of the laggest controllers ever built.
The Genesis 3 button controller used a 74HC157 multiplexer for an Encoder, making the controller pin compatible with Sega Mark III/Master System and Sega SG-1000 consoles (and other consoles that used a DB 9 connector like the Atari 2600) and those controllers compatible with the Genesis.
The controller was read in 2 cycles, first cycle pin 7 has zero change and reads the D-pad and the B and C buttons.
Second cycle, pin 7 gives +5 volts and the start and A buttons are read.
All states on all buttons canāt not be read simultaneously.
The 6 button controllers was a hack on the duplexing hack, and the controller is fully read in 4 cycles, a 3rd signal was given on Pin 7, a pulse which is used on the 3rd and 4th read.
The 3 button controller used discrete logic and the read time is in nano seconds, but the 6 button with itās custom chip can take as long as 200 milliseconds for all the button states to be read.
Somebody know about Qanbaās Dragon input lag ?
I will buy an Obsidian , i suppose it share the same Pcb or close to Dragonā¦
^ ditto any data on those new quanbas input lag ? In the market and between this or medketz
Would love to test them, but not going to buy one just to test.
Will take a bit of explaining as to exactly how these numbers were established, but will edit that in later.
So, the setup is the same as per previous times. Coloured band appears on the screen and a button on the stick/pad is triggered at the same time. I have used a 1ms input window to try to more accurately determine where the inputs are actually polled. When the latest input occurs, I capture a screen shot of this image, then count down to where the coloured bar is to determine how late in the frame the input has occurred. Converting this into ms is possible, and then 2F (33.33ms) is added for the next two frames until an animation change occurs.
An HDMI to Component converter is used, in a separate test Iāve established that this adds in the order of .25ms of lag.
Game is BBCPE as usually, chosen because it is rapid to respond, consistent and available across all the relevant platforms.
This looked at how early in the frame an input could occur. This is useful as combined with the other data it gives some idea of either how wide the polling window is, or how frequently the sticks are polled. The other piece of data that would be useful is how many results were generated from each set, however Iāll leave that for now.
As you can see, at least 10 results were generated for each stick (5 earliest and 5 latest). Iāve captured that many again, but in the interest of time havenāt analysed all of them.
Starting to love your work @noodalls !
So the wired USB mode for the dualshock 4 is slower than Bluetooth mode? Were your tests on ps4? I feel lied to by Sony!
All tests are on PS4.
Tried a new method of sending outputs to the sticks/pads/pcbs, to get a little more information out of each trial. I quite like the way that it works, so will write it up here.
As always, the setup is an arduino sending signals to push/release buttons while simultaneously turning off parts of a component video signal, so that a watermark appears on the screen to demonstrate when the button was pushed. For this test I used the UFB, as it has been reliably the fastest responding device. I also used BBCPE, which is my standard game as it is fast, and available across multiple formats.
What is different this time is that instead of a single input, I did two different inputs of different length. The cycle is 24 frames long, as this allows the BBCPE Ragna ducking animation to finish with no concerns of overlapping animation.
As usual, the input advances by 25-50 microseconds on each subsequent cycle.
The video demonstrating this is here.
https://www.youtube.com/watch?v=14sfHzLX8Q8
Now, it starts roughly at the top, ignore the first few cycles.
Putting things together a little bit, most sticks/pcbs/pads Iāve looked at must have a fairly high polling rate, as the results tend to bunched together fairly closely.
However, the MCCthulhu (on 10ms) and the TE2 donāt seem to behave like this. Even between them, my impression is that the X1TE2 polls maybe every 10ms (not the exact number) whereas the MCCthulhu keeps the polling window open for 10ms. The difference being the TE2 can still achieves results about as fast as the UFB at times, whereas the MC seemed to never get faster than about 10ms slower than the 1ms polling time result.
Explanation of input lag testing
https://www.youtube.com/watch?v=jNSWB6DwpgQ
Demonstration of input lag testing (wireless vs wired DS4 controller)
https://www.youtube.com/watch?v=07nKZBXed7M
Video captured during the above video
https://www.youtube.com/watch?v=ftlfQGZvFtw
1P red left new DS4 wired in USB mode , responding with green bar near the top of the screen. Top = earlier in the frame = slower.
2P blue right old DS4 usb cable connected for charging in wireless mode. Green bar later = faster.
Hello, I am wondering what is the best pcb board for pc? I mostly play SF5, It doesnāt matter it is via direct input or x-input as long as it most responsive. Also curious if there is a method to reduce input lag on pc (i.e premium sata USB board?)
Hori hrap VX , X360 seem one of the best.
so pretty much 360 lag result is applied to PC ?
I donāt know about other 360 arcade stick but i sure Hori hrap Vx is my fastest arcade stick on both 360 and PC.
It seem is faster than last ps4 Hrap 2017 too.
thank you for the info.