Donkey Kong (FC) Disassembly

[segaloco]

Just sharing a new thing I've been working on for a while. Decided to shelve my other disassembly projects and work up Donkey Kong since it's a launch title and theoretically at the root of the family tree of SRD Famicom code. Indeed I've already observed several of the same patterns that I've seen in later titles, just earlier variations, less polished. All in all it's been a great experience, I also used the opportunity to beef up some analysis tools and practices that I use when going through the process, so lots gained from the exercise even though DK has already been disassembled at least once.

Anywho, this can be found after the link: https://gitlab.com/segaloco/fc_dk

It's not done (when are these sorts of things ever) but it's pretty well split up into chunks that analysis can be finished on relatively independently, a theme of my disassembly work, as opposed to the usual style of just throwing all banks in their own monolithic files ignorant of the logical structure of the application.

Where possible I've tried to use similar names, file separations, and headers as my other disassembly stuff, as again my goal in all of this is to suss out similarities between different codebases by the same programmers. A happy side effect is theoretically anything using the same interfaces and formats should be relatively trivial to port between different SRD applications.

Enjoy, make cool things! While again it's not done done, it may be far enough along to tinker with so long as at present you keep module boundaries the same (i.e. throw padding in where necessary). I know there are still ROM pointers in the APU section of the code that need to be decoded, so unfortunately it's not all relocatable quite yet, but I've been leaving the APU stuff to the end since I've pretty well documented the general Nintendo sound engine, it's just a matter of applying that to this copy.

[TakuikaNinja]

I don't know if you were aware of this disassembly while making this, but it's always good to see a different perspective on the same game.

If you're up to the challenge, there's always the FDS version. It has a different PRG layout occupying the entire 32K of PRG-RAM (as opposed to 16K of PRG-ROM on the NROM128 cart releases). I haven't looked into it deeply yet but if I had to guess:

1. They were using older source code meant for an NROM256 cart. That would explain the seemingly older CHR data used in this version.
2. They were intending on making enhancements to DK like they did with their other FDS ports (Ice Climber, Clu Clu Land, etc.) but ran out of time. Perhaps 50m ended up on the cutting room floor again? They seems to be some $FF padding in the PRG data.

[segaloco]

That'll be a pass 2 once I finish up the primary stuff and then roll some of the findings into my other works. I need to finish ZEL-B and Doki Doki Panic as well, then I've got a whole host of "other version" stuff to merge into many of my disassemblies. After all that is done I plan on turning to Zelda 2 and SMB3, since both theoretically might derive side-scrolling physics from SMB and/or DDP. That's one of the larger goals here, to try and paint a thorough picture of the evolution of SRD's side-scroller physics designs over the lifetime of the Famicom.