PC Engine Homebrew News: The duo that brought you FX-Unit Yuki returns! A demo for "Nyanja!" is available, an action platformer akin to games like Bubble Bobble & Snow Bros in gameplay style.
Main Menu

Six-Button Controllers through a TurboTap

Started by TailChao, 02/25/2018, 01:45 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

TailChao

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.

Avenue_Pad_6_Schematic.png
Based upon this six button schematic, 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.

TailChao

Guess I'll answer my own question.

IMG

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.

fluxcore

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.
There is no knowledge that is not power

TailChao

Quote from: fluxcore on 03/03/2018, 02:32 PMIn 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.

NecroPhile

Quote from: TailChao on 03/03/2018, 09:41 AMIMG
I won't pretend to understand any of what you guys are talking about, but this gif is awesome.  :mrgreen:
Ultimate Forum Bully/Thief/Saboteur/Clone Warrior! BURN IN HELL NECROPHUCK!!!

exodus

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)

TailChao

Quote from: exodus on 03/08/2018, 02:24 PMI'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.

ccovell

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.  :(

TailChao

Quote from: ccovell on 03/12/2018, 08:24 PMThe 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.

ccovell

Quote from: TailChao on 03/12/2018, 10:28 PMGetting 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.