Closed SourMesen closed 7 years ago
freem
commented
7 years ago Hi, sorry for the late reply; I was out of town and my two factor auth decided to crap out on me. This does sound interesting, and I'm all for adding it. Not sure when I'll be able to get around to reviewing and merging the changes, but if @nicklausw doesn't get to it first, I'll shoot for this Sunday/the 27th.
SourMesen
commented
7 years ago Hey, no worries about the delay. Should I make a pull request out of this then? Also, if you compare with my branch, make sure you include all 4 commits I made (the link above was just the first commit I originally did)
And completely unrelated, but I noticed that this line accesses uninitialized memory ("str") - it's also there in the export_lua function. It looks like it was copied from elsewhere in the code (where "str" is actually initialized when used). Not really a big deal considering the condition required to even execute that statement, but I figured I'd mention it at least.
freem
commented
7 years ago Should I make a pull request out of this then?
That would probably be the best course of action, yeah.
uninitialized memory issue
I hadn't actually looked into how sonder's old code had worked, so this is news to me. Thanks for the heads up. (The Lua export appears to be based on this code, which explains why it shows up there.)
SourMesen
commented
7 years ago Opened pull request #13
Hey, (and sorry in advance for the wall of text below!)
I've been wanting to integrate asm6 with Mesen and was faced with a number of issues. Parsing the .lst files is possible but complex, and FCEUX's .nl label format can be imprecise for projects that use bank switching.
Mesen's current internal representation of labels is precise - labels are based on the memory type (e.g 2kb internal ram, work ram, save ram, prg rom) and the address is based on the offset from the start of that memory type. So a label might be type "PRG ROM" at offset $38000, for example
Essentially, I implemented a new switch option in asm6 (based on this fork) to dump the labels into a format that matches Mesen's. The format I came up with (.mlb) is similar to .nl files and is simple to parse. e.g:
Each line is formatted as "Type:Address:Label:Comment", with the "comment" portion being optional. New lines in comments are escaped as "\n" in text form. Types: 'R' = internal ram, 'P' = prg rom, 'S' = save ram, 'W' = work ram, 'G' = "registers" (which is essentially a way of giving names to addresses in the CPU's memory space ($0000-$FFFF))
I also added a switch to create a basic CDL file (which can be used in both Mesen & FCEUX) since they are used by Mesen's disassembler to remember which portions of the PRG ROM is code and can be disassembled.
Testing with this project and loading the mlb & cdl files into Mesen's debugger, I get a pretty good result:
Basically, I'm wondering if you'd be interested in merging my changes? I tried to use the same code/naming style as the rest of the code. My C is quite rusty (haven't actually used plain old C in ages), but I think it turned out ok. I might still have to make some modifications (I haven't even completely finished coding the import/export to .mlb feature I want to add to Mesen yet), but I think this format makes sense(?).
There's still room for improvement, though. For one, being able to distinguish between constants used like "LDA #Constant" and actual memory locations like STA MyVariable would be great - but it doesn't look like there's any simple way to accomplish this?
EDIT: I added the ability to import/export labels in the same format to Mesen and fixed a couple of issues I noticed along the way.
I updated the file format/fork to move the comment to be on the same line as the label (and available for any type of label). I also tweaked the CDL file output so that anything generated via the "filler" function is no longer marked as data.