Skip to content

Mesen labels export is flawed #16

@DevRubicate

Description

@DevRubicate

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions