Rhialto

Ha! You're asking me to remember something from decades ago! I have been pondering it a bit. My best current guess at my reasoning about the "^ label" syntax is that it forms some sort of symmetry with the "#directive" syntax. There is a possibility that somebody suggested that such symmetry was lacking, but it could have been my own idea. I am totally not sure on that point. I am fairly certain that I didn't invent this to conform to some sort of external existing source files or anything like that. I also don't think I used it much myself other than test cases. As to why in particular I chose the "^" symbol, I would currently guess that the "^" in regular expressions indicated "match only at the beginning of a line", and here it has the similar meaning "pretend that the next thing is at the beginning of the line" (being the opposite of "pretend that the next thing is NOT at the beginning of the line").

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.

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".

First let me introduce myself: I am the Rhialto whose email got quoted some messages back. In the past I have made a number of feature additions to Dasm. I just registered here, mainly to join this thread. I think it's great that there is still some development in Dasm. Is there anyone who has write access to the dasm-dillon project on sourceforge to check these changes in? Or do we need (yet another) copy in a new location? I think this needs a few more small changes. STRLISTSIZE now occurs like this: asm.h://#define STRLISTSIZE 4 asm.h:#define STRLISTSIZE (sizeof(STRLIST)-4) main.c: sl = (STRLIST *)permalloc(STRLISTSIZE+1+strlen(buf)); ops.c: base = (STRLIST *)ckmalloc(sizeof(STRLIST)-STRLISTSIZE+strlen(str)+1); ops.c: sl = (STRLIST *)ckmalloc(sizeof(STRLIST)-STRLISTSIZE+1+(str-s1)); ops.c: newdir = (STRLIST *)permalloc(STRLISTSIZE + 1 + strlen(buf)); The ones in the middle with sizeof(STRLIST)-STRLISTSIZE are now wrong; that bit should just be STRLISTSIZE. That's in v_execmac(), so I expect problems if you're using a macro expansion. Oh, and when I looked at how this "STRLISTSIZE" got introduced and when it got used incorrectly in the first place, it seemed (from what limited past versions I could still find) that I might have been the person to introduce it, and use it incorrectly... oops!