controller auto reset

For anything related to IO (joypad, serial, XE...)

Moderator: BigEvilCorporation

User avatar
KanedaFr
Administrateur
Posts: 1116
Joined: Tue Aug 29, 2006 10:56 am
Contact:

controller auto reset

Post by KanedaFr » Wed Jun 28, 2017 10:28 pm

Controller data is read by switching TL/TH
You have to switch them an even times.

What would happen if, by mistake, I switch them an odd times?
has the controller somekind of reset-to-defaut-after-X-ns feature ? or will my read be bugged for the rest of the game ? ;)

User avatar
TmEE co.(TM)
Very interested
Posts: 2307
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: controller auto reset

Post by TmEE co.(TM) » Wed Jun 28, 2017 10:53 pm

You'll eternally have wrong input if you don't do the switching right. TH and others remain what they were set by the code, they never magically change state if you wait, not even when you press reset. Only power-on-reset will reset controller ports IO to a predetermined state (and games use it to detect if there's a power on or a reset).
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

User avatar
HardWareMan
Very interested
Posts: 705
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Re: controller auto reset

Post by HardWareMan » Thu Jun 29, 2017 9:19 am

I think it doesn't matter which level of TL/TH you will keep after periph access routine. Most important is switch it to default right before new periph access.

Some doubts I have with 6-button joypat. It is have timeout to fall back to LRUD from XYZM. But I don't know, will it work with TL/TH = 0 or not. We need it find out.

User avatar
KanedaFr
Administrateur
Posts: 1116
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Re: controller auto reset

Post by KanedaFr » Thu Jun 29, 2017 11:53 am

It's exactly because of the 6B joypad that I asked this.

From what i know,

Code: Select all

asking ABC
wait vlank
asking XYZ
won't work

I remember a talk about how fast the reading should be to avoid "reset" for 6B pad, multiplayer,, .....

Mask of Destiny
Very interested
Posts: 567
Joined: Thu Nov 30, 2006 6:30 am

Re: controller auto reset

Post by Mask of Destiny » Thu Jun 29, 2017 5:45 pm

I'm not sure the exact reset value is known for the 6B controller. From looking at the PCB, it looks like it's probably using an RC-based timer which is probably going to vary in timing both from controller to controller and also with temperature. That said, the timing is such that if you have any kind of sane arrangement that polls the controllers once per frame, you'll never have a problem.

User avatar
Sik
Very interested
Posts: 706
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: controller auto reset

Post by Sik » Thu Jun 29, 2017 6:43 pm

On a 3 button controller it's literally just a MUX so it doesn't matter.

On a 6 button controller it increments a counter every time TH goes from 0 to 1. This part is important because a lot of people insist that the first step is $00 when it's $40, which can make things confusing if you aren't aware of it.

What I do is this:
  • $40 = first 3 button read (↑ ↓ ← → B C)
  • $00 = second 3 button read (A Start)
  • $40 = ignored
  • $00 = ignored
  • $40 = ignored
  • $00 = 6 button check
  • $40 = 6 button read (X Y Z Mode)
If the 6 button check fails, reading ends there since it must be a 3 button controller (where this doesn't matter). If the check passes, then the sequence ends at the $40, and when the controller resets, it'll be back at the first step. In other words, you probably want to make sure that TH = 1 when the reading is over if you know it's a 6 button controller.

If you leave TH = 0 at the end of the sequence, when it resets it'll go back to the second step on that list, and you need to adjust accordingly.
Sik is pronounced as "seek", not as "sick".

Chilly Willy
Very interested
Posts: 2587
Joined: Fri Aug 17, 2007 9:33 pm

Re: controller auto reset

Post by Chilly Willy » Thu Jun 29, 2017 11:58 pm

I've done a TON of testing on official and third party controllers, and this is what I do for 6-button controllers:

Code: Select all

    pb = (vu8 *)0xa10003 + port*2;

    v1 = TH_CONTROL_PHASE(pb);                    /* - 0 s a 0 0 d u - 1 c b r l d u */
    val = TH_CONTROL_PHASE(pb);                   /* - 0 s a 0 0 d u - 1 c b r l d u */
    v2 = TH_CONTROL_PHASE(pb);                    /* - 0 s a 0 0 0 0 - 1 c b m x y z */
    val = TH_CONTROL_PHASE(pb);                   /* - 0 s a 1 1 1 1 - 1 c b r l d u */
where

Code: Select all

static u16 TH_CONTROL_PHASE(vu8 *pb)
{
    u16 val;

    *pb = 0x00; /* TH (select) low */
    asm volatile ("nop");
    asm volatile ("nop");
    val = *pb;

    *pb = 0x40; /* TH (select) high */
    val <<= 8;
    val |= *pb;

    return val;
}
6-button pads want TH high in between read cycles. So you start out with TH high. I don't read it because that data is superfluous. The pad keeps track of how many high-to-low-to-high transitions are done. After the last low-to-high transition, you MUST wait about 1/60th of a second or the pad won't respond correctly to the next read. That's why pad reading is generally done by the vblank int handler. I notice that sik's code doesn't do the last high-low-high cycle - that's needed to get the pad id (that sa1111 byte in the comment). That's part of identifying a six button controller from something else. Of course, Sega didn't make anything else that used the same protocol, but it's still part of it. I seem to remember a third party stick that didn't work right if you didn't do that last cycle. Official Sega pads can be stopped after any low-to-high transition and still respond correctly as long as you wait that 1/60th sec before trying to read it again. Some third party stick don't since all Sega games do the full four cycles.

Note, the code is from SGDK... which I helped with a few things, notably the controller code. I spent a lot of time with the Menacer, the Justifier, the Phazer, the SMS trackball, an SMS pad, sticks of all makes and models, a TeamPlayer, and a US mouse to get it all working on real hardware. :lol:

User avatar
TmEE co.(TM)
Very interested
Posts: 2307
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: controller auto reset

Post by TmEE co.(TM) » Fri Jun 30, 2017 12:53 am

Image

Technically you're not supposed to use the "1111" as ID, only the "0000" :P
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

User avatar
Miquel
Very interested
Posts: 324
Joined: Sat Jul 30, 2016 12:33 am

Re: controller auto reset

Post by Miquel » Fri Jun 30, 2017 11:55 pm

And even more: you have to request z80 bus before anything. Sega hardware division making every day more sane people.

Chilly Willy
Very interested
Posts: 2587
Joined: Fri Aug 17, 2007 9:33 pm

Re: controller auto reset

Post by Chilly Willy » Sun Jul 02, 2017 5:58 pm

TmEE co.(TM) wrote:Technically you're not supposed to use the "1111" as ID, only the "0000" :P
Yeah, sorry, misspoke on that... been a while (years) since I wrote that code. But you should still fetch it. His pseudo-code isn't doing that. Notice how they do four high-to-low-to-high transitions? His only does three. My point was that doesn't get the entire data packet, and a few odd-ball controllers won't work because of that.

User avatar
Sik
Very interested
Posts: 706
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: controller auto reset

Post by Sik » Sun Jul 02, 2017 10:30 pm

But wouldn't such controllers also break with games that only support 3 button controllers? (the whole point of automatic reset is to make that stuff work)

EDIT: I do recall some controllers break if you try to read too much though, and when the controller is just initialized it may be in an undefined state, so it's in your best interests to avoid using the controller as soon as you initialize the ports. Yeah, this problem has actually happened before.
Sik is pronounced as "seek", not as "sick".

r57shell
Very interested
Posts: 475
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Re: controller auto reset

Post by r57shell » Mon Jul 03, 2017 5:25 am

so short mind
viewtopic.php?f=23&t=2308

when I made ROM, was much smaller discussion :?
Image

Chilly Willy
Very interested
Posts: 2587
Joined: Fri Aug 17, 2007 9:33 pm

Re: controller auto reset

Post by Chilly Willy » Mon Jul 03, 2017 6:36 pm

Sik wrote:But wouldn't such controllers also break with games that only support 3 button controllers? (the whole point of automatic reset is to make that stuff work)

EDIT: I do recall some controllers break if you try to read too much though, and when the controller is just initialized it may be in an undefined state, so it's in your best interests to avoid using the controller as soon as you initialize the ports. Yeah, this problem has actually happened before.
From my memories (not always right), I had a third party six-button pad (with no mode button) that would work if you did ONE cycle per vblank (normal 3-button read), or if you did FOUR cycles per vblank (6-button read), and return garbage for anything else. My thought at the time was that whatever internal state machine (be it hardware or software) they used only checked for timeout at one cycle, or four cycles, but not two or three. Probably saved themselves two or three logic terms by skimping like that. :lol:

As to doing more cycles, I did once try this in a loop outside the vblank, and some controllers worked fine, but none of my official 6-button pads. Those needed the timeout period.

User avatar
Miquel
Very interested
Posts: 324
Joined: Sat Jul 30, 2016 12:33 am

Re: controller auto reset

Post by Miquel » Wed Jul 05, 2017 6:22 pm

Chilly Willy wrote:Note, the code is from SGDK... which I helped with a few things, notably the controller code.
Chilly Willy wrote: From my memories (not always right), I had a third party six-button pad (with no mode button) that would work if you did ONE cycle per vblank (normal 3-button read), or if you did FOUR cycles per vblank (6-button read), and return garbage for anything else. My thought at the time was that whatever internal state machine (be it hardware or software) they used only checked for timeout at one cycle, or four cycles, but not two or three. Probably saved themselves two or three logic terms by skimping like that. :lol:
????
The SGDK reads the 3 button state in the 3rd cycle...

Chilly Willy
Very interested
Posts: 2587
Joined: Fri Aug 17, 2007 9:33 pm

Re: controller auto reset

Post by Chilly Willy » Wed Jul 05, 2017 8:03 pm

You're looking at the 6-button code. The 3-button code does this

Code: Select all

static u16 read3Btn(u16 port)
{
    vu8 *pb;
    u16 val;

    pb = (vu8 *)0xa10003 + port*2;

    val = TH_CONTROL_PHASE(pb);                   /* - 0 s a 0 0 d u - 1 c b r l d u */
    val = ((val & 0x3000) >> 6) | (val & 0x003F); /* 0 0 0 0 0 0 0 0 s a c b r l d u */
    val ^= 0x00FF;                                /* 0 0 0 0 0 0 0 0 S A C B R L D U */

    return val | (JOY_TYPE_PAD3 << JOY_TYPE_SHIFT);
}
So it only does one cycle for the 3-button. Three button pads have a separate routine so that you spend as little time as possible banging on the hardware in the vblank. You can set the 6-button pad to use the 3-button routine if you want the most speed and don't need the extra features. Just do

Code: Select all

    JOY_setSupport(PORT_1, JOY_SUPPORT_3BTN);
Note that this won't work for pads connected to a team player or other tap, only pads connected directly to the console.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest