-
Notifications
You must be signed in to change notification settings - Fork 27
Description
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.