CD32 joypad blue button vs standard 2 button joystick

[jotd]

Here's a big puzzle for me.

I adapted the ReadJoyPad.s source code to properly detect joystick or joypad, and depending on that, I'm not reading all the buttons if a joystick is connected, but only fire & 2nd button (or RMB, or Sega 2nd button)

like this:

        moveq    #CIAB_GAMEPORT1,d3    ; red button ( port 1 )
        moveq    #14,d4            ; blue button ( port 1 )
        move.w    #$6f00,d5        ; for potgo port 1
        moveq    #joy1dat,d6        ; port 1
        move.b    controller_joypad_1(pc),d2

.rd
        lea    $DFF000,a0
        lea    $BFE001,a1

        moveq    #0,d7

        
    ;two buttons

        btst    d4,potinp(a0)    ;check button blue (normal fire2)
        seq    d7
        add.w    d7,d7

        btst    d3,ciapra(a1)    ;check button red (normal fire1)
        seq    d7
        add.w    d7,d7

        and.w    #$0300,d7    ;calculate right out for
        asr.l    #2,d7        ;above two buttons
        swap    d7        ;like from lowlevel
        asr.w    #6,d7

    ; read buttons from CD32 pad only if CD32 pad detected

        moveq    #0,d0
        tst.b    d2
        beq.b    .no_further_button_test
        
        bset    d3,ciaddra(a1)    ;set bit to out at ciapra
        bclr    d3,ciapra(a1)    ;clr bit to in at ciapra

        move.w    d5,potgo(a0)

        moveq    #8-1,d1
        bra.b    .gamecont4

.gamecont3    tst.b    ciapra(a1)
        tst.b    ciapra(a1)
.gamecont4    tst.b    ciapra(a1)    ; wepl timing fix
        tst.b    ciapra(a1)
        tst.b    ciapra(a1)
        tst.b    ciapra(a1)
        tst.b    ciapra(a1)
        tst.b    ciapra(a1)

        move.w    potinp(a0),d2

        bset    d3,ciapra(a1)
        bclr    d3,ciapra(a1)
    
        btst    d4,d2
        bne.b    .gamecont5

        bset    d1,d0

.gamecont5    dbf    d1,.gamecont3

        bclr    d3,ciaddra(a1)        ;set bit to in at ciapra
        move.w    #$FFFF,potgo(a0)    ;changed from ffff, according to robinsonb5@eab

This code works fine when a joypad is connected. It also works fine when a joystick is connected (ex: Shadow of the Beast III, you can switch weapons with 2nd/blue button).

It fixes the "all button pressed" issue when connecting a joystick when a joypad is detected.

BUT it doesn't work for one damn game I'm trying to adapt: Bubble & Squeak.

This game has 3 control options:

- standard joystick: up jumps
- 2 button joystick: 2nd button jumps
- joypad: 2nd button jumps, play => pause, ...

The 2 button option doesn't work, even in the original game: if you press the 2nd button, it jumps once, then it doesn't work.

I adapted my routine to fix this, and it's the same!! Internally, the button is seen as pressed even if you release it.

It's not a joystick issue: same behaviour on WinUAE.

So my question is: what is the difference between reading blue button joypad and reading 2nd button?

[Toni Wilen]

Probably the usual: Paula POTGO button 2 IO pin direction is not in output mode + data=1.

If input mode: only pads that have pullup resistor in pad buttons work (This includes CD32 pad). Pads without pullup resistor: button is pressed, IO pin goes to zero voltage level, when button is released: IO pin stays at zero voltage. Button appears stuck.

You can confirm it in WinUAE by switching between "gamepad" and "joystick". Gamepad emulates pullup resistor.

[jotd]

Thanks Toni, makes sense but why does it happen only in this game? (and good call emulating that one in Winuae, saves a lot of time)

The only difference is that the game can possibly use the OS even within the game (there are even some exec Debug calls if LMB is pressed!!)

Paula POTGO button 2 IO pin direction is not in output mode + data=1

isn't that line doing that (at the end of the reading?):

move.w    #$FF00,potgo(a0)

Some games do

move.w    #$CC01,potgo(a0)

instead. AFAIR if you do that before reading, it doesn't read anything (kind of "clears" the button state).

[Toni Wilen]

Setting bit 0 of POTGO most likely causes some side-effects: following 8-10 scanlines Paula pulls line to zero (to empty POT line capacitors), then it waits until capacitor(s) have high enough voltage. Which won't happen if joystick/pad does not have pullup resistors. So nothing changes

If $ff00 does not work, game probably does POTGO write somewhere else. "-inputdevicelog 16" will log all POTGO writes.

[jotd]

That's what I suspected, but I didn't find anything. "-inputdevicelog 16" you mean on the command line right?

Does a memwatch write on DFF034 work? Because I have tried that. Well, you're probably right, since other games don't have this issue, and this very game is "smart" with 2nd button (as opposed to older games which ignore it, so no risk)

[Toni Wilen]

Originally Posted by jotd

That's what I suspected, but I didn't find anything. "-inputdevicelog 16" you mean on the command line right?

Yes. Add also -log to see log in realtime.

Does a memwatch write on DFF034 work? Because I have tried that. Well, you're probably right, since other games don't have this issue, and this very game is "smart" with 2nd button (as opposed to older games which ignore it, so no risk)

It should work but sometimes it can have problems with IO registers.

[jotd]

erm, found the issue(s) just for laughs I'm going to relate them:

First, the "btst #E,($16,A6)" (test potinp) was not disassembled properly by IRA (a bunch of DC.Ws that went unnoticed among other properly disassembled instructions!!). So regexing the code to hunt for those failed!

Second: the 2-button joystick adaptation that I did for the CD32 read routine is wrong:

       moveq    #0,d0
        tst.b    d2
        beq.b    .no_further_button_test
        
       ... read the rest of the buttons

        bclr    d3,ciaddra(a1)        ;set bit to in at ciapra
        move.w    #$FF00,potgo(a0)    ;changed from ffff, according to robinsonb5@eab
.no_further_button_test

as you saw, ".no_further_button_test" is AFTER the potgo write, so my code fails on a 2 button / non CD32 joypad.

A case of blatant Murphy's Law!! now I have to re-adapt the whdload slaves I updated recently to make them work properly with a 2-button joy. Fortunately, there aren't so many of them / some of them need updating anyway.

Thanks again.