+SpiceWare Posted February 24, 2018 Share Posted February 24, 2018 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? Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted February 25, 2018 Share Posted February 25, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 25, 2018 Author Share Posted February 25, 2018 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. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted February 25, 2018 Share Posted February 25, 2018 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. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 25, 2018 Author Share Posted February 25, 2018 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 25, 2018 Share Posted February 25, 2018 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(). 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 25, 2018 Author Share Posted February 25, 2018 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. Quote Link to comment Share on other sites More sharing options...
CurtisP Posted February 25, 2018 Share Posted February 25, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 25, 2018 Author Share Posted February 25, 2018 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 26, 2018 Share Posted February 26, 2018 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. Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted February 26, 2018 Share Posted February 26, 2018 Fröhlich You guys should look up what that means! Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 26, 2018 Share Posted February 26, 2018 You guys should look up what that means! He's a good guy, so it's a good match. Quote Link to comment Share on other sites More sharing options...
SmileyDude Posted February 27, 2018 Share Posted February 27, 2018 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 27, 2018 Author Share Posted February 27, 2018 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. Quote Link to comment Share on other sites More sharing options...
+stephena Posted February 27, 2018 Share Posted February 27, 2018 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. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 27, 2018 Author Share Posted February 27, 2018 Agreed - once I get SpiceC far enough along I want to put it in git. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 28, 2018 Author Share Posted February 28, 2018 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" Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 1, 2018 Share Posted March 1, 2018 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); } 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted March 1, 2018 Author Share Posted March 1, 2018 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); } 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.