Okay, two separate issues.
Quote:
I tried changing the assume statements
Good but not enough. The ".cpu" statement changes as well, from
Code:
.cpu T_32_L16
to
Code:
.cpu T_32_M16
Changing from LSB to MSB is what swaps the octet order in string characters, as HXA will put the character octet in the least-significant postition and zero-fill the rest. For an 16-bit "byte" LSB descriptor that becomes "XX 00", and for an MSB that becomes "00 XX".
Tested that again; works as described.
Now for an LSB descriptor HXA by default extracts octets in the order 0->01->012->0123, for 8-, 16-, 24- and 32-bit quantities respectively. For 16-bit values you want the order "10" and for 32-bit quantities the order "1032", which is why the ".assume" is used to specify those. Reversed 32-bit quantities should come out "3210", but they already do by default, so there's no need to change that.
For an MSB descriptor the default extractions are 0->10->210->3210. The 16-bit value is in the the proper order, but the 32-bit values, normal and reversed, are not, so they need to be changed via ".assume".
That should take care of the first issue.
Quote:
(This is parenthetical, because I think it's a diversion...)
Actually it's not. It's a bug of sorts. In the file "i6502.a" there is this:
Code:
.if cpu$() ~ /L16/ ; 16-bit "byte" (and 65K "zero page") ?
abs_mask .equ $FFFF0000
.else ; assume 8-bit byte (and 256-byte "zero page")
abs_mask .equ $FFFFFF00
.endif
Look at the listing. "abs_mask" has the value $FFFFFF00, because changing the descriptor from "_L16" to "_M16" causes the match to be false and so "abs_mask" gets the second value, not the first.
Thus the address $0000FF00 becomes non-zero when masked, and is taken as absolute, rather than zero page.
Changing the code to this:
Code:
.if cpu$() ~ /[LM]16/ ; 16-bit "byte" (and 65K "zero page") ?
abs_mask .equ $FFFF0000
.else ; assume 8-bit byte (and 256-byte "zero page")
abs_mask .equ $FFFFFF00
.endif
should be one way to make the match succeed and the proper value given to "abs_mask".