Daemonbite Sega adapter doesn't break cycling

[redsteakraw]

I made a 2 player Daemonbite Sega adapter.
I cannot get SAM to recognize the inputs to break the cycling. If I pick up the controller and start playing it will cycle to the next game after 3 minutes. The keyboard does do a good job at breaking the cycling but not the gamepad.
here is the Dmesg output for my input.

input.txt

[mrchrisster]

Hey thanks for letting us know. I have a daemonbite snes controller and I'm happy to test it when I get a chance. We fixed a problem with joystick input detection yesterday. So first, can you make sure you're running the latest version by running MiSTer_SAM_on.sh

[redsteakraw]

I deleted the ini file and updated to the latest version just to make sure.

[mrchrisster]

Does it work now?

[redsteakraw]

I updated it just now and it still doesn't work

[mrchrisster]

What happens if you just have only this one device connected to the MiSTer and issue the following command through SSH: while true; do if [[ $(xxd -l 128 -c 8 /dev/input/js0 | awk '{ print $4 }' | grep 0100) == "0100" ]]; then echo "Button pushed"; fi; sleep 0.2; done Try pushing some buttons and see if it outputs something. Also what's the output from ls -lah /dev/input

[redsteakraw]

I am able to get the "button pressed" text if I roll the dpad while pressing a button but it doesn't show reliably. If I press any button by itself it won't show anything or if I just roll the dpad it won't show anything.

ls -lah /dev/input total 0 drwxr-xr-x 4 root root 260 Apr 27 17:43 . drwxr-xr-x 12 root root 1.9K Apr 27 17:43 .. drwxr-xr-x 2 root root 160 Apr 27 17:40 by-id drwxr-xr-x 2 root root 160 Apr 27 17:40 by-path crw-rw---- 1 root input 13, 64 Apr 27 17:40 event0 crw-rw---- 1 root input 13, 65 Apr 27 17:40 event1 crw-rw---- 1 root input 13, 66 Apr 27 17:40 event2 crw-rw---- 1 root input 13, 67 Apr 27 17:43 event3 crw-rw---- 1 root input 13, 68 Apr 27 17:43 event4 crw-rw-r-- 1 root input 13, 0 Apr 27 17:40 js0 crw-rw-r-- 1 root input 13, 1 Apr 27 17:40 js1 crw-rw---- 1 root input 13, 63 Apr 27 17:40 mice crw-rw---- 1 root input 13, 32 Apr 27 17:40 mouse0

[mrchrisster]

That's great info thanks. We just tested mayflash and xbox which works as expected. It seems like 8bitdo is working a bit differently

[mrchrisster]

Just tested my daemonbite snes adapter and i can't replicate your problem unfortunately. output is as expected for SNES daemonbite. (You have to hold down a button for a few milliseconds to get the button pushed message)

[mrchrisster]

one other thing you could test is while true; do xxd -l 200 -c 8 /dev/input/js0 |grep 0100; sleep 0.3; done (for button pushes) and while true; do xxd -l 200 -c 8 /dev/input/js0 |grep ff7f; sleep 0.3; done (for dpad right)

[redsteakraw]

For the first one similar results left or right plus the B button seems to give results but not anything on it's own

00000008: 19f3 5300 0100 8101 ..S..... 00000068: 3ef7 5300 0100 0101 >.S..... 00000080: aff7 5300 0100 0101 ..S..... 00000090: 1af8 5300 0100 0101 ..S..... 000000b0: eef8 5300 0100 0101 ..S..... 000000c0: 2bff 5300 0100 0101 +.S..... 00000008: a900 5400 0100 8101 ..T..... 00000078: 9d03 5400 0100 0101 ..T..... 00000090: 9004 5400 0100 0101 ..T..... 000000b0: cb21 5400 0100 0101 .!T..... 00000058: 5725 5400 0100 0101 W%T..... 00000078: 4a26 5400 0100 0101 J&T..... 00000098: 5127 5400 0100 0101 Q'T..... 000000b0: f629 5400 0100 0101 .)T.....

The second one is a little less reliable but similar only if I press left or right while pressing the B button. The Daemonbite adapters / arcade sticks have the d-pad emulating a joystick where at resting state is 0 and when right is pressed the value is 32767 and left is -32767 up is 32767 for Y and down in -32767 for Y

[redsteakraw]

while true; do xxd -l 200 -c 8 /dev/input/js0 |grep 0100; sleep 0.3; done

this doesn't work with button presses on their own just the b button with right or left at the same time.

while true; do xxd -l 200 -c 8 /dev/input/js0 |grep ff7f; sleep 0.3; done

this also doesn't work when just pressing the d-pad only pressing the dpad right or left while pressing the b button

[mrchrisster]

thanks, so it definitely works differently than the joysticks we tested. we might have to use a different way to detect button pushes.

[redsteakraw]

So I did some testing and jstest seems to accurately show the joystick button presses on the --old interface but only lists the a and b button. None of the event commands work

[mrchrisster]

great, that would have been my next question.

#!/usr/bin/env python

import struct
import time
import glob
import sys

packstring = "iiiiiiii"

infile_path = sys.argv[1]
EVENT_SIZE = struct.calcsize(packstring)
file = open(infile_path, "rb")
event = file.read(EVENT_SIZE)
(a,b,c,d,e,f,g,h) = struct.unpack(packstring, event)
b = b %10
d = d %10
f = f %10
h = h %10
print(b,d,f,h)

Can you test this python script please and see if it captures all 4 main buttons? This is our old detection script... Save it as joysniff.py and run it with while true; do joysniff.py /dev/input/js0; done Thanks again for your help on this!

[redsteakraw]

okay so the script works for A B C and X

4 0 6 2 5 0 6 2

so it adds 1 to the number for the corresponding button when pressed, for example the output shows when nothing is pressed then I pressed the A button.

[mrchrisster]

Excellent. so we could implement that and that should make your controller work (and probably everyone else's who has issues with the current joystick detection) I'll submit the script to our test branch. Don't have much time the next couple of days but hopefully we have it all working by the weekend for you.

[Mellified]

The test branch has the new python-based controller detection code. If you're feeling brave you can download the "on" script from test, update the INI to 'branch="test"' and give it a whirl. We're still debugging it though.

[mrchrisster]

we would appreciate if you can let us know if this works for you

Install this version of MiSTer_SAM_on.sh Install this version of MiSTer_SAM.ini Change #branch="test" to branch="test" in MiSTer_SAM.ini and run MiSTer_SAM_on.sh

[redsteakraw]

I have to do some more testing but so far it seems to be working.

[redsteakraw]

Yes it seems like the test branch fixes the problem. Thank you! I can now leave my MiSTer on and pick up my controller and play when something that is interesting cycles in! I am going to test a couple of other controllers I have to see if I can find bugs in this implementation. But so far my Sega Daemonbite adapter is working as expected.

[mrchrisster]

Excellent, thanks for the feedback. I'll close the issue for now. Please open a new issue if you find any problems with the testing implementation.

[redsteakraw]

Tested my NES, Arcade and Sega Genesis Daemonbites and there are no problems and I tested my iBuffalo SNES style controller and there are no problems with that as well the new joystick detection is working as intended!

[mrchrisster]

Oh wow, you got all the low latency controllers! Thanks for doing some testing. Right now we can't detect dpad button pushes yet, something I will try to get working today.

[redsteakraw]

I technically bought the iBuffalo because it was the cheapest SNES style controller for my retropie, only years later did I find out it also is one of the lowest latency controllers in general. I made all the other daemonbite adapters and controllers from arduino pro micros and extension cables, and a jamma harness for my arcade stick. I also have a working coin mech in my joystick. I am happy to test what I have to make sure everything is working.

[mrchrisster]

Thanks for helping us test the new python implementation, you'll get a mention in the readme ;) Arduino pro micros are awesome, I have 3 daemonbite devices here as well. I cleaned it up a little more and noticed that start and select button were not recognized. Would you mind updating MiSTer_SAM_on.sh and test once more if it's working?

[redsteakraw]

Everything is broken, the SAM won't launch and If I launch it manually it won't cycle at all.

[mrchrisster]

I've taken out start and select button detection. Hopefully this will make it work again for you

[redsteakraw]

Everything seems to be working again

[mrchrisster]

ok great thanks. I'll leave it like this then for now.

[mawk]

Is this fix present in the main branch now? I'm currently having some issues with joystick detection using the 8bitdo arcade stick. I believe that it's a similar situation as above, where I'll attempt to play a game by turning on and connecting the arcade stick, but none of the inputs seem to get detected (by SAM that is, haha. able to play games okay) and SAM moves on to something else. Should I test out the test branch?

[mrchrisster]

Hey mask, the main branch now has the same code as the test branch so no need to switch. Does the problem persist after a reboot?

[mawk]

Woah! You bet it does. I hadn't noticed that before:

It happened to me once, I did a normal reboot and just loaded up any old game. Then after playing that for some time, SAM took over and loaded up one of the random games.

Let me know if you need any additional data and I'll get it your way.

[mawk]

Hey, just checking in. Any idea how I might get around the above issue?

[mrchrisster]

Hey mawk, let's try and figure this out together! First thing would be to get the dmesg output after you connect your device. Can you open ssh, disconnect the controller, then plug in your controller and type dmesg. Can you send us the relevant info about your controller? Also, currently we don't have Bluetooth support. Is your controller a Bluetooth device?

[mawk]

Yup, sure thing! And nope, not bluetooth, using the 8bitDo 2.4Ghz USB adapter.

input.txt

[mrchrisster]

Hmm, looks like the 8BitDo Arcade Stick is registered as hiddev0 which none of my devices are, so it's not easy to check what can be done here... My guess is the arcade stick is not being recognized internally as a joystick on the MiSTer. You can check that by typing ls -l /dev/input/js* on ssh (with only the arcade stick connected) and see if there are any js devices. Here is my output:

/dev/input# ls -l /dev/input/js*
crw-rw-r-- 1 root input 13, 0 Dec 31  1969 /dev/input/js0
crw-rw-r-- 1 root input 13, 1 Dec 31  1969 /dev/input/js1

We can try and use keyboard detection if it works like a keyboard. What happens when you enter while true; do xxd -l 8 -c32 "/dev/hidraw0" | cut -c1; done If it continually displays a 0, it won't work. If it only displays a 0 when you push a button, we can add your controller easily to the script.

[mawk]

Prior to connecting the 8BitDo arcade stick, checking for joysticks gives me this:

/root# ls -l /dev/input/js* crw-rw-r-- 1 root input 13, 0 Dec 31 1969 /dev/input/js0

After connecting it, I see:

/root# ls -l /dev/input/js* crw-rw-r-- 1 root input 13, 0 Dec 31 1969 /dev/input/js0 crw-rw-r-- 1 root input 13, 1 May 15 17:24 /dev/input/js1

So that looks fine to me. Trying out the loop now...

/root# while true; do xxd -l 8 -c32 "/dev/hidraw0" | cut -c1; done 0 0 0 0

Which doesn't look great. Seems to output a "0" on its own ever few seconds without my pressing anything. Additionally, I'm not able to get any "0"s in response to button presses or joystick movements.

[mrchrisster]

great, that would have been my next question.

#!/usr/bin/env python

import struct
import time
import glob
import sys

packstring = "iiiiiiii"

infile_path = sys.argv[1]
EVENT_SIZE = struct.calcsize(packstring)
file = open(infile_path, "rb")
event = file.read(EVENT_SIZE)
(a,b,c,d,e,f,g,h) = struct.unpack(packstring, event)
b = b %10
d = d %10
f = f %10
h = h %10
print(b,d,f,h)

Can you test this python script please and see if it captures all 4 main buttons? This is our old detection script... Save it as joysniff.py and run it with while true; do joysniff.py /dev/input/js0; done Thanks again for your help on this!

Interesting that it shows up as two joysticks... Can you follow the steps from the quote?

Edit: Disregard the comment about showing up as two joysticks, just saw you had a joystick connected prior. It's best to test without any other peripherals connected so that the arcade stick shows up as js0

[mawk]

It's strange, I'm not sure what the additional joystick is to be honest. I don't believe that I have anything else hooked up... unless the IO board counts as some sort of input (since it has those three buttons on top... not sure!).

Regardless, I did run that code (tweaked the input to js1), and it looks like I am getting some changes when I hit the four main buttons:

/media/fat/Scripts# while true; do joysniff.py /dev/input/js1; done 4 0 6 2 4 0 6 2 4 0 6 2 4 0 6 2 4 0 6 2 4 0 6 2 4 0 6 2 4 0 6 2 5 0 6 2 4 1 6 2 4 0 6 2 4 0 6 2 4 0 7 2 4 0 6 2 4 0 6 2 4 0 6 2 4 0 6 2 4 0 6 3 4 0 6 3

Basically see the 4062 pattern repeat, with the values changing in response to the main button presses.

[mrchrisster]

ok, great. so basically everything seems to be working the way it should - and still something is wrong... so let's test the actual code

#!/usr/bin/env python

import struct
import time
import glob
import sys

packstring = "iiiiiiiiiiiiiiiiiiii"

infile_path = sys.argv[1]
EVENT_SIZE = struct.calcsize(packstring)
while True:
    try:
        file = open(infile_path, "rb")
        event = file.read(EVENT_SIZE)
        (a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t) = struct.unpack(packstring, event)
        if b != 8454144 or d != 25231360 or f != 42008576 or h != 58785792 or n != 109117440 or p != 125894656:
           print("Button pushed")
        time.sleep(0.2)
    except FileNotFoundError:
        print(" Joystick disconnected")
        sys.exit(1)

It checks for two more buttons and I suspect this is where the issue lies... Can you test if the message "button pushed" appears with the above code?

[mawk]

Yup, and it looks like I AM seeing the "button pushed" message (as well as the "Joystick Disconnected" when I disconnect it:

/media/fat/Scripts# while true; do joysniff2.py /dev/input/js1; done Button pushed Button pushed Button pushed Button pushed Button pushed Button pushed Button pushed Button pushed Button pushed Button pushed Button pushed Button pushed Button pushed Button pushed Joystick disconnected Joystick disconnected

The "Button Pushed" message is fairly responsive, and I'm seeing it with the two extra buttons you mentioned as well. So it basically seems like it's doing what you'd expect

[mrchrisster]

Ok thanks for checking. So we know the code works as expected. What the js0 device could be is a mystery to me.. it's not the IO board, at least it shows no js devices for me with IO board.

It might be worth trying to reset MiSTer SAM and pull a fresh copy as described in the readme. Your 8bitdo controller is recognized correctly so it shouldn't give us any trouble..

[mawk]

Ugh, that did it. I'd tried updating and deleting the MiSTer_SAM.ini, but I'd missed the .MiSTer and the SAM contents in the /media/fat/ dir, and getting rid of those followed by an update must have done it. Sorry for taking up your time with the debug!

I love the script and plan on using it pretty extensively. Thanks again for all of the help getting it to work

[mrchrisster]

Awesome man. Glad we got it working :) Have a great rest of your day!

[mawk]

Hey mrchrisster!

Just wanted to report back in on something I just realized.

I started having that same old issue again where the arcade stick wasn't getting recognized, and I started poking about a bit to see if I could isolate the cause. I think I have an idea, and it may be something you're aware of already.

When I have some controllers connected to the MiSTer and do a cold reboot, they show up like this when I SSH:

/root# js.check crw-rw-r-- 1 root input 13, 0 Dec 31 19:00 /dev/input/js0 crw-rw-r-- 1 root input 13, 1 Dec 31 19:00 /dev/input/js1 crw-rw-r-- 1 root input 13, 2 Dec 31 19:00 /dev/input/js2

You can see the datestamp is much older. And all connected controllers are recognized and SAM is working as intended.

However, when I take one of those controllers and disconnect/reconnect and re-run the js.check:

/root# js.check crw-rw-r-- 1 root input 13, 0 Dec 31 1969 /dev/input/js0 crw-rw-r-- 1 root input 13, 1 Dec 31 1969 /dev/input/js1 crw-rw-r-- 1 root input 13, 2 May 16 12:22 /dev/input/js2

There you can see that one of the joysticks now has an updated timestamp associated with it, and that joystick won't interrupt SAM cycling, while all of the others still will.

I'm guessing that you're aware of this hotplugging behavior, but I just wanted to report that this seems to really be what was going on the other day.

Do you think you'd be able to support hotplugging at some point? I see a keyboard hotplugging issue open, but I'm not sure if js hotplugging is also on your radar. This would be cool for people who like to use the 2.4Ghz wireless adapters, since those controllers will be turned on/off when not in use.

As always, thanks so much for all of the hard work and support for this awesome MiSTer script!

[mrchrisster]

Js hotplugging detection is a feature of SAM. We'll look into it!

[mrchrisster]

Hotplugging has been fixed and should work now in latest main. Just update with MiSTer_SAM_on.sh and let us know if it works for you please :)

[mawk]

Hey there, just updated and gave it a shot, and I'm still having some issues. With that being said, I think that I can sort of provide a little more feedback. I was looking how how the script works a little bit (stil don't have a super clear understanding of it), and it looks like something it breaking down during the activity checking.

When I connect the controller, I can see inside the /tmp/.SAM_Joy_Change that the controller is detected:

/dev/input/ CREATE js2 /dev/input/ CREATE js2 /dev/input/ CREATE js2 /dev/input/ CREATE event4 /dev/input/ CREATE event4

However, after pressing some buttons, on the joystick that I just connected, I'm not seeing anything show up in the /tmp/.SAM_Joy_Activity file. I believe that it's this activity file that the script is checking in on to see if there's a need to interrupt the cycling. Also, I've verified that I do see "Button pushed" when I test out another controller (one of the ones that were connected on start-up).

I know that we verified that this joystick's inputs are recognized with the joysniff.py file, so I'm not sure what's going on at this point. I figure I may poke around a bit more if I've got the time, but I wanted to give you the update.

[mawk]

Another potential breadcrumb:

I rebooted to the OSD, and connected my joystick then, prior to the game looping starting up (so /tmp/.SAM_Joy_Change & /tmp/.SAM_Joy_Activity didn't update from the last looping set of data). Essentially, SAM was just checking for the default 60 seconds of inactivity at this point.

Then, once the first game started up, I checked the /tmp/ files, verified that they'd been reset (no record of the joystick change, just some events -- makes sense, since the js had been connected prior to the game looping starting & no "Button pushed" in *_Activity), and then mashed on some buttons with the joystick. At this point, checking the /tmp/.SAM_Joy_Activity showed "Button pushed", and the game loop breaks.

So all this seems to indicate to methat there's some disconnect in the Joy_Change -> Joy_Activity tracking.

[mawk]

Alright! Last update for now! One more breadcrumb:

I found that when I navigate through OSD and activate the MiSTer_SAM_on.sh (and then just hit the first option to enable SAM now), that everything works as it should:

• I'm able to connect my arcade stick on the fly
• /tmp/.SAM_Joy_Change detects that a joystick has been added
• /tmp/.SAM_Joy_Activity gets the button pushed when I smack some buttons on it

However, after I break out of that initial game loop, I think that the communication breaks down. If I go back to OSD from there and wait until the game looping starts up again, then things start to misbehave:

• disconnect js (*after game looping restarts)
• /tmp/.SAM_Joy_Change reflects this with some "DELETE js2" lines
• reconnect js
• Again, /tmp/.SAM_Joy_Change reflects this with some "CREATE js2" lines
• However, when I smack the buttons this time, I don't see anything updated in the /tmp/.SAM_Joy_Activity file

So I'm thinking that there's some issue with the loop that we end up in when we break out of the initial cycling and fall back into the general monitoring loop... Speculation since I still don't fully understand all of the behavior here, but that's what I'm thinking.

Hopefully all of this is clear and helps with some of the debug!