Fix for slow SNES controllers #117
Conversation
I added a new game controller query routine. This solves problems with many of these cheap SNES controller core which have no shift registers but a Microcontroller onboard. These are often too slow to be queried by the stock readbuttons routine. Use the define SLOW_CONTROLLERS=1 for enabling the new routine, which is default in this fork. How it works: The stock routine reads the controller during VSync with nearly no delays. This results in very short load and clock pulses, which are too fast for some controllers. The new routine reads one bit per scanline, after the HSync pulse. It therefor needs 17 scanlines. These fit in the area below the VSYNC and the active video frame. Let's call it the upper border. This results in a much slower clock sequence for the controller without wasting time in delay loops. Drawbacks: At the moment there ist no mouse support because the upper border area has not eneough lines for that. Maybe I can move the routine to the active video area, but that might break video timing at some games.
|
I don't think that Matt and Lee own any controllers that are affected by this? This works for me so maybe if Thorsten changes it to being off by default and the old controller code is used by default instead this could be merged? Lee - you said this causes problems for your cuzebox fork? |
|
Seems you forgot the commit message for your latest commit. What's been fixed in this latest commit? |
|
DethAdd3r's post regarding this PR on Uzebox forums from https://uzebox.org/forums/viewtopic.php?t=11311 "I finally got around to checking out BlueScreens hsync code, and it seems great to me. Still need to test it on hardware, it does break emulation for Keyboard+Mouse versions of CUzebox but that needs a rework anyway. It's also optional, and it's nice to have the option since many over the years have these types of controllers. My guess, this will be a standard option going forward. I would add it default to my games retroactive if it works out. That said, I don't see why Hyperkin mouse can't be an additional option. Basically a compile option to handle whether hsymc reads happened or not, where if they did, just do the extended read portion with increased timing. The first 16 bits are done, maybe that still comes close to the traditional read it all in vsync SNES mouse method? Also not opposed to a PS/2 mouse option, but for compatibility I think it needs to output in SNES format and work with any reading scheme which works for Hyperkin or SNES mouse." |
Added some descriptions.
Changed some pins for freeing up the second UART
Addet Photos
|
It's not my project so @uze6666 may disagree with me but I don't think your schematics are likely to get merged into the main Uzebox repo. You'll notive that non of the other Uzebox variants have had their designs added to the main repo, even the well documented ones with gerber files and cases etc such as the EdUzebox. For the moment you can create a new thread on the Uzebox forum, most likely under Hardware sub forum, and share your schematic there. Eventually I expect @uze6666 will also create you a wiki acount. Your fix for the slow SNES controllers however is likely to get merged into the main Uzebox repo but I think Uze is likely to ask to reduce this commit just to the SNES controller fix. What you could do is fork the Uzebox github repo and change it how you want to match your design, it is open source after all, but I wouldn't expect Uze to merge anything back other than your slow SNES pad fix. |
|
Thank you for your advice. I didn't expect to merge my hardware into main Uzebox repo. It is too special with all this adapter stuff. This Repo is already a fork of the main repo (at least I hope so, this github stuff is new to me and I don't fully understand it). I want all my Uzebox stuff together at one place and I don't know how to submit the slow controller fix to main, but not my hardware. |
|
I am getting concerned that Uze is no longer with us. Its been several months since he has posted anything to the Uzebox forums. I hope I'm wrong. |
|
I have posted one of these slow controllers to Uze today. |
uze6666
force-pushed
the
master
branch
3 times, most recently
from
954076a to
9a17b0b
Compare
|
I think @Bluescreen2001 will have to re-commit this? When I say re-commit I mean it may need to be re-organized a bit to match the current Uzebox repo structure. My recollection is that Thorsten's slow controller fix couldn't be adopted mainly because it stopped building and working but there were other reasons too I think, as if that one wasn't good enough. What are your thoughts on adding the Omega gerbers etc to the official repo @uze6666 ? We had a few revisions in quick succession but that isn't going to continue. It might be a good idea to wait a few more weeks because soon Jimmy will be building an Omega 1.4 and he should be testing the final two untested features - the microsd socket and using a ESP12F soldered to the PCB, with the correct cap etc to use Uzenet. I've only tested Uzenet via the ext header on it so far and soldered an ESP to an Omega's PCB with the wrong firmware. I've built 5 Omegas so far and not had any issues other than those that have since been fixed like the tolerance of the din socket holes. |
Some cheap SNES controller are very slow. The standard Uzebox kernel queries the controller too fast, so these controller don't work.
This fix queries the controller during HSYNC with one pulse per scanline, which should be slow enough for even the slowest controller.
But there is a drawback: no mouse support. I have not enough free scanlines to support this. Therefor I implemented a deinfe switch for disabling the new behaviour:
SLOW_CONTROLLERS = 0 : Disable slow controller support, enable mouse support as before
SLOW_CONTROLLERS = 1 : Enable slow controllers (default)