Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mesen labels export is flawed #16

Open
Drakim opened this issue Nov 7, 2017 · 4 comments
Open

Mesen labels export is flawed #16

Drakim opened this issue Nov 7, 2017 · 4 comments

Comments

@Drakim
Copy link

Drakim commented Nov 7, 2017

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.

@SourMesen
Copy link
Contributor

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.

@Drakim
Copy link
Author

Drakim commented Dec 30, 2017

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.

@SourMesen
Copy link
Contributor

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.

@zulc22
Copy link

zulc22 commented Mar 18, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants