Wireless SNES controllers

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Wireless SNES controllers

Post by Jubatian »

That's not a terrible amount of waiting, although of course for generating 16 pulses, it eats away about a scanline instead of a fraction of a scanline.

I think a better solution may be clocking the controller in HSync code, to remain compatible with the various video modes, after the video mode itself, or maybe after VSync (whichever is simpler in code and has 16 scanlines for this task, as far as I remember, the 224 line tall display starts at scanline 20, so after Vsync could be a nice place for this). This would possibly work well for both the mouse and these controllers without taking away more time than necessary from the VBlank available to games.

I think I will do an experiment with it on this weekend.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Wireless SNES controllers

Post by D3thAdd3r »

If we could support nearly all the controllers inside of HSYNC time, it would be quite a useful accomplishment. Especially the SNES mouse or PS/2 interface could benefit, probably, from the same solution later on.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Wireless SNES controllers

Post by Jubatian »

Here is a test version of Flight of a Dragon which I built using various SNES controller timing diagrams I found. It works on the real hardware, but not on either emulator! I fixed CUzeBox, though (so if you check it out and compile, this FoaD version will work properly on it). Uzem totally fails.

So, those of you who have these SNES controllers: Can you play this version? (Clock pulses are still quite short, about 1us, so whatever may happen. However this version should give the controller plenty of time, one full scanline between each sampling, to react so long it can catch the pulses)

Uzem... After a hour or so of frantic debugging peppering the bloody thing with "printf"s totally baffled about why my input was just disappearing like magic, I found it... it tries to recognize a keyboard interface by that the latch and the clock is low simultaneously which condition is also valid for the NES/SNES controller, so I ended up having code which does that since that was the only way to do it in the least amount of scanlines (there are only 19 there at 224 lines display height, and now I am using 18, so maybe one scanline extra is OK, then this method doesn't work). Why? Why? Why...

(Also Uzem acts on the wrong edge of the clock, so even eliminating this problem somehow, it still fails with the buttons jumbled up)

EDIT: I replaced the attached binary. It should work in the (unmodified) emulators, but the clock pulse is a bit narrower.
Attachments
foaddemo.uze
FoaD Demo with new controller handling
(59.16 KiB) Downloaded 604 times
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Wireless SNES controllers

Post by D3thAdd3r »

Looking at this more I think I actually have the one pictured somewhere, except it is a different color. I will try to find this and report back. I know it didn't work right stock, which is why it quickly met the random junk box(which is different from the garbage, though much less organized).
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Wireless SNES controllers

Post by Jubatian »

...though much less organized :lol:

Will be waiting for reports then! I used FoaD for now since it has a simpler, trimmed kernel, and I know better its video generation (which I rewrote from ground-up), however if this proves to be functional, I will implement it in the normal kernel. SNES mouse would be notably faster with the changes as there wouldn't be 10us (~280 clocks) waits in the main program between bits.

Of course then the bootloader still won't work, and every game in existence would require a recompile to work. Anyway, it is nice to improve hardware compatibility even if it can not be done for everything at once.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Wireless SNES controllers

Post by Jubatian »

Huh, anyone? Any experience with those controllers using the FoaD version posted above?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Wireless SNES controllers

Post by D3thAdd3r »

If I find it I will let you know, so much stuff, so little organization on my part :roll:
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Wireless SNES controllers

Post by Jubatian »

Huh, anyone tried anyting on this? Nicksen maybe?
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Wireless SNES controllers

Post by nicksen782 »

I don't think that I did. A kernel change would require the recompile of all games.

I wonder about a hardware solution. Something that can act as a go-between the Uzebox and the SNES controller.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Wireless SNES controllers

Post by Jubatian »

I meant whether you tried that FoaD version above with the controller, which have modified controller timings, to see whether that timing works.

Of course it's true that it would demand recompiling everything without a hardware solution. Either of these is problematic for its own. The HW solution could probably be quite messy, and possibly a lot harder to obtain than a recompile for games which have their source readily available (and still build all fine), and of course issues might arise with the change (A wild example: the modification demanded 2 extra bytes of RAM per controller. FoaD had exactly 2 bytes free, now in that game literally every single bit of the ATMega's 4096 bytes of RAM is used for something - if it hadn't got those bytes free, I would have had some quite difficult time to figure out how to add it without modifying something in the game's functionality. Of course normally I would rather expect timing issues arising in one or another game).

For the software solution luckily we have control over possibly the majority of the game sources (as we did some research after them during fixing up the Games and Demos list), so possibly we could improve the situation by recompiling those ourselves. That of course would still leave existing SD cards bundled with Uzeboxes without updated games, but there is no way to give those people a working solution without effort on their part (either refreshing their game library or building a hardware solution if they wanted to use these controllers).
Post Reply