Puffweet dot com

RSS

Contact

Category: kungfu_re

  • RE’ing Kung Fu for NES, Part 3

    Progress Update

    I spent about another month of reverse engineering Kung Fu for the NES. As always I keep making progress but boy does it feel slow sometimes. I’ve managed to map out even more memory locations, some definitely some less definitely. I’ve started tracing the different modes and sub modes, but sticking to the simpler ones like the title screen, the “save Sylvia” screen, and the ending screen. I’ve found various routines for music/effect playing and drawing code and some object handling code like knives and effects. I’ve found areas related to enemies’ position, state, and timers but it’s still pretty vague right now. But little by little, the code reveals itself. Still a long way to go but it’s steady progress

    Mesen

    I’ve been using Mesen as my emulator of choice because of it’s great debugging features. As more and more of the RAM gets figured out the memory viewer just becomes swaths of uncategorized red areas, as seen above. So I made a fork and added a feature to specify the highlight color for labels, as seen below.

    I’m unsure whether I did it “correctly” and it changes a file format so I don’t know if I’ll want to make a Pull Request out of it.

    Development Quandaries

    I haven’t tackled the main game update routine yet because 1) I haven’t found it and 2) I’m already intimidated by the code in “basic” areas that I feel like I have no chance right now at the larger, more complex functions. I’m sure I’ll eventually get to it and come to understand it but I wish it would go faster.

    As usual I’ve been using ChatGPT to answer questions about working in 6502 code and to explain bits of code to me. I don’t know how I feel about using something like Claude to do the analysis. I feel it would go much faster, but I’ve got all these scattered thoughts about it.

    • I would have to spend money on Claude (or whatever) when using my brain is free.
    • But my brain is tired.
    • Will it cost me 20$ or 1000$? I have no idea. Do I love Kung Fu that much to spend money on it?
    • Using AI in theory should let me be able to finish and move on to something else faster.
    • I don’t know how it would make me feel about the result. It feels like cheating, but do I love Kung Fu that much to do everything on my own? To have it take the time it takes?
    • Would the results even be correct? From experience I can’t trust AI’s results as-is so I’d need to intervene often or use it in very focused way.
    • I don’t want to do a “fire and forget” reverse engineering on the game with AI. I don’t want to do a “decomp” where it just translates the code blindly. I want to properly document all the code so that I could in theory port it to proper C later, just like I did with Downland.
    • Part of me is like: it’s a 40 year old game! Who cares?
    • I’m thin skinned and I don’t want people to get angry at me for something that’s a hobby for fun.
    • I don’t mind my current usage of AI. Using ChatGPT as a reference and a helper I’m totally okay with. Not being an assembly programmer by any stretch, I’m happy I can use it to answer all my shamefully noob questions without bothering anybody on a discussion forum. And it’s free.

    So I don’t know. For now I’m sticking to my current working scheme. After spending a good month on it I want to work on something else for a while. I don’t mind having this project be something I work on from time to time.

    On to the next thing!

  • RE’ing Kung Fu for NES, Part 2

    Just slowly plugging along. I’ve been alternating between trying to understand snippets of code in Ghidra, looking at memory changes at runtime in Mesen, changing them to see what they do, and tracing execution paths in the debugger.

    That’s probably the cycle I’ll be doing all the way through.

    I can’t debug through Ghidra but it’s got extensive commenting/renaming features. Mesen’s debugger has a few label creation/renaming features but it’s a more limited. I don’t seem to be able to add comments, which would’ve been nice. The debugging features are pretty great, though.

    One thing I haven’t seen in Mesen is a feature to track whether certain values went up or down between breaks. It only marks values that have been written to. It would help pinpoint memory values that go down, like health bars or time counters.

    So far in memory I’ve identified some various timers, the random number generator, player lives and progression, joystick/oam/ppu register copies. I’ve also found update functions for what I guess are the different “modes”, like the title screen and game play, with each mode having multiple functions, which are maybe sub-modes. Haven’t gone too deeply into it yet. Identified a few simple utility get/set/clear functions for memory and PPU.

    I realized I could look at Game Genie codes to help figure out certain values. There aren’t that many codes out there but it did identify a few things.

    Moved the project file to the cloud to at least have some semblance of backup and version control. I’ll have to figure out how I want to store this in GitHub or something.

  • RE’ing Kung Fu for NES

    On a whim I decided to look into reverse engineering Kung Fu, a launch title for the NES released in 1985. I was surprised there wasn’t a lot available online already.

    Ever since RE’ing Downland I was thinking about my next RE project. I wanted something I could complete in a reasonable amount of time with a reasonable amount of effort. I have huge ambitious dreams of RE’ing all my favorite games, but I have no time or patience for anything big.

    The Kung Fu ROM is 40 kilobytes, 8kb of program and 32kb of graphics rom. I think that’s pretty much what I can realistically tackle.
    (Correction: It’s actually 32kb of program ROM and 8k of graphics ROM. The people responsible have been sacked.)

    I did find a YouTube video series by DandyLo about KungFu’s inner workings, including one about how it handles collisions.

    One thing I’ve already found that surprised me is that the main player character is made out of background tiles, not sprites. If the game already uses sprite 0 to do the split screen, I wonder how it scrolls the middle part of the screen to move the player around.

    I got a Ghidra project up and started the preliminary investigation. I’m also using Mesen and its debugging features. I’m not very far in. I’m at the point where it sets up RAM, the PPU, and namespaces and then goes into an infinite loop. After that I guess it handles everything through the vblank handler.

    I’ve barely gotten off the ground but I’ll want to post up the work somewhere. I don’t actually know if I can post Ghidra projects on Github. At the very least I’ll post a disassembly listing.

    I plan to interleave this work with other projects. I still have maybe a few more Downland Unearthed articles in me, and I’ll want to eventually tackle scrolling of really large areas in SMS Rally. The idea is that instead of intensely concentrating on just one project (and potentially burning out, again) switching between different ones will keep my interest and energy up. We’ll see!