Joy2 CD32 PLAY button

[killergorilla]

Hi Toni,

I'm having problems with WinUAE.

I've added a check in my new frontend which checks if the play button is being pressed. For some reason in WinUAE 1.5.3 and 1.5.2 it seems to think the PLAY button is being pressed continuosly without me pressing any buttons.

I went back and tested and figured out that version 1.5.1 is the newest version that doesn't seem to be doing this.

EDIT:

I've just checked with Joy1 as well and it's the same.

[jotd]

Originally Posted by killergorilla

Hi Toni,

I'm having problems with WinUAE.

I've added a check in my new frontend which checks if the play button is being pressed. For some reason in WinUAE 1.5.3 and 1.5.2 it seems to think the PLAY button is being pressed continuosly without me pressing any buttons.

I went back and tested and figured out that version 1.5.1 is the newest version that doesn't seem to be doing this.

EDIT:

I've just checked with Joy1 as well and it's the same.

How do you check the buttons? The only working way is through lowlevel.library.
The routine that you find in games (with a bunch of tst.b $bfe001 for delay) does not generally work for me. I still do no understand when it works and when it does not, but I think it's related to memory speed and also the amount of vertical blank interrupts that occur during the read (maybe I'm wrong on that one, never could figure this out properly).

[killergorilla]

I'm using lowlevel.library. But I'm not using assembly, I'm using AmigaE.

I do it by setting portState to the result of ReadJoyPort(1)

Then doing a bitwise AND between portState and JPF_BUTTON_PLAY.

The code is working for every other button on the CD32 pad (JPF_BUTTON_BLUE, JPF_BUTTON_REVERSE etc.)

It's working in WinUAE 1.2, 1.3, 1.5.1, just not 1.5.2 and 1.5.3

It's triggering PLAY even when I set both port 1 and port 2 to <none> in the "Game & IO Ports" screen.

[Toni Wilen]

Not working in some non-available software isn't very useful (=post small example program or something)

Does it still work in some random game(s)?

[killergorilla]

There's a small program in the zone.

All it does it print out the name of whatever button you press.

The program exits when you press red/fire1.

Here it constantly prints out PLAY.

[a4k-oerx]

Unfortunately you did not supply a source, but a quick disassembly shows that you open lowlevel.library (without success-check btw.) and then directly go in a WaitTOF()-loop which does ReadJoyPort().

Did you try with a SetJoyPortAttrsA() call before your loop which explicitly sets the type of JoyPad/Joystick? Maybe it's an autosense-does-not-work problem?

Maybe a part of this E-source helps you out how to do that: http://www.paradroid.net/ags/arcadegameselector.e

Verified here: Your current program prints continous Play with a standard A4000 setup in latest WinUAE.

[killergorilla]

Yeah I know it doesn't check if it's been successful, I just bundled a few lines of code together to prove my point.

It's nothing to do with auto-sense working or not, as the GREEN, YELLOW, etc. buttons are not available when you set the control to JOYSTK. They are only available with GAMECTLR. And they are all working absolutely fine bar PLAY. I do not want to force it to a specific control type because I want CD32 buttons and standard joystick buttons to work together.

The fact that this only occurs in > WinUAE 1.5.1 and only occurs with the play button leads me to believe it is nothing to do with the code.

[a4k-oerx]

Well, if I use your program on a WinUAE CD32 setup (started from a CD which boots into a WB3.1), it works fine, no "Play" output all the time. So I came to the autosense-conclusion...

[killergorilla]

Just did a bit more testing.

I turned JIT off and it stopped doing it.

Did a little more testing.

It happens when "Adjustable between CPU and Chipset" is set but only with the slider in the far left 5 positions. The further right I move it, the slower it seems to be displaying PLAY until I get 6 from the left and it stops.

[Toni Wilen]

Confirmed. Something to do with new "analog" second/third button handling which emulates charging/discharging of POTxDAT capacitors.

Real 2nd/3rd button bits won't change instantly (reason for those tst.b $bfe001's in cd32 read routines) and I guess I forgot to add special handling for "too fast" modes

[killergorilla]

Ah excellent, I thought I was going mad for a minute.