Open Drakim opened 7 years ago
FYI, I am aware of this and do want to take a look at it soon. I was busy getting the next version of Mesen out and did not find the time for this. I'm not overly familiar with the ways to define variables/constants, etc. in ASM6 (or any assembler really), so the approach I took when coding that is definitely far from perfect. I'll try to take another look at it and see if some improvements can be made. As for .ignorenl, that's definitely a good point - I meant to do this, but ended up forgetting about it, I'll add support for this.
That would be amazing. I really like Mesen's debugger a whole lot more than FCEUX, but with the label export being as wonky as it is I simply had to turn it off and debug without labels when using Mesen.
Still haven't had the chance to check this, unfortunately, but I did add some options in 0.9.5 to configure the import of DBG/MLB files which allows you to disable the importation of certain types of labels. Using this, you should at the very least be able to import the PRG ROM labels, even if the rest is still unusable.
it also fails to work with the BASE directive, meaning that for how I set up FDS development, it exports symbols that are file offsets instead of memory offsets.
In the function export_mesenlabels(), it is assumed that all labels of type LABEL are program code labels, and all labels of type VALUE or EQUATE are either RAM variables or registers.
This assumption is not very good, as all .dsb definitions, even when wrapped inside an .enum or .ignorenl, is treated as program code labels and given the P: tag in the resulting .mlb file.
This can be worked around by never using the .dsb directive and always manually deciding upon RAM locations with = or EQU assignments, but this is very unwieldy and unfriendly. It means you have to manually assign addresses to every variable instead of letting the assembler do the heavy lifting.
In the VALUE or EQUATE section of the function, the type of RAM (or register) assigned is based on some simple heuristics based on address ranges. Maybe the same system could be used in the program section? From what I understand, if an label is pointed to anywhere between $0000-$07FF, you can be certain it's the NES internal RAM, and so on.
Lastly, it would be great if the .ignorenl directive also worked for export_mesenlabels just like it does for FEUX, as you can often have hundreds of constants with various integer values, which will currently be forcefully exported to the .mlb file and cause all manner of nonsensical labels at random places.