ACME Cross-Assembler Activity
multi-platform cross assembler for 6502/6510/65816 cpu
Brought to you by:
marcobaye
Activity for ACME Cross-Assembler
-
Marco Baye committed [r449] on Code
fixed confusing "no string given" error message, now there are separate
-
Piero Furiesi modified a comment on ticket #30
Solved. Maybe there's something wrong in ACME when calculating (+) reference. !macro BEQ .l { !set .b = (* - 126 <= .l) & (.l <= * + 129) !ifdef .b {!if .b { BEQ .l } else { BNE * + 5: JMP .l}} }
-
Solved. Maybe there's something wrong in ACME when calculating (+) reference. !macro BEQ ~.l { !set .b = (* - 126 <= .l) & (.l <= * + 129) !ifdef .b {!if .b { BEQ .l } else { BNE * + 5: JMP .l}} }
-
... But this one fails (why?) * = $C000 +LBL ~mylabel !for .i, 1, 10 {NOP} +BEQ mylabel ;short !for .i, 1, 200 {NOP} +BEQ mylabel ;long !for .i, 1, 200 {NOP} +BEQ mylabel ;long !for .i, 1, 200 {NOP} +BEQ mylabel ;long -- FAILURE
-
;THIS WORKS! ;ACME release 0.97 ("Zem"), 1 Aug 2025 ;define .l as a target for a (long) branch. "LBL is a Long Branch LBL." !macro LBL ~.l { !set .l = * } ;long branches: .l must be a label defined by +LBL macro !macro BEQ .l { !set .b = (* - 126 <= .l) & (.l <= * + 129) !ifdef .b {!if .b { BEQ .l } else { BNE + : JMP .l :+ }} } * = $C000 +BEQ mylabel ;long !for .i, 1, 200 {NOP} +BEQ mylabel ;short !for .i, 1, 10 {NOP} +LBL ~mylabel !for .i, 1, 10 {NOP} +BEQ mylabel ;short !for .i, 1, 200 {NOP} +BEQ...
-
;THIS WORKS! ;ACME release 0.97 ("Zem"), 1 Aug 2025 ;define .l as a target for a (long) branch. "LBL is a Long Branch LBL." !macro LBL ~.l { !set .l = * } ;long branches: .l must be a label defined by +LBL macro !macro BEQ .l { !set .b = (* - 126 <= .l) & (.l <= * + 129) !ifdef .b {!if .b { BEQ .l } else { BNE + : JMP .l :+ }} } * = $C000 +BEQ mylabel ;long !for .i, 1, 200 {NOP} +BEQ mylabel ;short !for .i, 1, 10 {NOP} +LBL ~mylabel !for .i, 1, 10 {NOP} +BEQ mylabel ;short !for .i, 1, 200 {NOP} +BEQ...
-
;THIS WORKS! ;ACME release 0.97 ("Zem"), 1 Aug 2025 ;define .l as a target for a (long) branch. "LBL is a Long Branch LBL." !macro LBL ~.l { !set .l = * } ;long branches: .l must be a label defined by +LBL macro !macro BEQ .l { !set .b = (* - 126 <= .l) & (.l <= * + 129) !ifdef .b {!if .b { BEQ .l } else { BNE + : JMP .l :+ }} } = $C000 +BEQ mylabel ;long !for .i, 1, 200 {NOP} +BEQ mylabel ;short !for .i, 1, 10 {NOP} +LBL ~mylabel !for .i, 1, 10 {NOP} +BEQ mylabel ;short !for .i, 1, 200 {NOP} +BEQ...
-
added a comment on where to fix a bug
-
Re-assembling alternate code after error
-
Once version 0.98 is released, it should be possible to do stuff like this using macro magic. ...and for CPUs that have "long" branches (like 65ce02), choosing the correct length could be done automatically. Version 0.98 will be out RealSoonNow (tm).
-
added "!break", "!continue" and "!return" (for loops and macros, respectively)
-
Ticket to close. I've thought about it again. This feature might only be useful for the "Target out of range" error, and a shell script that modifies the source file and re-invokes acme is much better.
-
Ticket to close. I've thought about it again. This feature might only be useful for the "Target out of range" error, and a shell script that modifies the source file and reactivates acme is much better.
-
I missed some colon, last code shoud read as {BCS + : JMP some_addr : +}
-
Re-assembling alternate code after error
-
Hi, I saw that !info & !debug pseudoopcodes have been added since [r332], many thanks! Documentation in docs/AllPOs.txt should be updated too ;)
-
moved test files around
-
fixed bug where "!if" complained about undefined conditions even if user had
-
"else if" can now also be written as "elif"
-
added FIXMEs
-
"fix" for previous commit
-
added "denial of service" example source code
-
small cleanup in src and docs concerning ACME library
-
added some comments and "!byt" and "!outfilestop" aliases.
-
added CLI option to override path to ACME library
-
minor change in arrangement of mnemo tables
-
Left shift by 24 errors on small numbers
-
MEGA65: Most Q-instructions "don't" support indexed addressing mode
-
MGEA65: Most Q-instructions "don't" support indexed addressing mode
-
Fixed LDQ, the others had already been fixed earlier. If you don't build ACME from source, you'll have to wait a few more days, but version 0.98 will be released RealSoonNow(tm).
-
MEGA65: LDQ (zp),Z and LDQ [zp],Z are supported
-
Fixed. If you don't build ACME from source, you'll have to wait a few more days, but version 0.98 will be released RealSoonNow(tm).
-
fixed addressing modes for M65 cpu (see tickets 22 and 23)
-
updated link in docs to "No More Secrets" document
-
Dan Sanderson posted a comment on ticket #29
Oh good! I was hoping it was something like that. My intuition was to add the zeroes so that there would be zeroes for >>24 to shift, i.e. so it didn't try to shift a 16-bit value 24 spaces and complain another way. If there's an existing path forward, I'll use it. ty!
-
The problem is not the left shift, but the leading zeroes: Using "$001600" instead of "$1600" marks the value internally with a flag for "the user wants an oversized addressing mode", which then causes the error because "lda #0" cannot be encoded with a 24-bit argument. You can a) remove the superfluous leading zeroes or b) use the command line switch "--ignore-zeroes" to disable this mechanism completely. I'll try to improve the docs for this error message.
-
Left shift by 24 errors on small numbers
-
updated toacme: v0.19 now has support for the "C128 Top-Assembler".
-
Macros as parameters to other macros
-
MEGA65 PLW mnemonic missing?
-
Pass strings in command line arguments
-
Support for \x hex values in strings
-
I implemented it, please re-test. Note that in order to be able to tell 42 and "42" apart, string values must be given in double quotes. But shells like bash remove these, so in bash the given example would have to look like this: acme -D FOO=\"BAR\" file.a
-
the "-D" switch can now assign strings in double quotes (but check your shell's quoting rules!)
-
reworked previous commit, added error checking and test cases
-
added support for \x hex values in strings (thanks to Gurce for the patch, see ticket #28)
-
Thanks for the patch, I'll merge it. It will be included in the 0.98 release.
-
Yes, at the moment the "-D" switch only accepts numbers. Accepting strings is on the TODO list. Implementing this wouldn't be that difficult, but then I'd have to explain shell quoting rules in the docs. ;)
-
Gurce created ticket #28
Support for \x hex values in strings
-
Timo Taipalus created ticket #27
Pass strings in command line arguments
-
updated list of warnings/errors
-
file names can now be specified via string symbols
-
refactored handling of dialects, newest behavior is now always given first
-
Oops, pardon me, checking the mega65 manual, there is now PLW, ok, nevermind then, welcome to cancel the ticket :D
-
Oops, pardon me, checking the mega65 manual, there is now PLW, ok, nevermind then, will cancel the ticket :D
-
MEGA65 PLW mnemonic missing?
-
renamed a function and changed some comments, no change in functionality
-
Olaf Seibert posted a comment on ticket #25
Great, that seems to work and produce the same program files as before. I plan to package this version for pkgsrc.
-
cleaned up previous fix
-
Incompatible change
-
Thanks for reporting this. It looks like I created this bug in r419. It should be fixed in r424, please re-test.
-
added regression test for previous fix
-
fixed bug introduced in rev 419 (see ticket #25, thanks for reporting!)
-
Incompatible change
-
refactored string handling
-
refactored !bin, !fill and !align a bit
-
refactored last commit
-
now ignores BOM at start of source file
-
fixed bug where "!skip" areas at start/end were included in output file
-
fixed bug where a segment warning could cause another segment warning to disappear
-
refactored "segment list" functions
-
moved segment checks to final pass, made v0.98 force --strict-segments
-
throwing of some errors can now be delayed until symbol changes are done
-
small fix so "label" and "label=*" throw the same error if pc undefined
-
a bit of refactoring concerning "unpseudopc"
-
fixed bug in anonymous backward labels
-
tiny refactoring
-
added code so release 0.98 will always use the smallest possible addressing mode
-
added dec() and hex() functions
-
Yes, that is to be expected: "-Wno-old-for" does the same as "--dialect 0.94.8", and that will disable string symbols because they were introduced in release 0.97, much later. The "--dialect" switches are meant for assembling older sources and shouldn't really be used with new projects. Now obviously it would be possible to change the "support older versions" mechanism to enable things like combining "all the features of 0.98" with "use the ancient !for syntax" - but I would really prefer to keep...
-
It seems to error if you assemble with "-Wno-old-for". !to "symboltest.prg", cbm !set mycolor = 7 *= $800 !macro will_be_expanded .color { lda #.color sta $d020 } !macro foo .tmp, .arg { ?(.arg) jmp * } +foo 0, "+will_be_expanded mycolor" rts Error - File acme-symboltest.acme, line 15 (Zone <untitled>): There's more than one character. Error - File acme-symboltest.acme, line 11 (Macro foo): Syntax error. Warning - File acme-symboltest.acme, line 15 (Zone <untitled>): ...called from here.
-
added missing sanity check
-
added code to tell "symbol already defined" (in this pass) and "symbol
-
"symbol twice" error now outputs location of previous definition,
-
refactored "macro twice" code. messages about initial definitions and macro
-
refactored error/warning stuff
-
refactored program counter / outbuffer stuff
-
finally removed the 64 KiB limit, the outbuffer size is now determined at
-
I agree on the syntax. Procedural in my opinion is crucial. Ideally we could have both, of course. I personally have several instances where somewhat complex calculations were needed for a single return value, in various places. This doesn't compress into an oneliner. Anything that does emit data or code should be disallowed, as well as modifying global variables.
-
writing to output buffer now only happens in final pass
-
Is there a use case for evaluating these functions procedurally? It seems like it would simplify things if they were purely functional. Functions can't sensibly emit code or data to the program, so it might help if the definition syntax made that clear. !func myfunc(.arg) = (.arg+10)/2 !byte myfunc(5), myfunc(6) PI = 3.14159 !func circarea(.r) = PI*r*r Sharing calling syntax with the built-in functions (is_number(), etc.) might also be beneficial.
-
added "output pass", to ease adding of new features.
-
rearranged struct, no change in functionality
-
in future versions, program counter in pseudopc blocks no longer silently wraps around to zero
-
Functions
-
Thanks, it seems to do what I was hoping for.
-
renamed struct component, no change in functionality
-
will be fixed in release 0.98 (it's already fixed, but because of backward compatibility, the old behavior is still used by default. you can test the new behavior using "--dialect future")
-
should be fixed now
-
I haven't written the docs for that feature yet, but if you compile ACME from source, you can already test it: Basically ?(SYMBOL) in the source code will be replaced with the contents of SYMBOL. So you'd pass the macro name as a string and then use the syntax given above to insert that string where it is needed. ...but please do not try to insert colons, braces, newlines etc. using this method.
1 >
