Suggested change to maple driver

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

Suggested change to maple driver

Post by Chilly Willy » Sun Jul 31, 2016 2:50 pm

I've mentioned before that the Mad Catz 6-button controller comes up in compatibility mode (4-button mode, with the extra two buttons setting the trigger fields to 255 if pressed). You press a button on the controller to program buttons, or hold the button to switch into 6-button mode. Compatibility mode returns the normal 4-button capabilities, while 6-button mode changes the caps to indicate the new buttons (C and Z). However, the current maple driver doesn't recognize this change.

HOWEVER, the current driver DOES query the device info periodically to determine if controller have been hot swapped. If a device doesn't respond to the query, it's detached from the device list. Then if it later responds to the query, it's reattached. You find this code in the devinfo callback:

Code: Select all

    else if(resp->response == MAPLE_RESPONSE_DEVINFO) {
        /* Device is present, check for connections */
        if(!maple_state.ports[p].units[u].valid) {
#if MAPLE_IRQ_DEBUG
            dbglog(DBG_KDEBUG, "maple: attach on device %c%c\n",
                   'A' + p, '0' + u);
#endif

            if(maple_driver_attach(frm) >= 0) {
                assert(maple_state.ports[p].units[u].valid);
            }
        }
If the valid flag is not set, it reattaches the device. However, this gives us the perfect chance to update the caps! Add an else statement in there and you get this:

Code: Select all

    else if(resp->response == MAPLE_RESPONSE_DEVINFO) {
        /* Device is present, check for connections */
        if(!maple_state.ports[p].units[u].valid) {
#if MAPLE_IRQ_DEBUG
            dbglog(DBG_KDEBUG, "maple: attach on device %c%c\n",
                   'A' + p, '0' + u);
#endif

            if(maple_driver_attach(frm) >= 0) {
                assert(maple_state.ports[p].units[u].valid);
            }
        }
        else {
            maple_devinfo_t     *devinfo;
            maple_device_t      *dev;
            /* Device already connected, copy function data in case of change */
            devinfo = (maple_devinfo_t *)resp->data;
            dev = &maple_state.ports[p].units[u];
            dev->info.function_data[0] = devinfo->function_data[0];
            dev->info.function_data[1] = devinfo->function_data[1];
            dev->info.function_data[2] = devinfo->function_data[2];
        }
Now if the valid flag is set, it copies the function data from the response to the device info struct. This updates the capabilities field, and so we can now see if the controller is changed by the user. This is something that's already done to detect hot swapping, and we don't even add a microsecond to the existing code, so it shouldn't be a burden over what's already done.
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

Re: Suggested change to maple driver

Post by Chilly Willy » Sun Jul 31, 2016 6:48 pm

Oh, one more thing related to the Mad Catz controller and the maple driver: I had reported that I needed to unplug and replug the controller before it worked right on the DC. That's only under KOS. It works fine with official DC stuff. So that told me there was maybe something wrong with the KOS maple startup.

Looking at the code, kos initializes all the devices as empty, then relies on the hot swap code in the vblank to add the devices. My guess is this occurs too soon for the Mad Catz - so the device is added in an indeterminate state. Sometimes it doesn't show at all, but most of the time it shows as a normal controller, but most of the buttons generate wrong (and often multiple) inputs.

My first idea was to reset the controller before adding it. So I changed the hot swap like this:

Code: Select all

...

    /* Initialize other misc stuff */
    maple_state.vbl_cntr = maple_state.dma_cntr = 0;
    maple_state.detect_port_next = -MAPLE_PORT_COUNT;
    maple_state.detect_unit_next = 0;
    maple_state.detect_wrapped = 0;
That means it tries the hot swap MAPLE_PORT_COUNT more times to start via negative next values. Then in the hot swap code:

Code: Select all

    if(p < 0)
		vbl_send_reset(p, u);
	else
		vbl_send_devinfo(p, u);
That resets each device once before then sending devinfo commands to detect the devices. That worked! ... once in a while. Now the Mad Catz either doesn't show up at all, or it works perfectly. Think maybe it's a issue with waiting a certain amount of time before it's ready, I did this:

Code: Select all

    maple_state.detect_port_next = -MAPLE_PORT_COUNT*2;
and not the Mad Catz worked more often, but still didn't show sometimes. So once more:

Code: Select all

    maple_state.detect_port_next = -MAPLE_PORT_COUNT*3;
and the Mad Catz worked six times for six tries. So I figure after the Maple bus is enabled, you are supposed to wait a certain amount of time for devices to stabilize before trying to use them, and you should probably send a reset command first to be sure they're in the proper state. The easiest thing for me to do was simply send X number of resets. Three seems to work fine. I'm wondering if I should do four just in case.
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

Re: Suggested change to maple driver

Post by Chilly Willy » Sun Jul 31, 2016 8:13 pm

Follow up on the Mad Catz init issue. I tried delaying, then doing one reset. Works about one in two tries. Then I tried a delay, a reset, another delay, and another reset. Works about one in three or four tries. I tried just four resets. Works about one in 6 to 8 tries. Then I tried a delay, and three resets. Worked 10 for 10 - the first time I actually reached ten successes in a row. So the initial value is currently

Code: Select all

    maple_state.detect_port_next = -40;
and the autodetect code is now

Code: Select all

    if(p >= -MAPLE_PORT_COUNT*3) {
		if(p < 0)
			vbl_send_reset(p, u);
		else
			vbl_send_devinfo(p, u);
	}
I'd really love to know what Sega actually does for the controller init.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5393
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 1 time
Been liked: 12 times
Contact:

Re: Suggested change to maple driver

Post by BlueCrab » Mon Aug 01, 2016 12:29 am

That's... Really hacky. I don't like that solution for what is probably a problem due to the hardware being non-compliant in the first place. :?

That certainly should not be the default.
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

Re: Suggested change to maple driver

Post by Chilly Willy » Mon Aug 01, 2016 10:16 am

BlueCrab wrote:That's... Really hacky. I don't like that solution for what is probably a problem due to the hardware being non-compliant in the first place. :?

That certainly should not be the default.
Yes, it seems that way to me, too. Which is why I'm asking for suggestions. The way the official SDK inits sticks works with it, so the controller meets whatever compliance rules Sega had. It does not work with stock kos, so kos is missing something that makes controllers like it work. The fact that it needs multiple resets clearly means I haven't figured it out yet.

Right now, only the first post is something I'm considering for official kos. The second and third posts are works in progress that clearly still need work before inclusion. The first suggested change is very clean and non-hacky. It fits in the existing code extremely well and solves a real problem in an elegant manner. The other is VERY much a hack, and if you can think of something I haven't tried yet, I'm all ears. :)
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

Re: Suggested change to maple driver

Post by Chilly Willy » Mon Aug 01, 2016 3:49 pm

Okay, I take it back... the Mad Catz controllers DON'T work with official games. I disconnected all the controllers and put the Mad Catz in the first port and booted Sonic Adventure. The controller was acting crazy until I unplugged and plugged it back in. I tried it twice and it was crazy twice. :o :oops:

So I guess the kos code is actually fine, although it would be nice to find a non-hackish way to make them work without having to unplug them.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5393
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 1 time
Been liked: 12 times
Contact:

Re: Suggested change to maple driver

Post by BlueCrab » Tue Aug 02, 2016 11:01 am

I didn't necessarily think you did want that to be the default action... I guess I didn't make that all that clear posting at 1:30 in the morning. :lol:

That said, I'm actually glad to see that it's just as broken with official software. Reinforces my idea that it's just a 3rd party controller being wonky due to not having the official specs. Dunno that there's an obvious non-hacky solution, but I guess one thing to do would be exposing a public function from the maple driver for at least sending a reset command to a device... Still would be hacky, but at least there'd be some possibility of making it work in userspace then. :wink:
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

Re: Suggested change to maple driver

Post by Chilly Willy » Tue Aug 02, 2016 11:22 am

BlueCrab wrote:I didn't necessarily think you did want that to be the default action... I guess I didn't make that all that clear posting at 1:30 in the morning. :lol:

That said, I'm actually glad to see that it's just as broken with official software. Reinforces my idea that it's just a 3rd party controller being wonky due to not having the official specs. Dunno that there's an obvious non-hacky solution, but I guess one thing to do would be exposing a public function from the maple driver for at least sending a reset command to a device... Still would be hacky, but at least there'd be some possibility of making it work in userspace then. :wink:
Actually, I'm wondering if it's maybe my DC and not the controller. I've tried two different Dream Pads on all the ports, and they both act the same, but hours of googling found no reports of similar issues with them. The only complaint I've found is that the dpad sucks for fighting games, and that some people think the angle on the buttons is too steep. Not a single one about the pad not working until you unplug/plug it. :?

I've got extras of these things (it was cheaper to buy a lot of eight than to buy two individually), so if you want one to check yourself on your system, just PM me. In the mean time, I'm just not gonna worry about that aspect. At the moment, just the first post with the change for updating the caps is all I want for now.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5393
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 1 time
Been liked: 12 times
Contact:

Re: Suggested change to maple driver

Post by BlueCrab » Tue Aug 02, 2016 11:50 am

Chilly Willy wrote:Actually, I'm wondering if it's maybe my DC and not the controller. I've tried two different Dream Pads on all the ports, and they both act the same, but hours of googling found no reports of similar issues with them. The only complaint I've found is that the dpad sucks for fighting games, and that some people think the angle on the buttons is too steep. Not a single one about the pad not working until you unplug/plug it. :?
I guess that would be a possibility... Only thing I could think of would be either a bad connection between the controller board and the motherboard or that the fusistor on the controller board is going up...
I've got extras of these things (it was cheaper to buy a lot of eight than to buy two individually), so if you want one to check yourself on your system, just PM me.
I'd be happy to test things out, if that's what you want to do. I've got plenty of Dreamcasts laying around, after all. :wink:
In the mean time, I'm just not gonna worry about that aspect. At the moment, just the first post with the change for updating the caps is all I want for now.
Feel free to go ahead and make that change in the repo, if you'd like. Make sure to update the CHANGELOG too (and the AUTHORS file). :wink:
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

Re: Suggested change to maple driver

Post by Chilly Willy » Tue Aug 02, 2016 2:53 pm

BlueCrab wrote:
Chilly Willy wrote:Actually, I'm wondering if it's maybe my DC and not the controller. I've tried two different Dream Pads on all the ports, and they both act the same, but hours of googling found no reports of similar issues with them. The only complaint I've found is that the dpad sucks for fighting games, and that some people think the angle on the buttons is too steep. Not a single one about the pad not working until you unplug/plug it. :?
I guess that would be a possibility... Only thing I could think of would be either a bad connection between the controller board and the motherboard or that the fusistor on the controller board is going up...
It can't be TOO bad because all other controllers (two DC controllers, a DC keyboard, a DC mouse, a DC Twin Stick, and a Total Control adapter) work just fine.
I've got extras of these things (it was cheaper to buy a lot of eight than to buy two individually), so if you want one to check yourself on your system, just PM me.
I'd be happy to test things out, if that's what you want to do. I've got plenty of Dreamcasts laying around, after all. :wink:
Well, you have your choice of black, purple, blue, and green. :grin:
In the mean time, I'm just not gonna worry about that aspect. At the moment, just the first post with the change for updating the caps is all I want for now.
Feel free to go ahead and make that change in the repo, if you'd like. Make sure to update the CHANGELOG too (and the AUTHORS file). :wink:
Right, thanks for the reminder.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5393
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 1 time
Been liked: 12 times
Contact:

Re: Suggested change to maple driver

Post by BlueCrab » Fri Aug 05, 2016 7:31 pm

Chilly Willy wrote:Well, you have your choice of black, purple, blue, and green. :grin:
Well, what color could be more apt for me than blue? :lol:
MetalliC
DCEmu Crazy Poster
DCEmu Crazy Poster
Posts: 27
Joined: Wed Apr 23, 2014 3:04 pm
Has liked: 0
Been liked: 0

Re: Suggested change to maple driver

Post by MetalliC » Sat Aug 06, 2016 7:33 am

did you tried to use maple bus reset pattern to Mad Catz controller ?
currently KOS have no code to handle maple patterns, so you have to implement it by yourself.

Code: Select all

maple_queue.c  void maple_queue_flush() {
        /* First word: message length and destination port */
        *out++ = i->length | (i->dst_port << 16);
add | ( 3 << 8 ) there to send reset pattern/command to that port

heh, I see there is also very hacky lightgun polling implementation, which enable SDCKB occupy (lightgun) mode but never switch port back to normal data transfer mode...
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

Re: Suggested change to maple driver

Post by Chilly Willy » Sat Aug 06, 2016 2:00 pm

I made a function to send the reset command:

Code: Select all

/* Send a RESET command for the given port/unit */
static void vbl_send_reset(int p, int u) {
    maple_device_t * dev;

	while(p < 0)
		p += MAPLE_PORT_COUNT;
    dev = &maple_state.ports[p].units[u];

    /* Reserve access */
    maple_frame_lock(&dev->frame);

    /* Reset device */
    maple_frame_init(&dev->frame);
    dev->frame.cmd = MAPLE_COMMAND_RESET;
    dev->frame.dst_port = p;
    dev->frame.dst_unit = u;
    dev->frame.callback = vbl_reset_callback;
    maple_queue_frame(&dev->frame);
}
If something more is needed to make the reset work, then my tests weren't actually resetting anything. :)
MetalliC
DCEmu Crazy Poster
DCEmu Crazy Poster
Posts: 27
Joined: Wed Apr 23, 2014 3:04 pm
Has liked: 0
Been liked: 0

Re: Suggested change to maple driver

Post by MetalliC » Mon Aug 08, 2016 3:38 pm

its not the same thing.
your's code send data packet to device, which tells device MCU to reset himself.
that code I've posted tells MapleDMA controller to generate special reset pattern on serial lines instead of sending data, device serial receiver must detect this pattern and do hardware reset.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5393
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 1 time
Been liked: 12 times
Contact:

Re: Suggested change to maple driver

Post by BlueCrab » Mon Aug 08, 2016 8:03 pm

I'd find it unlikely that a 3rd party hardware peripheral would probably respond to that particular way of resetting it... Considering I don't think that was documented in any of the semi-public documentation that developers had...
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

Re: Suggested change to maple driver

Post by Chilly Willy » Tue Aug 09, 2016 12:03 am

Well, it can't hurt to try it. When I get the chance, I'll try sending that to the Dream Pad and see what happens.
MetalliC
DCEmu Crazy Poster
DCEmu Crazy Poster
Posts: 27
Joined: Wed Apr 23, 2014 3:04 pm
Has liked: 0
Been liked: 0

Re: Suggested change to maple driver

Post by MetalliC » Tue Aug 09, 2016 8:30 am

BlueCrab wrote:I'd find it unlikely that a 3rd party hardware peripheral would probably respond to that particular way of resetting it... Considering I don't think that was documented in any of the semi-public documentation that developers had...
nope, its pretty full documented in public available Maple patent - http://www.google.com/patents/US6338105
I highly doubt 3rd party developers made DC peripherals in unlicensed way, and without official documentation (MAPLE82E.doc and other docs we have now)
looks like it is something 'new and undocumented' as for KOS only ;)

PS: I'm wondering - that is inside Mad Catz controller, some their's own custom chip or Sega 315-something ?
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5393
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has liked: 1 time
Been liked: 12 times
Contact:

Re: Suggested change to maple driver

Post by BlueCrab » Tue Aug 09, 2016 9:46 am

MetalliC wrote:
BlueCrab wrote:I'd find it unlikely that a 3rd party hardware peripheral would probably respond to that particular way of resetting it... Considering I don't think that was documented in any of the semi-public documentation that developers had...
nope, its pretty full documented in public available Maple patent - http://www.google.com/patents/US6338105
I highly doubt 3rd party developers made DC peripherals in unlicensed way, and without official documentation (MAPLE82E.doc and other docs we have now)
looks like it is something 'new and undocumented' as for KOS only ;)

PS: I'm wondering - that is inside Mad Catz controller, some their's own custom chip or Sega 315-something ?
I wasn't aware that it was in the patent. If that's the case, then they certainly should have had that information, so I retract that previous statement.

That said, most third party peripherals tend to be unlicensed (or at least they did back in those days, even often times when they claimed to be officially licensed), so my statement about them not having any documentation that wasn't at least semi-public (i.e, came with the devkit and such) still would stand.

And we still stay away from any such documentation with KOS (semi-public or stuff that wasn't ever meant to leave Sega).
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

Re: Suggested change to maple driver

Post by Chilly Willy » Mon Aug 15, 2016 2:47 pm

Yeah, you have to be very careful about sources of info for third-party software, open source or not. That said, when do the Maple patents expire? After they expire, any and all info in them is fair game.

I'll open up one of my Dream Pads and see if the chips are marked. Very often, controllers use an epoxy blob over a die rather than an actual chip you can read the numbers off of. Especially complicated ones like programmable sticks with analogue and digital pads and proportional triggers and stuff.

EDIT: As I figured - it's an epoxy blob type board. The silk screening says the board is REV 2.2.
Post Reply