So, something that would help speed up workflow immensely - is there any way to make some sort of declaration of script to include or file to incbin in a variable way?

I fully get that ASM is NOT a high level language. But I'm curious. It has functions like .include. Could the target of that .include be variable, somehow? Let's say I had moveScript1 and moveScript2. Is there any way to define which to include in a variable way? In know that a constant expects a numerical value, but something like that...(I know this isn't directly possible, but conceptually)

Code:

MOVE_SCRIPT = "scripts\MoveScript1.asm" ;; sets a target

.include MOVE_SCRIPT ;; this now does the same as ;; .include "scripts\MoveScript1.asm"

Again, I know this won't work and isn't directly possible the way it is written. Is there any way to achieve this basic idea? I realized how much simpler being able to expose choices like this from the tool would be for the end user of what we're working on! As it is, we have the tool write out actual ASM for these sorts of includes in line, but this would be a really cool shortcut!

Are you referring to 6502 assemblers in general or ca65 in particular? If ca65 in particular, look up .define macros in "ca65 Users Guide" and see if they help. If you want a tested example, I can provide one in several hours once I am at a PC with ca65 installed.

Hey dude - I was talking about in 6502 assemblers (using ASM6 at the moment). I don't know if it's directly possible there, but...definitely figured it was worth asking. It's something most people wouldn't have much use for, but it occurred it would be super beneficial for what we're trying to do. Curious if anyone has done anything like it.

I've used preprocessors for a couple things, such as shuffling variable declarations for buffer overflow testing and converting NESASM source code to ca65 when packing multiple ROMs into one 32K bank for Action 53.

Following up on this one. As described, this worked fine. Now, again, I'm just pushing into *weird* territory, piggybacking on this. And again, it's just a housekeeping thing to make things cleaner, not integral. Was wondering, though, if anyone had any thoughts.

So, I have a macro, in which I just declare a word as an argument. So, like:

Code:

LoadNametable newScreen

And then the macro actually apples #< and #> to newScreen, and I can easily use it to look up the address of the label newScreen. Super handy!

Now, using the trick outlined above, I thought perhaps if I'd done something like this:

Code:

foo equ "newScreen"

...then I could write this:

Code:

LoadNametable foo

....which would effectively give me "LoadNametable newScreen", since foo equ newScreen, and just inserting newScreen works fine. However, ASM6 assembler throws an error that foo is not a number. So it's not doing exactly what I had hoped in that instance.

Anyone know of a way to do something like this? If not, I have a hundred ways around it. This would just be a prettier way!

Thanks.

*****UPDATE - after some playing, this works fine as a constant after all. Huh. Disregard.

I think the larger problem is you're using ASM6. Which is quite a weak and poor assembler, with unusual syntax and odd "quirks". Since 6502 assemblers are dime a dozen its not hard to find a better one that does more of what you want. So instead of trying to bend ASM6 it makes more sense to just jump to another assembler.

If you want a little bit more ACME, if you want a fair amount of power CA65, if you want to pull all the tricks tass64. If you want to use scripting as much as possible their is the unholy thing known as KickAss its claims to be an assembler but a lot of people are not sure.

i use asm6 for doing quick tests/learning new methods and see the results quickly (simple test programs that yield a value somewher in zp if they do what i think they ought to do), while my actual projects, however small, are ca65 since i feel it gives me a better handle on things.

If this is for NESmaker, i guess asm6 is pretty much locked in at this point? ca65 could potentially help ease the interfacing between the GUI and the actual assembly and make it more versatile, though.

Who is online

Users browsing this forum: No registered users and 6 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum