Reading the second fire button

[hukka]

I'd like to have my game support the second fire button available on some joypads/joysticks (such as the C button on a Sega Megadrive joypad, which is all I have to test it with.)

To initialize that (along with the right mouse button), I do a

lea CUSTOM, a6
move.w    #BIT15|BIT14|BIT11|BIT10, POTGO(a6)  ; OUTRY+DATRY+OUTLY+DATLY

and to read,

btst    #14-8, POTGOR+CUSTOM        ; was secondary fire button hit?
bz    .Fire2                ; yes

However, it only works on WinUAE, and only if I reinitialize the POTGO register each frame. Otherwise the second fire button gets 'stuck' after being pressed once. Is that how it's supposed to work?

The real problem is that it doesn't work at all on my A1200. I'm seeing nothing in POTGOR when pressing the second fire button. The right mouse button is read fine. The pad is in working condition and the second button works in other games that support it. Any pointers please?

[Mrs Beanbag]

all the many hardware eccentricities are not emulated exactly (i'm sure Toni Wilen can furnish us with the details) but you have to introduce a small delay between writing to POTGO and reading POTGOR because of physical electronics, there is a capacitor that has to charge up or something. It's to do with the way it handles these pins being both input and output capable. Why they didn't abstract this away from the programmer i don't know but there you go.

It is like a DMA wait, a few scanlines should do it i think although i've never tried it myself.

[phx]

Originally Posted by hukka

lea CUSTOM, a6
move.w    #BIT15|BIT14|BIT11|BIT10, POTGO(a6)  ; OUTRY+DATRY+OUTLY+DATLY

I don't remember now which pin is connected to the second button, but I was successful by initializating POTGO with $ff00 in my game, just once during startup.

The real problem is that it doesn't work at all on my A1200.

Yes, some Amigas might fail because of their aged capacitors(?).

[Mrs Beanbag]

"Mapping the Amiga" on p467 recommends waiting 300 microseconds between writing POTGO and reading POTGOR

[Lonewolf10]

A quote from Toni from a thread somewhere on EAB (sorry I didn't record the exact location in my source code):

Originally Posted by ToniWilen

; Reading Keyboard
; ================
;
; Check that CIA-A serial port (SP) interrupt is set (or use ports
; interrupt), if set, read SDR, then set bit 6 in CIA-A CRA, wait at least
; ~70us, clear bit 6. (this is one method to handle handshake, there is
; also another one)
;
; This tells keyboard micro controller that key code has been read and
; new code can be sent.

Here's my calculations from my own keyboard reading routine. In order to wait ~300uS, 4 scanlines should be sufficient assuming that 1) my calculations are correct and 2) you are designing this for a PAL system

;
;
;  PAL
;  ===
;
;  50 VBLs / second = 0.02 seconds per VBL
;  250 scanlines per VBL = 0.00008 seconds per scanline
;  0.00008 seconds = 0.08 milliseconds (mS)= 80 micro seconds (uS)
;

[Toni Wilen]

Only need to set second button data direction and data bit to one. You sure your BITxx macro works? It looks like data direction is in input mode (only works if button has pullup resistor)

[Asman]

In Solomon's Key I used following code and as far as I remember it works. I tested it with cd32 pad on my a1200.

		btst	#14,$dff016
		bne.b	.exit

		st	fireballKey

.exit
		or.w	#$c001,$dff034

Routine is call one per frame.

[Toni Wilen]

Originally Posted by Asman

or.w #$c001,$dff034

That code reads from write-only register! (EDIT: It becomes write FFFF to POTGO!)

There is no need to write to bit 0 (only needed if other than red or blue CD32 pad needs to be read) or to write it each frame.

Note that KS vblank routine will reset POTGO: do not update POTGO until you have taken over the system or you will need to update it each frame to override KS POTGO write.

[Asman]

Originally Posted by Toni Wilen

That code reads from write-only register! (EDIT: It becomes write FFFF to POTGO!)

There is no need to write to bit 0 (only needed if other than red or blue CD32 pad needs to be read) or to write it each frame.

Note that KS vblank routine will reset POTGO: do not update POTGO until you have taken over the system or you will need to update it each frame to override KS POTGO write.

Oh, thank you Toni. So lets assume that I over taken system. Then I can do this in following manner, one time per frame

		btst	#14,$dff016
		bne.b	.exit

		st	fireballKey

.exit
		move.w	#$c000,$dff034

right ?

[Toni Wilen]

Originally Posted by Asman

Oh, thank you Toni. So lets assume that I over taken system. Then I can do this in following manner, one time per frame

		btst	#14,$dff016
		bne.b	.exit

		st	fireballKey

.exit
		move.w	#$c000,$dff034

right ?

It should work but if it does not, you probably have some other write to POTGO somewhere else and bit 0 write side-effect "overrides" it. (For example because pot capacitor is forced to discharge. POT lines are quite special, they have both digital and analog components)

[hukka]

Thanks everyone for the replies!
So if I'm understanding correctly, although I have system enabled while running, this should still work:

VBL_interrupt:
    lea CUSTOM, a6
    move.w    POTGOR(a6), Pot
    ; (some other stuff)
    move.w    #$C000, POTGO(a6)

But it doesn't - the value I get from POTGOR reads $5500. I'm not touching POTGO/POTGOR anywhere else than the vblank interrupt.

[Toni Wilen]

Originally Posted by hukka

Thanks everyone for the replies!
So if I'm understanding correctly, although I have system enabled while running, this should still work:

VBL_interrupt:
    lea CUSTOM, a6
    move.w    POTGOR(a6), Pot
    ; (some other stuff)
    move.w    #$C000, POTGO(a6)

But it doesn't - the value I get from POTGOR reads $5500. I'm not touching POTGO/POTGOR anywhere else than the vblank interrupt.

Setting POTGO first, then reading POTGOR should work (You probably need delay between writing to POTGO and reading POTGOR to allow pot capacitor charge or discharge depending on button state, without delay you may get incorrect button state. I think I timed this sometime ago and delay needed was very short, less than 1 scanline)

Normally your VBL routine (if it is added using exec routines) has lower priority than OS routine that sets POTGO "incorrectly". You can also try using very high priority for your VBL routine.

[hukka]

Okay, I took it out of the vbl routine and into the mainloop which does this now:

    WaitLine 270
    move.w    #$CC00, POTGO+CUSTOM

    WaitLine 276
    move.w    POTGOR+CUSTOM, Pot

And it still doesn't work, Pot still reads $5500. In both WinUAE and my 1200. I made sure that's the only place POTGO(R) gets touched in my code. The WaitLine macro works properly.

Originally Posted by Toni Wilen

Normally your VBL routine (if it is added using exec routines) has lower priority than OS routine that sets POTGO "incorrectly". You can also try using very high priority for your VBL routine.

Thanks for the tip - does anyone happen to have info on how to set the priority?

[Toni Wilen]

Originally Posted by hukka

Okay, I took it out of the vbl routine and into the mainloop which does this now:

    WaitLine 270
    move.w    #$CC00, POTGO+CUSTOM

    WaitLine 276
    move.w    POTGOR+CUSTOM, Pot

And it still doesn't work, Pot still reads $5500. In both WinUAE and my 1200. I made sure that's the only place POTGO(R) gets touched in my code. The WaitLine macro works properly.

It should work, it has to work. It is exact same method as reading right (or middle) mouse button. (You do remember that read data is inverted? 1 = not pressed, 0 = pressed)

Thanks for the tip - does anyone happen to have info on how to set the priority?

Interrupt node priority field, check RKM

[hukka]

Originally Posted by Toni Wilen

It should work, it has to work. It is exact same method as reading right (or middle) mouse button. (You do remember that read data is inverted? 1 = not pressed, 0 = pressed)

Well, time to make a minimal test program!
And a clarification because I'm not sure I mentioned this, I'm seeing the POTGOR register change from $5500 to $1500 when pressing the second fire button in WinUAE. But not on the Amiga. And those aren't the values I should be getting anyway, right?

Interrupt node priority field, check RKM

Thanks for the pointer!

[Toni Wilen]

Originally Posted by hukka

Well, time to make a minimal test program!
And a clarification because I'm not sure I mentioned this, I'm seeing the POTGOR register change from $5500 to $1500 when pressing the second fire button in WinUAE. But not on the Amiga. And those aren't the values I should be getting anyway, right?

It looks correct. Bit 14 is data bit (1=not pressed, 0=pressed).
Does bit 10 toggle when pressing right mouse button?
If yes, does joystick port also work if you insert mouse in joystick port and press right mouse button?

[hukka]

Originally Posted by Toni Wilen

Does bit 10 toggle when pressing right mouse button?
If yes, does joystick port also work if you insert mouse in joystick port and press right mouse button?

Yes to both. But nothing with either pads I tested with (a Megadrive pad and a brand new clone pad). I just tried the WHDload version of Great Giana Sisters which has the option of using the second button for jumping and it worked great with the MD pad, so I know it's not the hardware at fault.

[Toni Wilen]

Originally Posted by hukka

Yes to both. But nothing with either pads I tested with (a Megadrive pad and a brand new clone pad). I just tried the WHDload version of Great Giana Sisters which has the option of using the second button for jumping and it worked great with the MD pad, so I know it's not the hardware at fault.

Aah, I thought you used normally wired pad. Strange, according to pad schematics it should work. Does it work if you set POTGO data direction to input? (Mouse won't work anymore or normal joystick but this is only a test)

[hukka]

Originally Posted by Toni Wilen

Does it work if you set POTGO data direction to input? (Mouse won't work anymore or normal joystick but this is only a test)

It does! So do I need to implement a routine to detect whether I should set the input bit, or is there something else I can do?

[Toni Wilen]

I think I start to understand what is going on.. (Megadrive pad does not really work like everything else..) But first we need to confirm all 3 possibilies:

- second button with pull up resistor, some game pads, original Commodore mice, 3rd party mice may not have it. (not pressed = second button pin pulled to +5v via 10k resistor, pressed = shorted to ground). CD32 pad in 2-button mode should be like this case too.

- second button without pull up resistor. (not pressed = second button pin is floating, pressed = shorted to ground)

- Megadrive pad which has TTL chip which apparently can't override signal when Paula is programmed to output mode = "pullup emulation".

Do you have all test cases? Could you check if your mouse has pullup? (Measure resistance between pin 9 and pin 7: infinite = no pullup, about 10k = pullup)

I still assume single read mode can't handle all 3 cases.