I'm still slowly moving forward with creating my own assembler, and I decided it'd be really cool to generate Mesen label files (.mlb) automatically, but I'm having trouble figuring out how to handle certain things.
If my understanding is correct, values represent offsets into each kind of memory, which is interesting because it does away with a lot of the complications of banking, but on the assembler's side, we don't normally know what kind of memory each label belongs to, since all labels are created from the same Program Counter.
Since we know we're generating NES ROMs, we can make certain assumptions based on the addresses where things are usually mapped. This is fine for simpler NROM programs, but once we start dealing with bankswitching, there's not much we can do without knowing which bank each label belongs to and how large the banks are.
My assembler has native support for banks, so every label has a bank number assigned to it. I suppose I could add the option of specifying a bank size when defining the bank number, so it'd be possible to calculate the overall offset of each label (BankNumber * BankSize + LabelValue). For this to work correctly, the bank size would have to be consistent throughout all the banks in the same memory type.
Another thing I'm struggling with is identifying "G" labels (registers), since they can be anywhere in the NES' addressing space, that means they'd be recognized as the other kinds of labels (internal RAM, PRG-ROM, etc.) based on their addresses. What can we do to differentiate these labels in the source code? And how to differentiate work RAM labels from save RAM labels?
Does anyone know of ways to deal with these issues in a sane way?
If my understanding is correct, values represent offsets into each kind of memory, which is interesting because it does away with a lot of the complications of banking, but on the assembler's side, we don't normally know what kind of memory each label belongs to, since all labels are created from the same Program Counter.
Since we know we're generating NES ROMs, we can make certain assumptions based on the addresses where things are usually mapped. This is fine for simpler NROM programs, but once we start dealing with bankswitching, there's not much we can do without knowing which bank each label belongs to and how large the banks are.
My assembler has native support for banks, so every label has a bank number assigned to it. I suppose I could add the option of specifying a bank size when defining the bank number, so it'd be possible to calculate the overall offset of each label (BankNumber * BankSize + LabelValue). For this to work correctly, the bank size would have to be consistent throughout all the banks in the same memory type.
Another thing I'm struggling with is identifying "G" labels (registers), since they can be anywhere in the NES' addressing space, that means they'd be recognized as the other kinds of labels (internal RAM, PRG-ROM, etc.) based on their addresses. What can we do to differentiate these labels in the source code? And how to differentiate work RAM labels from save RAM labels?
Does anyone know of ways to deal with these issues in a sane way?