RevEng Posted February 2, 2014 Share Posted February 2, 2014 It looks like some invalid forms were slipping through. Here's the fixed version. Windows, Linux, and OS X x86 32-bit binaries are in the .zip file. They should work on 64-bit systems. Source code is in the src.tar.gz [Removed. See later post for updated version] Quote Link to comment Share on other sites More sharing options...
finnw Posted February 2, 2014 Share Posted February 2, 2014 (edited) Possible bug: DASM allows bit abs,x This is not a legal instruction! Would be nice to fix, as it took me a while to realise why my code didn't work Cheers A Similar: lda.a $80,x; Trying to use abs,x instead of zp,x; to burn an extra cycle If I meant abs,x then I should have written lda.ax $80,x ; or just lda.ax $80 but instead it assembles as lda $0080 with no warning. Edited February 2, 2014 by finnw Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted February 2, 2014 Author Share Posted February 2, 2014 20 78a8 b5 80 lda $80,x 21 78aa ad 80 00 lda.w $80,x ;WRONG! 22 78ad ad 80 00 lda.a $80,x ;WRONG! 23 78b0 bd 80 00 lda.ax $80,x MODE SYNTAX HEX LEN TIM Immediate LDA #$44 $A9 2 2 Zero Page LDA $44 $A5 2 3 Zero Page,X LDA $44,X $B5 2 4 Absolute LDA $4400 $AD 3 4 Absolute,X LDA $4400,X $BD 3 4+ Absolute,Y LDA $4400,Y $B9 3 4+ Indirect,X LDA ($44,X) $A1 2 6 Indirect,Y LDA ($44),Y $B1 2 5+ I only use .w for absolute addresses, but that's a nasty bug! To be specific, where an absolute address is used, it should assemble with opcode $BD but instead it's ignoring the X addressing and assembling opcode $AD when .a or .w is used to specify an absolute address. Totally wrong!! Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 2, 2014 Share Posted February 2, 2014 Fixed. Non-indexed forced modes are now adjusted to indexed modes if ,x and ,y are discovered during later parsing. Windows, Linux, and OS X x86 32-bit binaries are in the .zip file. They should work on 64-bit systems. Source code is in the src.tar.gz [removed. see sourceforge or lower posts for latest] 1 Quote Link to comment Share on other sites More sharing options...
Rhialto Posted February 2, 2014 Share Posted February 2, 2014 Similar: lda.a $80,x; Trying to use abs,x instead of zp,x; to burn an extra cycle If I meant abs,x then I should have written lda.ax $80,x ; or just lda.ax $80 but instead it assembles as lda $0080 with no warning. I think that the use of those extensions (.ax etc) was originally meant to disambiguate what you had written. For instance, if some instruction could use zero page or abolute adressing, it would force it to be one or the other. What's used here (the "lda.ax $80 you mention) is different: either the extension is used to force an adressing mode to be something else than what's written, *or* the extension and the written adressing don't match because there is a mistake (depending on how you want to view it). I think it was never made for this case, and therefore isn't checking for it. And the response could be two different things: it could throw an error "what you write here doesn't look enough like the mode you seem to want", or it could force it somehow. Personally I am in favour of giving an error message. If you want to index by X there is no reason not to just write the ",x". Quote Link to comment Share on other sites More sharing options...
finnw Posted February 2, 2014 Share Posted February 2, 2014 I think that the use of those extensions (.ax etc) was originally meant to disambiguate what you had written. For instance, if some instruction could use zero page or abolute adressing, it would force it to be one or the other. What's used here (the "lda.ax $80 you mention) is different: either the extension is used to force an adressing mode to be something else than what's written, *or* the extension and the written adressing don't match because there is a mistake (depending on how you want to view it). I think it was never made for this case, and therefore isn't checking for it. And the response could be two different things: it could throw an error "what you write here doesn't look enough like the mode you seem to want", or it could force it somehow. Personally I am in favour of giving an error message. If you want to index by X there is no reason not to just write the ",x". Yes , disambiguating is what I wanted to do in the first place. The problem is that the ".a" suffix has two effects: Use a 16-bit, not 8-bit address Disable indexing The first was intentional but the second was not. So there are three modes to consider: .bx (aka .zx) - the default (given the ,x operand) .wx (aka .ax) - the intended mode (and also consistent with the ,x operand) .w (aka .a) dasm gave me #3 (which is what I asked for, though I did not intend to.) But now the ",x" operand is inconsistent, so it would be nice to have a warning about that. I'm not sure if it should be a fatal error (there may be legitimate reasons to override the addressing mode in a macro.) Also since .bx is the default and .w was specified, I don't think it would be correct to infer .wx which is not the same as either of those (but a mixture of the two.) Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted February 9, 2014 Author Share Posted February 9, 2014 I have attempted to update SourceForge with the new source and binaries. Haven't used SF before, so let me know if not OK. Cheers A 3 Quote Link to comment Share on other sites More sharing options...
+batari Posted February 9, 2014 Share Posted February 9, 2014 I agree about the ambiguity. I think there needs to be one and only one standard: .w, and this should apply for any addressing mode. Whether there is indexing or not should be determined by the actual index, and the .wx, .wy, .bx, .ax, or whatever is at best superfluous. I vote to deprecate .ax, .wx, .wy, .bx, and any and all two-letter extensions, and issue a deprecation warning if any are used, so old code will still assemble. I just don't see why any are necessary. Is there any reason at all? Quote Link to comment Share on other sites More sharing options...
Kylearan Posted March 3, 2014 Share Posted March 3, 2014 (edited) Oh my, dasm is still very broken. I never should have used it for my project, it drives me crazy... maybe we should pin a thread about its problem and weird idiosyncrasies for newbies like me, to warn them. (Are there any better alternatives, for Windows?) Now dasm aborts assembly again with nonsensical "label mismatch" errors which all worked before. Unfortunately my project is so big and I don't really understand the issue, which makes it hard to isolate the problem and post a test case. So let me at least try to describe what's happening when: I have a larger chunk of code where essentially I do several "lda #<label; adc ZPvarA; sta ZPVarB + LabelA - LabelB + 1". No branches in there; a jmp and a bcc a couple of bytes before, and the next branches happens a lot of bytes later, but not in this larger chunk. Suddenly assembly failes, complaining about lots of label mismatches which for the most part have nothing to do with this part of the code. If I add a "jmp .test; ALIGN $100; .test" inbetween, suddenly all works again. Argh! Good thing I don't (yet) have to fight for every byte and can use silly workarounds like this. I hope this won't come up more often. Edited March 3, 2014 by Kylearan Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 3, 2014 Share Posted March 3, 2014 DASM has problems when addresses change during assembly. Do you have conditional assembly blocks? Also, what's the ORG of your code? Quote Link to comment Share on other sites More sharing options...
Kylearan Posted March 3, 2014 Share Posted March 3, 2014 DASM has problems when addresses change during assembly. Do you have conditional assembly blocks?No, except for what's in macros.h and ARPM_Bankswitch.h (see below). Also, what's the ORG of your code?I use the ARPM_Bankswitch.h macros by Robert Mundschau, and use several banks. I also use multiple "ORG $80; var ds 1; ..." declaration blocks to declare different sets of variables for different kernels. Might this be a problem? (Worked until now) Quote Link to comment Share on other sites More sharing options...
Kylearan Posted March 3, 2014 Share Posted March 3, 2014 Oh, and the last output from dasm before the variable mismatch errors is "old value: $750f new value: $740f". Unfortunately it doesn't say for what. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 3, 2014 Share Posted March 3, 2014 Definitely sounds like some addresses are assumed non-ZP in first pass and ZP in later passes. But without the source code it is hard to tell. Quote Link to comment Share on other sites More sharing options...
Rhialto Posted March 3, 2014 Share Posted March 3, 2014 (edited) Wouldn't the listing tell you up to what point it is working? If necessary, use even the -L option which apparently lists all passes, not just the last one. Somewhere in there you should be able to find what makes Dasm thinks is in error. Oh, and Edit: Has anyone tried "make test"? For me I get lots of errors and the "supercat" test tries to generate an infinite output file. murthe.3:.../other/dasm-dillon/trunk$ gmake test (cd src; make; cd ..) mkdir -p bin cp src/dasm bin/dasm cp src/ftohex bin/ftohex echo "Running tests..." Running tests... (cd test; make; cd ..) (cd atari2600; make test; cd ..) diff boing26.bin boing26.bin.ref ./run_tests.sh ----- define_echo ----- Complete. ------------------------error ------------------------error ----- demo ----- segment: code 0000 ???? vs current org: 0005 Aborting assembly demo.asm (46): error: Origin Reverse-indexed. ------------------------error ------------------------error ----- empty ----- Complete. ------------------------error ------------------------error ----- example ----- Complete. ------------------------good ------------------------error ----- fill ----- Complete. ------------------------error ------------------------error ----- jentzsch1 ----- Warning: Unable to open 'vcs.h' Complete. ------------------------error ------------------------error and it goes on a bit. Edited March 3, 2014 by Rhialto Quote Link to comment Share on other sites More sharing options...
Kylearan Posted March 4, 2014 Share Posted March 4, 2014 Wouldn't the listing tell you up to what point it is working? It shows over 20 "label mismatches" with line numbers and addresses, yes, but the labels it complains about are at completely different places in the code. Some of them are declared in the "ORG $80" variable section, and some of them are (local) .labels used for branches. But these labels are not in the part of the code where a "jmp .test; $ALIGN 100; .test" removes the problems. (Instead of that "$ALIGN 100" workaround, removing some lines of code there would remove the problem as well, but of course I need that code.) @Thomas, the problems with posting source code are a) it's huge (several thousand lines of code in several banks) and I haven't found any logic behind the problem yet for isolating a simple test case, and b) it's the demo I will hand in for the competition at the Revision demoparty, so I'm not ready to show it publicly yet. :-/ If I ever find out how I can trigger this with a simple test case, I will post it here of course. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 4, 2014 Share Posted March 4, 2014 Has anyone tried "make test"? For me I get lots of errors and the "supercat" test tries to generate an infinite output file. Yeah, I don't think it ever passed a lot of the test cases. Not in recent years, anyway. I think some of the tests represent bugs or issues that were never fixed, rather than regression tests. Like supercat.asm. Others don't have .bin.ref files, so the test comparison always reports "error". Others pass the binary comparison but fail the hex comparison because the .hex.ref file has a spurious $1A character at the end. I modified run_test.sh to only run against tests with reference files, removed the spurious $1A character in the hex reference, and all but fill passed. The fill fail represents a genuine bug (the align fill bug) which I'll take a look at. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 4, 2014 Share Posted March 4, 2014 Here are updated binaries (Windows, Linux, and OS X) and source with the align+fill fix. dasm-2.20.11-2014.03.04-binaries.zip dasm-2.20.11-2014.03.04-source.tar.gz It also has the fixed hex.ref files, and my version of run_tests.sh, which only runs against tests that have .ref files. All test cases with references are now passing both tests. As the other test cases without references get fixed, the fixer should generate .ref files for them and they'll be automatically included in the run_tests.sh run. At least some of the cases without reference files shouldn't compile without errors, like negative.asm using "lda #256", and the jentzsch[12].asm using "ldz". I don't really think a binary comparison is particularly meaningful for these kinds of tests. Maybe in the future there can be a modification to run_tests to do different "throw error" testing for these sorts of tests. I don't have time to dig into some of the deeper issues, but I'm still up for any quick fixes that anybody runs into. 1 Quote Link to comment Share on other sites More sharing options...
Kylearan Posted March 4, 2014 Share Posted March 4, 2014 Fantastic, that fixed the problem I had! I feel kind of guilty reporting bugs without having a look at dasm myself, so that's greatly appreciated. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted March 5, 2014 Author Share Posted March 5, 2014 Files added to sourceforge. Untested. I trust you Thanks! 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 5, 2014 Share Posted March 5, 2014 Thanks Andrew! Quote Link to comment Share on other sites More sharing options...
+bcombee Posted March 26, 2014 Share Posted March 26, 2014 (edited) I'm seeing a strange bug with the latest version on Windows trying to compile the 2048.asm from https://github.com/chesterbr/2048-2600/blob/master/2048.asm When building, it would repeatedly fail with error 2048.asm (500): error: Unknown Mnemonic 'of'.until I changed a line reading bit $80 ; (3) ; and P1 close to the beginning of the secondto bit $80 ; (3)I've not had time to build a debug version of this and try to track down the assembler bug yet, but does this seem familiar to any of the developers? Edited March 26, 2014 by bcombee Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 26, 2014 Share Posted March 26, 2014 Not sure, but DASM shows weird results if the file was saved on a Linux system and then opened in Windows. That's because the linefeeds are different. You can try to convert the file to using Windows linefeeds. Quote Link to comment Share on other sites More sharing options...
+Propane13 Posted January 15, 2016 Share Posted January 15, 2016 Sorry to unearth an old thread, but I would like to download the new version of DASM (in my case, for Mac). However, it is currently hosted on SourceForge. I know that for a long time, that was a safe site, but sadly that changed in 2015, when it became a potentially untrusted host. Is there any other place I can download the binaries (mirrors, etc)? Thanks! -John Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 15, 2016 Share Posted January 15, 2016 You can grab it from the 7800AsmDevKit at 7800.8bitdev.org, which has binaries for OS X, Linux, and Windows 1 Quote Link to comment Share on other sites More sharing options...
+Propane13 Posted January 15, 2016 Share Posted January 15, 2016 You can grab it from the 7800AsmDevKit at 7800.8bitdev.org, which has binaries for OS X, Linux, and Windows This is exactly what I need. Thanks! -John 1 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.