nesdev.org

Does anyone have any Mesen Label Files (.mlb) that they would be willing to share with a noob trying to learn NES Dev?

Thanks

In particular, does anyone have a label file for Atlus/LJN's baseball game?

I doubt too many people have reverse-engineered old games using Mesen, to be honest (or if they have, I don't think anything's been made public).

If you're just wanting to look at fully annotated assembly code for a NES game, there's a few ones of old games floating around and a fair amount of open-source projects available on GitHub, like you mentioned in another thread. If those projects use CA65, you can import the .dbg file that CA65 can generate into Mesen's debugger and get labels for everything (it also enables the "Source View" option which lets you step through the original code files, rather than the disassembly). If they use ASM6, you can compile them with freem's ASM6f fork to generate a (somewhat decent) .mlb file to import into Mesen.

For anything else, though, creating a .mlb file implies reverse engineering the game and manually creating labels in Mesen's debugger, so it's pretty time consuming.

For reverse-engineering "stuff", I would suggest browsing over to http://www.romhacking.net/ . It's not just a site containing IPS patches of translated games; there are in fact docs on specific games which were reverse-engineered. It's less common, but it does exist. Sometimes romhacks also include readmes or technical docs/notes from those who did the REing. This is all on a per-game basis. I have seen some docs/things that contained .cdl files (for code/data logging of specific games), but in general it's rare, and romhackers don't tend to give this out by default (because the end-user tends to not care; they just want to play the translated or hacked game). You can always ask them, though! The community is surprisingly helpful and friendly, esp. to technically-inclined folk.

In general, the usual set of tools is:

1. A file splitting tool, to split a ROM up into its respective PRG banks, and/or PRG+CHR banks,
2. A disassembler -- and reading its documentation to understand how to invoke it, to give you output that's helpful
3. An emulator with an integrated debugger -- the common go-tos are Mesen, FCEUX, or Nintendulator, but there are others (see forum/other threads about this subject, as it varies per OS) -- and spending the time reading the emulator docs to get familiar with debugger behaviour and nomenclature,
4. Getting familiar with whatever mapper is used, if applicable
5. Expecting to put in VERY long hours understanding what's going on, with meticulous note-taking. This is where you will spend all of your time. Do not expect it to come easily -- it often won't, even for the experienced. I still do a lot of my notes with pencil/paper, then bring in digitally key concepts/points (usually into a .txt file) once I find something definitive.

The nesdev Wiki has a thorough list of tools and emulators; romhacking.net does as well. Understand that a good portion of tools may be from older times (late 90s/early 2000s), where MS-DOS and older Windows were common, so some you find may not work. YMMV.

koitsu wrote:For reverse-engineering "stuff", I would suggest browsing over to http://www.romhacking.net/ . It's not just a site containing IPS patches of translated games; there are in fact docs on specific games which were reverse-engineered. It's less common, but it does exist. Sometimes romhacks also include readmes or technical docs/notes from those who did the REing. This is all on a per-game basis. I have seen some docs/things that contained .cdl files (for code/data logging of specific games), but in general it's rare, and romhackers don't tend to give this out by default (because the end-user tends to not care; they just want to play the translated or hacked game). You can always ask them, though! The community is surprisingly helpful and friendly, esp. to technically-inclined folk.

In general, the usual set of tools is:

1. A file splitting tool, to split a ROM up into its respective PRG banks, and/or PRG+CHR banks,
2. A disassembler -- and reading its documentation to understand how to invoke it, to give you output that's helpful
3. An emulator with an integrated debugger -- the common go-tos are Mesen, FCEUX, or Nintendulator, but there are others (see forum/other threads about this subject, as it varies per OS) -- and spending the time reading the emulator docs to get familiar with debugger behaviour and nomenclature,
4. Getting familiar with whatever mapper is used, if applicable
5. Expecting to put in VERY long hours understanding what's going on, with meticulous note-taking. This is where you will spend all of your time. Do not expect it to come easily -- it often won't, even for the experienced. I still do a lot of my notes with pencil/paper, then bring in digitally key concepts/points (usually into a .txt file) once I find something definitive.

The nesdev Wiki has a thorough list of tools and emulators; romhacking.net does as well. Understand that a good portion of tools may be from older times (late 90s/early 2000s), where MS-DOS and older Windows were common, so some you find may not work. YMMV.

Thank you, that's really helpful. I'm just trying to learn how all of this stuff works. In the past when I've wanted to learn more about a new language, after reading a book or two, I go grab someone's code off of github and start figuring out what it's doing. This NES programming has been really challenging. It was super easy to get something basic running on my NES Classic, but after that I've stalled out. I have a laundry list of things I want to figure out how to do, and I'm working my way through some github examples. Part of the problem I've been having is the differences between code written with different assemblers, and using different Mappers.

I appreciate all the help

Your struggles are completely legitimate/justified, meaning I absolutely agree with you. It's always wonderful when people who publicise code/things don't disclose key pieces of info either, like what assembler they're using and what version, or list off what tools they used to make a particular thing. I've said for years that just putting something on the Internet/web/whatever doesn't make things inherently better for people when it comes to learning/understanding. Clear/concise documentation for that purpose is needed. The NES is no exception to this rule.

There's a strange misconception today that because the NES is old, or because it's "got charm", or whatever, will be easy to learn. It isn't. 6502 is one thing, but the rest of the hardware and all that surrounds it is a whole other ball game. I do not consider the NES a good "beginner's console" at all. I consider it one of the more difficult video game consoles to grasp, once you start getting into the important bits. In several ways the SNES is actually easier (but in other ways it's more complicated, ex: audio, video modes, sprites, and the CPU memory map).

There's a pretty substantial difference between, say, looking at someone's general-purpose 6502 routine for doing some math, and understanding what this sequence of instructions that write to a "magical ROM address" to with a mapper, or what a specific sequence of writes to some PPU registers do (and why the ordering matters).

Maybe the misconception stems from tons of people trying to do NES emulators? Or Nintendo's attempt to cash in on nostalgia? Or North America's surreal "everyone can/should code" mantra supported by code.org? I don't know the root cause. All I know is that "entry level" stuff might be common, but once you get past that, it's often harrowing for beginners.

koitsu wrote:6502 is one thing, but the rest of the hardware and all that surrounds it is a whole other ball game.

I agree completely... basic 6502 programming is super easy, but the way the 6502 (particularly the NES) interfaces with everything is the real challenge. I've been coding professionally for more than 20 years, and coding games for about 15 years. The basics of the 6502 were pretty quick to learn, but then you have to understand how the PPU works, then you have to learn how memory is segmented, and how bank switching works.

It feels pretty easy to get buried in all of this. I feel like I'm all the way down the rabbit hole right now.

Thanks for sticking with me through my stupid questions