Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|07685||DIP/Input||Minor||Always||Jun 12, 2020, 09:42||25 days ago|
|Tester||oboewan42||View Status||Public||Platform||MAME (Official Binary)|
|Assigned To||cuavas||Resolution||Fixed||OS||Windows 10 (64-bit)|
|Version||0.221||Fixed in Version||0.238||Build||64-bit|
|Fixed in Git Commit||d29287e||Github Pull Request #|
|Summary||07685: sonic, cabalus, possibly others using upd4701a: mapping joystick to trackball causes input to go haywire|
|Description||Moving an analog joystick axis that's mapped to a trackball axis - specifically one connected to a uPD4701A - causes the input to go haywire, even when sensitivity is set to 1. Mouse input appears to work fine.|
|Steps To Reproduce||Map an analog stick to a trackball (MAME is set up this way by default if you have a controller with an analog stick), then move the stick and watch the analog controls go haywire. Visible in-game, in the test menu in sonic, and in the "Analog Controls" menu. Compare with version 0.185.|
I vaguely remembered being able to play SegaSonic perfectly fine with an analog stick in an older version of MAME, so I checked for a regression. Last working version was 0.185, it broke in 0.186. Looking in the whatsnew it looks like there was a rewrite of the code for the uPD4701A around that time.
Tested in sonic and cabalus, both exhibit this issue, haven't had a chance to look at anything else (what other games use it?)
Centipede works fine, so it seems to be limited to that chip.
|Affected Sets / Systems||sonic, cabalus, possibly others using upd4701a|
|There are no relationship linked to this issue.|
Jun 14, 2020, 19:00
|I don't have a decent non-mouse analog device to use for testing at this time, but I've acknowledged for now.|
Jun 18, 2020, 17:47
This may be a problem with not accounting for PORT_RESET, which the uPD4701 emulation now depends on.
Other sets to test include arknoid2, ridleofp and simpbowl.
Jun 18, 2020, 19:10
|arknoid2 and ridleofp have the same issue (did not test simpbowl)|
27 days ago
|I wish there were some way to reproduce this without additional hardware.|
25 days ago
|The symptom is “fixed” but the real problem is that PORT_RESET is cancer and should be killed. It simulates an incremental encoder where the counter is automatically reset by the vertical blanking signal of the first screen in the system (or the 60Hz virtual first screen update for screenless systems). This is almost never correct. The systems/devices need to be fixed so they reset their up/down counters at the correct time.|