Page 3 of 5

Re: Wireless SNES controllers

Posted: Wed Jul 19, 2017 8:17 pm
by nicksen782
I think a hardware dongle would be best since it wouldn't require changes to any Uzebox games. No changes, no surprises. And, if you have wireless controllers then that is when you would need the dongle.

I could probably build something. Basically, the Uzebox polls too fast (or too slow) and the dongle needs to act as a sort of governor / repeater, right?

What is the timing that I would need? The controllers are just shift registers and I have a couple spare ATMEGA328s around.

Re: Wireless SNES controllers

Posted: Thu Jul 20, 2017 3:03 pm
by nicksen782
Okay, so I looked back at this thread and it has been stated that the Uzebox polls the SNES controller 10 times faster than the controller would normally expect. Shift registers are rather resilient so it hasn't been an issue. These wireless controllers must be more sensitive.

Slowing down the kernel sounds like a bad idea. I want a wireless controller without having to recompile every game/demo ever made. So, I propose the hardware dongle approach.

The dongle would poll the controller at a slower speed and keep the data in a buffer. When the Uzebox polls the dongle then the buffer would be sent to the Uzebox. The buffer would be constantly overwritten. So, the Uzebox gets to talk at it's faster speed and the wireless controller gets to talk at it's slower speed.

It would be nice to get male and female connectors for SNES controllers. I'll need to get that first really. a

Re: Wireless SNES controllers

Posted: Sat Jul 22, 2017 9:31 pm
by D3thAdd3r
Hardware dongle maybe isn't too bad for someone who really wants wireless controllers. Only thing I would suggest, is to make sure the performance on these is good first. The ones I tried, and maybe I tried multiple not sure they are these ones, did not work on Uzebox but did work on all tested SNES/Super Famicom games off my SD cartridge. "Worked" is relative, as the latency was so bad as to basically be unplayable. Literally destroys the feel of input/reaction...throw that on a laggy LCD, not worth playing. I remember for sure I back to back tested whichever ones they were with wired controllers, and the difference in feel was very high. Would have to be something in the radio link, might be Bluetooth.

At least I would compile some game with the slower timing(this is not what caused the latency of course), and try it with that to make sure the hardware approach is warranted. That said, if a solution comes to light I would be pretty interested in not having to use the extension cables I currently use.

As I understand it, to buffer a slower timing, you necessarily would only have that data after the poll it came in on. That would introduce ~17ms latency, though that sounds like nothing, it starts to add up if using an LCD, etc.

Re: Wireless SNES controllers

Posted: Sat Jul 22, 2017 9:37 pm
by D3thAdd3r
BTW the very cheapest source of male/female SNES ends is these ~$3+free shipping extension cables from China. I ordered a load of them for Uzebox1284, and if you take them apart they are quite usable for a lot of things.

Re: Wireless SNES controllers

Posted: Sat Jul 22, 2017 10:20 pm
by nicksen782

I wanted something decent so I bought SNES extension cables from Retro-bit. Same company that makes my wireless controller too. They fit fine and look good.

So, the problem is that the Uze polls too quickly? Yet, normal wired SNES gamepads work just fine. Why is that? Why is it that wireless gamepads malfunction or do not work at all?

Some research:
SNES controller signaling question :
Useful info was found here.

Pinouts & Protocol FAQ : ... /faqs/5395
Pinouts and some timing info. Especially "5. SNES Controller Communication Protocol". It states how to the first bit (button B) is a little different.

Arduino-SNES-Controller : ... r_test.ino
This code is rather simple and very close to what I intended to do.

So, what are my plans? Please look at the attached picture. I assume that the wireless controllers have an actual micro in them instead of simple shift registers. I'm further led to believe that shift registers can take a lot of abuse and still be happy. I wonder if the micro in the wireless gamepads are emulating the protocol directly and not any odd behavior of an abused shift register. This is my present hypothesis.

So, these wireless controllers need to spoken to correctly. Changes to the Uzebox kernel would affect over 100 games that would need to be recompiled. Also, not many of us have wireless controllers and what we have works. I would like to create a sort of bridging device that would talk to the Uzebox and the wireless gamepad receiver in exactly the way that each side wants to be spoken to.

I think that presenting the Uzebox with a shift register (directly) would be better than to try to emulate one on the micro (which I already believe is the reason that the wireless gamepads fail.) There is a poll speed difference, I know this. The Uzebox is faster.

Lets have the bridge read the values from the gamepad and literally output all 16 bits (the last 4 are always tied high and are optional) to a parallel-in shift register. Just make sure that the Uzebox isn't driving the latch of the shift register as the bridge device is.

If this works, then the shift register could be polled repeatedly by the Uzebox with no loss of data even if the data were not to change.

If the bridge could use a hardware interrupt to detect when the Uzebox is reading the shift register we could prevent the bridge and the Uzebox from accessing the shift register latch at the same time.

Okay, mind-dump complete. :) Comments?

EDIT: I just realized that only the Uzebox needs to drive the latch pin of the shift register! So, let's have the bridge just keep pushing the state it has of the game pad. When the Uzebox wants it then it will just do what it normally does which is latch it (gets new state on the shift register inputs) and then read it. No extra latency unless the reading from the gamepad itself is slow enough to notice.

Re: Wireless SNES controllers

Posted: Sun Jul 23, 2017 4:30 am
by D3thAdd3r
nicksen782 wrote:
Sat Jul 22, 2017 10:20 pm
Can't beat $1.42, single quantities, free shipping!
nicksen782 wrote:
Sat Jul 22, 2017 10:20 pm
Yet, normal wired SNES gamepads work just fine. Why is that?
Not sure how they implement it, but I would guess some custom epoxy blob ASIC or so. Maybe they use dedicated pins on that. Could be a limitation of the wireless stuff so they don't read any faster than they can send it, not sure. I have several weird SNES controllers besides the stock ones, that don't work, or they work but buttons are wrong, etc. where they work on SNES. Those are all wired and could probably be made to work with timings, but I didn't really like the feel of these ones anyway.

In a certain way this almost seems related to the keyboard, but the ultimate goal there being PS/2 mouse support as well, probably does not leave much room for other things.

Honestly you have me quite a bit more interested in this than I ever was before. If one was going to develop out a solution like this, it would be nice if it could be made to work with more than just that specific controllers. There used to be something called Direct Pad Pro, and it was able to read in all kinds of things like PSX controllers, Saturn controllers, Genesis controllers, etc. though to a parallel port on the PC. Not so applicable for this, but the style was built on config files which specified timing and stuff, so that weird things could be supported later like Atari Jaguar controllers.

Re: Wireless SNES controllers

Posted: Sun Jul 23, 2017 4:44 am
by D3thAdd3r
Actually thinking about it more, it seems a lot easier to use an ATtiny instead of shift registers and buffering logic. You could also eliminate any real latency, by reading just a little ahead of when the Uzebox will ask for it, which would require adjusting they delay after each frame to make up for clock drift. The ATtiny should be able to do 16mhz with the PLL, without an external clock and the accuracy should be good enough. I experimented with that for N64 controllers but never finished, based on an Arduino implementation. They literally had it working in C by analyzing the compilers output and doing different hacks to wait, but ultimately assembly is the right answer there.

Re: Wireless SNES controllers

Posted: Sun Jul 23, 2017 4:51 am
by CunningFellow

Is there a reason you don't feel like using a a USART in SPI mode rather than extra shift registers ?

The SPI hardware in a micro controller is really just an 8 bit shift register so should not have a problem with clocking speed. At least up too 1/2 of the micros external clock rate. If you use a USART rather than the vanilla SPI peripheral you even get double buffering so can load all 16 bits out at the same time.

With respect to D3thAdd3rs concerns about extra latency. You could have software time the read of the wireless controller so it ends exactly when the Uzebox is ready to ask for the bits.

Do you have any AVRs sitting around with USARTS in them?

Re: Wireless SNES controllers

Posted: Sun Jul 23, 2017 5:30 am
by nicksen782
I was suggesting that the bridge micro to act as 16 buttons against an actual shift register read by the Uzebox. I figured that the problem was that shift registers could take the extra polling speed. Ultimately, this bridge could work for other devices such as ps/2 keyboards that may require special timing. Heck, put a ps/2 port on the thing and flip a switch and you have a keyboard for Uzenet without having to cut wires.

I'm not sure how to use USART in SPI mode. My thoughts were to present the Uzebox with an interface that would work exactly the same.

I have some ATMEGA328 (Arduinos chips). I also have 3 SNES extension cords for sacrifice. Amazon had them on Prime and I wanted them quickly.

I'm hoping that within a couple days I will have something wired up.

Ideas are great! This is going to happen!

Re: Wireless SNES controllers

Posted: Sun Jul 23, 2017 8:55 am
by Jubatian
Uhh... Could anyone please tell anything about the experimental modified timing I posted earlier? I would still like to see whether the kernel itself could be changed to support these different controllers so long it doesn't break anything.

It can be implemented in parallel with a hardware solution. That way new or recompiled games would work fine without a hardware dongle, while the HW dongle would be available for older games which for whatever reason aren't possible to be recompiled.