Donkey Kong Program Code

[ChrisP]

 

SHIT JUST GOT REAL.

[SQUIIDUX]

just saw this, i went from 6 to midnight!

[marinomitch13]

Just when I thought I was done with my own personal reading for the day...

[stella_blue]

I've attached a commented disassembly of a Donkey Kong rom. Most of the comments in this file are from a commenter who wishes to remain anonymous, but some of the comments are my own.

Thank you, Jeff.  This is huge!

A great deal of work remains to be done, but we couldn't have asked for a better head start.

[mikegmi2]

Very cool stuff, but remember what happened when Indiana finally got the holy grail...people died, that whole place collapsed?  Ok he saved his dad's life, maybe bad example...

Ok remember in Jurassic Park...sure they messed with the genetic code and created dinosaurs and stuff, but at what price?  John Hammond's grandchildren almost died, that lawyer got killed...some things are better left alone.

[stella_blue]

Ok remember in Jurassic Park...sure they messed with the genetic code and created dinosaurs and stuff, but at what price?  John Hammond's grandchildren almost died, that lawyer got killed...some things are better left alone.

If a thorough analysis of the DK code leads to the disappearance of a few lawyers, is that really a bad thing?

[mikegmi2]

No, not at all, but what about the children?!  WHAT ABOUT THE CHILDREN!

[xelnia]

Two questions:

I was messing around with frame-advance tonight and I noticed something that I hope someone can clarify for me. Does the Jumpman (or Fred) running animation actually stop for 1 frame for every 2 frames of movement? It looks to me like Jumpman stops for one frame every time a new sprite is loaded for the animation, then moves forward for 2 frames in the new position, then stops for 1 frame while the next sprite loads...etc, etc.

Is he actually moving forward every single frame, or is every 3rd frame a "dead" frame?

Second question: What constitutes "one pixel" for this game? It looks to me like the button on Jumpman's overalls would be one pixel of yellow, but I don't know how the screen area and sprites are broken down.

[stella_blue]

I was messing around with frame-advance tonight and I noticed something that I hope someone can clarify for me. Does the Jumpman (or Fred) running animation actually stop for 1 frame for every 2 frames of movement? It looks to me like Jumpman stops for one frame every time a new sprite is loaded for the animation, then moves forward for 2 frames in the new position, then stops for 1 frame while the next sprite loads...etc, etc.

Is he actually moving forward every single frame, or is every 3rd frame a "dead" frame?

Yes, every 3rd frame is a "dead" frame.  The sprite changes, but the horizontal position does not.

I verified your observations using MAME 0.140 with the debug option.  I recorded a game and played back the first few seconds of Level 1-1, with Mario running to the right on the bottom girder.  Using a "memory window" and individual frame advance, I monitored memory location #6203 (Mario's "X" Position).  Beginning with the first frame in which Mario appears, I observed the following hex values (1 for each frame, in groups of 3):

3F 40 40

41 42 42

43 44 44

45 46 46

47 48 48

49 4A 4A

4B 4C 4C

4D 4E 4E

4F 50 50

51 52 52

53 54 54

55 56 56

57 58 58

59 5A 5A

5B 5C 5C

5D 5E 5E

5F 60 60

61 62 62

63 64 64

65 66 66

67 68 68

69 6A 6A

6B 6C 6C

6D 6E 6E

6F 70 70

71 72 72

73 74 74

75 76 76

77 78 78

79 7A 7A

7B 7C 7C

7D 7E 7E

7F 80 80

81 82 82

83 84 84

85 86 86

87 88 88

89 8A 8A

8B 8C 8C

8D 8E 8E

8F 90 90

91 92 92

93 94 94

95 96 96

97 98 98

99 9A 9A

9B 9B 9C

9D 9E 9E

9F A0 A0

A1 A2 A2

A3 A4 A4

A5 A6 A6

A7 A8 A8

A9 AA AA

AB AC AC

AD AE AE

AF B0 B0

B1 B2 B2

B3 B4 B4

B5 B6 B6

B7 B8 B8

B9 BA BA

BB BC BC

BD BE BE

BF C0 C0

C1 C2 C2

C3 C4 C4

C5 C6 C6

C7 C8 C8

C9 CA CA

CB CC CC

CD CE CE

CF D0 D0

D1 D2 D2

D3 D4 D4

D5 D6 D6

D7 D8 D8

D9 DA DA

DB DC DC

DD DE DE

DF E0 E0

E1 E2 E2

E3 E4 E4

E5 E6 E6

E7 E8 E8

E9 EA EA

At "X" Position = EA, Mario reaches the right edge of the screen.

So yeah, while Mario is running (left or right), the animation sequence is:

Move => Move => Sprite Change  |  Move => Move => Sprite Change  |  Move => Move => Sprite Change

Thanks for the question, Jeremy.  And now, on with the countdown!   

[up2ng]

Very nice, I didn't know that!

This must be related to a couple of (pretty annoying) situations that come up while holding the hammer.

1)  Sometimes you can move backwards one pixel without turning around.

2)  Sometimes you turn around "instantly" and occasionally you make a "wide" turn with the hammer, allowing a barrel to roll under your hammer in situations where the spacing clearly shows that there should have been enough time to smash it.

We must be able to blame these deaths on "the dead frame"!

[xelnia]

Thanks for checking on this Scott! I noticed the dead frame while I was looking for the part or parts of Jumpman's sprite collection that share "common" pixels. In other words, what parts of his body are always drawn the same way regardless of his pose or position. I came to the conclusion that the front edge of his belly shares the same edge with what would be his ankle when his foot is kicked forward. Even though those are different "body" parts, the color and position stays consistent through the whole running animation.

The whole point of that exercise was to always have a reference point as I learn about optimal positioning on springs, barrel "safe" spots, etc.

The hex code above is pretty foreign to me, although I can see that each set of three appears to increment. Do I read this left-to-right or top-to-bottom? Does each set of three represent an X-position on the screen? What would this code look like if there was no dead frame?

[stella_blue]

The hex code above is pretty foreign to me, although I can see that each set of three appears to increment.

Hexadecimal is just a numeral system with a base of 16 instead of 10.

Because we need to represent the numbers 10-15 with a single digit, we use the letters A through F:

A = 10,  B = 11,  C = 12,  D = 13,  E = 14,  F = 15

As an example, 76 (decimal) is the equivalent of 4C (hex).

In decimal notation, 76 = ( 7 x 10 ) + ( 6 x 1 ) = 70 + 6

Similarly, in hexadecimal, 4C = ( 4 x 16 ) + ( 12 x 1 ) = 64 + 12

Do I read this left-to-right or top-to-bottom?

Left to right.

Does each set of three represent an X-position on the screen?

Each set represents 3 separate values, 1 for each frame.  I grouped them that way to show that the X-Position increases by +1 for the first 2 frames, but is unchanged in the 3rd frame.  I should have presented the data more clearly.

So, the first 4 sets (3F 40 40;  41 42 42;  43 44 44;  45 46 46) contain Mario's X-Position for 12 consecutive frames:

		X-Position		X-Position
Frame		(Hex)		(Decimal)
01		3F		63
02		40		64
03		40		64
04		41		65
05		42		66
06		42		66
07		43		67
08		44		68
09		44		68
10		45		69
11		46		70
12		46		70

What would this code look like if there was no dead frame?

If all dead frames were eliminated, the X-Position would increase by +1 for every frame, not just 2 out of 3.

So, it would look like this:

3F 40 41

42 43 44

45 46 47

48 49 4A

4B 4C 4D

4E 4F 50

51 52 53

54 55 56

57 58 59

5A 5B 5C

5D 5E 5F

60 61 62

63 64 65

66 67 68

69 6A 6B

6C 6D 6E

6F 70 71

72 73 74

75 76 77

78 79 7A

7B 7C 7D

7E 7F 80

81 82 83

84 85 86

87 88 89

8A 8B 8C

8D 8E 8F

90 91 92

93 94 95

96 97 98

99 9A 9B

9C 9D 9E

9F A0 A1

A2 A3 A4

A5 A6 A7

A8 A9 AA

AB AC AD

AE AF B0

B1 B2 B3

B4 B5 B6

B7 B8 B9

BA BB BC

BD BE BF

C0 C1 C2

C3 C4 C5

C6 C7 C8

C9 CA CB

CC CD CE

CF D0 D1

D2 D3 D4

D5 D6 D7

D8 D9 DA

DB DC DD

DE DF E0

E1 E2 E3

E4 E5 E6

E7 E8 E9

EA

The table is smaller, because fewer frames would be required to reach the right edge of the screen.

[xelnia]

Ok, that all makes sense now, as much as it can for my current level of knowledge anyway!

I also noticed tonight that at the top of a ladder, when Jumpman is facing "away" from the player, he actually moves left or right for 4 consecutive frames before the sprite refresh. So, I'm going to look into this whole debug option with WolfMAME and see what I can learn. Probably not any earth-shattering stuff here, but I always like to know as much about as something as possible.

[ChrisP]

Just for fun: Hex counting - which is how these computers count - also explains why shit always seems to blow up in these programs when the number 255 is involved.

255 is the total range between 00 and FF in hex (16x16), which covers all possible values of one byte of information.

[stella_blue]

Just for fun: Hex counting - which is how these computers count - also explains why shit always seems to blow up in these programs when the number 255 is involved.

255 is the total range between 00 and FF in hex (16x16), which covers all possible values of one byte of information.

Actually, 255 is generally well-behaved, unless the leftmost binary digit (bit) is used to denote a negative number.

It's when he invites his neighbor 256 over that all hell seems to break loose:

• 256  =>
• Killscreen Glitch  =>
• Twin Galaxies DK Scoreboard  =>
• The King of Kong  =>
• Advanced Point-Pressing Techniques  =>
• The Kong Off I  =>
• Donkey Blog  (you didn't actually think I'd forget, did you?)  =>
• The Kong Off II  =>
• Donkey Kong Forum  =>
• "Advanced Donkey Kong Strategy" Subforum  =>
• "Donkey Kong Program Code" Topic  =>
• This Latest Post  =>
• 256

Interesting evolutionary timeline that has brought us full circle.

Hmmm, maybe 256 isn't so bad, after all?