www.retrosoftware.co.uk
http://www.retrosoftware.co.uk/forum/

BeebASM zeropage vs Absolute problem.
http://www.retrosoftware.co.uk/forum/viewtopic.php?f=73&t=547		 Page 1 of 1
Author:  PitfallJ [ Wed Dec 01, 2010 9:15 pm ]
Post subject:  BeebASM zeropage vs Absolute problem.
I've got the following code

ROR $0056

which compiles to

66 56 (i.e. ROR $56)

however I want it to compile to it's absolute form:

6E 65 00 (i.e. ROR $0056)

Is there any method to force BeebASM to do this?



I'm recompiling some disassembled code and I need the alignment of some later code to be kept the same.

- PJ
Author:  RichTW [ Wed Dec 01, 2010 9:45 pm ]
Post subject:  Re: BeebASM zeropage vs Absolute problem.
No, unfortunately not :(

Unfortunately, your best choice right now is:
Code:
EQUB &6E:EQUW &56   ; ROR &0056 (absolute)

which admittedly is horrible.

I've had to do a similar thing recently to force a LDA 0,X to be absolute rather than zp addressed. Given that 6502 opcode syntax is ambiguous, BeebAsm will always choose what it considers to be the most efficient addressing mode - which is right 99% of the time, but unfortunately these odd cases have to be handled like this (it's what BBC BASIC used to do too).

Another feature (ahem) of BeebAsm is that symbols it hasn't yet encountered will be automatically created with the current program counter address. So if you have symbols defining zero page addresses, make sure they are defined before they're used, otherwise BeebAsm will assign them a 16-bit value, and use 16-bit addressing modes. The exception to this is if you're assembling code in the zero page, in which case unknown symbols will get 8-bit values, even if they're defined as some 16-bit value later on. This bit me recently, so perhaps it's worth being aware of.

(*Edit to say - BeebAsm will actually warn you that something odd is up if it creates a symbol as an 8 bit value, and it's later defined as a 16 bit one, so it won't harm you invisibly. But having to work-around it caused me some pain...)

Unfortunately, I don't have any time to spend on BeebAsm at the moment, so for now that workaround's the best we've got!

Sorry 'bout that :oops:
Author:  PitfallJ [ Wed Dec 01, 2010 11:50 pm ]
Post subject:  Re: BeebASM zeropage vs Absolute problem.
Thanks for the EQUB suggestion - that solves my current problem.


You could trigger absolute vs. zeropage by the number of digits in the source file.
e.g. $0034,X versus $34,X but I tell you the thing I would really love to have is macros!

I could then just make up a new one called RORABS ...

Writing 6502 can be so long winded sometimes I'd love to be able to use things like:

STZ
ADD
ADD16
LSR3
JNE (long branch)

etc.

I was actually using some 6502 code a while ago written with commands like JNE - I had to pre-convert it's asm into a new asm so I could then beebASM it!

- PJ
Author:  RichTW [ Thu Dec 02, 2010 8:04 am ]
Post subject:  Re: BeebASM zeropage vs Absolute problem.
A few people have requested macros, but, for the moment, I'm not going to add further features to BeebAsm. Feel free to add anything you wish to it and submit a new version though! :)

I think the problem I have with macros is they can tend to make you lazy, and you can miss valuable optimisations, e.g. blindly using an ADD16 when you can be sure that the MSB is 0 (and therefore can use the BCC-INC trick), or even just something as small as clearing the carry flag when you know it's already clear. Admittedly, with the kind of code I tend to write, I'm always counting cycles or bytes, so seeing the code exactly as it is assembled is important to me.

To add a small amount of high-level structure, I tend to put multiple instructions which belong together on one line, e.g. a load/add/store. This way I can read the line as if it were a single operation, which feels quite clear.

Quote:
You could trigger absolute vs. zeropage by the number of digits in the source file.

Maybe, although I don't really like it much as there shouldn't be any distinction between the constants &79 and &0079 - also, this doesn't solve the problem of labels' values not being known until the second pass. I think maybe the best way to do it is using a new function which takes an 8-bit parameter and returns a 16-bit one, e.g.
Code:
ROR ADDR16(&56)
LDA ADDR8(unknownlabel)

If I have time to revisit BeebAsm, I'll try and add something like this.
Page 1 of 1 All times are UTC [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/