Joystick reading code

[Thorham]

Originally Posted by mc6809e

Interrupts probably should be off. If an interrupt is serviced between the first two moves, enough time may elapse to allow switch bouncing (arcing between contacts of the switch) to increment the counters in joy1dat.

True, but the solution seems simple:

    move.w  joy1dat(a5),d0
    and.w   #$0303,d0

Originally Posted by mc6809e

With the additional stick up test, in the worst case it may take 28+9*20=208 cycles -- more than twice as many cycles.

A jump table is fastest, yes. But so what? 208 cycles x 50 frames per sec = 10400 cycles out of 7.14 million cylces on an A500. Who cares?

Originally Posted by mc6809e

But what bothers me the most about this sort of code is the variance it introduces in execution time. It increases the possibility that some obscure combination of inputs and state is going to cause things like dropped or skipped frames -- that makes debugging more difficult.

Dropped or skipped frames because of max 10400 cycles per sec? Doesn't seem too realistic to me.

[Mrs Beanbag]

Originally Posted by Thorham

What's the point of all this if you can just clear joytest, read joy1dat and compare? Why bit shuffle the data from joy1dat, use a lookup table, and compare?

because you might want to treat each direction (that is, vertical and horizontal) independently, regardless of diagonals.

[mc6809e]

Originally Posted by Leffmann

That's exactly the opposite to what I was saying. That code may be the best choice in some cases, but it also dictates that the game code must be adapted to the tiny joystick routine, when you should instead adapt the joystick routine to the game code.

Actually the jump table is the more flexible technique.

There's nothing that says the addresses in the table have to point back directly into the game code.

The destination addresses for the jmp (a0) could just as well all be small code snippits, all ending in rts, that place arbitrary values in any location convenient to the game's code.

[mc6809e]

Originally Posted by Thorham

Dropped or skipped frames because of max 10400 cycles per sec? Doesn't seem too realistic to me.

Possibly, so I'll just concede the point, then.

I just find it enjoyable to try and puzzle out faster and faster code.

I can't be the only one here that thinks that's fun.

[Mrs Beanbag]

yeah i love cycle shaving, pointless though it can be

[Thorham]

Originally Posted by Mrs Beanbag

because you might want to treat each direction (that is, vertical and horizontal) independently, regardless of diagonals.

Good point.

Originally Posted by mc6809e

I just find it enjoyable to try and puzzle out faster and faster code.

I can't be the only one here that thinks that's fun.

You're quite right.

Anyway, how about this (for the heck of it):

    move.w  joy1dat(a5),d0
    and.w   #$0303,d0
    move.w  d0,d1
    add.w   d1,d1
    add.w   #$0101,d0
    add.w   d1,d0

Now you can use btst on d0.

Bits:

01 = right
02 = down
09 = left
10 = up

[mc6809e]

Oh, that's fast for sure, Thorham.

What's cool is the code starts to look a bit like SIMD. And the obvious extension with longs to handle joy2dat too let's you process 4 pairs of bits at a time.

Nice.

[Thorham]

Originally Posted by mc6809e

What's cool is the code starts to look a bit like SIMD. And the obvious extension with longs to handle joy2dat too let's you process 4 pairs of bits at a time.

That's a very good idea. Something like this:

    move.l  joy0dat(a5),d0
    and.l   #$03030303,d0
    move.l  d0,d1
    add.l   d1,d1
    add.l   #$01010101,d0
    add.l   d1,d0

Bits:

direction   joy0dat     joy1dat
right            17           1
down             18           2
left             25           9
up               26          10

[jimmy2x2x]

EDIT: I didn't want to start a new thread as this one is very active at the moment - hope its not too OT..

Would this code be OK for reading buttons 1 and 2 in the routine?

; ReadJoystick - Reads joystick port 2 and populates variables
; EXIT: All "JOY" variables are either 0 or 2 (if pressed)

ReadJoystick:
		move.w	HWBase+joy1dat,d0			; Read Up Down Left Right
		move.w	d0,d1
		add.w	d1,d1
		eor.w	d0,d1
		move.w	#514,d2
		and.w	d2,d0
		and.w	d2,d1
		lea		JoyLeft(pc),a0
		move.w	d0,(a0)+
		move.w	d1,(a0)
;		rts
		
		sub		d0,d0						; Fire Button
		btst.b  #7,ciaa						; Was using $bfe0ff
		bne.s   .NoFire
		or		#512,d0
.NoFire		
		btst	#14,HWBase+potgor			; 2nd Fire Button
		bne.b	.No2ndFire
		or		#2,d0
.No2ndFire:
		move.w	d0,JoyButton				
		move.w	#$c000,HWBase+potgo			; This line *MIGHT* have to be moved away from potgor read
		rts		

JoyLeft			dc.b	0			; Joystick input
JoyRight		dc.b	0
JoyUp			dc.b	0
JoyDown			dc.b	0
JoyButton		dc.b	0
JoyButton2		dc.b	0

[Mrs Beanbag]

Originally Posted by Thorham

That's a very good idea. Something like this:

oh yeah i'm liking this. any way to get the fire buttons in as well, though?

[Thorham]

Originally Posted by Mrs Beanbag

oh yeah i'm liking this. any way to get the fire buttons in as well, though?

Sure, but is it useful? You have to read several registers to read all three buttons, and then you need extra code to mix that data with the directional data. Seems like a better idea to just btst those registers directly. It's probably faster and easier.

[Thorham]

If you don't mind splitting the joystick direction bits into two registers, then you can do this:

    move.l  joy0dat(a5),d0
    move.l  d0,d1
    add.l   d1,d1
    eor.l   d0,d1

Bits:

register    direction   joy0dat     joy1dat
d0          left             25           9
d0          right            17           1
d1          up               25           9
d1          down             17           1

[Mrs Beanbag]

well it might be faster but i don't know about easier...

from a stylistic point of view, i prefer to keep all the joystick reading code in a single subroutine, and return the result in a data register.

also i like to do things like (newValue AND NOT oldValue) in order to test which buttons have just been pressed or released.

[Thorham]

Originally Posted by Mrs Beanbag

well it might be faster but i don't know about easier...

It's for inlining.

Originally Posted by Mrs Beanbag

from a stylistic point of view, i prefer to keep all the joystick reading code in a single subroutine, and return the result in a data register.

I can understand that. The code I posted before the last snippet can be used that way. Now it also makes sense why you'd want the buttons in there as well. It should be easy to add. Perhaps like this (untested):

    move.l  joy0dat(a5),d0
    and.l   #$03030303,d0
    move.l  d0,d1
    add.l   d1,d1
    add.l   #$01010101,d0
    add.l   d1,d0

    move.b  $bfe001,d1
    and.b   #$c0,d1
    or.b    d1,d0

    swap    d0
    
    move.w  potgor(a5),d1
    and.w   #$5500,d1
    rol.w   #4,d1
    lsl.b   #4,d1
    or.w    d1,d0

Now everything is in d0, that is, all directions for both ports, and all three buttons for both ports... if I didn't make a mistake

If you only want button 1 for both ports, just drop everything from the swap (inclusive).

[Codetapper]

Don't forget CD32 controller buttons too

@robinsonb5

So I removed all the other (confusing) values from both tables and ended up with this:
Code:
_joy_tableX: dc.w 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,-1, 0
_joy_tableY: dc.w 0, 1, 0, 0,-1, 0, 0, 0, 0, 0, 0, 0, 0, 0
This appears to work fine!

Cool - but just double check that the code still works for diagonals?
I'm wondering if that's what the other values were for?

Well...I have no idea why I told it worked fine, because it does NOT work fine with diagonals at all!

So the lookup-tables really should look like this:

_joy_tableX:
    dc.w    0, 0, 1, 1, 0, 0, 0, 1,-1, 0, 0, 0,-1,-1 
_joy_tableY:    
    dc.w    0, 1, 1, 0,-1, 0, 0,-1,-1, 0, 0, 0, 0, 1

The complete lookup-index is as follows:
LEFT: $0018 = 24/2 = 12 + 1 = 13th value in table _joy_tableX = -1
RIGHT: $0006 = 6/2 = 3 + 1 = 4th value in table _joy_tableX = 1
UP: $0008 = 8/2 = 4 +1 = 5th value in table _joy_tableY = -1
DOWN: $0002 = 2/2 = 1 + 1 = 2th value in table _joy_tableY = 1

LEFT+UP $0010 = 16/2 = 8+1 = 9th value in both tables (-1, -1)
LEFT+DOWN $001A = 26/2 = 13+1 = 14th value in both tables (-1, 1)
RIGHT+UP $000E = 14/2 = 7+1 = 8th value in both tables (1, -1)
RIGHT+DOWN $0004 = 4/2 = 2+1 = 3rd value in both tables (1, 1)

Now I also understand why these tables both are 14 values long, because of the LEFT+DOWN combo.

Just to be complete:

My first attempt of joystick-reading code looked like this:

    move.w #1,d6

    move.w $dff00c,d0    ; X1
    move.w d0,d1        ; Y1
    lsr.w #1,d1
    eor.w d0,d1

    btst #1,d0
    bne .joyRight

    btst #9,d0
    bne .joyLeft

    btst #0,d1
    bne .joyDown

    btst #8,d1
    bne .joyUp

    bra .noJoy

;----- move Sprite

.joyRight:
    add.b d6,1(a6)    ; increase sprite Hstart

    btst #0,d1
    bne .joyDown

    btst #8,d1
    bne .joyUp

    bra .noJoy

.joyLeft:
    sub.b d6,1(a6)    ; decrease sprite Hstart

    btst #0,d1
    bne .joyDown

    btst #8,d1
    bne .joyUp

    bra .noJoy

.joyDown:
    add.b d6,(a6)    ; increase sprite Vstart
    add.b d6,2(a6)    ; increase sprite Vstop
    bra .noJoy

.joyUp:
    sub.b d6,(a6)    ; decrease sprite Vstart
    sub.b d6,2(a6)    ; decrease sprite Vstop
.noJoy:

Which does work fine (also with diagonals).

[Thorham]

Originally Posted by borchen

Just to be complete:

My first attempt of joystick-reading code looked like this:

...

Which does work fine (also with diagonals). Today 13:20

Then keep it. There's nothing wrong with the joystick reading code, and those lookup tables aren't needed. You can optimize the lsr.w #1,d1 to add.w d0,d0 and test different bits, but that's not very important.

Why are those lookup tables not needed? Because they create more code, and in the end you still have to use compare instructions.