Arakula / dasmfw

The DisASseMbler FrameWork
GNU General Public License v2.0
13 stars 4 forks source link

Unexpected behaviour: label lengths #13

Open phillipeaton opened 2 years ago

phillipeaton commented 2 years ago

Consider the following: image Only 16 characters of the 0c label are being added to the output file.

If I comment out the following, or comment out one of the other of these settings: image It makes no difference, the first 16 characters are still displayed and used (though the formatting changes a bit).

If I comment out the following line: image then it works OK. In the previous examples, it's like it's overriding the 0c's label name with 0d's label name, but only 16 characters. image

It's possible I'm using it wrong...maybe this is a feature, not a bug!

Whlist I'm typing...the reason I'm adding several labels for Zero Page addresses is that when an address in a range is encountered, dasmfw puts e.g. "ZP+123", where 123 is decimal. I'm much prefer hex, but I can't figure out a simple way to get it to output hex. I think I queried this with you before, but I can't remember the reason.

Arakula commented 2 years ago

You can either write label 0d ZP_Color_RAM_PtrX+1 or tell dasmfw that multiple labels are allowed for an address by setting option multilabel on

I'd suggest the first, however - using multiple labels for an address opens a can of very ugly worms.

phillipeaton commented 2 years ago

Ignoring the multiple labels can of worms, I don't understand why the label 0d line overrides the label 0c before it, or why adding the X should resolve the problem. (It doesn't, see below.)

If I put this image

dsamfw gives this, the +1 seems to give unexpected behaviour image

I've managed to work around it anyway, as shown below image

which gives me image