Donkey Kong source code

[Heaven/TQA]

imho commenting needs always time and esp. in 6502 you would need to comment every bit... imho in high level it's easier as you have a procedure or codeblock or even commands which you can describe easier... but in 6502 it does not help to write this code is doing the "3d to 2d perspective transformation" when the code is hard to read and most of the "intelligence" went into creating the lookup tables or other help-files

 

but that's just me.

[landondyer]

I know this is a very old thread, but I have a question. When I clicked on the text file that indicated it was the main program, I saw a lot of comments in the code (the stuff followed by the semicolon; please note, I know nothing at all about programming). I like looking through code; it's interesting to me to contemplate how all these esoteric commands are the things that eventually translate into a game.

 

I didn't read all the posts, but from what I gather, it appears that all the comments in the listing were written by the actual programmer. When programmers write code, do they always put in comments? I always thought that this was done by the hobbyists who disassemble the game. Why do programmers put in comments? Are they required to by the companies for which they work? And is all this code literally written line for line, or were there tools back then to automatically write the code based on what the programmer wanted and the inputs he/she put into the tools...in other words, could the programmer move the barrels around in a certain pattern, thus causing the tool to write lines of code corresponding to that pattern?

 

The dates mentioned in the program -- the ones with the funny comments attached -- were those the actual dates that defined the timeline of this project?

 

Comments are a tool to help code understanding. The comments in DK were written (by me) when I first wrote the code. I like to think of it this way: If you can't explain what's going on to someone else, you don't understand it yourself. Also, reading uncommented code, especially assembly language, is horrible. (The original 68K Macintosh ROMs were highly commented 68000 assembly language. Most good bodies of assembly language are very well commented. If you write crappy code, most places will fire you eventually).

 

There's no magic in writing code like this. You figure out the data structures and algorithm, translate that to instructions (maybe via pseudo code, that's usually how I did it), and debug what you wrote. No "moving barrels around" and having the computer figure something out; *you* have to write the code that moves the barrels, not the other way around.

 

The dates are real. Those comments are really just snarky ways of saying "I was working pretty hard" (and in retrospect this project went together really fast). IDS stands for "Internal Design Spec", by the way.

 

Assembly language isn't all that esoteric. There are a lot of fiddly details and it's a really primitive, but the low-level details of CPUs are generally well documented. It's not esoteric, it's just that it hurts to write it and normally nobody does it if they can avoid it. :-)

[firestorm]

 

Comments are a tool to help code understanding. The comments in DK were written (by me) when I first wrote the code. I like to think of it this way: If you can't explain what's going on to someone else, you don't understand it yourself. Also, reading uncommented code, especially assembly language, is horrible. (The original 68K Macintosh ROMs were highly commented 68000 assembly language. Most good bodies of assembly language are very well commented. If you write crappy code, most places will fire you eventually).

 

There's no magic in writing code like this. You figure out the data structures and algorithm, translate that to instructions (maybe via pseudo code, that's usually how I did it), and debug what you wrote. No "moving barrels around" and having the computer figure something out; *you* have to write the code that moves the barrels, not the other way around.

 

The dates are real. Those comments are really just snarky ways of saying "I was working pretty hard" (and in retrospect this project went together really fast). IDS stands for "Internal Design Spec", by the way.

 

Assembly language isn't all that esoteric. There are a lot of fiddly details and it's a really primitive, but the low-level details of CPUs are generally well documented. It's not esoteric, it's just that it hurts to write it and normally nobody does it if they can avoid it. :-)

 

Landondyer I admire your work for Atari and have question if I may ask.

When you where working at Atari making great Donkey Kong and Super Pac-Man ports do you remember how you were choosing colors for your games?

Where you tuning colors for PAL system as well?

I have started topic NTSC vs Pal colors on this forum because I found that colors described in Atari Basic manuals and Gtia documents are not possible to display on modern NTSC TV's with default control values(hue/phase/color balance at 0)

Pages from gtia.pdf

[sack-c0s]

The general rule I follow is this:

 

*The code does what it does

*The comments tell you what you *wanted* the code to do.

 

Those two things aren't always the same

 

so:

 

LDX something

DEX

STX something

 

looks okay doesn't it?

 

; Increment the counter

LDX something

DEX

STX something

 

sets alarm bells ringing.

 

Even if the code is theoretically obvious to another programmer it provides a layer of security and I've found and fixed plenty of bugs looking at things that way.

 

 

I'm not sure how I'd have handled oldschool, back-in-the-day games porting. It's 'interesting' work when you have the source code....

Edited October 22, 2014 by sack-c0s