KallistiOS
Madcatz contoroller was malfunctioning in doom64 and GTA3
Hello. I have dreamcast madcatz controller which is just the very same controller as below link. https://retroravengames.com/products/mad-catz-sega-dreamcast-controller?variant=45599769919729 But whenever I run doom64 in dreamcast, it was totally malfunctioning. It was always moving sideways without pushing any button in control and whenever I pushed Dpad in main menu, any options always selected without pushing A or B or X or Y button.
I recorded this malfunctioning with android phone. https://www.dropbox.com/scl/fi/6ff1fzkl1itvh5v8kky2k/20250111_193835.mp4?rlkey=wkrmz5g2iinr2gutsw6tvs60x&e=1&st=0iovls1r&dl=0
And In GTA3,Whenever I got in a car,It always went backwards without pusing Z or C or trigger button. and Afterall, camera point of view won't changed freely. https://www.dropbox.com/scl/fi/opt0k421wci22zdozdn2t/20250111_192021.mp4?rlkey=0ht9yw07gkdh1zyovctbac5wu&st=5vzfz1ro&dl=0
Is there any fix for this malfunctioning of Madcatz controller?
Aaaaaaaah, so the plot thickens.
We've had reports of the RetroFighters controller malfunctioning on Doom64 and GTA3--always thinking the turbo and B buttons were held down. At the time, I hadn't heard of any issues with any other controllers, so I was more inclined to blame their HW.
The fact that you're now seeing this on a totally unrelated piece of HW (even if it's shitty Madcatz, lolol), leads me to believe that this may indeed be a KOS issue on our side... also I think I own that controller too and can help test/debug.
We had issues with saving on GTA3, and Chris (VM2, DreamConn) did a maple capture and found WE ARE SENDING PACKETS TOO CLOSELY TOGETHER TO MAPLE DEVICES. Evidently no more than 1 maple frame can be sent per vblank, and we were apparently violating that rule, so the VMU was not yet prepared to process the next Maple request...
I have a feeling all of these issues are interrelated and could all be caused by sending Maple frames too closely together.
@dogos1 if you have a setup to send an elf with console support, perhaps you could provide the output of this: https://dcemulation.org/phpBB/viewtopic.php?t=97047 with the controller connected? That would give the most detail we can get for IDing the controller from software.
We had issues with saving on GTA3, and Chris (VM2, DreamConn) did a maple capture and found WE ARE SENDING PACKETS TOO CLOSELY TOGETHER TO MAPLE DEVICES. Evidently no more than 1 maple frame can be sent per vblank, and we were apparently violating that rule, so the VMU was not yet prepared to process the next Maple request...
Is that per-device, per-unit, or a bus-wide limitation? If it's per-device then the cause might be fixed by https://github.com/KallistiOS/KallistiOS/pull/804/ . As the autodetection having its own frame meant that two frames could be sent to the same unit in the same vbl, which wasn't possible with the fully static frames as there would never be more than one frame around per device.
@dogos1 if you have a setup to send an elf with console support, perhaps you could provide the output of this: https://dcemulation.org/phpBB/viewtopic.php?t=97047 with the controller connected? That would give the most detail we can get for IDing the controller from software.
How can I execute "mapletest.bin" in dreamshell in order to provide the output script? FYI I have IDE/G1-ATA mod japanese V1 dreamcast and SEGA official and madcatz controller
We had issues with saving on GTA3, and Chris (VM2, DreamConn) did a maple capture and found WE ARE SENDING PACKETS TOO CLOSELY TOGETHER TO MAPLE DEVICES. Evidently no more than 1 maple frame can be sent per vblank, and we were apparently violating that rule, so the VMU was not yet prepared to process the next Maple request...
damn i didn't know about this problem, is it only original hardware and usb4maple that can handle this. before only WINCE could create a problem for 3rd party devices, because their packets were too close to each other and created problems for slow devices
#1147 May positively impact this issue, if it is related to general command traffic. It blocks a number of different commands that could be sent to memory cards that, depending on the specific one, would cause hardware errors to be thrown and could stop the whole controller from working right. This would impact sending LCD, Beep, or Clock commands to non-VMU memcards (3rd party or official 4x VMS)