Calculated Symbol

[BacchusFLT]

In my project, the screen memory is at $f400, and defining the lo/hi byte of a piece of code that copies data to a part of the screen, I would like to use a calculated symbol. I do have a vague recollection of a discussion similar to this, but I am not sure and can't find it when looking.

In principle, I would want to be able to enter a symbol that is a calculation that is "screen + $01c2" and enter that for both the low and high byte.

See this example:

[fadden]

Set the symbol to Screen and pick "low" or "high", the offset is computed automatically. The exact form of the expression depends on the expression mode setting (Settings, Display Format tab, Expression Style pop-up).

The current system offsets the byte values independently, so you'd get "#>Screen+1" rather than "#>Screen+$100", though that varies (e.g. Merlin treats it as a 16-bit value). If you're looking for "#>(Screen+$1c2)", that's not currently an option, because there's no way to tie the two LDA statements together to form a 16-bit value.

[BacchusFLT]

I was aware that it does the computations automatically, but there are two issues here;

• The low byte turns to Screen + 194, so in decimal form. I really want the offset in hex.
• He hibyte format does look wierd. I am indeed looking for #>Screen+$01c2

I see the issue in tieing them together as they are totally separate instructions, but I guess that is why I would want to visualise it so that they both use the same "screen + $01c2" calculation.

[fadden]

The problem is that the format needs to encompass multiple instructions. For example:

  lda #$c2
  ldx #$01
  lda #$c4
  ldx #$02

should become:

  lda #<(Screen+$01c2)
  ldx #>(Screen+$01c2)
  lda #<(Screen+$02c4)
  ldx #>(Screen+$02c4)

(The parenthesis may or may not be needed, depending on assembler operator precedence.) The formatter needs to recognize that two independent operands are actually dependent. We'd need a way to establish the relationship in the UI, track it, and display it in the editor. Issue #120 touched briefly on the UI/UX aspect.

The offsets are shown in decimal for "small" values and hex for "large" values, where small is currently defined as < 256. Making every adjustment decimal or every adjustment hex across the entire project would be straightforward; configuring the adjustment format for each individual operand would be harder.

[BacchusFLT]

I am humbly aware how easy it is to say "only" for a task you don't have to do yourself, but if it would be possible to enter a calculation as the symbol name, then that would handle the stuation for me.

If that was the case, there is no need to make the link. If they could be linked, that would of course be a bonus, but I don't see it as necessary - especially not if there are downstream complications from such a requirement.

I understand why the paranthesis are there - logically if the ">" of the expression ">Screen+$1c2" is evaludated first, the result would be totally different that if the addition ius done first. I am assuming that what I see in the main window is a sort of pseudo code, that is eventually converted to the assembler of choice. Given that KickAssembler would apply the ">" last, then my preference would be to not see them, but it's a minor thing for me.

[BacchusFLT]

I'm not saying this is the same thing, but it's somewhat related (Labels and offset references);

I had two labels which are the hi and lo of a set of pointers (word format - at address 1fc0 and 1fc1)). When I make them into word pointers (address table), the reference to the second one is lost ($1fc1). Shouldn't the second one (at address 203f) be WeapoinPoint+1? Isn't a data table a region that should be referenced using the initial label?

[fadden]

if it would be possible to enter a calculation as the symbol name, then that would handle the stuation for me

This falls into the general category of allowing expressions in the operand field. It's on the list. It's tricky to handle because every assembler has completely different ideas about expression syntax. Whatever you enter has to be made to work with every assembler.

Given that KickAssembler would apply the ">" last, then my preference would be to not see them, but it's a minor thing for me

There are three options for on-screen display: "common", "cc65", and "merlin". "Common" uses the standard precedence tables you'd find in a high-level language like C, and works for 64tass and ACME. cc65 mixes things up a little, allowing the parenthesis to be avoided in certain circumstances. Merlin is a whole different thing. Not sure where KickAssembler falls. (cf. https://6502disassembly.com/sg-listing-notes.html)

When I make them into word pointers (address table), the reference to the second one is lost ($1fc1). Shouldn't the second one (at address 203f) be WeapoinPoint+1?

That should be working. One thing that might make it not work would be if you had an explicit format on line $203f that could not be evaluated, e.g. it had a symbolic reference to a nonexistent symbol, and it had to fall back on hexadecimal. If that's the case, there should be a "ref'd symbol not found" item in the Messages window at the bottom of the screen (click the "N messages" button in the bottom right if the window is hidden). And if you click on line $203f, the Info window would indicate an explicit format (green outline) rather than an auto-format (blue outline).

If that's the case, resetting the format on line $203f (right-click, Remove Formatting) would fix it.

[BacchusFLT]

Den sön 26 feb. 2023 kl 23:22 skrev Andy McFadden @.***

:

When I make them into word pointers (address table), the reference to the second one is lost ($1fc1). Shouldn't the second one (at address 203f) be WeapoinPoint+1?

That should be working. One thing that might make it not work would be if you had an explicit format on line $203f that could not be evaluated, e.g. it had a symbolic reference to a nonexistent symbol, and it had to fall back on hexadecimal. If that's the case, there should be a "ref'd symbol not found" item in the Messages window at the bottom of the screen (click the "N messages" button in the bottom right if the window is hidden). And if you click on line $203f, the Info window would indicate an explicit format (green outline) rather than an auto-format (blue outline).

If that's the case, resetting the format on line $203f (right-click, Remove Formatting) would fix it

The issue was that WeaponPoint+1 had its own label that was suppressed as it was not pointing to a byte that was +1. So I make the WeaponPoint into bytes, removed my label, and then made it back to word, and now it's fine.

[image: image.png]

[fadden]

I see... it found a matching label for the operand address, but the label was hidden by the formatting. So it generated an auto-format at $203f for the label, but had to draw it as hex. There should be a "hidden label" warning for $1fc1.

FWIW, the Remove Formatting action also removes embedded labels. I added it so you don't have to convert things to bytes to strip out the hidden bits, which is much more annoying for an instruction than a .word (have to tag the code as data, remove the label, switch it back to code).