Fix for slow SNES controllers

[Bluescreen2001]

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)

[danboid]

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?

[danboid]

Seems you forgot the commit message for your latest commit. What's been fixed in this latest commit?

[danboid]

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."

[danboid]

@Bluescreen2001

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.

[Bluescreen2001]

@danboid

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.

[danboid]

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.

[danboid]

I have posted one of these slow controllers to Uze today.

[danboid]

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.