Jump to content

Photo

Need some help with dasm include enhancement


18 replies to this topic

#1 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • 12,698 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sat Feb 24, 2018 5:41 PM

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?



#2 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 761 posts
  • Location:Orlando, FL US

Posted Sat Feb 24, 2018 8:04 PM

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.



#3 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,698 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sat Feb 24, 2018 10:02 PM

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.



#4 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 761 posts
  • Location:Orlando, FL US

Posted Sat Feb 24, 2018 10:19 PM

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.



#5 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,698 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sun Feb 25, 2018 9:26 AM

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.



#6 RevEng OFFLINE  

RevEng

    Bit Player

  • 5,176 posts
  • Location:bottom of the stack

Posted Sun Feb 25, 2018 10:10 AM

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().

#7 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,698 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sun Feb 25, 2018 11:31 AM

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.



#8 CurtisP OFFLINE  

CurtisP

    Moonsweeper

  • 260 posts

Posted Sun Feb 25, 2018 12:09 PM

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/...4-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.



#9 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,698 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sun Feb 25, 2018 2:20 PM

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.


#10 RevEng OFFLINE  

RevEng

    Bit Player

  • 5,176 posts
  • Location:bottom of the stack

Posted Sun Feb 25, 2018 9:25 PM

Sticking it in v_include makes sense to me.  :thumbsup:

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.

#11 CPUWIZ OFFLINE  

CPUWIZ

    Commander

  • 34,756 posts
  • I am the one who knocks!
  • Location:SoCal

Posted Sun Feb 25, 2018 9:28 PM

Fröhlich

 

You guys should look up what that means! :D



#12 RevEng OFFLINE  

RevEng

    Bit Player

  • 5,176 posts
  • Location:bottom of the stack

Posted Sun Feb 25, 2018 9:33 PM

You guys should look up what that means! :D


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

#13 SmileyDude OFFLINE  

SmileyDude

    Moonsweeper

  • 263 posts
  • 6502 Hacker
  • Location:Wilmington, MA

Posted Tue Feb 27, 2018 3:42 PM

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 by SmileyDude, Tue Feb 27, 2018 3:43 PM.


#14 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,698 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Tue Feb 27, 2018 4:03 PM

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.

#15 stephena OFFLINE  

stephena

    River Patroller

  • 3,362 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Tue Feb 27, 2018 5:26 PM

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.



#16 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,698 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Tue Feb 27, 2018 5:30 PM

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



#17 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,698 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Wed Feb 28, 2018 5:00 PM

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"


#18 RevEng OFFLINE  

RevEng

    Bit Player

  • 5,176 posts
  • Location:bottom of the stack

Posted Wed Feb 28, 2018 6:08 PM

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);
}


#19 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,698 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Wed Feb 28, 2018 7:18 PM

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);
}






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users