Need some help with dasm include enhancement

[+SpiceWare]

For SpiceC I'm creating a config.h file that contains info needed to build a project, such as:

MENU_KERNEL = "Menu/48pixel.asm"
GAME_KERNEL = "Game/space.asm"
SCORE_KERNEL = "Score/radar.asm"
AUDIO = TIA_ONLY
    MAC DIGITAL_AUDIO
        nop #AMPLITUDE
        sta Sleep3
    ENDM

---

My plan was to use the *_KERNEL symbols like this in the 6507 code:

       INCLUDE SCORE_KERNEL

---

I knew dasm supports string symbols (from the project's symbol file):

SCORE_KERNEL             616461722e61736d      str          "Score/radar.asm"

---

But discovered that it does not support using them in the include statement:

Warning: Unable to open 'SCORE_KERNEL'

---

I tracked down dasm source with recent bug fixes by RevEng (reply #8) and have done some digging. In ops.c I've modified v_include() to be this:

void
v_include(char *str, MNEMONIC *dummy)
{
//    char    *buf;
//    
//    programlabel();
//    buf = getfilename(str);
//    
//    pushinclude(buf);
//    
//    if (buf != str)
//        free(buf);
  
  char    *buf;
  SYMBOL *sym;
  SYMBOL *s;
  char temp[100];
  
  printf("dgs str = %s\n", str);
  
  sym = eval(str, 0);
  
  for(s = sym; s; s = s->next)
  {
    printf("%s\n", s->string);
    sprintf(temp, "%s", s->string);
  }
  
  programlabel();
  buf = getfilename(temp);
  printf("dgs buf = %s\n", str);
  
  pushinclude(buf);
  
  if (buf != temp)
    free(buf);
  
  FreeSymbolList(sym);
}

---

Which worked! The symbol list even shows the string as being referenced:

SCORE_KERNEL             616461722e61736d      str     (R ) "Score/radar.asm"

---

So I know where to make the change, but I'm not at all familiar with what the eval() function is doing. Anybody have some pointers for this?

[ZackAttack]

Just a thought here. Since all the 6502 code is going to be part of the framework. Why not just include it as bins which can be pulled into the C build. That way users of Spice C don't have to configure dasm at all. You build the C files and it spits out the 32KB file.

 

It should be fairly simple to accomplish with a few header files, some preprocessor directives, and maybe some linker script magic.

[+SpiceWare]

You can mix & match menu, game and score kernels so the location of things will move around in 6507 BIN. Sure I could prebuild each combination, at the moment I have plans for 2 menu, 3 game kernels and 3 score kernels so would need to pre-build 18 BIN for inclusion by the C code, but that quickly becomes large as new choices are added. A new score option was suggested by kdgarris, which would bump that up to 24 pre-built BINs. Add a new menu option after that and we're at 36.

To complicate the above, I'm working on having it push the free space to the front of the 6507 code, so if the choices result in 3K of 6507 code an extra 1K will be available in the C code space.

Additionally, letting dasm build from source means easier debugging via Stella, it'll pick up the symbol file and show my labels rather than like LF093.

[ZackAttack]

I assumed that there would be some modules which can be mixed and matched. That's why I suggested wrapping them in header files with some sweet preproc magic to fix up the offsets of everything. Each module header would know how big it is and would calculate offsets for its symbols based on some global modules size variable after which it would increase the global modules size by the amount of itself.

 

Regarding debugging. Users of Spice C shouldn't need to debug the prebuilt kernels. You could do what I do for strong-arm and have a special debug cart class which runs win/Linux/mac binary and then you just build it as part of stella and debug it that way. This is how I'm developing Wushu Masters. I do everything in visual studio and only bother building for ARM when I'm ready to test on actual hardware. Of course you could just as easily use eclipse, gdb, or whatever other toolchain that is capable of building/debugging stella source.

[+SpiceWare]

Being able to debug the kernels is for me, right now during SpiceC development, as well as in the future for anybody else who wishes to add a new kernel as has happened with bB. Having to wrap up precompiled modules in headers files and deal with "relocation magic" makes it more complex for later enhancements, and thus less likely new kernels would be developed by others.

[+RevEng]

So I know where to make the change, but I'm not at all familiar with what the eval() function is doing. Anybody have some pointers for this?

I'm an infrequent dasm hacker, and far from being an authoritative source, but I have tweaked eval() while working on bug fixes... eval() is used to parse out the line of assembly source code after the opcode/pseudo-op, and do stuff like set the right address mode flags, decode symbols, assemble-time math, etc.

 

I think what you've done shouldn't be a problem. eval(str) is used pretty much the same way you did, to decode symbols (and perform any math) in the handler for ORG, v_org().

[+SpiceWare]

Thanks!

 

After looking at it some more, I think moving the call to eval() into getfilename() would make more sense as then it should also work for incbin and incdir.

[CurtisP]

You can mix & match menu, game and score kernels so the location of things will move around in 6507 BIN. Sure I could prebuild each combination, at the moment I have plans for 2 menu, 3 game kernels and 3 score kernels so would need to pre-build 18 BIN for inclusion by the C code, but that quickly becomes large as new choices are added. A new score option was suggested by kdgarris, which would bump that up to 24 pre-built BINs. Add a new menu option after that and we're at 36.

 

To complicate the above, I'm working on having it push the free space to the front of the 6507 code, so if the choices result in 3K of 6507 code an extra 1K will be available in the C code space.

 

Additionally, letting dasm build from source means easier debugging via Stella, it'll pick up the symbol file and show my labels rather than like LF093.

 

I agree that it's easier to just let the assembler do all the work of locating the included code. You also don't have to deal wiith linking of object code. I wanted the same simplicity in C02 (http://atariage.com/forums/topic/267074-c02-compiler/) but rather than using dasm's include functionality, the compiler copies the include file contents directly into the asm file that is generated.

[+SpiceWare]

Turns out all getfilename() does is remove the quotes from the filename. Results from eval() already come back without the quotes, so I've revised v_include() to be:

void
v_include(char *str, MNEMONIC *dummy)
{
  SYMBOL *sym;
  
  sym = eval(str, 0);
  if (sym->flags & SYM_STRING )
  {
    programlabel();
    pushinclude(sym->string);
  }
  
  FreeSymbolList(sym);
}

---

Does what I need it to, so I've resumed work on SpiceC.

Is anybody acting as a keeper for dasm updates? If not, perhaps we should start a new github repository to keep track of the enhancements and fixes we've done.

[+RevEng]

Sticking it in v_include makes sense to me.

 

Peter Fröhlich was (is?) maintaining the Sourceforge tree, but for various reasons it's different than the bug fixed version we made here, which is the dasm version you've applied your work to here. (plus the Windows linefeed fix) I don't believe Peter wants to take all of those fixes wholesale, at least in part because some fixes aren't needed and others will need modification for his version. (we actually attempted to update sourceforge and we messed up his tree, because it differed so starkly.)

 

I've been including our fixed dasm source and binaries (Windows, OS X, Linux) as part of 7800AsmDevKit, 7800basic, and the bB 64k with fixes fork. I'll keep doing that, but I'd also be glad to work with a repo somewhere. I just don't have the time and understanding to merge everything into Peter's tree, check for regressions, etc. Especially since our version has been quite extensively tested.

[CPUWIZ]

Fröhlich

 

You guys should look up what that means!

[+RevEng]

You guys should look up what that means!

He's a good guy, so it's a good match.

[SmileyDude]

I had setup a GitHub repo years ago for dasm. I think it was just a fork of whatever the latest version I could find at the time along with some fixes I needed on the Mac.

 

https://github.com/munsie/dasm

 

I don't know if it's helpful or not, but it is the version of dasm that I use for my own 6502 development. So at least I know it works

Edited February 27, 2018 by SmileyDude

[+SpiceWare]

Cool! I still need to wrap my head around how git works. I had lots of trouble submitting updates for Stella. I gave up due to frustration & lack of time (was finishing Draconian for PRGE) and just sent updates directly to stephena.

[+stephena]

And I'll take code contributions any way I can get them That being said, learning how to use git may be more beneficial in the long run.

[+SpiceWare]

Agreed - once I get SpiceC far enough along I want to put it in git.

[+SpiceWare]

I discovered a minor issue with this change. This no longer works:

        include vcs.h       
        include macro.h

---

because dasm now tries to evaluate them. Quoting them resolves the issue:

        include "vcs.h"       
        include "macro.h"

[+RevEng]

Maybe only accept the eval result if it has a length>0. Something like...

 

void
v_include(char *str, MNEMONIC *dummy)
{
    char    *buf;
    SYMBOL *sym;
    programlabel();
    buf = getfilename(str);
    sym = eval(str,0);
    if (strlen(sym->string)>0)
        pushinclude(sym->string);
    else
        pushinclude(buf);
    FreeSymbolList(sym);
    if (buf != str)
        free(buf);
}

[+SpiceWare]

Great idea! Looks like the SYM_STRING test fails in this instance, so I added an else to handle it.

void
v_include(char *str, MNEMONIC *dummy)
{
  SYMBOL *sym;
  
  programlabel();
  
  sym = eval(str, 0);
  if (sym->flags & SYM_STRING )
  {
    pushinclude(sym->string);
  }
  else
  {
    char *buf;
    buf = getfilename(str);
    
    pushinclude(buf);
    
    if (buf != str)
      free(buf);
  }
  
  FreeSymbolList(sym);
}