"Incomplete expression." in ASM6 macro

I'm building an audio driver in ASM6, and I'm up to where I build a table of sound effect addresses and lengths. But when I try to express lookup tables using macros, I get "Incomplete expression" errors.

When I assemble this source file and provide -L to expand macros in the listing file:


This listing is produced:


What is causing these errors, and what should I understand in order to figure out how to fix them?

Isn't this because the * is being interpreted as the multiplication operator, since ASM6 uses $ for the PC?

Thanks for help. Now I have to figure out how to programmatically distinguish the two in the ca65 code I'm converting without having to hand-edit both copies every time I change something.

Well, you could use ca65's dollar_is_pc feature and start using $ all around...

A new question

Translating * to $ at the start or end of an expression or parenthesized subexpression fixes one layer of the above MCVE but changes the error message I get when I assemble the whole project. If I try to translate the ca65 idiom for an include guard to ASM6, it ends up not recognizing the macro at all, instead producing "Illegal instruction" but only for the first use of each such macro.

Source:

Listing:

The macro does different things (both wrong) on different invocations. The first time it says "Illegal instruction" and the second time it generates incorrect code. This makes me think I'm hitting an ASM6 bug. I decided to work around it in the translator by detecting whether a particular .ifndef is an include guard and changing it to a .if 1 if so.

Maybe that "*** Illegal Instruction" is attempting to say that your dw baseaddr and db length are confusing for asm6 bc you haven't defined the values of baseaddr and length?

Sorry tepples, I just noticed that you do define the values in your macro calls... maybe this error is created bc you db length before you call the macro? I think tokumaru taught me that the macro has to be defined before it can be called... maybe the same logic applies to whatever baseaddr and length are.

Sounds like a bug indeed.

In any case, I've reduced another test case.

It seems like most actual bugs in ASM6 disappear once a forward reference is made no longer forward.

Are you trying to use include guards because multiple source files include the same stuff?

Yes. Both the driver and the instrument/sequence data include one of the header files, and I can't guarantee which gets included first because ASM6 requires them to be included in output file order.

So both the driver and instrument/sequence data are assembled together in one unit?

ASM6 normally assembles everything as one translation unit, so yes, driver and data are assembled together. It's possible though tricky to assemble something as multiple translation units with ASM6. If so, the separately assembled translation unit has to have entry points at fixed addresses, such as $8000, $8003, $8006, $8009, etc.

The problem with the traditional .ifndef type include guard is that ASM6 is a multiple-pass assembler, and anything inside an .ifndef with a following .define inside it will get processed on the first pass, but not on the second. The ASM6 only states that .ifdef and .ifndef operate depending on whether the operand symbol is defined/not defined, without any mention as to whether the definition is supposed to occur prior to the directive or not, so it's implied then that forward references are included as part of .ifdef/.ifndef's operation.

The fallout, of course, is that when ASM6 gets to the second pass, the included file's contents end up not getting output at all.

What you obviously wanted was the first include, and ONLY the first include, to occur. After thinking it over, I may have an ASM6-specific workaround.

Let's say you have your driver in driver.asm and instruments/sequence data in song.asm, and they both include a file called foo.asm for whatever reason. Now, since ASM6 is assembling these as one translation unit, it follows that there must be a top-level source file for the driver and data to go into, assuming one of them isn't the top-level file (I don't know enough about your code to make too many assumptions here).

Now, you obviously don't want foo.asm included twice. My idea is this: define a symbol in the top-level file that precedes the driver and data files that matches whatever symbol you'd have used for foo.asm's include guard:



Then, at the beginning of foo.asm, put this in:



And hopefully that should cause only the very first .include of foo.asm to have any effect on the unit's output, since FOO_ASM will be set to nonzero on the first include, but zero on any subsequent includes, until the next pass.

ASM6 is still drunk.

I'm developing a library where features can be turned on or off at build time. The user edits a config file to set constants to zero or nonzero. Then after the config file is processed, another include file tests whether each constant has been set: if ifndef returns that the constant hasn't been set yet, it gives the constant a reasonable value. But when I was introducing support for prefixed constant and macro names in this library, ASM6's macro system started acting up.

Steps to reproduce:


Expected behavior:
The PP_ name, transposition, and PI_ name in each db statement in the listing correspond to the macro call right above it.

Actual behavior:
The PP_ name, transposition, and PI_ name in each db statement stop corresponding to the preceding macro call soon after PSDAT_arp_waltz.



I guess I could find some other way to provide defaults.