feature: how to deal with labels when using DP

[binary1230]

it would be interesting if there's a way to solve this issue.

consider the following ASM code:

STZ $0A                            ;C70328|640A    |001E0A; 

I know from running this game and capturing the tracelog data that the final RAM address it's going to is $001E0A (which is register DB value of $1E00 + this constant of $0A.

Let's say I have a label for this like character_hp =1E0A

In the final asm, it would be cool if there was a way to have this reference character_hp like this somehow:

STZ $character_hp

I have a feeling there's not really a way to directly put that label name in there, since DP is runtime dependent.

Still, I think Diz can at least know that it's likely to be character_hp and maybe note it in the label, or, make a search function in the app that can connect the dots here.

I'm basically trying to make it so humans can know when looking at this casually that this instruction is likely operating on character_hp

[IsoFrieze]

This might be something worth talking about with the people who maintain asar--there might be a way (if there isn't already) to set the DP register (direct page, DB is data bank) via an assembler directive. So you can do something like:

!character_hp = $1E0A
;;
LDA.W #$1E00
TCD
.directpage $1E00
STZ.B !character_hp

and that last instruction would automatically subtract the direct page offset specified by the directive, and result in $0A.

Then, all Diz would need to do is make sure to insert those directives whenever the direct page changes, and 'undo' all those offsets to get the proper label.

[binary1230]

(woops, yea I meant DP, not DB)

that would be very cool if Asar supported that! I will check that out.

that makes a ton of sense. it does seem like the combination of "STZ.B" to mean "constrain to 1 byte" and character_hp and .direct_page to be enough to infer that it just needs to put "0A" in there.

I keep thinking over this idea more generally. i.e. implementing constraints in Diz, where essentially Diz knows information about what bytes the resulting ROM "must" be, so it can pick the right choice when there are multiple options for things like mirrored addresses.