Uzebox TODO list

[CunningFellow]

There is something very wrong with search engines these days.

[uze6666]

a few things I'd like to see eventually including a Uzebox multitap

Why make one when there's a lot to buy on ebay starting at USD50$? I doubt the cost and efforts to make one would be significantly under that.

[danboid]

DA said that SNES multitaps won't work with the Uzebox for some reason that I don't recall. He's tested it. I think its mentioned in the Mega Bomber thread.

[D3thAdd3r]

Yeah they don't keep clocking out the extra controllers like the NES ones do. You have to interface with an extra wire.

Probably true though, that modifying an existing one with an ATtiny85 would be cheaper/faster. Make it present data the same way the NES ones did and call it a day.

[nicksen782]

Do you guys remember that Uzebox Gamepad Translator device that I created a few years ago? It had the same shift registers on the side attached to the Uzebox and was accessed in the same way. The ATMEGA on that device would correctly poll the gamepad and then put the gamepad state on the shift registers that the Uzebox would read. The problem was that the kernel timing was off. That worked for gamepads based on shift registers but not for wireless gamepads that likely used a MCU. Is the multitap the same way? My code was really simple. The hard part was wiring it all. Would something like that device help?

[D3thAdd3r]

Something like that would it, or it could be part of the solution. If that, then why stop at multitaps.

I like Alec's "crazy idea" for the UzeBus. If sending it, may as well put the whole sledgehammer through. Address the devices you support, ignore the ones you don't. All backwards compatible with no kernel bloat.

Then a multitap is a subset use, and you would have an entire extra hacking base for Uzebox hardware projects. Read it all just like the mouse with extended data as needed.

[uze6666]

Yeah they don't keep clocking out the extra controllers like the NES ones do. You have to interface with an extra wire.

Oh ok, you mean it uses one of the extra connector pins the Uzebox doesn't use. In that case I get it. Gutting an existing one is an option. But rethinking about it, PCBs are cheap at JLCpcb and SNES connectors too on AliExpress. A quick estimate for 4 sness conn, pcb, extension cable and mega88 is ~20$. Just add 3D printed enclosure and you'be be good to go.

I like Alec's "crazy idea" for the UzeBus. If sending it, may as well put the whole sledgehammer through. Address the devices you support, ignore the ones you don't. All backwards compatible with no kernel bloat.

That would be nice, however I'm not sure it was implemented in the keyboard firmwares. I have to check.

[Artcfox]

Is there a free pin on the extension header that could be used for the extra wire in an official multi-tap?

[uze6666]

Is there a free pin on the extension header that could be used for the extra wire in an official multi-tap?

According to the pin allocation thread a couple pins should be free:

Code: Select all

PA5 (ADC5/PCINT5)      : (Joypad) /Free
PA6 (ADC6/PCINT6)      : (Joypad) / Free
PB2 (PCINT10/INT2/AIN0): Reserved 

PA5 or PA6 seems taylor made for this case . But of course one would need to have to hack a wire from the 644 to the snes port.