| |
Slammer
Registered: Feb 2004 Posts: 416 |
Kick Assembler Thread 2
The previous thread took a little long to load, so this is a new fresh one.. |
|
... 592 posts hidden. Click here to view all posts.... |
| |
Shadow Account closed
Registered: Apr 2002 Posts: 355 |
I'm getting some strange behaviors with pseudopc set to a zeropage address.
I have some code that I assemble into memory, then copy to zeropage runtime. However, the self modifying parts of it doesn't get properly assembled to the ZP versions of the instructions if I reference a label that is further ahead in the code.
Here's an example that demonstrates this:
.pc=$1000
.pseudopc $90
{
some_label:
lda $1000
inc some_label+1
inc some_other_label+1
some_other_label:
lda $1000
}
This get assembled into:
AD 00 10
E6 91
EE 99 00
AD 00 10
I would have liked it to be:
AD 00 10
E6 91
E6 98
AD 00 10
|
| |
Slammer
Registered: Feb 2004 Posts: 416 |
You have stumbled upon an interesting detail. To simplify a bit, look at the following:.pc = $fd
lda label
label: In the case the position of the label depends on the size of the command, and the size of the command depends on the position of the label so the only way to determine if the command can use its zeropage form is by trial and error, which might get quite complex and lead to more passes.
Instead Kick Assembler tries to reduce the command to its zeropage form when it first meets the command, and since it doesn't know the value of the label, it fails and marks the command as using the absolute addressing mode. This is the reason why the first command in your example is reduced to the zeropage form and the second isn't.
So what do you do then?. You can use this little magic trick to tell the assembler that you want a zeropage command: .pc=$1000
.pseudopc $90
{
some_label:
lda $1000
inc some_label+1
inc CmdArgument(2, some_other_label+1)
some_other_label:
lda $1000
}
The magic is the argument type constant 2 which actually is 'AT_ZEROPAGE' which is not exposed in the current version but will be in the next release (Nobody I know of have had this problem before - placing code on the zeropage seems kind of special, but might be a smart optimization?)
Previously I have had plans for making it easier to force addressing modes like this:inc.zp label
lda.abs $0000
and they can be reintroduced on the todo list if there is a demand for it.
|
| |
tlr
Registered: Sep 2003 Posts: 1739 |
Quoting SlammerPreviously I have had plans for making it easier to force addressing modes like this:inc.zp label
lda.abs $0000
and they can be reintroduced on the todo list if there is a demand for it.
It should be possible to resolve it in most cases using additional passes but I'd vote for your solution with extensions.
I've used .z and .a in dasm quite a lot.
|
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
I second tlr. Sometimes i use abs-mode for zp addresses for VIC timing reasons, to make it take a cycle more. In this case I do it like this:
.by LDA_ABS
.wo zpAdr
This approach can be used the other way around too of course, but it's a bit clumsy in the long run.
|
| |
Shadow Account closed
Registered: Apr 2002 Posts: 355 |
Sorry Slammer, I write strange code for strange platforms, so I guess I end up hitting those cases noone thought of! :)
I'll try the workarounds posted here! |
| |
tlr
Registered: Sep 2003 Posts: 1739 |
Typo:
buf_zp:
.fill 4 do <ctrl>-t here
^ |
v
Error: Invalid number of arguemnts
at line 122, column 2 in test.asm
|
| |
Slammer
Registered: Feb 2004 Posts: 416 |
Thanks. It's corrected in the next release. |
| |
Slammer
Registered: Feb 2004 Posts: 416 |
I just release v3.20. One of the new features is that you can force addressing modes like this:inc.zp label
lda.abs $0000 orinc.z label
lda.a $0000 Btw. the 'chars inheriting from number' issue was implemented in v3.19
|
| |
tlr
Registered: Sep 2003 Posts: 1739 |
Great! |
| |
tlr
Registered: Sep 2003 Posts: 1739 |
Quote: I just release v3.20. One of the new features is that you can force addressing modes like this:inc.zp label
lda.abs $0000 orinc.z label
lda.a $0000 Btw. the 'chars inheriting from number' issue was implemented in v3.19
Hmm, in 3.20 do:
.pc = $0801
ldy.a $c000,x
sta.z $fb,x
This will silently ignore the indexed addressing mode (= bad).
Also this could be resolved in a nicer way as we know that it must be <zp>,y: .pc = $0801
stx lab,y
.label lab = $fb
|
Previous - 1 | ... | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | ... | 61 - Next |