Detecting the controller type?

[PkK]

I'd like to be able to detect the controller type.

 

Is there a known way to do so.

 

Background: In my game Io, one moves the cursor on the screen to decide where to build something. One also scrolls through a list of things to build.

With the normal controller, the joystick is used to move the cursor, the list is scrolled one item at a time by pressing the second fire button (and the first fire button gives the actual build command).

Moving the cursor is much nicer using the roller controller. So I implemented roller controller support for the single-player mode.

But scrolling the list might be nicer using the spinner wheel. So the people using a super action controller could get that instead.

 

Therefore I'd like to know what controller is attached to the CV:

 

1) Roller controller

2) Super action controller(s)

 

I don't care about plain controllers or unattached controllers being put into one of these categories.

 

Philipp

 

[PkK]

I wrote a small test program to look into the behaviour of Super Action Controller (SAC) and Roller Controller (RC). It displays the state of the controller ports at 0xfc and 0xff after spint and vint.

 

I tested on a setup with an unmodified CBS RGB ColecoVision with various controllers.

 

Results so far:

1) The bits of ports 0xfc and 0xff relevant to the SAC / RC are bits 4, 5 and 7. No surprise here.

2) It doesn't matter if port 0x80 or 0xc0 was previously written to (at least not in the short term).

3) For the SAC and RC, bit 4 is low if an interrupt-generating change recently happened. No surprise here either.

4) For the SAC, bits 5 and 7 give the quadrature of for current state of the spinner wheel. The accuracy of this seems to be 45°, while interrupts are generated every 90°. Thus just using the interrupt only gives half the precision of the SAC. The interrupts happen, such that bit 5 can be used to get the direction of the turn.

5) For the RC, bit 5 gives the direction of the previous turn. Bit 7 is nearly always the opposite of bit 4. Brief exceptions only happen during transitions.

6) For no or plain controllers, bit 7 is always 0, while bits 4 and 5 are always 1.

 

That yields:

 

1) Checking bits 4 and 7 might give a heuristic: For the SAC, they are the same about half the time. Without the SAC they are nearly always opposite. Gives a 50% chance of detecting a SAC at a port. Higher is the spinner moves when players pick up the controllers after switching on the CV. Even higher when SACs are used in pairs. But we will still get false negatives.

2) Check for spint at startup. If a SAC or RC is present, we might get some when players pick up SACs or touch the RC.

3) Check bit 5. For plain or no controllers it will always be 1. If we ever see a 0, we have a SAC or RC. This will still give false negatives as we only have a 50% chance of detecting a SAC at a port and a 75% chance of detecting a RC.

 

Combining all these should give a decent chance at setting a default config of SAC vs RC, but it doesn't seem good enough to just use the information without notifying the player and offering them a chance to change it in the start menu.

 

Philipp

 

P.S.: The test program was compiled with not-yet-released libcv 0.24.

 

test.rom

test.c.gz