Donkey Kong Forum
Donkey Kong Strategy => Advanced Donkey Kong Strategy => Topic started by: ChrisP on July 08, 2013, 07:47:14 pm
-
I guess it's about time that this was posted.
This will be totally unintelligible to pretty much all of us (including me), but people wanted it, so what the heck.
This is US Set 1 (TKG-4), in plain text.
I don't remember what program I used to disassemble it (it was 7 months ago and I never used it before or since), and I'm quite sure that I didn't do it "optimally." If any of these opcodes didn't get translated correctly, I would not know.
BUT it's "in order" and complete, as far as I know. This combines c_5et_g.bin, c_5ct_g.bin, c_5bt_g.bin, and c_5at_g.bin, which are the game code ROMs.
If nothing else my line numbers (in HEX) line up with the ones that Jeff Kulczycki has here (http://"http://www.jeffsromhack.com/products/d2k_random_points.htm), so it would appear that I did something right.
If anybody's got a better version, feel free to post it!
-
let's see what we can get going here
-
Excellent! Once the manual is done, I swear a solemn vow to learn assembly and read this code!!!
-
3F30 through 3F9F are definitely NOT opcodes, for example.
"PROGRAM,WE WOULD TEACH YOU.*****TEL.TOKYO-JAPAN 044(244)2151 EXTENTION 304 SYSTEM DESIGN IKEGAMI CO. LIM."
So that section is just HEX codes for ASCII text characters. (50 is HEX for "P", 52=R, 4F=O, etc.)
But the disassembler translated them in terms of the Z80 opcode instruction set, so in the disassembled file it reads as
3f30 50 LD D,B
3f31 52 LD D,D
3f32 4F LD C,A
etc.
My disassembly might be full of problems like that, or might not be, because I don't know what I'm doing, or what I'm reading. I don't know how to differentiate what's actually machine code from what's junk. Probably very little junk in here though, I would assume, since the whole program had to fit into 16K.
-
Someone should call that number. ;D
-
Here it is unconverted in case somebody wants to re-disassemble it.
The secret message (or, at least, the part of it that didn't get overwritten by the U.S. code changes) is at the bottom.
-
Oh yeah, it was dz80 that I used.
And as Jeff says (http://www.jeffsromhack.com/toolbox/assembling.htm):
"dZ80 won't tell you when you've hit data instead of code. You'll just have to be on your toes and notice when the code stops making sense and starts looking like random garbage."
(Which is what causes the problem of dz80 trying to translate that text as machine codes)
-
Oh yer.
In the code I posted the "$"s came out as "H"s, but it's all the same stuff...
Now we just need somebody to figure all this out!
Allen?
-
Who volunteers to create the Program Code Training Video? :P
-
That would be you Corey the resident video editing guru ;)
-
Corey, here are some helpful links for starters:
http://sgate.emt.bme.hu/patai/publications/z80guide/ (http://sgate.emt.bme.hu/patai/publications/z80guide/)
http://www.worldofspectrum.org/Z80.html (http://www.worldofspectrum.org/Z80.html)
http://www.zilog.com/docs/z80/um0080.pdf (http://www.zilog.com/docs/z80/um0080.pdf)
-
I added another .txt version to the post above which includes the line numbers, the HEX codes, and the ASCII equivalent. Looks nicer than the other .txt, though it isn't the "true" 16KB version.
We are analyzing difficult this program.
-
im working this boys!
-
This is the mother of all "wht da?"s
-
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.
There are improvements that can be made to this file. The list of RAM values at the top is incomplete, certain comments are not very detailed, and I know for a fact that there are some errors in these comments, because looking through it just now I realized that I did not correct all the errors I encountered when I originally was reading through this. I think I will probably go through this file and add more detailed comments and explanations (and fix the errors) for the parts that I have read through myself. If anyone else is considering making modifications to this file as well it might be worthwhile to use something like etherpad (http://etherpad.org/), which provides the ability to collaboratively edit text files in real-time.
The parts that I have looked at are:
- The barrel deployment routine, specifically the timing of barrel releases and the cause of "pauses" from DK and their length
- Wild barrel behaviour on all internal difficulties including the cause of bombs and those that start as bombs but transition to normal wild barrels part-way down
- The entire fireball movement algorithm including both freezers and normal fireballs
- Conveyor directions on pie factory and pie deployment
-
:o :o :o
SHIT JUST GOT REAL.
-
just saw this, i went from 6 to midnight!
-
Just when I thought I was done with my own personal reading for the day...
-
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.
-
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.
-
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?
-
No, not at all, but what about the children?! WHAT ABOUT THE CHILDREN!
-
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.
-
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! 8)
-
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"!
-
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?
-
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.
-
Ok, that all makes sense now, as much as it can for my current level of knowledge anyway! ;D
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.
-
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.
-
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 (http://donkeykongblog.blogspot.com) (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? :)
-
Huh?
-
Huh?
Yeah, I should avoid posting anything unless I'm reasonably well rested. The resulting content is likely to fall under the "Questionable Sanity" category. ???
I was mainly trying to convey 2 points, albeit in a roundabout, stream of consciousness manner:
- The number 255 (Hex FF) isn't really a problem, since it can be stored in a single byte of memory. The trouble starts with 256 (and anything greater), as it causes an overflow condition.
- If not for that original arithmetic overflow issue, many of the other events/items listed (other than the TG Scoreboard) might never have transpired and/or been created. Ironically, a programming oversight became a major factor in the development of the thriving DK community we have today.
Is that any better?
-
Scott, is there any easy to way grab a long string (group? herd? flock? I'm so bad with programmer terminology) of values from the WolfMAME 140 debug program? For example, if I want to watch one value for 100 frames, is there anyway to grab all 100 values at once instead of using pause/frame-advance and writing down each value, one at a time?
-
Scott, is there any easy to way grab a long string (group? herd? flock? I'm so bad with programmer terminology) of values from the WolfMAME 140 debug program? For example, if I want to watch one value for 100 frames, is there anyway to grab all 100 values at once instead of using pause/frame-advance and writing down each value, one at a time?
Jeremy, it sounds like Lua scripting might be your best bet. Unfortunately, I have no experience with Lua, and I've only used the MAME debug option a handful of times.
In another thread, Jeff Willms has attached a sample Lua script, and listed some useful memory locations:
Calling all DK-Playing Programmers (https://donkeykongforum.net/index.php?topic=228.msg3376#msg3376)
Within that same topic, Paul (hooch66) has provided a link to an online Lua manual:
Lua 5.1 Reference Manual (http://www.lua.org/manual/5.1/)
I wish I had more detailed advice, but at least you have a place to start.
Good luck!
EDIT: Obviously, learning a scripting language doesn't qualify as an "easy way" to do what you're asking. How many of these memory locations are you attempting to track?
-
Scott, is there any easy to way grab a long string (group? herd? flock? I'm so bad with programmer terminology) of values from the WolfMAME 140 debug program? For example, if I want to watch one value for 100 frames, is there anyway to grab all 100 values at once instead of using pause/frame-advance and writing down each value, one at a time?
You can do this by using the MAME debugger console.
If you wanted to watch memory location 6203 for example, you would enter this line on the console:
bp 66,1,{printf "memory 6203 = %x" , b@6203; g}
If you wanted to watch other memory locations, change the values of 6203 in the line above to some other number.
This will display, in the debugger console, the value (in hexadecimal) of this location every time line 66 in the code is encountered. Since line 66 is the start of the interrupt routine, this should happen every frame.
Don Hodges
http://www.donhodges.com (http://www.donhodges.com)
-
Thanks Don! Much appreciated.
-
Hi all,
I've started my own commented disassembly of Donkey Kong and came upon this forum by chance. Obviously this thread in particular is going to be very useful to me - so thanks to whoever originated the disassembly and those that have enhanced it up until this point. Some may be interested to know that this is the 3rd disassembly that I know about; the 1st was a direct translation to 6809 for the TRS-80 Color Computer by SockMaster, the 2nd (not public AFAIK) reportedly by Jeff of the Foundry Level fame. Unless of course the one here is actually the latter.
Thus far I've only managed the initialisation and main (foreground and background) loops, and the 'INSERT COIN' and title screens. I was in the process of working my way through the level-drawing routine when I decided to see what the net had to offer. SockMaster's disassembly, whilst very useful to me, is quite lacking in areas that don't pertain to tile and sprite rendering, as his impetus was porting it to the Coco.
I have to say though, at the risk of biting the hand that feeds me, that some aspects of this disassembly are a little, umm... pointless. I mean, commenting SUB #10 with 'subtract #10', or pointing out that #07 is '111' in binary is of no use to anyone that can already read Z80 code. You may be of the opinion that I am an ingrate, but I've also commented a few games myself (including Space Invaders and Tutankham arcade games, as well as a few console and micro games) and specifically avoid this type of comment myself. The intention of the code should be commented, not the instruction. The disassembler already does that.
A case in point:
0E75 D610 SUB #10 ; subtract #10
0E77 77 LD (HL),A ; store
and what is really happening:
0E75 D610 SUB #10 ; get matching bottom piece of girder
0E77 77 LD (HL),A ; display tile
Anyway, rant aside, I'm porting Donkey Kong to 68K or, more specifically, the Neo Geo, as I'm reverse-engineering the original. This will certainly help speed things along, so thanks again to those involved; I'll post a (hopefully) fully-commented and re-locatable assembly listing (produced via IDAPro) when I'm done!
EDIT: Blog here -> http://ngpace.blogspot.com.au/ (http://ngpace.blogspot.com.au/)
-
Hi all,
I've started my own commented disassembly of Donkey Kong and came upon this forum by chance.
Hello and welcome to the forums! There are definitely a few people here interested in the workings of the DK code (myself among them) so I'm very interested to see the results of your project.
but I've also commented a few games myself (including Space Invaders and Tutankham arcade games
I just recently started playing Tutankham. Would it be possible to get a copy of this commented code?
-
Hello and welcome to the forums! There are definitely a few people here interested in the workings of the DK code (myself among them) so I'm very interested to see the results of your project.
Thanks! With the hints in the disassembly here, I'm already making headway with the level drawing routines, which are largely unknown at this point. I think an hour or two more and I'll have it cracked. Basically the 5-byte chunks in the level data contain a flag, and a pair of X,Y coords for start and end points. The LSB 3 bits in each byte is an index in to the tile set, whose MSB's are determined by the 1st flag byte. $2FF0 takes the packed X,Y tilemap coords and returns the VRAM address in HL (some of the comments already there in this routine are wrong - someone didn't understand how the carry flag works).
I just recently started playing Tutankham. Would it be possible to get a copy of this commented code?
Sure. I'll have to dig it out tonight and see what shape it's in. I was going to port it to the TRS-80 Color Computer, and actually got the game running on it - you could even coin-up and "play"! The "only" issues were that the screen was rotated 90 degrees, and there was no scrolling. I deduced it wasn't worth persuing further when I patched MAME to scroll the arcade Tutankham 2 pixels at a time - it looked sucky! And even to get that far, I'd have to double-buffer the display on the Coco. Bleh!
-
I just recently started playing Tutankham. Would it be possible to get a copy of this commented code?
Sure. I'll have to dig it out tonight and see what shape it's in. I was going to port it to the TRS-80 Color Computer, and actually got the game running on it - you could even coin-up and "play"! The "only" issues were that the screen was rotated 90 degrees, and there was no scrolling. I deduced it wasn't worth persuing further when I patched MAME to scroll the arcade Tutankham 2 pixels at a time - it looked sucky! And even to get that far, I'd have to double-buffer the display on the Coco. Bleh!
I didn't get an opportunity to dig it out last night; I'll get to it in the next few days. It did occur to me that I worked on it before I really had grasped some of the functionality of IDAPro, so it's a bit clumsy in places (eg. all references to RAM variables are in comments, rather than labelled). I might be able to rectify that relatively quickly when I dig it out.
If you don't hear anything from me in the next week, feel free to PM me and hassle me! I've been meaning to release it, along with some of my other disassemblies, here <http://www.computerarcheology.com/wiki/wiki (http://www.computerarcheology.com/wiki/wiki)> for years!
-
I didn't get an opportunity to dig it out last night; I'll get to it in the next few days.
No worries! Don't go out of your way on my account. I'm not a programmer so I'm basically getting a free ride by getting to look at all the hard work you and others do with the commented code for these games. :P
-
Tonight I finally found my Tutankham disassembly and I'm quite embarrassed to say that it's not quite as complete as I remembered. :-[
To be fair, I last touched it in 2008, and I was primarily concerned with the graphics rendering routines as I was porting it to another 6809-based machine. To cut a long story short, I got it running on the target, but the screen was rotated and the scrolling wasn't implemented. The intention was to rotate all the graphics (most of the graphics are rendered as 'tiles' despite the fact that the display is bit-mapped) and then update the code to handle the rotated display. Then I could look at implementing the scrolling, as the target did have a horizontal scroll mechanism. Alas, what I didn't realise until late in the game was the fact that the target could only scroll 4 pixels at a time, or 2 using double-buffering. I simply gave up at that point, shortly after I rotated the alpha 'font'.
You're welcome to look at what code I have commented, but it's mostly 'infrastructure' code and graphics routines. There's nothing in the way of AI, or anything like that. The game uses ROM banking but, IIRC, the code is contained either in un-banked area, or is all swapped-in by default at start-up. The other banks were, IIRC, only graphics and game data. The listing is a little bit of a mess in that there's a jumble of segments defined for hardware registers and RAM, but not too bad. Let me know if you're still interested.
On a topic more relevant to this site/thread, my Donkey Kong disassembly is coming along nicely. I've commented about 50% of the code now, which covers most of the 'non-gameplay' routines. I've just started into the code that lets Mario move around the screen; running, climbing and jumping (the latter of which isn't commented yet). I should stress again that the comments are strictly describing the intention of the code, and not merely the instructions.
-
I've been meaning to post this. I've done some cleaning up of the comments in the fireball movement algorithm of the code. This section previously had a lot of question marks, uncertainties and mistakes, which I have fixed. I've also removed some of the line-by-line comments of what the assembly is doing and replaced it with more high level comments of what small blocks of code are doing In other words, my comments assume the reader has the knowledge of assembly to know the effects of each instruction, so instead of describing this line-by-line the comments describe the logic behind what is going on. Hopefully with these changes the routine should be easier to understand, I know I had trouble understanding parts of it when I first read it since the code is kind of confusing with a lot of jumping around.
The fireball algorithm starts at $30ED. Also, I've added comments at the top of the document on the fireball data tables, RAM addresses $6400 to $649F which are used extensively throughout the fireball movement algorithm.
This should be of interest to anyone wanting to know at a very precise level everything about how fireballs move. Most of what's described in the comments has been discussed in various threads on this forums, so if you want to understand the code behind some of these discussions you should take a look.
-
Thanks, Jeff.
Speaking for myself, no attract mode experiments this time around. I promise. ;)
-
Thanks Jeff, much appreciated as it will certainly make my life easier too - your previous listing has certainly given me a big head-start. I get that much of the code is of little interest to those whose primary impetus is to master playing the game and, to be fair, I could have ported the game without understanding a single line of code (well, almost). I must say that I'm daunted by the jumping code that I've just implemented... it's going to be a strain to understand exactly how it works, and very tempting to leave it and come back to it later... :-[
Hopefully my listing will be a conglomeration of the work done by yourself, myself and a few select others and we'll finally have 100% (or very close) code coverage. I do know someone who is interested in designing additional levels for the game (much like the Foundry) but perhaps not on the original hardware. I'll leave that to them as I'm personally not interested in changing the original behaviour.
For those that haven't seen, I've posted a short video of the game running on the Neo Geo so far on my blog... http://ngpace.blogspot.com.au/ (http://ngpace.blogspot.com.au/)... and soon I hope to post an new video with Mario climbing, jumping and falling.
-
Tonight I finally found my Tutankham disassembly and I'm quite embarrassed to say that it's not quite as complete as I remembered. :-[
I'm still very interested in taking a look!
-
Thanks Jeffw and others for your efforts, the commented disassembly code in reply #43 looks like very high quality. I teach computer architecture and assembly language programming and would like to show my students what real hand-crafted assembly code looks like.
-
I think we should put this disassembly up on a wiki, so it will be easier to collaborate on it. I can do this myself if necessary.
I also suggest we move this thread into the General forum, since it doesn't have that much to do with strategy and it's more likely to be read there.
-
Welcome to the Donkey Kong Forum! A page has been designed for exactly this purpose, feel free to contribute on the DK wiki code assembly (http://wiki.donkeykonggenius.com/Donkey_Kong_Code) page.
-
So there is! Thanks for pointing it out.
Man, some of the stuff in here is insane. The RST's with their "return to higher subroutine" trick, which also appears in some normal procedures... I'd never encountered that before, though I haven't done a whole lot of ASM in my life. But I wouldn't expect a subroutine to return to the caller's caller.
-
Sure thing. I wish I knew more about this stuff myself but one must have the time and motivation and weigh the practical usage.
-
So there is! Thanks for pointing it out.
Man, some of the stuff in here is insane. The RST's with their "return to higher subroutine" trick, which also appears in some normal procedures... I'd never encountered that before, though I haven't done a whole lot of ASM in my life. But I wouldn't expect a subroutine to return to the caller's caller.
I just realized that Jeff had posted a more recent version of the code a few posts earlier. This version of the text is now on the wiki as opposed to the text of the code that was previously posted by Jeff near the beginning of this thread. Update complete.
-
In fact if anyone is presently interested in seeing the differences between the first file that Jeff posted and this most recent update can view this page. It will take about 45 seconds to load. I don't know if this will always be a live link especially if other edits are made on the page but for now it might be neat to see how Jeff altered his previous text.
http://wiki.donkeykonggenius.com/~donkeyko/mw/index.php?title=Donkey_Kong_Code&curid=14&diff=1099&oldid=27 (http://wiki.donkeykonggenius.com/~donkeyko/mw/index.php?title=Donkey_Kong_Code&curid=14&diff=1099&oldid=27)
-
I wondering if anyone has looked into how wild and bomb barrels are handled. For instance, are they possible both possible ever barrel including blues (starting 3rd?) with equal 1/16 for wild and 1/? for bomb?
This could obviously help for general runs if say it was found bombs could only occur every other barrel, but I'm interested for purposes of making a 1-1.
currently the goal is to get the 8th barrel (blue) down to make a fireball ASAP via kong having no pauses, and then the blue being a bomb, but I'm not sure if the code even allows that to happen.
-
I wondering if anyone has looked into how wild and bomb barrels are handled. For instance, are they possible both possible ever barrel including blues (starting 3rd?) with equal 1/16 for wild and 1/? for bomb?
This could obviously help for general runs if say it was found bombs could only occur every other barrel, but I'm interested for purposes of making a 1-1.
currently the goal is to get the 8th barrel (blue) down to make a fireball ASAP via kong having no pauses, and then the blue being a bomb, but I'm not sure if the code even allows that to happen.
Welcome mate!
For those that aren't aware Spiderwaffle here is doing a TAS run for 1-1.
I don't know much about how the bombs and wilds occur so anyone in the know please chime in 8)
love it.
-
I wondering if anyone has looked into how wild and bomb barrels are handled. For instance, are they possible both possible ever barrel including blues (starting 3rd?) with equal 1/16 for wild and 1/? for bomb?
This could obviously help for general runs if say it was found bombs could only occur every other barrel, but I'm interested for purposes of making a 1-1.
currently the goal is to get the 8th barrel (blue) down to make a fireball ASAP via kong having no pauses, and then the blue being a bomb, but I'm not sure if the code even allows that to happen.
Bombs are made from Stork poop Kappa
Any barrel can be a wild barrel (except the 2nd and 3rd at the start of a barrel board?)
Blue barrels are only released every 8th Barrel
In order for a "wild" to be a "bomb":
You need to get a "wild" first (1/16, excluding potential tiredness-WB-frequency-changes discussed on CAGDC ( <Pigger> )). Each barrel has a "counter" that tracks vertical position on the screen (this is used to determine when to roll around the edges, off the screen and where wilds bounce next). There are only so many barrel slots, and they get recycled as barrels leave the screen, however, the "height" value is not cleared.
A barrel needs to be pulled as a "wild" AND its' "height" value needs to be equal to or less than the 6th girder; If both parameters are met, Kong will drop a "wild" and when the game tries to determine which girder it hit last (using the counter), it gets a value for something other than the 6th girder, so the barrel logic says that is the next girder it needs to hit and free-falls to that location, before transitioning to a wild. A full bomb requires a y-counter value that is equal to or less than the 2nd girder. <confused>
Bonus: A bomb-wild, transitional barrel, can only occur if the barrels' internal counter is something other than the lowest girder; so you can only get a transitional bomb-wild if you smashed a barrel on a girder above you, or if a wild left the screen above you (basically you need the vertical counter to be somewhere in the middle of the screen). Kong will drop a "bomb" that will fall to one girder lower than the y-counter and then transition to a regular wild barrel.
Below is a good example of the bomb-wild transition. In the replay you can see a wild barrel bounce off of the 4th girder (left side) while I have the hammer, after the hammer runs out, Kong drops a "wild" that is expressed as a bomb, but changes to a wild when it reaches that "next" lowest girder, dependent on the barrel slots' conserved vertical height value (in this case its the 3rd girder).
http://www.twitch.tv/f_symbols/c/5883357 (http://www.twitch.tv/f_symbols/c/5883357)
Bombs are more common than bomb-wilds (barrels tend to leave on the bottom 2 girders, early in the screen). Both types are more common later in the screen than in the beginning (bombs and transitionals), because y-positional values succumb to entropy.
Also, welcome sir! Kreygasm
1-1 Hype