Uzebox Forums

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.

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.

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.

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

...though much less organized

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.

Huh, anyone? Any experience with those controllers using the FoaD version posted above?

If I find it I will let you know, so much stuff, so little organization on my part

Huh, anyone tried anyting on this? Nicksen maybe?

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.

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