PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: TailChao on February 25, 2018, 05:45:38 AM
-
I'm trying to read the state of multiple six-button controllers through a TurboTap. Unfortunately I don't own any of these controllers nor could find any information on how this is supposed to work.
Based upon this six button schematic (http://www.webalice.it/cicciopetito/archivio/Avenue_Pad_6_Schematic.png), and these TurboTap notes I'm guessing you'd do the following :
1) Start with SEL high and CLR low.
2) Raise and lower CLR to reset the turbotap.
3) Read in all five controllers' data by toggling SEL ten times...
3a) IFF the controllers' data are all low when SEL is high, THEN this is a six button controller. We can assume the data pulled in when SEL is low will be the extra buttons' states.
3b) IFF the controllers' data were all low when SEL was high previously - but aren't now, THEN this is a six button controller and we're pulling in the "default" button set.
3b) IFF the controllers' data are never all low when sel is high, THEN this is definitely a two button controller.
4) Repeat steps 2-3 a second time to identify and fetch the other half of the data for any six button controllers.
Any help would be appreciated.
Edit : Made signal names a little more clear.
-
Guess I'll answer my own question.
(http://karnovssecretclub.com/Purgatory/TurboPoll.gif)
Looks like my guess above was correct. Below is some more info about the tap :
Rising Edge of CLR resets the TurboTap and selects Controller 1.
|
V
___ ___
CLR ____/ \_________________________________________________/ \___ ...
____________ ___ ___ ___ ___ _________________
SEL \___/ \___/ \___/ \___/ \___/ ...
^
|
If CLR is still high on the Rising Edge of SEL, Controller 1 will remain
selected and SEL1 will just toggle. So the Rising Edge of CLR resets the
tap and the first controller will remain selected until it lowers.
____ _________________________________________
CLR1 \___________/ \_______ ...
____________ _________________________________________________
SEL1 \___/ ...
________________ _________________________________________
CLR2 \_______/ ...
____________________ _________________________________________
SEL2 \___/ ...
________________________ _________________________________
CLR3 \_______/ ...
____________________________ _________________________________
SEL3 \___/ ...
________________________________ _________________________
CLR4 \_______/ ...
____________________________________ _________________________
SEL4 \___/ ...
________________________________________ _________________
CLR5 \_______/ ...
____________________________________________ _________________
SEL5 \___/ ...
After ten edges on SEL, the tap will deselect all controllers. I've seen claims that repeatedly toggling SEL after this will either cause the tap to wrap around or just stop reading and output "0000" - I've gotten both behaviors to occur and can't find a pattern for either. So my guess is that the intended behavior was the tap should stop reading after ten toggles of SEL but this doesn't work right so don't depend upon it in any software.
-
I made some slight notes on the functionality when writing the PC Engine handling for the UPCB controller's 6 button functionality, so this is kind of the other end of what you're talking about:
https://github.com/fluxcorenz/UPCB/blob/master/tg16.h
In particular, this may interest you:
"On the six button Avenue6 controller, the enable pin is also used to
check an additional two banks by alternating between the banks each
time enable is dropped. Rather than the usual 5 cycles of the select
line, SF2 (and presumably other 6 button games) only send 3 cycles,
and then reset the enable pin, so it doesn't lose resolution by
having to poll twice."
SF2 doesn't fully read the inputs from ports 3-5. IIRC port 3 is partially read (I think the RUN button is checked?), but the 4 and 5 are basically unread. Seems like the behaviour is driven by the game.
-
In particular,SF2 doesn't fully read the inputs from ports 3-5. IIRC port 3 is partially read (I think the RUN button is checked?), but the 4 and 5 are basically unread. Seems like the behaviour is driven by the game.
Good to know, thanks!
It makes sense that SF2 is using a simplified read routine like that. If it only needs support for two players there's no point in spending time reading in the extra data.
-
(http://karnovssecretclub.com/Purgatory/TurboPoll.gif)
I won't pretend to understand any of what you guys are talking about, but this gif is awesome. :mrgreen:
-
I'm here for the turbotap gifs
(and this is interesting - is it that it's just not powering the other slots? does it take more power to get a 6 button controller going vs a 2? feels like that'd be pretty negligible)
-
I'm here for the turbotap gifs
(and this is interesting - is it that it's just not powering the other slots? does it take more power to get a 6 button controller going vs a 2? feels like that'd be pretty negligible)
All five controllers are always powered through the tap (and yes, the difference in power draw between three and six button controllers should be negligible). The important thing is that only one controller is selected at a time.
The tap could have been implemented a few ways in hardware to get the same read results (i.e. SEL could be passed to all controllers directly rather than the fancy counting sequence in the gif). But I want to make a knockoff to use FEKA controllers so the specifics are helpful.
-
The above facts that you illustrated with the GIF is sadly the reason that I discovered my RS232/UART monitor PCEmon can't be used with a TurboTap: there's no way to select one of the 5 ports, and then send serial data to it through the output lines. :(
-
The above facts that you illustrated with the GIF is sadly the reason that I discovered my RS232/UART monitor PCEmon can't be used with a TurboTap: there's no way to select one of the 5 ports, and then send serial data to it through the output lines. :(
You might actually be able to send data out, it's just not convenient and you could only use the first port on the tap. You're using Output 0 (SEL) for TxD and Input 3 ("L / RUN") for RxD, right?
The rising edge of CLR will always reset SEL1 to a high state. If you keep CLR high instead of lowering it like the documents say - then toggle SEL, SEL1 will toggle but the tap will never advance to the next controller port. So if you program the transmit routine to abuse this it should work.
Getting data in or doing full duplex would be a bigger problem.
-
Getting data in or doing full duplex would be a bigger problem.
Yeah, the idea is both send/receive full(ish) duplex since the PCE also echoes each byte received as it comes in.