Donkey Kong Program Code

[up2ng]

Huh?

[stella_blue]

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?

[xelnia]

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?

[stella_blue]

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

Within that same topic, Paul (hooch66) has provided a link to an online Lua manual:

Lua 5.1 Reference Manual

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?

[phantomdj]

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:

Code: [Select]

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

[xelnia]

Thanks Don! Much appreciated.

[tcdev]

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:

Code: [Select]

0E75  D610      SUB     #10 ; subtract #10
0E77  77        LD      (HL),A ; store

and what is really happening:

Code: [Select]

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/

[xelnia]

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?

[tcdev]

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!

[tcdev]

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> for years!

[xelnia]

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. 

[tcdev]

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.

[Jeffw]

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.

[stella_blue]

Thanks, Jeff.

Speaking for myself, no attract mode experiments this time around.  I promise.   

[tcdev]

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/... and soon I hope to post an new video with Mario climbing, jumping and falling.