This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

CA65 macros with long parameter lists (bug?)

CA65 macros with long parameter lists (bug?)
by on (#125083)
I've encountered a problem a second time around now where I believe I've run into a bug in ca65. I have a macro with 13 parameters. In some situations, CA65 will say "unexpected trailing garbage characters." In another situation, it will not.

This does NOT say "unexpected trailing garbage characters"
Code:
define_location {(LOCATION_FLAGS_CAMERA_X_SCROLLING_DISABLED_SET | LOCATION_FLAGS_CAMERA_Y_SCROLLING_DISABLED_SET | LOCATION_BRIGHTNESS_LEVEL_4)}, area_index_dungeon, dungeon_entity_set, dungeon_0_0_entity_instances, dungeon_palette, 0, 0, 11, 5, sfx_door, 3, soundeffect_one, HERO_DIRECTION_UP


This DOES say "unexpected trailing garbage characters"
Code:
define_location {(LOCATION_FLAGS_CAMERA_X_SCROLLING_DISABLED_SET | LOCATION_FLAGS_CAMERA_Y_SCROLLING_DISABLED_SET | LOCATION_BRIGHTNESS_LEVEL_4)}, area_index_dungeon, dungeon_entity_set, dungeon_0_0_entity_instances, dungeon_palette, 0, 0, 11, 5, 0, 0, 0, HERO_DIRECTION_UP


Here is the macro definition itself:
Code:
.macro define_location flags, area_index, entity_set_address, entity_instances_address, palette_address, camera_start_x, camera_start_y, hero_start_x, hero_start_y, sfx_address, sfx_channel, sfx_stream, hero_direction
  .byte flags                                   ;flags      .byte
  .byte area_index                              ;area_index .byte
  .word entity_set_address                      ;entity_set_address .word
  .word entity_instances_address                ;entity_instances_address .word
  .word palette_address                         ;palette_address .word
  .byte $20 | ((>(16*camera_start_x) & 1) << 2) ;nametable_start_hibyte .byte
  .word (16*camera_start_x)                     ;camera_start_x .word
  .word (16*camera_start_y)                     ;camera_start_y .word
  .byte <(16*camera_start_x)                    ;camera_start_scroll_x .byte
  .byte (224 + (16*camera_start_y)) .MOD 240    ;camera_start_scroll_y .byte
  .word (hero_start_x*16)                       ;hero_start_x .word
  .word (hero_start_y*16)                       ;hero_start_y .word
  .word sfx_address                             ;on_enter_sfx_address .word
  .byte sfx_channel                             ;on_enter_sfx_channel .byte
  .byte sfx_stream                              ;on_enter_sfx_stream  .byte
  .byte hero_direction                          ;hero_direction .byte
.endmacro


All I've done is replace three parameters, sfx_door, 3, and soundeffect_one (an address, a constant, and an equate), with 0, 0, 0 (three constants). I can juggle the results (whether I get the error) by using \ with .linecont + and other things which don't actually affect the parameter list itself.

The nonsense earlier where I surround a bunch of OR'ed equates with { } was what I thought, previously, to be a workaround for the same problem.

I'm going down the path of building Ca65 to try to learn what the heck is going on, but now I'm running into that whole kerfuffle with what to do with truncating negative values listed after .byte or .word. I thought I saw a thread here discussing said kerfuffle, but I couldn't find it just now. (I had been using a much older build of ca65 without that problem). I'm considering updating my whole codebase to just work with that change, and see if this bug I've run into was fixed in the interim.

I could of course come up with a workaround, or write my own preprocessor to just spit out my locations into binary files instead of these huge macro definitions, but, I'd like to be able to rely on the assembler to assemble code that appears to be correct, even if my usage of it is quirky.
Re: CA65 macros with long parameter lists (bug?)
by on (#125091)
This works without any warnings/errors. Can you post a self-contained example that manifests the problem?
Code:
$ ca65 --version
ca65 V2.13.3 - (C) Copyright 1998-2012 Ullrich von Bassewitz
ca65: No input files
$ ca65 $f -o temp
$ ld65 -t nes -o temp temp


Code:
.segment "HEADER"
.segment "STARTUP"
.segment "VECTORS"
.segment "CHARS"
.code

HERO_DIRECTION_UP = 0
soundeffect_one = 0
LOCATION_FLAGS_CAMERA_X_SCROLLING_DISABLED_SET = 0
LOCATION_FLAGS_CAMERA_Y_SCROLLING_DISABLED_SET = 0
LOCATION_BRIGHTNESS_LEVEL_4 = 0
area_index_dungeon = 0
dungeon_entity_set = 0
dungeon_0_0_entity_instances = 0
sfx_door = 0
dungeon_palette = 0

.macro define_location flags, area_index, entity_set_address, entity_instances_address, palette_address, camera_start_x, camera_start_y, hero_start_x, hero_start_y, sfx_address, sfx_channel, sfx_stream, hero_direction
  .byte flags                                   ;flags      .byte
  .byte area_index                              ;area_index .byte
  .word entity_set_address                      ;entity_set_address .word
  .word entity_instances_address                ;entity_instances_address .word
  .word palette_address                         ;palette_address .word
  .byte $20 | ((>(16*camera_start_x) & 1) << 2) ;nametable_start_hibyte .byte
  .word (16*camera_start_x)                     ;camera_start_x .word
  .word (16*camera_start_y)                     ;camera_start_y .word
  .byte <(16*camera_start_x)                    ;camera_start_scroll_x .byte
  .byte (224 + (16*camera_start_y)) .MOD 240    ;camera_start_scroll_y .byte
  .word (hero_start_x*16)                       ;hero_start_x .word
  .word (hero_start_y*16)                       ;hero_start_y .word
  .word sfx_address                             ;on_enter_sfx_address .word
  .byte sfx_channel                             ;on_enter_sfx_channel .byte
  .byte sfx_stream                              ;on_enter_sfx_stream  .byte
  .byte hero_direction                          ;hero_direction .byte
.endmacro

define_location {(LOCATION_FLAGS_CAMERA_X_SCROLLING_DISABLED_SET | LOCATION_FLAGS_CAMERA_Y_SCROLLING_DISABLED_SET | LOCATION_BRIGHTNESS_LEVEL_4)}, area_index_dungeon, dungeon_entity_set, dungeon_0_0_entity_instances, dungeon_palette, 0, 0, 11, 5, sfx_door, 3, soundeffect_one, HERO_DIRECTION_UP


define_location {(LOCATION_FLAGS_CAMERA_X_SCROLLING_DISABLED_SET | LOCATION_FLAGS_CAMERA_Y_SCROLLING_DISABLED_SET | LOCATION_BRIGHTNESS_LEVEL_4)}, area_index_dungeon, dungeon_entity_set, dungeon_0_0_entity_instances, dungeon_palette, 0, 0, 11, 5, 0, 0, 0, HERO_DIRECTION_UP
Re: CA65 macros with long parameter lists (bug?)
by on (#125093)
Quote:
I thought I saw a thread here discussing said kerfuffle, but I couldn't find it just now.

I think the thread you were referring to is here: viewtopic.php?f=2&t=10819

You could try a recent build of ca65 and use .feature force_range
Re: CA65 macros with long parameter lists (bug?)
by on (#125095)
Do recent builds have a version, or are there basically dozens of "current" versions that everyone is using, each with its own slightly different set of bugs?
Re: CA65 macros with long parameter lists (bug?)
by on (#125109)
"Recent" builds are pulled from the git repo (details here). The only snapshot packages I can find are for Windows. Numbering of the versions appears to have fallen by the wayside.
Re: CA65 macros with long parameter lists (bug?)
by on (#125110)
tepples wrote:
Numbering of the versions appears to have fallen by the wayside.

I thought it was 2.14.0 and Oliver just hasn't done any further *official* releases yet?

From the latest binary drop:
Code:
$ ./cc65.exe -V
cc65 V2.14.0


The drops are identified by similar datestamp format as prior 'snapshots' provided by Uz:

20131205.1_drop.zip

EDIT: So...in other words, to answer blargg...people can at least say "I'm using 20131205.1 drop version."
Re: CA65 macros with long parameter lists (bug?)
by on (#125219)
Thanks guys, I updated to the latest version (added .feature force_range, and twiddled how I'm passing args to the linker...) and the bug is no more. I've subscribed to the CC65 mailing lists so hopefully next time I encounter something like this I'll be more likely to be aware of it.
Re: CA65 macros with long parameter lists (bug?)
by on (#125268)
I was able to do an inverse git bisect (good is bad and bad is good) to find out where the bug got fixed.

Code:
commit d18fd210aaba5f7dbde515defa30ad3cc403259d
Author: uz <uz@b7a2c559-68d2-44c3-8de9-860c34a00d81>
Date:   Thu Jul 7 20:07:29 2011 +0000

    The line counter got confused for lines with more than 256 chars. Removed the
    restriction alltogether, so lines with arbitrary length should be handled
    correctly. Not that it is of much use for an assembler, but this has really
    been a somewhat ancient limitation.
   
   
    git-svn-id: svn://svn.cc65.org/cc65/trunk@5072 b7a2c559-68d2-44c3-8de9-860c34a00d81



This makes sense...my macro statements were huge. And man, I was using a really old version of CA65. I think I leveled up today. :)

So to anyone else who has any remnants of amateurish practices in their NES deving: update your tools!
Re: CA65 macros with long parameter lists (bug?)
by on (#125277)
GradualGames wrote:
I was able to do an inverse git bisect (good is bad and bad is good) to find out where the bug got fixed.

This makes sense...my macro statements were huge. And man, I was using a really old version of CA65. I think I leveled up today. :)

So to anyone else who has any remnants of amateurish practices in their NES deving: update your tools!

Ah, this explains why your first post sounded so familiar! I remember reporting this exact bug to Uz back in 2011, but didn't remember the details of it until now.
Re: CA65 macros with long parameter lists (bug?)
by on (#125279)
Comment in passing (off-topic): thumbs up to reviewing git commit history, and equally big thumbs up to uz for writing a commit message that describes what the issue was.

I only mention this because lots of users of software never actually review commit histories (suppose it's something users shouldn't have to do if there's a decent ChangeLog maintained, but I still follow commits on any major open-source project I use), and lots of software developers put in worthless commit messages (why even bother using a VCS if you aren't clear what your change is for?).