Amiga 4000 - CD32 Joypad

[jotd]

Originally Posted by stx2199

apart from the fact that the CD32 pads don't work well
The A1200 rev2b also have problems with standard joystick and the 2nd button not working on some games

I'm sure this can be fixed on the motherboard using a resistor
since it seems the A4000 have idem bug,the solution could be the same

I'm sure you can use software patches instead of risking to ruin your motherboard.


Quote games that don't work I'll fix them or point you to a whdload version that fixes them.

[Lamaman71]

Ha jotd - yeah Im with you there!

So, all of the games you have touched are great. Apidya doesnt work with the second button (on my 4000)- have a lovely chat with Girv and he suggested I speak to you - plus, as already mentioned, Turrican 2 AGA and Devils Temple. Havent had much time to play this last weekend - got drawn into Second Samurai / IK+ and then, well, that was that!

[stx2199]

Originally Posted by Lamaman71

Never heard of this hardware fix … I’d be interested in learning more about it if anyone has any details?

the fix is a pullup resistor connected between pin 9 (2nd button) and pin 7 (+5v)
a 5k or 10k resistor will work fine, I tested
this fix the 2nd button joy not working on some games in the A1200 rev 2.b
basically works energizing the 2nd button making it also much more sensitive

I don't know if fix the cd32 pad issue btw

[stx2199]

Originally Posted by jotd

I'm sure you can use software patches instead of risking to ruin your motherboard.


Quote games that don't work I'll fix them or point you to a whdload version that fixes them.

Under the risk of ruining the motherboard with poor soldering, the fix that I explained above can also be done on the joystick itself.

[jotd]

no the CD32 pad issue is different than the pullup resistor issue on joysticks.

And writing $FF01 to $DFF034 after reading POTGO in $DFF016 works better than soldering (specially for those who have 2 left hands like me when it comes to waving the iron)

[Daedalus]

And to add to that, adding resistors to pins 5 or 9 will affect the operation of analogue controllers. Not that many people use them...

[jotd]

What I'd do:

- open a mantis ticket for each whdload problematic game.
- contact McGeezer for an update on Devil's Temple
- contact Muzza for an update on Turrican.

Let them know I can help them fix the problem quickly.

[stx2199]

Originally Posted by Daedalus

And to add to that, adding resistors to pins 5 or 9 will affect the operation of analogue controllers. Not that many people use them...

the pin 5 is the 3rd button not used in games excepting a pair of whload modified games as battle squadron and same other one which I don't remember, is not really necessary

adding a resistor on the pin 9 is always a must do it not only for the A1200 rev 2b but even for any Amiga since that 2nd button is not very sensitive by default

you will find that in same games you press the 2nd button gently and nothing happens, then the resistor fix make it work correctly

[jotd]

Originally Posted by stx2199

the pin 5 is the 3rd button not used in games excepting a pair of whload modified games as battle squadron and same other one which I don't remember, is not really necessary

not really. As a lot of recent cd32 joypad whdload patches also support 3rd button for pause or something else. I wouldn't destroy my third button if I had a 3-button joystick.

[Daedalus]

Originally Posted by stx2199

the pin 5 is the 3rd button not used in games excepting a pair of whload modified games as battle squadron and same other one which I don't remember, is not really necessary

As I said, pins 5 and 9 are used for analogue controllers in a number of games, and will be directly upset by adding resistors or capacitors to that signal, as well as pin 5 being used for various things like the CD32 protocol, fully reading Megadrive pads, middle mouse button, some implementations of 3-button pads, mouse scrollwheel, the upcoming dual-stick controller from Abstraction, and other things. There are dozens, maybe even hundreds of games these days that can use the CD32 pad, thanks to WHDLoad. And even in modern times there are a number of games recently released or soon to be released that use a CD32 pad.

adding a resistor on the pin 9 is always a must do it not only for the A1200 rev 2b but even for any Amiga since that 2nd button is not very sensitive by default

I haven't seen the issue personally, but I think you're somewhat misunderstanding the issue. If the right mouse button works fine then the Amiga is doing what it's supposed to do. If the switch in a mouse can trigger the input but the switch in a joystick can't, then the joystick is at fault, not the machine.

Perhaps a good alternative might be to add your resistors in a small adaptor cable. That way you can plug it in whenever you feel it's necessary, without permanently modifying the Amiga and upsetting the various other functions of the port.

you will find that in same games you press the 2nd button gently and nothing happens, then the resistor fix make it work correctly

I haven't found that, no. Maybe I'm testing the wrong games, or maybe my 2B motherboard doesn't share the issue, but when I press a joystick button, it makes a good electrical connection from pin 6 or pin 9 to ground, pulling that line low and allowing detection of the button press in software.

[DanyPPC]

In the past on A1200 rev 2B I used a standard Konix Speedking 2 Button joystick for MasterSystem. This doesn't have any chip inside, except for the autofire for Button 1, but it works very well on A1200 2B.
RysMk2 adapter with a Innext USB Supernes style gamepad also works properly on a A1200 Rev 2B in cd32 mode. Tested with WHDLoad games and not.
Se the user can try these solution if these can be of help with his A4000 machine.

[jotd]

I haven't seen the issue personally, but I think you're somewhat misunderstanding the issue. If the right mouse button works fine then the Amiga is doing what it's supposed to do. If the switch in a mouse can trigger the input but the switch in a joystick can't, then the joystick is at fault, not the machine.

Are you sure about this? For instance 2nd button always work from a CD32 joypad and fail in some games for standard 2-button joysticks like Wico for instance, probably because coders used a CD32 joypad or a nice joystick.

I never heard about mouse having the same issues (but I may be wrong, they had to test their mouse inputs when they created the game).

[Daedalus]

I haven't checked that game so I haven't seen it. But for me, the 2nd button of the CD32 pad has always worked as button 2 in standard controller mode. However, the digital output from a logic chip might be where the problem lies - a mechanically-switched joystick or mouse button doesn't give any issues, so it would appear the logic thresholds of such chips aren't accounted for by the Amiga (which was designed before the CD32). This might also explain issues some people have with USB controller adaptors too for example. But my point was that pressing a switch gently shouldn't make a difference if the switch is working properly; pressing harder shouldn't make any difference.

[Muzza]

Just FYI. It’s on my list to look at a fix for T2AGA. Maybe tomorrow. Maybe later.

[Muzza]

Originally Posted by jotd

This is the ancestor of the code I'm now using.

The code is a collaborative effort, I didn't start it, and I remember having a hard time making it work reliably. Once thing I did was joypad/joystick detection at start, so after that either I read using the tst ciaapra loop or in a classic way, not both

In the new code I'm looping 10 times not 9. The comment says otherwise now I'm noticing... Maybe it's wrong in Readjoypad.s code... Anyway ReadJoypad.s is the piece of code used in whdload fixes and it works...

But I think that the old readjoypad code is wrong when it's reading first the buttons in a conventional way (1 and 2) then in the CD32 serial way. Reading button 2 that way discharges the capacitor (or whatever) making further readings unreliable.

Either read buttons using POTGO/CIAAPRA or use loop, which will read ALL buttons anyway (red, blue, yellow..). Check newer Readjoypad.s in any source of mine ex https://github.com/jotd666/whdload_s...e/ReadJoypad.s

Note: the CD32 loop read takes more cycles than dumb read of CIAPRA & POTGO, but it's the only way to read all CD32 buttons, not only button 1, 2 (and 3 for sega joystick/3-mouse buttons, which is bit 10 if I'm not mistaken, but not for a CD32 pad)

Comparing the code you linked to mine, I found two differences.
1. I was using FFFF for POTGO_RESET instead of FF00
2. I was missing the line: or.b #$C0,ciapra(a1) ;reset port direction

I modified my code and had the original poster test it, but he reported no improvement.

The other difference is the number of loops as you pointed out, but after looking closely, I don't think they are all that different.

In ReadJoystick.s the _read_joystick routine does one POTINP test for the 2nd fire button, then 8 loops of POTINP reads for CD32 specific buttons.

The _detect_controller_types routine does 10 loops of POTINP reads (but no POTINP test for the blue button). If either of the last two bits are set, the controller is marked as being a CD32 pad.

My code combines both routines in one (supporting hot-swapping of joysticks/pads was useful during testing - although I accept few players would find it an important feature). So I am testing POTINP once for the 2nd fire button, then doing 9 loops of POTINP reads. If the final two bits were 01, then I mark it as a CD32 pad. So I think this is essentially the same as _detect_controller_types ?


I don't have a great understanding of how the hardware works here, so I'm reliant on some help here. The only thing I can think of trying next is to separate the read and detect routines like WHDLoad does, although I don't know why that would make a difference.

[Muzza]

Another difference, when doing the ten reads to test if it is a CD32 pad, my code checks if the last two bits are %01. The WHDLoad code checks if the last two bits are non-zero.
BUT... if you plug in a two button joystick, and hold down the second button, those last two bits will be 11, meaning it could be mistaken for a CD32 pad.

At least that is what happens if I change my code to test for non-zero.

The OP reported that the controls menu was constantly changing its mind as to whether a CD32 pad was plugged in or not. So there does seem to be something unreliable here.

[jotd]

there is another implementation on lowlevel library implementation that goes dynamic and not static. I have decided for a detection at start then save cpu cycles not reading non-existent buttons for my games.

This gave me headaches for years until I first detect then do the specific thing.

My code combines both routines in one (supporting hot-swapping of joysticks/pads was useful during testing - although I accept few players would find it an important feature). So I am testing POTINP once for the 2nd fire button, then doing 9 loops of POTINP reads. If the final two bits were 01, then I mark it as a CD32 pad. So I think this is essentially the same as _detect_controller_types ?

It doesn't seem like it, as the testers have success with the detect then read approach but not with yours. I'm really not an expert at this. I just tried things until I found something that works 100% of the time for 100% of the machines. My only original idea was to separate detection & read, and that helped a lot.

About hot swap, I understand this could be a pain if not possible as sometimes (specially for 2 player games) you click to start the game, then you plug the 2nd controller. That's why I re-do the detection at key phases of the game. Just after intro, just before game starts, maybe when game is paused as well!... That could make it rather transparent, as the extra buttons aren't used much in the intro or menu.

[ross]

Just by chance in recent days I was trying to make a generic routine for managing Joystick/Joypad, which did not include a detecting routine, but which adapted in real time, even for on-the-fly insertions of all types of controllers (I don't know if it's possible but I want to try).

The routine is based on available connection schemes and not on available code which in my opinion may or may not work under specific conditions.

From what I understand, the problematic cases can be those of Joysticks with 2nd button, which can be divided into 3 main categories:
1) Joystick with pullups: both method (Joypad or Joystick mode) report valid 2nd button
2) Joystick without pullups: 2nd button is valid only in Joystick mode (in Joypad mode pin is floating and can be stuck).
3) Joystick with 'strange' internal driving, that require Paula in input mode: only Joypad mode report valid 2nd button.

With careful management of Paula's I/O bits perhaps it is possible to handle everything.. and with a single routine uniquely executed every frame.. maybe.
There's no harm in trying

[fgh]

I know Mickgyver made a huge research effort on cd32 pad compatibility and the various ways software detect cd32 pads, etc. before finishing his KTRL+ pad.

Just had a quick look at his threads and this bit could perhaps be relevant, but it’s a bit vague
https://eab.abime.net/showpost.php?p...&postcount=365

[Muzza]

I did a test build where if the user selects Joypad as the control scheme, the code will assume a CD32 pad and no longer do the 'test if it is a CD32 pad or joystick' each frame. In combination with the two small changes I mentioned earlier this means the code should be doing the same as the ShadowOfTheBeast3 WHDLoad slave.

But... OP tested it and it didn't fix anything. Beast3 does work for him though. So either there is some other difference I've missed, or the problem isn't with this code.
Also OP reports it is only the blue button causing a problem, which is strange because that is just Fire 2, and doesn't even involve the more troublesome CD32 pad code.

After a day of messing with this, the song 'Only Amiga...' is in my head. But for the wrong reasons.