To me the most obvious way to do this is to look for combinations like up+A, down+A, left+A, right+A. Even if I reserve the Start button for pausing, that still leaves me with 12 combinations (4 each for A, B and Select). 12 holes is plenty for this kind of game, and actually due to screen space limitations I’ve decided to limit myself to 10 holes.

Detecting button combinations on the NES is a little bit tricky. I don’t want to allow the player to hold down B and spam the dpad to hit many holes very quickly. Also, if the player presses up+left at the same time while pressing B, I don’t want two holes to be hit simulataneously. On the other hand, it would be unreasonable to expect the player to hit two buttons at once in the exact same frame. Nobody is that fast. So I have to allow some leeway. With that in mind, here is how my Button Combo routine works.

Button Combo Routine

Output

My button combo routine takes what the user has pressed and outputs a value 0-12. The output possibilities are laid out like this:

• 0: no combination was pressed.
• 1-4: B+dpad was pressed (in order: up, down, left, right)
• 5-8: A+dpad
• 9-12: Select+dpad

Each of these values is mapped to a hole, and I use the outputted value to index into hole-related tables. For example, here is a table that I use to determine if a valid hole was whacked:

valid_holes:
    .byte 0             ;unused (no combo)
    .byte 1, 1, 1, 1    ;B (up, down, left, right order)
    .byte 1, 1, 1, 1    ;A
    .byte 1, 1, 0, 0    ;Select
    .byte 0, 0, 0       ;unused (select+left, select+right unused)

I have tables for attribute table PPU addresses and the like as well.

Input

When I read the controller every frame, I store two sets of data in RAM. One is the current button states (pressed or not pressed), which I store in a variable called joypad1. The other is off-to-on transitions, ie what was unpressed last frame but is pressed this frame. Off-to-on transitions are stored in a variable called joypad1_pressed.

Each variable is one byte, basically a bitflag with each bit corresponding to a button. My controller reading routine stores button information in this order:

joypad1 and joypad1_pressed bits:

76543210
||||||||
|||||||+- right
||||||+-- left
|||||+--- down
||||+---- up
|||+----- start
||+------ select
|+------- B
+-------- A

Logic

The first thing I do in my button combo routine is to check if A, B or select is pressed. If not, obviously we can’t have a combo, so skip to the end.

;---------------------------------------------------
; check for dpad+button combos
.proc check_combos
    lda joypad1
    and #%11100000      ;isolate A, B, select
    beq @somewhere_near_the_end
    ;....snip

If a button is pressed, I want to grab its combo value and store it in RAM:

.proc check_combos
    lda joypad1
    and #%11100000      ;isolate A, B, select
    beq @clear_btn_val  ;if not pressed, clear btn_val
    lda joypad1_pressed
    and #%11100000      ;if off_to_on, we need to set the flag, else skip to dpad check
    beq @check_dpad
@set_btn_val:
    asl                 ;shift the A button bit to the CF
    bcc @B
    lda #$05            ;if A bit is set, store 5 in btn_flag  (5, 6, 7, 8 = A combo)
    bne @store
@B:
    asl                 ;shift the B button bit to the CF
    bcc @Select
    lda #$01            ;else if B bit is set, store 1 in btn_flag (1, 2, 3, 4 = B combo)
    bne @store
@Select:
    lda #$09            ;else Select bit must be set, so store 9 in btn_flag (9, 10, 11, 12 = Select combo)
@store:
    sta btn_val         ;add dpad value to this to get index
@check_dpad:
    ;.....snip

@clear_btn_val:
    lda #$00
    sta btn_val
@end:
    rts
.endproc
    

Notice that I check if the button is newly pressed or if it was held from last frame. This check is for a special case. Say the user is holding A. Then say a monster they want to smack appears in the up+B hole. The player will press up+B, but there is a chance that there will be several frames of A+B as the player slides their thumb from A to B. I want to catch the newest button press (B), not the older one (A). So I check joypad1_pressed. If a button is newly pressed this frame, I set btn_val. If not, I skip straight to the dpad (btn_val having been set in a previous frame).

To say it another way, I only alter the value of btn_val in two cases: when a new button is pressed, or when no buttons are pressed. This is important for another case too, which I will get to in a moment.

Note that if on the off-chance that B, A or Select are newly pressed simultaneous in the same frame, A takes precedence over B, which takes precedence over Select. Not going to happen often, and when it does it’s not a big deal – the player will know they mashed both buttons.

Finally we check the dpad to complete the combo:

@check_dpad:
    lda btn_val
    beq @end            ;if A, B, Select not pressed, no combo
    lda joypad1
    and #%00001111      ;isolate dpad
    beq @end            ;if no arrows pressed, no combo
    tay
    lda dpad_add, y     ;else, grab arrow value from table (up = 0, down=1, left=2, right=3)
    clc
    adc btn_val         ;add arrow value to button value.  Results in a number 1-12
    sta joypad1_combo
    jsr do_button_combo
@clear_btn_val:
    lda #$00
    sta btn_val
@end:
    rts

First thing I check is if btn_val is 0. But if we made it this far, shouldn’t this be non-zero? The player is definitely holding down either A, B or Select afterall. Yes they are, but btn_val could still be zero. After a button combo is registered, I process the combo via do_button_combo and then I clear btn_val. This check for btn_val == 0 covers the case that a button combination was recently processed (say last frame), but the player hasn’t released the buttons yet. It took me some bug-hunting before I realized I needed this check. Button Combinations are tricky, aren’t they?

The rest is pretty straightforward. I check the dpad. If no arrow is pressed, there is no combo so I return. If an arrow is pressed, I grab its value from a table and add it to btn_val to get the final combo value. The reason for the dpad_add table is to protect against cases of multiple arrows being pressed at the same time. If up+left is pressed, for example, I resolve it to up. If left+right is pressed, I resolve it to left. If you’re curious, my table looks like this:

;this table maps each possible d-pad combination to a single d-pad direction
;   0 = up, 1 = down, 2  = left, 3 = right
dpad_add:
    .byte 0     ;unused (will never be read)
    .byte 3     ;r -> right
    .byte 2     ;l -> left
    .byte 2     ;r+l -> left
    .byte 1     ;d -> down
    .byte 1     ;d+r -> down
    .byte 1     ;d+l -> down
    .byte 1     ;d+r+l -> down
    .byte 0     ;u -> up
    .byte 0     ;u+r -> up
    .byte 0     ;u+l -> up
    .byte 0     ;u+r+l -> up
    .byte 0     ;u+d -> up
    .byte 0     ;u+d+r -> up
    .byte 0     ;u+d+l -> up
    .byte 0     ;u+d+r+l -> up

Having this in table form makes it easy to modify in the future if I need to tweak some of the values (poor right arrow gets overruled a lot, doesn’t he?). If you want to know more about this technique, I have written about protecting against odd dpad combinations using tables before.

That’s it. It’s a little complicated but it works. I haven’t optimized this routine, so it’s possible that I could improve it somehow. I’d rather move forward though, since this works fine the way it is.

Incidentally, the player is allowed to hold a dpad arrow and spam A/B/Select. Doing so is of such limited use that I don’t see it being abusive. If testing reveals otherwise though, I’ll rewrite the routine to protect against that.

Full Routine

Here’s the full routine in case anyone wants to copy/paste it into their game. If you do, I will feel really happy if you mention me in the credits somewhere. :)

;---------------------------------------------------
; check for dpad+button combos
.proc check_combos
    lda joypad1
    and #%11100000      ;isolate A, B, select
    beq @clear_btn_val  ;if not pressed, clear btn_val
    lda joypad1_pressed
    and #%11100000      ;if off_to_on, we need to set the flag, else skip to dpad check
    beq @check_dpad
@set_btn_val:
    asl                 ;shift the A button bit to the CF
    bcc @B
    lda #$05            ;if A bit is set, store 5 in btn_flag  (5, 6, 7, 8 = A combo)
    bne @store
@B:
    asl                 ;shift the B button bit to the CF
    bcc @Select
    lda #$01            ;else if B bit is set, store 1 in btn_flag (1, 2, 3, 4 = B combo)
    bne @store
@Select:
    lda #$09            ;else Select bit must be set, so store 9 in btn_flag (9, 10, 11, 12 = Select combo)
@store:
    sta btn_val         ;add dpad value to this to get index
@check_dpad:
    lda btn_val
    beq @end            ;if A, B, Select not pressed, no combo
    lda joypad1
    and #%00001111      ;isolate dpad
    beq @end            ;if no arrows pressed, no combo
    tay
    lda dpad_add, y     ;else, grab arrow value from table (up = 0, down=1, left=2, right=3)
    clc
    adc btn_val         ;add arrow value to button value.  Results in a number 1-12
    sta joypad1_combo
    jsr do_button_combo
@clear_btn_val:
    lda #$00
    sta btn_val
@end:
    rts
.endproc

;this table maps each possible d-pad combination to a single d-pad direction
;   0 = up, 1 = down, 2  = left, 3 = right
dpad_add:
    .byte 0     ;unused
    .byte 3     ;r -> right
    .byte 2     ;l -> left
    .byte 2     ;r+l ->left
    .byte 1     ;d -> down
    .byte 1     ;d+r -> down
    .byte 1     ;d+l -> down
    .byte 1     ;d+r+l -> down
    .byte 0     ;u -> up
    .byte 0     ;u+r -> up
    .byte 0     ;u+l -> up
    .byte 0     ;u+r+l -> up
    .byte 0     ;u+d -> up
    .byte 0     ;u+d+r -> up
    .byte 0     ;u+d+l -> up
    .byte 0     ;u+d+r+l -> up

Conclusion

So button combinations are done with, and if you watched the video embedded in the last post you will see that they work quite well! This game is really coming along.

After a long break I finally got back to some homebrew coding. I worked in 6502 for a few hours today. I didn’t work on Explorer, but rather a different game project that is less ambitious. I’ll introduce the game properly in a future post.

What I Did Today

Button Combos

One thing that I needed for the new game project was a way to detect button combinations like up+A or right+B – the kind that you use to select plays in TecmoBowl. It was a little tricky to pull off. For one thing, if the player presses something like up+left+A, I need to resolve that to either up+A or left+A. I need to work that out for all possible combinations of button presses. This includes taking care of cases where A+B are pressed at the same time.

Another issue is with holding buttons. If the player holds B down and makes circles around the dpad, I only want it to catch the first combination. To do two combos in a row, they should release the B button and press it again. But what if the player hits up+B, and then while still holding B they press A+left? Does the holding of B stop the 2nd combination from being picked up or not? There are a lot of possible cases since the controller reading routine is called 60 times per second. The player can’t control their input on a frame-by-frame scale. Sliding from B to A might very well contain several frames (fraction of a second) where both buttons are held down before the B button is released. Not impossible to solve, but it wasn’t as straightforward as I had expected.

Sound Engine

Another thing I did today was port my sound engine to ca65. I wrote my NES sound tutorials for the NESASM assembler. My tutorials are a continuation of another set of tutorials which use NESASM and I wanted to stay consistent. Plus most new nesdevers start with NESASM as it is very newbie-friendly.

My tutorial sound engine was an improvement over the one I had previously written in ca65, so I wanted to replace the old with the new. So I spent some time today porting my sound engine from NESASM to ca65. I was sure everything was going to break as soon as I got all the syntax converted. But it didn’t! Once I got it to assemble it worked perfectly on the first try! That was a relief.

Scopes

ca65 lets you define scopes. Scopes enable you to keep parts of your program hidden from the other parts of your program. It’s good to separate modules, especially in large programs, so that you don’t have variable conflicts and the like. These bugs are the hardest to trace in assembly language.

I didn’t use scopes before because I didn’t really know how. But I found a great thread on nesdev about ca65 scopes that told me how to do it, so I spent some time today separating my sound and controller reading modules from the main program. Everything feels much … cleaner now. Like washing your hands after working outside on a summer day. I can physically feel how much easier things are going to be in the future for me with scopes.

New NES

I bought an NES! Ordered it on Yahoo Auctions on Saturday and it arrived at my house on Sunday! All I need now is a PowerPak and I can start testing my programs on real hardware. I can’t wait!

I’m too lazy to upload pictures here, but you can see the ones I posted to twitter here:

My new NES 1
My new NES 2