solving the CD32 joypad "mystery"

[jotd]

ok Toni, I'm about to test this.

Can you tell me where the CIA chips are located on the mobo? I searched for pics but found nothing.

Also: I've used JoyPortTest by Psygore with my 060 board disabled and same thing: joypad buttons aren't recognized (except for red of course)

EDIT: tested and still same issue: even with delays x9 (9 times slower) the red button is detected, others aren't.

I've zoned "_JoyButtonTestHDDev.zip", it uses whdload (src included) you can start it and change the timer. Works fine in winuae, fails on my A1200. Will test on CD32 TF232 as well.
Tell me if you need more info.

EDIT: I'm realizing that I'm not waiting the VBL delay between reads. So my test is moot... Let me change that later today. Don't test it as reading the buttons too fast renders the read useless (and that's an issue with second button in some commercial games which have native 2 button support like Banshee and some others)

[jotd]

Toni, updated (in the zone) with VBL wait between readings. Still same... Do you think you'll be able to find a solution on a real miggy?

[Toni Wilen]

Originally Posted by jotd

Toni, updated (in the zone) with VBL wait between readings. Still same... Do you think you'll be able to find a solution on a real miggy?

More questions..

Increased dummy CIA delays didn't change anything?

Does detection return "no CD32" even when pad is connected?
Does CD32 pad buttons work normally if you skip detection and assume pad exists?

EDIT: You sure it isn't the pad? It is possible some crappy 3rd party pads don't return "extra button" states correctly.

[jotd]

I have always got time for your questions.

- Increased dummy CIA delays didn't change anything?: I performed an higher loop: no go, so no.
- Increased dummy CIA delays didn't change anything?: I have removed the detection (joypadtest by psygore seems to wrongly detect the pad as well) so I don't kno
- Does CD32 pad buttons work normally if you skip detection and assume pad exists?: detection isn't called, so pad is assumed, and no it doesn't work
- It is possible some crappy 3rd party pads don't return "extra button" states correctly: It's an original CD32 pad from C=. It's been working perfectly on the CD32. Maybe now it's buggy. I have several of those. I'll check again

to sum it up, here are the tests I'm planning:

- Running joypadtest/my tester on my TF232 card on my CD32
- Testing with another CD32 joypad
- Testing with another A1200 motherboard (rev 1D)
- not all those tests at the same time

As said before, I believe the TF232 messes with joypad readings, and I cannot test with my raw CD32 because the CD doesn't work anymore!

[jotd]

I feel stupid: one of my joypads is clearly not working. Well, red button works, others don't...
both original.

Going to make a little fire in the garden.

I'm relieved, but there's still an issue with pads and non-CD32 HW. Lemme check better.

Got 3 joypads. One is broken: only red is working. Probably internal circuitly...
The other one works perfectly. Psygore proggy or my tester: works fine
The third one, really bad contacts on shoulder buttons, but works fine apart from that.

No wonder why I was going crazy now it's possible to test all those joypad-compliant games & HW.

Sorry for this mess.

[Retro1234]

Are you sure Blue button isnt working, I.e in two button mode?

Ive had pads that I thought weren't working but were in Two button mode.

[jotd]

no, blue isn't working either. Red seems completely different circuitry from 2nd buttons on SEGA joypads, and all-but-red seems completely different circuitry from red button in the CD32 pads.

I have 2 wico joys, 1 joy has second button not working, unless you switch to: both buttons equals. Which means that the button itself isn't at fault. The circuitry is.

That plus the software issues while reading those (respect the timings, POTGO initialization) make all this subject a real nightmare

[TuRRIcaNEd]

Is it worth seeing if you can hunt down a third-party CD32 pad to see if the circuitry layout is any clearer?

[alpine9000]

I have been playing around with CD32 pad detection and had some interesting results on my A1200.

I have two original CD32 pads, using lowlevel.library the detection of these pads as CD32 is inconsistent at best, and often always incorrectly detected as joysticks. My comp pro pad will always be detected correctly as will my mega drive pad via the Megadrive2cd32 converter.

Using techniques similar to outlined in this thread, I can detect them correctly as CD32 pads 100% of the time (as long as all potgo directions are correctly set).

I was able to recreate my results using various joystick tester apps from aminet, although the non lowlevel.library techniques of these vary in quality.

I am assuming that my cd32 pads are not in perfect condition and this explains why lowlevel.library doesn’t always work, but it’s also encouraging that it is possible to accurately detect.

[jotd]

Same here, the other way round, with the HW detection routine used in some WHDLoad slaves. Joystick is sometimes wrongly detected as joypad, and mayhem ensues when pressing one of the buttons...

Maybe automatic detection isn't such a good idea after all. We'd need an option to force joy type.

[Toni Wilen]

I think it would be good idea to make simple test executables (which would disable interrupts, do the test, enable interrupts, return result. Source of pad reading code include) and then test, test and test. (and include type of pad, Amiga and CIA part number)

There is still no scientific enough results

[alpine9000]

Originally Posted by jotd

Same here, the other way round, with the HW detection routine used in some WHDLoad slaves. Joystick is sometimes wrongly detected as joypad, and mayhem ensues when pressing one of the buttons...

Maybe automatic detection isn't such a good idea after all. We'd need an option to force joy type.

I think I have seen that condition, and it’s like all CD32 buttons are pressed (or a whole bunch of them). From what I can see this condition is possible to detect and reject as joystick behavior (disable pad processing), as the number of pressed buttons doesn’t seem to be possible to get with a real pad?

[alpine9000]

Originally Posted by Toni Wilen

I think it would be good idea to make simple test executables (which would disable interrupts, do the test, enable interrupts, return result. Source of pad reading code include) and then test, test and test. (and include type of pad, Amiga and CIA part number)

There is still no scientific enough results

Indeed, I tested my A500 (ks1.3/3.1), A600 (KS2), Escom A1200 and CD32 with 2xCD32 pads, competition pro pad and mega drive controller. Tested with OS running and track loader with no OS.

Oh, one thing I also discovered was using a joystick extension cable can hurt accurate discovery.

[jotd]

one thing I read somewhere is that mouse/joy detection only works if mouse is moved/button is pressed/don't remember.

I used a joystick doubler and dropped it at some point. I don't remember why, but it wasn't reliable (because it was super convenient)

All this knowledge (earned by trial and error of everyone) is invaluable

[alpine9000]

Another weird one, very slightly off topic, but I have a reproduction Competition Pro joystick that was modified to allow a second button, this second button has worked on some games but not others, for example the TurricanII WHDload will pick up the second button, but say McGeezer's new Rygar will not find it.

I tried it with a few joystick testers and in cd32 mode it reports all cd32 buttons (not directions) pressed _except_ the cd32 blue button.

If you combine this with ciaa_pra to get the actual state of the 1st button, you can get a nicely working 2 button setup, but how is this thing wired to get that behaviour.

[jotd]

One possibility is that POTGO isn't reset. CD32 pads don't care, but other joystick need that pin to be reset else button only works once.

    move.w  #$FF00,$DFF034

Some original code in amiga games which support the 2nd joystick are broken that way.

"All button pressed" behaviour happens when trying to read joystick with a joypad routine.

That's even how I autodetect the joystick/joypad: try to read the buttons at startup and if I get spurious extra bits, then it's a joystick.

[alpine9000]

Originally Posted by jotd

One possibility is that POTGO isn't reset. CD32 pads don't care, but other joystick need that pin to be reset else button only works once.

    move.w  #$FF00,$DFF034

Some original code in amiga games which support the 2nd joystick are broken that way.

"All button pressed" behaviour happens when trying to read joystick with a joypad routine.

That's even how I autodetect the joystick/joypad: try to read the buttons at startup and if I get spurious extra bits, then it's a joystick.

Yes I already set potg to this value, but this joystick is slightly different when B2 is pressed compared to other ones. Firstly you can’t read b2 using the normal simple joystick potgo read, and the pattern of cd32 buttons set when b2 is pressed excluded the b2 bit.

[alpine9000]

So I checked this joystick out with a multimeter, it's wired differently than a "normal" 2 button stick. Instead of Button2 connecting Pin 9 (Button2) with Pin 8 (GND), it connects them via a 300ohm resister, and it also connects Pin5 (Button3) with Pin 8 (GND) through the same resister when another button is pressed.

Edit: Ah, I found this schematic:

http://wiki.icomp.de/wiki/File:JoystickMod.jpg

[majinga]

Originally Posted by alpine9000

...

http://wiki.icomp.de/wiki/File:JoystickMod.jpg

The switch is for the C64 mode.
In the C64 the 2nd button is active high, in the Amiga active low.


Poty is almost useless in Amiga and in the C64. I don't know about the AtariST.


The problem is R1, is there to limit the current when S1 is connected to VCC. But with this resistor in some Amiga games the second button cannot be recognized, due to the voltage drop across the resistor.

[Toni Wilen]

It probably works on some hardware because Paula's POT lines are supposedly quite sensitive to +5v level, also POT caps may have drifted too much etc.

Check what you get by reading POT value (method is described in HRM) when button is kept pressed. It should be zero but you probably get some small value.