Taking a deeper dive into Karate Champ's code, I started charting the RAM more thoroughly.
Cheat Code
I stumbled upon what appears to be a scrapped cheat code.
In game state #00, byte $004F thru $0052 are cleared to #00. For 240 (#f0) game frames, while the title screen is scrolling up, the program will check if $004F and $0052 are clear, then wait for input on gamepad 1. If detected, it will load $00AC into the X-register and map the input to $00AD,X. It will then increase $00AC, allowing many inputs to be logged.
NOTE: Byte $00AC is never set outside this subroutine. This means by default it will be either #00 or #ff, depending on the byte initialization settings of the console/emulator. If the console defaults bytes to #ff, then the first write to $00AD,X will overwrite $00AC with the input. Resetting the console, exiting attract mode, or getting a game over will not reset $00AC, so it will retain its previous value until a power cycle.
NOTE: Byte $004F is also cleared when entering attract mode.
If byte $0052 is set to #0a, which corresponds to the length of the cheat code, the program will compare $0053 thru $005C against the cheat code. The code itself is:
[ #10 #80 #20 #40 #20 #80 #10 #40 #01 #02 ]
This corresponds to:
[ Up, Rt, Dn, Lf, Dn, Rt, Up, Lf, A, B ]
If the entered code matches, byte $004F changes to #ff. From this point, each time the player presses A on gamepad 1, if byte $0051 is less than #09, it will increase $0050. If $0050 reaches #0a, it will roll back to #00 and increase $0051. If $0051 is #09 and $0050 is also #09, nothing will happen. Thus, we can think of this ($0051, $0050) pair as decimal value ranging from 0 to 99.
NOTE: A physical turbo controller purportedly can repeat a button press 10 times per second. A turbo function in an emulator like FCEUX will repeat a button 30 times per second. So while an emulator would be able to max out at 99, a physical turbo controller would probably only reach a value of 40. Without a turbo controller, a player would be hard-pressed to reach 25. This is all based on the assumption that the turbo button was held at the start of the title scroll.
Given that bytes $004F thru $0052 are reset every time game returns to the title screen, the player would have to enter code every time the title scroll starts. There would be nowhere near enough time, even with a turbo controller, to enter the code and select whichever value is supposed to be represented by ($0051, $0050). This makes the code useless.
All of this is moot, however. Even though I can see in the program where $004F gets set, I can't find anywhere that $0052 gets written to. Not only that, I can't find anywhere else $0050 and/or $0051 get read. As you can see here, the subroutine for fetching the code is self-contained, so it's not like I missed a branching conditional.
>00:85D1: A5 4F LDA $4F Sys.CHEATCODE_PASS = #$FF
00:85D3: 30 28 BMI $85FD
00:85D5: A5 52 LDA $52 Sys.CHEATCODE_LENGTH = #$0A
00:85D7: C9 0A CMP #$0A
00:85D9: B0 0D BCS $85E8
00:85DB: A5 1B LDA $1B Sys.INPUT_LAST_PRESS[GP1] = #$00
00:85DD: F0 3E BEQ $861D
00:85DF: A6 AC LDX $AC Sys.CHEATCODE_INPUT_LOG_POINTER = #$21
00:85E1: 95 AD STA $AD,X = #$10
00:85E3: E6 AC INC $AC Sys.CHEATCODE_INPUT_LOG_POINTER = #$21
00:85E5: 4C 1D 86 JMP $861D
00:85E8: A2 00 LDX #$00
00:85EA: B5 53 LDA $53 Sys.CHEATCODE_INPUTS[0],X
00:85EC: DD 1E 86 CMP $861E,X @ $861E = #$10
00:85EF: D0 2C BNE $861D
00:85F1: E8 INX
00:85F2: E0 0A CPX #$0A
00:85F4: D0 F4 BNE $85EA
00:85F6: A9 FF LDA #$FF
00:85F8: 85 4F STA $4F Sys.CHEATCODE_PASS = #$FF
00:85FA: 4C 1D 86 JMP $861D
00:85FD: A5 1B LDA $1B Sys.INPUT_LAST_PRESS[GP1] = #$00
00:85FF: 29 01 AND #$01
00:8601: F0 1A BEQ $861D
00:8603: A5 51 LDA $51 = #$00
00:8605: C9 09 CMP #$09
00:8607: D0 06 BNE $860F
00:8609: A5 50 LDA $50 = #$00
00:860B: C9 09 CMP #$09
00:860D: F0 0E BEQ $861D
00:860F: E6 50 INC $50 = #$00
00:8611: A5 50 LDA $50 = #$00
00:8613: C9 0A CMP #$0A
00:8615: 90 06 BCC $861D
00:8617: A9 00 LDA #$00
00:8619: 85 50 STA $50 = #$00
00:861B: E6 51 INC $51 = #$00
00:861D: 60 RTS -----------------------------------------
The whole segment concerting $00AC and $00AD et al is not even utilized by the code subroutine. It serves no visible purpose. Furthermore, since $00AC is only reset by power cycling, it is only a matter of time before $00AD,X will overflow into the audio aspect of the zero page, and then eventually loop over the top of the zero page, causing program corruption.
This code only appears in the US release. If I had to guess, I would say it appears to be a scrapped difficulty selector. The programmers either did not have time to address the bugs, or scrapped the code without ever noticing the critical bug.
Player Controls
This is a refresher for anyone that read my previous review.
The gamepads are only updated once per every 8 game frames. This is why the instruction manual said you need to hold the buttons down in order for your attack to register. You do not need to hold buttons down for them to register, you just need to make sure they are down on every eighth frame. Unfortunately, there is no simple way of knowing when every eighth frame is.
When a player walks, he only moves 1 pixel every other game frame. With controls locked for 8 frames, this means the player will move 4 pixels at a time when walking. We can thus try to think of the screen as having a 4 pixel wide grid, although we will soon see that this is not actually the case.
Many attacks will move the player 8 pixels when executed. Leaping and jump kicks, will move the player by an odd amount, shifting the player off the grid.
Collision checks with the other player happen after moving. This means even if both players are aligned to the grid, the moving player will shift 1 pixel off-grid.
Even though the gamepads are updated only once every 8 frames, a player's state is updated every frame. Most states are animated and will stay on each state for 10 frames, not 8. This means a player could quite possibly enter one of the walking states in the midst of the eight-frame cycle after having released one of the attack buttons and still holding the D-pad. This will throw the player off the grid.
Moving to the edges of the screen will realign a player with the grid
CPU Players
Byte $005D keeps track of match decisions. The lowest 2 bits are player 1 and the next 2 bits are player 2. If both bits are set for a player, it is treated as "0". Bit 7 in $005D is set in attract mode. This bit does not mean the game is in attract mode, however. It denotes that player 1 (white) is CPU-controlled. Bit 6 denotes that player 2 (red) is not CPU-controlled.
When toggling between 1 Player and 2 Player mode on the title screen, the option alternates between #00 and #40. This value is copied to $005D when Start is pressed. One might understandably assume that #00 means one-player mode, #40 means 2-player mode, and #80 means attract mode. However, if you change the value from #40 to #c0, you can play as player 2 (using gamepad 2) while the CPU plays as player 1 with its own AI instructions.
When controlled by the CPU, player 1 will follow a specific pattern. The CPU will repeat the same command for 80 frames. There are 16 commands, which correspond to simulated button presses on gamepad 1:
- A (punch x3)
- B (back kick x2)
- Dn (squat)
- A & B (roundhouse x2)
- Lf (back up)
- Lf & A (low kick x2)
- A (punch x2)
- A (punch x2)
- A (punch x3)
- Lf & A (low kick x2)
- Rt & A (front kick x 2)
- Lf (back up)
- A & B (roundhouse x2)
- Dn (squat)
- B (back kick x3)
- A (punch x2)
Conversely, the CPU for player 2 uses a much more complex AI. Byte $0065 is the CPU's rank. It will change up its behavior at rank 3, 5 (minor change), 6, and 7 (minor change). The CPU will only act when in the Idle state. Since there are only two major behavioral changes, we can think of the CPU has having Easy, Normal, and Hard difficulties, with some minor ramps up in difficulty halfway through the latter two.
A player can be in one of 62 states. However, some states are tied into each other. Each state has a corresponding subroutine, both for humans and CPU. Below is a list of each state ("Idle" is state 0):
- Step forward 0
- Step forward 1
- Step backward 0
- Step backward 1
- Block High 0
- Block High 1
- Block Low 0
- Block Low 1a
- Squat
- Jump 0
- Jump 1
- Block High 1b (different foot position)
- Reverse Punch 0
- Reverse Punch 1 (hold)
- Reverse Punch 2
- Low Punch 0
- Low Punch 1 (hold)
- Low Punch 2
- Front Kick 0
- Front Kick 1 (hold)
- Front Kick 2
- Back Kick 0
- Back Kick 1 (hold)
- Back Kick 2
- Round Kick 0
- Round Kick 1 (hold)
- Round Kick 2 (hold)
- Low Kick 0
- Low Kick 1 (hold)
- Low Kick 2
- Right Foot Sweep 0
- Right Foot Sweep 1 (hold)
- Right Foot Sweep 2
- Left Foot Sweep 0
- Left Foot Sweep 1 (hold)
- Left Foot Sweep 2
- Jump Kick 0
- Jump Kick 1
- Jump Kick 2
- Jump Kick 3
- Reverse Kick 0
- Reverse Kick 1
- Reverse Kick 2
- Back Round Kick 0
- Back Round Kick 1 (hold)
- Back Round Kick 2
- Leap Right 0
- Leap Right 1
- Leap Right 2
- Leap Left 0
- Leap Left 1
- Leap Left 2
- Knocked Back 0
- Knocked Back 1
- Knocked Forward 0
- Knocked Forward 1
- Hit Low 0
- Hit Low 1 (same as 57 for some reason)
- Standing
- Bowing
- Cheering
Bit 7 of a human's state is set for states that deal damage. However, this is never utilized anywhere that I have noticed. It may have been left over from old hit detection code.
At all ranks, the CPU will follow a basic movement pattern. If the CPU player is at either edge of the screen, it will leap toward the center. If player 1 is more than 24 pixels away, it will walk forward. Otherwise, it will consider attacking when close enough.
Randomization for player 2's AI is based on a frame counter, byte $00A3. These possible actions are:
Reverse Punch (3/16 chance)
Round Kick (3/16 chance)
Back Round Kick (2/16 chance)
Low Punch (2/16 chance)
Low Kick (2/16 chance)
Front Kick (1/16 chance)
Jump Kick (1/16 chance)
Right Foot Sweep (1/16 chance)
Left Foot Sweep (1/16 chance)
Byte $00A4 counts how many frames the player 2 CPU is not actually in the midst of an attack. I will call these "passive frames". This determines the odds of the CPU choosing an attack.
Typically, the CPU will act on every 8th or 16th step. If you lock $00A4
to an odd number, the CPU will never attack.
All of player 1's attacks are briefly telegraphed to byte $0094 at the moment the attack starts. If the CPU is rank 5 and in the Idle state at that exact moment, it will attempt to back away from player 1, regardless of how close to the attack it is.
Easy Difficulty
For the first three ranks, the CPU will check if both players are facing each other. If so, it checks if the number of passive frames is a multiple of 16. If that's the case and if player 1 performed a blockable attack, the CPU will block it.
If it doesn't block anything, then the CPU checks if the number of passive frames is a multiple of 8. If so, it checks if player 1 is on the first frame of a low kick or foot sweep. It will jump over such attacks. Otherwise, it then checks if player 1 is on the first frame of a reverse punch, front kick, or round kick. If so, the CPU will duck under the attack.
By this point, the CPU will check if the number of passive frames is a multiple of 16 again. If not, it will do nothing and the passive frame count will increase. Otherwise, the CPU will choose a random attack.
Normal Difficulty
This time, the CPU can block the three slow attacks after just 4 passive frames. If it doesn't block, it will jump over low attacks. If player 1 is on the first frame of a high reverse punch, round kick, or jump kick, the CPU will duck. Unlike in Easy, there is no passive frame requirement for these evasive maneuvers.
The requirement for a random attack is now just 4 passive frames.
Hard Difficulty
Behavior is generally the same as Normal. However, if the CPU does not block, but player 1 is on the first frame of a high reverse punch or front kick, the CPU will back up instead of ducking.
Attacks
As you can tell from the AI code, simply taking a couple steps backward can save a point. Likewise, walking into an attack can save you.
Certain attacks are further telegraphed on the very first frame, for just one frame. A Front Kick and a low Reverse Punch telegraph to bit 6 of the player's points variable. A Back Round Kick telegraphs to bit 7 of the player's point variable. These are the only blockable attacks. So if you ever wondered why you can't block, this is the reason.
As mentioned in my review of Karate Champ on the NES, a player's position along the y-axis has no bearing on anything. It's all about positioning along the x-axis. But if vertical positioning has no bearing on hit detection, why does the CPU jump or duck to avoid attacks?
Every attack has a handful of states it simply cannot hit. For example, jump kick and both round kicks will never hit a player in the squatting or foot sweep states. Likewise, neither the low kick nor foot sweeps will ever hit a player in any of the jumping states.
The program stores a massive array of hit box widths for all attacks against every state the opponent could be in. With 11 attacks, 53 possible sparring states, and 2 facing directions for each player, that's a look-up table of 2332 bytes!
If you are too far from or too close to your opponent, your attacks will
either miss or only score a half point. In order to get a full point,
you have to be the exact distance specified in the array. Every width is an even value, many of which are multiples of 4. Having your back up against the wall, so to speak, could help you pull off full-point attacks -- but it could also help your opponent.
The array order within each state match-up is facing right attacking opponent in the back, facing right attacking opponent head-on, facing left attacking opponent head-on, facing left attacking opponent in the back. Sprite origins are in the top-left, so distances in the array vary depending upon the directions both players are facing. In addition, when the data is two widths and two negatives, such as with the Foot Sweeps, only the two widths are used.
Below is a list of which states each attack cannot hit.
- Reverse Punch:
- Any time:
- Jumping - legs up only
- Reverse Punch - arm extended only
- Jump Kick - leg extended only
- Leaping - legs up only
- Facing each other:
- Walking Forward - legs crossed only
- Walking Backward
- Squatting
- Low Punch - first frame only
- Foot Sweeps
- Not facing each other:
- Foot Sweeps - leg extended only
- Low Reverse Punch
- Any time:
- Jumping
- Jump Kick - legs up only
- Leaping - legs up only
- Facing each other:
- Walking Forward - legs crossed only
- Walking Backward
- Right Foot Sweep - leg extended, attacker faces left only
- Left Foot Sweep - leg extended, attacker faces right only
- Reverse Kick - not the first frame
- Front Kick
- Any time:
- Jumping - legs up only
- Jump Kick - not the first frame
- Leaping - legs up only
- Facing each other:
- Walking Forward - legs apart only
- Walking Backward
- Back Kick - leg extended only
- Round Kick - leg extended only
- Back Round Kick - leg extended only
- Back Kick
- Any time:
- Squatting
- Low Punch
- Foot Sweeps
- Jump Kick - legs up only
- Leaping - legs up only
- Facing same direction:
- Walking Forward - legs crossed only
- Walking Backward - legs crossed only
- Round Kick
- Any Time:
- Squatting
- Low Punch
- Foot Sweeps
- Jump Kick - leg extended only
- Leaping - legs up only
- Facing each other:
- Back Round Kick - leg extended only
- Facing same direction
- Back Kick
- Low Kick
- Any time:
- Jumping
- Round Kick - leg extended only
- Low Kick - leg extended only
- Jump Kick
- Reverse Kick
- Leaping
- Facing each other:
- Foot Sweeps - leg extended only
- Foot Sweeps
- Any time:
- Squatting
- Jumping
- Foot Sweeps
- Jump Kick
- Leaping
- Jump Kick
- Any time:
- Squatting
- Foot Sweeps
- Jump Kick
- Leaping - legs up only
- Reverse Kick
- Any time:
- Jumping - legs up only
- Jump Kick - legs up only
- Leaping - legs up only
- Back-to-back:
- Walking Forward - legs crossed only
- Back Round Kick
- Any time:
- Squatting
- Jumping - legs up only
- Low Punch
- Foot Sweeps
- Jump Kick - leg extended only
- Back Round Kick
- Leaping - legs up only
Bonus Round
There is only one bonus round in the NES version. Other versions had a bull (which I always just tried to jump over, but I guess you're supposed to hit it?), and I think even a board-breaking event. There will only ever be two vases on-screen at a time in this bonus round, so it's not too difficult once you get the hang of it.
When a match winner has been decided, the current game frame count is ANDed by #70 and then added to 5. This value is applied to both vases. An appearance timer is set to #80 (2 seconds) for the first vase and #ff for the second.
The lower nybble is the vase's state, with 5 being the state for counting down the timer until the vase appears. The upper nybble deals with the vase's position. If bit 3 of the position is set, the vase will appear on the right side of the screen, otherwise it will appear on the left. This alternates each time. The vase's height is determined by the lower 2 bits of the position after increasing it by 1.
There are 8 waves of vases. The time between vases reappearing decreases by #10 frames (roughly 1/4 s) the first five waves, stays at #30 (roughly 2/5 s) for the next three waves, then resets.
As you can see, the bonus round is very basic and repetitive. The hardest part about it is dealing with the hit detection. The key is to learn to attack earlier rather than later, but not too early. You can actually hit a vase just before it reaches you.
For vases, there is a much smaller array for collision checks between the player and vases for each attack state. Each state has four sets of 4 distances. The first set is when the vase is flying to the left while the player is facing right, the second is when the vase is flying left while the player is facing left, the third is when the vase is flying right while the player is facing right, and the fourth is when the vase is flying right while the player is facing left. Each individual distance corresponds to the vase's height.
If the distance value is #ff, the vase will pass through the player. If the distance between the player and the vase is less than that value, the player will get knocked out and the bonus round will end. Next, the program adds 8 to the distance value to find the maximum range for the player's attack, then subtracts 8 from the distance value to find the minimum range. If the distance to the vase is within that range, the vase is safely broken and the player's score increased.
You read that right. The knockout check happens before the breakage check. That means hit box is not 16 pixels wide, but merely 8 pixels.
As a reminder, the controller is only read once every 8 frames. Walking moves you half a pixel each step, so 4 pixels per step. As if that wasn't already making things difficult enough, each animated state the player may be in requires 10 frames before animating to the next state. Further complicating matters is the fact that the vase is not locked to this same eight-frame cycle. It can spawn at any time and moves at a steady 1 pixel per frame.