Closed phillipeaton closed 2 years ago
That m2a32 call looks like a data area interpreted as code (see the following fcb $04?).
Agreed, but would dasmfw know that? And why would it care? It's going to be there for a while until I work out what it is in the source binary code. Like I said, I'm not sure if it's a bug, maybe dasm is working as intended, but it didn't seem right to me at first sight.
No, it wouldn't. dasmfw doesn't perform any intricate flow analysis to separate code from data (which can be a very hard thing to do if, for example, indirect addressing using jump tables is used). It relies on the user to provide correct information in the form of proper code and data statements. By default, everything is code (except, of course, for those processors which clearly separate code and data).
It can give subtle hints, however - if an address is used in an instruction that clearly indicates it's referencing data (LDA, as a simple example) and there's no label in place for that address, it uses a "M" prefix for generated labels; if the referenced address is clearly code (JMP, for example), it uses a "Z" prefix.
Ok, if it's expected behaviour, I can manually put some labels in the info file until I have really confirmed that they're data statements.
I suppose you could see it as a good thing because it forces you to look at these addresses and confirm manually that they are data, something you'd eventually need to do anyway.
The M and Z prefixes are news to me. I assumed the Z prefix was for a one byte offset, as they often appear in simple loops. It might be worth putting this information in the help file, I couldn't find an explanation for M/Z when I looked previously.
I'm not sure this is a bug, but it just doesn't seem right.
When assembling using as65, it's complaining about multiple undefined labels:
until
![image](https://user-images.githubusercontent.com/44277038/166841192-46eafa2b-6ee4-423a-8892-83f21973471c.png)
If I search for e.g. m2a32 as shown in the picture, the only place I find it in the file is:![image](https://user-images.githubusercontent.com/44277038/166840629-c8b445e8-7700-40d0-bece-0094c278f2cd.png)
There are lots of other labels defined at the start of of the file, but not m2a32:![image](https://user-images.githubusercontent.com/44277038/166840756-8728a5a8-a6fc-4b0a-9212-79caa5de91c0.png)
In the nfo file, these are defined as below, but it doesn't look like there is an overlap of the addresss in question, so it shouldn't effect it:![image](https://user-images.githubusercontent.com/44277038/166841148-1d403a3f-f144-4f17-ae53-95ab57769c99.png)