Joystick testing thread

[Sorgelig]

Centipede Arcade supports only simple joystick.

[mlc4050]

Yes the testing I did was on SNES, Genesis, and NES. I can test any other Core if needed.

I have to do some more testing but so far using MiSTer_20200109 works fine with this this adapter. I'll test versions past this and see what version made this adapter stop working and report back.

After doing some further testing it looks like MiSTer_20200225 is the first binary that stopped the Mayflash SNES USB adapter from working properly for both Ports on the adapter and being able to use 1 and 2 player.

Thank you Jeebs, after a night of headaches, your quoted post is the answer to my problem. The 20200225 binary also prevents my Xin Mo 2 player usb encoder from working as a 2p controller as well, where instead both controllers control the same player (although it is recognized as js0 and js1 under /dev/input). The Xin mo will work correctly as a 2p controller otherwise in earlier mister binaries after putting usbhid.quirks=0x16c0:0x05e1:0x040 in the u-boot.txt file under the linux/ folder

[paulbnl]

After doing some further testing it looks like MiSTer_20200225 is the first binary that stopped the Mayflash SNES USB adapter from working properly for both Ports on the adapter and being able to use 1 and 2 player.

That is the release with the new way of merging devices. The VID of your adapter needs to be added to disable merging for Mayflash devices.

[Jeebs]

After doing some further testing it looks like MiSTer_20200225 is the first binary that stopped the Mayflash SNES USB adapter from working properly for both Ports on the adapter and being able to use 1 and 2 player.

That is the release with the new way of merging devices. The VID of your adapter needs to be added to disable merging for Mayflash devices.

How do we go about doing that?

[Jeebs]

After doing some further testing it looks like MiSTer_20200225 is the first binary that stopped the Mayflash SNES USB adapter from working properly for both Ports on the adapter and being able to use 1 and 2 player.

That is the release with the new way of merging devices. The VID of your adapter needs to be added to disable merging for Mayflash devices.

How do we go about doing that?

I'm not sure what format this should be in but it seems this might be the VID info?

Code: Select all

input_0e8f_3013_v3.map
HID\VID_0E8F&PID_3013&REV_0111&Col02
0e8f:3013

I also tried adding usbhid.quirks=0x0e8f:0x3013:0x040 to the u-boot.txt file but the issue was still there with this device.

[paulbnl]

How do we go about doing that?

You have to ask Sorgelig nicely.

[Jeebs]

How do we go about doing that?

You have to ask Sorgelig nicely.

I see thank you.

Sorgelig could please add this in when possible? Pretty please with a cherry on top

Disable Merging for the Mayflash VID

Code: Select all

input_0e8f_3013_v3.map
HID\VID_0E8F&PID_3013&REV_0111&Col02
0e8f:3013

[mlc4050]

How do we go about doing that?

You have to ask Sorgelig nicely.

I see thank you.

Sorgelig could please add this in when possible? Pretty please with a cherry on top

Disable Merging for the Mayflash VID

Code: Select all

input_0e8f_3013_v3.map
HID\VID_0E8F&PID_3013&REV_0111&Col02
0e8f:3013

Hi Jeebs,
As a rainy day (self quarantine) project, I got the Xin Mo adapter working with the latest released. With the same steps the Mayflash adapter would work as well.

Long explanation if you want to try this, you need a linux computer with Git installed.
1. Using the directory of your choice, clone the mister main repo:
git clone https://github.com/MiSTer-devel/Main_MiSTer.git

2. change directory to the repo folder you just cloned:
cd ./Main_MiSTer

3. git checkout origin/master (pretty sure the latest commit on master is checked out by default, but making sure)

3. The file that needs to be updated is input.cpp, I used nano to edit the file:
sudo nano input.cpp

4. The line of code needing to be changed is this (at line 2734 in the latest verison of the code)
if (input.vid == 0x289B) continue;

5. Change this line to (based on your Mayflash adapter VID of 0x0E8F, the Xin Mo is 0x16c0 for reference):
if(input.vid == 0x289B || input.vid == 0x0E8F) continue;

6. Save and exit

7. make the project, this builds the MiSTer binary:
make

8. After make is complete, the MiSTer binary will be sitting in the same directory as your repo

9. Transfer this file to your MiSTer (through FTP probably), and voila

Keep in mind that putting a new MiSTer release binary on your Mister would overwrite this change until it's supported in the Main_MiSTer repo, but thought it was a fun and doable project if you wanted to get your Mayflash adapter working with the latest version of the code.

-mlc4050

[Jeebs]

Hi Jeebs,
As a rainy day (self quarantine) project, I got the Xin Mo adapter working with the latest released. With the same steps the Mayflash adapter would work as well.

Long explanation if you want to try this, you need a linux computer with Git installed.
1. Using the directory of your choice, clone the mister main repo:
git clone https://github.com/MiSTer-devel/Main_MiSTer.git

2. change directory to the repo folder you just cloned:
cd ./Main_MiSTer

3. git checkout origin/master (pretty sure the latest commit on master is checked out by default, but making sure)

3. The file that needs to be updated is input.cpp, I used nano to edit the file:
sudo nano input.cpp

4. The line of code needing to be changed is this (at line 2734 in the latest verison of the code)
if (input.vid == 0x289B) continue;

5. Change this line to (based on your Mayflash adapter VID of 0x0E8F, the Xin Mo is 0x16c0 for reference):
if(input.vid == 0x289B || input.vid == 0x0E8F) continue;

6. Save and exit

7. make the project, this builds the MiSTer binary:
make

8. After make is complete, the MiSTer binary will be sitting in the same directory as your repo

9. Transfer this file to your MiSTer (through FTP probably), and voila

Keep in mind that putting a new MiSTer release binary on your Mister would overwrite this change until it's supported in the Main_MiSTer repo, but thought it was a fun and doable project if you wanted to get your Mayflash adapter working with the latest version of the code.

-mlc4050

This is a fun little project to test out. Thanks for the info. I tried it on Ubuntu within Windows 10 WSL and I'm getting the following when using make. Thoughts? What version of Linux should be I using? I can always fire up a VM.

Code: Select all

arm-linux-gnueabihf-gcc: error trying to exec 'cc1plus': execvp: No such file or directory

[mlc4050]

Hi Jeebs,
As a rainy day (self quarantine) project, I got the Xin Mo adapter working with the latest released. With the same steps the Mayflash adapter would work as well.

Long explanation if you want to try this, you need a linux computer with Git installed.
1. Using the directory of your choice, clone the mister main repo:
git clone https://github.com/MiSTer-devel/Main_MiSTer.git

2. change directory to the repo folder you just cloned:
cd ./Main_MiSTer

3. git checkout origin/master (pretty sure the latest commit on master is checked out by default, but making sure)

3. The file that needs to be updated is input.cpp, I used nano to edit the file:
sudo nano input.cpp

4. The line of code needing to be changed is this (at line 2734 in the latest verison of the code)
if (input.vid == 0x289B) continue;

5. Change this line to (based on your Mayflash adapter VID of 0x0E8F, the Xin Mo is 0x16c0 for reference):
if(input.vid == 0x289B || input.vid == 0x0E8F) continue;

6. Save and exit

7. make the project, this builds the MiSTer binary:
make

8. After make is complete, the MiSTer binary will be sitting in the same directory as your repo

9. Transfer this file to your MiSTer (through FTP probably), and voila

Keep in mind that putting a new MiSTer release binary on your Mister would overwrite this change until it's supported in the Main_MiSTer repo, but thought it was a fun and doable project if you wanted to get your Mayflash adapter working with the latest version of the code.

-mlc4050

This is a fun little project to test out. Thanks for the info. I tried it on Ubuntu within Windows 10 WSL and I'm getting the following when using make. Thoughts? What version of Linux should be I using? I can always fire up a VM.

Code: Select all

arm-linux-gnueabihf-gcc: error trying to exec 'cc1plus': execvp: No such file or directory

Give this a crack:

1. dpkg --list | grep compiler

This will show the compilers you have installed, check if you have g++.

2. If not, Install g++
sudo apt-get install g++

alternatively try the instruction here, it installs gcc, g++ and others: https://linuxize.com/post/how-to-instal ... ntu-18-04/

3. If make still errors out after installing g++, try a test compile on input.cpp, and see if you get an output file (input.o):
g++ -o input.o input.cpp

4. check for input.o:
ls


Ping me back with the g++ compile output if make doesn't work. Also, ping me back if it does

[Jeebs]

Give this a crack:

1. dpkg --list | grep compiler

This will show the compilers you have installed, check if you have g++.

2. If not, Install g++
sudo apt-get install g++

alternatively try the instruction here, it installs gcc, g++ and others: https://linuxize.com/post/how-to-instal ... ntu-18-04/

3. If make still errors out after installing g++, try a test compile on input.cpp, and see if you get an output file (input.o):
g++ -o input.o input.cpp

4. check for input.o:
ls


Ping me back with the g++ compile output if make doesn't work. Also, ping me back if it does

I ended up going a little bit of a differnet route with it being Windows 10 and using Ubuntu via WSL. Here's what I ended up doing in case this helps someone down the road.

1. Launched the Linux Shell and ran: sudo apt-get install make
2. Created a directory for GCC/Other Tools if needed: C:\wsl
3. Navigated over to that path via Linux Shell: cd /mnt/c/wsl
4. wget -c http://snapshots.linaro.org/components/ ... ihf.tar.xz
5. tar xf gcc-linaro-5.4.1-2017.01-rc2-x86_64_arm-linux-gnueabihf.tar.xz
6. Added the following to the Windows PATH: C:\wsl\gcc-linaro-5.4.1-2017.01-rc2-x86_64_arm-linux-gnueabihf\bin

After that I was able to user Make successfully.

[macle]

Hello,

There are plenty of comparisons of latency of 8BitDo "M30 2.4g" vs "M30 BT" in wireless mode, but I cannot find any which compares wired mode.

Is there a difference in latency in case of this two models when they are used in wired mode??

Regards,
M.

[SegaSnatcher]

Hello,

There are plenty of comparisons of latency of 8BitDo "M30 2.4g" vs "M30 BT" in wireless mode, but I cannot find any which compares wired mode.

Is there a difference in latency in case of this two models when they are used in wired mode??

Regards,
M.

M30 BT is much worse wired than the M30 2.4Ghz wired.

https://github.com/eniva/MisSTer_Guides ... ce-Ranking

[macle]

Hello,

There are plenty of comparisons of latency of 8BitDo "M30 2.4g" vs "M30 BT" in wireless mode, but I cannot find any which compares wired mode.

Is there a difference in latency in case of this two models when they are used in wired mode??

Regards,
M.

M30 BT is much worse wired than the M30 2.4Ghz wired.

https://github.com/eniva/MisSTer_Guides ... ce-Ranking

Thats what I looked for. Thank you.

M.

[redsteakraw]

Just a question theoretically can USB polling be overclocked further than 1000Hz? Is this even possible? Would this require a custom driver or firmware would this saturate the USB's bandwith, would this break compatibility with practically every joystick / controller?

[dukrous]

Just a question theoretically can USB polling be overclocked further than 1000Hz? Is this even possible? Would this require a custom driver or firmware would this saturate the USB's bandwith, would this break compatibility with practically every joystick / controller?

From what I know USB 2.0 high speed has a max polling rate of 8000 Hz. The DE10-Nano may be different. I've never dug into it.

Practically, it doesn't seem all that useful. With 1000 Hz you're talking about an input every 1ms. If the game is moving along at 60 FPS, then you're talking about 1 frame every 16ms. Unless you have a really amazing reaction time that is consistently faster than 1ms, with a 1000Hz polling rate it should feel instantaneous to you.

[redsteakraw]

Just a question theoretically can USB polling be overclocked further than 1000Hz? Is this even possible? Would this require a custom driver or firmware would this saturate the USB's bandwith, would this break compatibility with practically every joystick / controller?

From what I know USB 2.0 high speed has a max polling rate of 8000 Hz. The DE10-Nano may be different. I've never dug into it.

Practically, it doesn't seem all that useful. With 1000 Hz you're talking about an input every 1ms. If the game is moving along at 60 FPS, then you're talking about 1 frame every 16ms. Unless you have a really amazing reaction time that is consistently faster than 1ms, with a 1000Hz polling rate it should feel instantaneous to you.

The Idea is given that there are active open projects to create controllers / adapters I just want to know what the limits. so 1 / 16.667 = 0.059 or 100-5.9 = 94% In frame input that is good but If you have the hardware to do better it would be worth a shot.2000hz is .5/16.667 = 0.029 or 97.1% in frame 4000hz is .25/16.67= 98.6% in frame. Yes there are diminishing returns but it may make a difference for speed runners. The only other thing is if the game code is polling at a given interval could you have a sort of input sync where you set the input at 60hz or multiple of 60 120, 180, 240hz and reset the polling to sync up with the game code. Assuming everything is regular and not sporadic could you theoretically get 100% in frame polling? Or are game code pollings not regular enough?

[dshadoff]

99% of games read the joypad value at the time of VBLANK.

This isn't necessarily the same thing as VSYNC, as most video controllers from that era assert VBLANK after the last scanline has been drawn, but often quite a bit before VSYNC occurs. And this varies by game, or even within the same game, based on where in the frame that last line is drawn.

Ideally, you want to present the already-read joypad values to the game's joypad read routine as late as possible prior to the actual read. I can't imagine a scenario where 1ms is measurably too slow for a human.

The exception cases are:
1) a small number of games which poll mid-frame as well as at the interrupt time (this is part of the 1%, but 1ms should service it just as well)
2) special controllers, which may rely on timing as part of the communication protocol (which need to have special processes written for them anyway)

If you are building a USB controller to poll faster than 1ms, that's fine but don't expect the system to add faster-than 1ms scanning.

[Sorgelig]

The minimum polling time for HID devices is 1ms.
Also calculating about possible lag due to missed polling window(i.e VBLANK) is not really correct. Core has current button state the whole time. So once you press the button before the vblank, it will be registered.
I think the input lag is just an display output lag. If screen has 2 frames lag, then of course you can't press the button earlier than 2 frames after the event.
Without lag you have the whole screen time to press the button. And of course games never designed when in one frame nothing happens and next frame you are too late. It's always something which is visible several frames so you have enough time to react.
Old controllers weren't ideal too. With rubber keys and oxidised contacts they also had lags. Even process of pressing the key often is more than 1ms.
Thus picking only one parameter and scream "arghhh, 1ms poll is too long" is not correct. You always have to analyse the whole chain of events where 1ms poll is a shortest part in the whole chain.
In most heavy sutuations i think it's beyond the MiSTer and belongs do doctors dealing with OCD and obsessions.

[redsteakraw]

The minimum polling time for HID devices is 1ms.
...
In most heavy sutuations i think it's beyond the MiSTer and belongs do doctors dealing with OCD and obsessions.

I just wanted to know the limits and how far they can be pushed. Yes I do know how crazy it may sound but now it is crystal clear 1ms is the limit, and you likely won't have much gains beyond that and there is no trick you can do to get closer to 0 delay with a lower but well timed polling rate.

[Sorgelig]

I just wanted to know the limits and how far they can be pushed. Yes I do know how crazy it may sound but now it is crystal clear 1ms is the limit, and you likely won't have much gains beyond that and there is no trick you can do to get closer to 0 delay with a lower but well timed polling rate.

May be you can start from yourself? Human also has lag. And it's much more than 1ms. So try to fix your lag to 0 first
Otherwise you are trying to shave something like 1% from 100% which is basically meaningless.

[redsteakraw]

I just wanted to know the limits and how far they can be pushed. Yes I do know how crazy it may sound but now it is crystal clear 1ms is the limit, and you likely won't have much gains beyond that and there is no trick you can do to get closer to 0 delay with a lower but well timed polling rate.

May be you can start from yourself? Human also has lag. And it's much more than 1ms. So try to fix your lag to 0 first
Otherwise you are trying to shave something like 1% from 100% which is basically meaningless.

Maybe if I drink enough Monster Energy drinks and freebase speed, I may be able to over come that mythical 1ms, but performance enhancing drugs are cheating

[Sorgelig]

I'm using mini arcade cabinet PiCade. And what i want to tell - those big buttons with long travel distance and big joystick with also long travel between side to side - they have waaay longer lag than 1ms. It's physically impossible to operate faster than 1ms. I think the quickest reaction you can provide with such controls is about 20ms (without counting human's lag).
So stop to thing about input lag over USB - this is meaningless lag comparing the whole chain from your eye to screen.

[redsteakraw]

I'm using mini arcade cabinet PiCade. And what i want to tell - those big buttons with long travel distance and big joystick with also long travel between side to side - they have waaay longer lag than 1ms. It's physically impossible to operate faster than 1ms. I think the quickest reaction you can provide with such controls is about 20ms (without counting human's lag).
So stop to thing about input lag over USB - this is meaningless lag comparing the whole chain from your eye to screen.

I am done with it I accept 1ms is practically lag free for all intent and purposes, I am setting up a daemonbite arcade controls with a IL joysticks / buttons with mini leaf spring switches just waiting on a shipment. The last comment was a joke, and by no means do I promote freebasing speed or drinking 10 Monster energy drinks in one sit in.

[werpu]

I'm using mini arcade cabinet PiCade. And what i want to tell - those big buttons with long travel distance and big joystick with also long travel between side to side - they have waaay longer lag than 1ms. It's physically impossible to operate faster than 1ms. I think the quickest reaction you can provide with such controls is about 20ms (without counting human's lag).
So stop to thing about input lag over USB - this is meaningless lag comparing the whole chain from your eye to screen.

I am done with it I accept 1ms is practically lag free for all intent and purposes, I am setting up a daemonbite arcade controls with a IL joysticks / buttons with mini leaf spring switches just waiting on a shipment. The last comment was a joke, and by no means do I promote freebasing speed or drinking 10 Monster energy drinks in one sit in.

I second that, the usb chain is the strongest link in all delays, you wont even get a zero delay on an original arcade set for the reasons stated above.
1ms does not make any difference in a human analog movement delay which ranges between 20 and 100ms depending on the humans speed and throw distance.
There are bigger fish to fry than anything usb related like for instance modern tvs and game mode.

I once posted that exactly on reddit and basically said, stop concentrating on usb it is pointless, and did not get too many friends there the general reasoning that everything usb related is bad simply is so entrenched in peoples minds while their problems with input lag usually are elsewhere. But fact is, you have a throw/travel distance on any classical arcade stick which introduces an "analog movement til the microswitch triggers" delay, which is way higher than what usb ever produces, so usb does not make any difference there.

And face it the human brain can cope with a small delay pretty well. Fact is also a good gamepad produces less delay because you don´t have so much throw/movement before an action can be triggered, but the downside is you lose the nostalgic arcade feeling and sometimes precision in controls.

But generally the lag of arcade sticks is hard to measure because you cannot fully get the point where the contacts are connected, you hear the typical microswitch click but even then depending on the mechanism you still do not have a full contact at this precise moment adding a few ms on top until you have electrical contact. Either way, stop concentrating on raw usb speed it is pointless at this point in time.

But that does not change the fact unfortunately that some encoder boards and controllers are really lousy introducing delays way higher than what a human would introduce (mostly cheap stuff thrown at the buyers for a few bucks) and that some tvs even in game mode add a lot of delay which is in the same ballpark at what humans introduce into the chain. But that is just a lousy controller/board but not usb itself.