rawbits Posted March 10, 2015 Share Posted March 10, 2015 Hi All! You are my last hope here. I try to compile a small test program using the CLEAN_START macro from macro.h (v1.06) but it gives me unresolved symbole for CLEAR_STACK in it. I'm using the latest x86-64 release of DASM 2.20.11 from the WUDSN pack. Which BTW seems to bee the latest stable release. (Yeah I know, but I use Eclipse for everything...except for linux. Linux is always problematic.) If I take out the CLEAN_START macro it's working fine. Directly copy&paste it also not works, took out the '.' so it uses global label and now it complains about CLEAN_START itself.I'm using these things for about 6 years now on Windows and I'm programming 8-bit assembly since '91 - but I can overlook anything ofcourse. Please help! I feel very lost now. Tell me if you need more information. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted March 11, 2015 Share Posted March 11, 2015 Please post a minimal "non-working" example, so that we can help you out. Pretty difficult to diagnose from the information you have given. Have you included " processor 6502" at the start? Have you included an org statement before calling the macro? Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted March 11, 2015 Share Posted March 11, 2015 When doing a reply you'll need to click "More Reply Options" down there in the bottom right to access the file attachment options. Use those options to attach your source code file. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 11, 2015 Share Posted March 11, 2015 Or may you simply misspelled CLEAR_START as CLEAR_STACK like the error says? Quote Link to comment Share on other sites More sharing options...
rawbits Posted March 11, 2015 Author Share Posted March 11, 2015 Here is what I get in the console. And I hope I attached the source of a basic kernel with the CLEAN_START marco called. I didn't tried this particular file on Windows but the code worked before.Compiling for hardware ATARI2600 on 2015.03.11. 19:46: /home/rawbits/BitProcessors/ASM/DASM/bin/dasm.linux-x86-64 /home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm -o/home/rawbits/RustyBits/Atari2600/example.bin -f3 -v5 -l/home/rawbits/RustyBits/Atari2600/example.lst Compiler 'DASM' output: START OF PASS: 1 ---------------------------------------------------------------------- SEGMENT NAME INIT PC INIT RPC FINAL PC FINAL RPC f000 f000 INITIAL CODE SEGMENT 0000 ???? 0000 ???? ---------------------------------------------------------------------- 1 references to unknown symbols. 1 events requiring another assembler pass. - Expression in mnemonic not resolved. --- Unresolved Symbol List 1.CLEAR_STACK 0000 ???? (R ) --- 1 Unresolved Symbol Unrecoverable error(s) in pass, aborting assembly! Running 'Stella': /usr/local/bin/stella /home/rawbits/RustyBits/Atari2600/example.bin Application returned with exit code 0. example.asm Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 11, 2015 Share Posted March 11, 2015 Weird. .CLEAR_STACK (note the dot before) is a local label inside the CLEAN_START macro. Have you checked the macro and made sure that CLEAR_STACK is written with a dot in both cases? Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted March 12, 2015 Share Posted March 12, 2015 I suggest you turn on listing output, then let us see what's actually happening. I wonder if it might be a CR/LF issue....? Something strange is happening inside that macro. Please post the macro.h file, too. I see you already generate a list file. Post it!! Thanks A Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 12, 2015 Share Posted March 12, 2015 I wonder if it might be a CR/LF issue....? Good catch! Assembling files on a Windows OS without CR/LF makes DASM freak out pretty unpredictable. Quote Link to comment Share on other sites More sharing options...
rawbits Posted March 12, 2015 Author Share Posted March 12, 2015 Good catch! Assembling files on a Windows OS without CR/LF makes DASM freak out pretty unpredictable. It works fine on Windows as everything always. Linux is the one having the problematic cases and struggle like this time. It seems, it is finding some strange bytes in that macro though. (had to rename 'cause site didn't let me upload) example.lst macro_h.txt Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 12, 2015 Share Posted March 12, 2015 CLEAN_START macro looks fine to me. Have you tried any of the other macros from macro.h? Do they show the same problem? If yes, maybe you have to replace the two byte Windows CR/LF (0x0d/0x0a) with the single byte Linux LF (0x0a). Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted March 12, 2015 Share Posted March 12, 2015 5 0000 ???? 6 0000 ???? SEG 7 f000 ORG $F000 8 f000 9 f000 Reset 10 f000 0 f000 CLEAN_START /home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic '\F84@'. 1 f000 \F84@ 2 f000 /home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic '5@'. 3 f000 5@ 4 f000 a2 00 ldx #0 /home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic 'P5@'. 5 f000 P5@ /home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic 'h5@'. 6 f000 h5@ /home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic ' 5@'. 7 f000 .CLEAR_STACK 5@ /home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic '\985@'. 8 f000 \985@ /home/rawbits/BitWaste/Atari2600/Scene_examples/example.asm (11): error: Unknown Mnemonic '\C05@'. 9 f000 \C05@ 10 f002 d0 00 bne .CLEAR_STACK 11 f004 Given the above errors in the listing file, it looks pretty certain to me that there are encoding problems in the macro.h file. I would grab a clean one from somewhere else and try that. Cheers A Quote Link to comment Share on other sites More sharing options...
rawbits Posted March 12, 2015 Author Share Posted March 12, 2015 I would grab a clean one from somewhere else and try that. But from where? Also it's working on Windows. And why the vcs.h works? They are from the same place btw and I use them some years now. CLEAN_START macro looks fine to me. Have you tried any of the other macros from macro.h? Do they show the same problem? If yes, maybe you have to replace the two byte Windows CR/LF (0x0d/0x0a) with the single byte Linux LF (0x0a). I didn't tried others. Will try them soon. Yes, I have tried to save them with only LF line ending and also with different encodings. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 13, 2015 Share Posted March 13, 2015 I think possibly its your "different encodings". I've been using the DASM under Linux for years, and don't have a problem with my macro.h, which I just confirmed has DOS style newlines. The macro file should be encoded as US-ASCII, but unless something weird happened, it should have been so in the first place. If all else fails, download the latest bB and extract the macro.h from there, as-is. That's the one I've been using. If the problem persists, use the dasm from there too, though it's identical to the latest SourceForge binary package. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted March 13, 2015 Share Posted March 13, 2015 A look at the binary version of the macro.h file you posted, particularly around the macro, doesn't show any problems. It has 0D/0A pairs as expected. So, I now think you have a dud assembler. It looks like you're running a 64 bit linux version. I recall 64 bit code being dodgy due to the really really dodgy C in DASM. Switch to the 32 bit version and I bet all your problems disappear. Cheers A Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 13, 2015 Share Posted March 13, 2015 I just confirmed that the version of DASM in the WUDSN compilers package is the older 2.20.11, before we added various fixes, including 64-bit fixes. If I use the 64-bit WUDSN one to assemble with CLEAN_START (or anything for that matter) I get a segfault partway through. If I use the post-fixed 64-bit dasm, it works fine for me. I've sent JAC! a PM with the info so he can update the WUDSN compiler package. Quote Link to comment Share on other sites More sharing options...
rawbits Posted March 14, 2015 Author Share Posted March 14, 2015 I just confirmed that the version of DASM in the WUDSN compilers package is the older 2.20.11, before we added various fixes, including 64-bit fixes. If I use the 64-bit WUDSN one to assemble with CLEAN_START (or anything for that matter) I get a segfault partway through. If I use the post-fixed 64-bit dasm, it works fine for me. I've sent JAC! a PM with the info so he can update the WUDSN compiler package. You are a real hero! Thanks! Just compiled the 2014.03.04 source and it works perfectly. BTW versioning is gay or what? Thank you all for the answers! You are an awesome community to help me this quick. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.