Only for 6502, it says.Optiroc wrote:According to the manual ".addr" is an alias for ".word", so if true using it should yield the same overflow error.
Alternative assembler recommendations?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: Alternative assembler recommendations?
Re: Alternative assembler recommendations?
I should be more careful about posting two minutes after being forced out of bed...Nicole wrote:Only for 6502, it says.Optiroc wrote:According to the manual ".addr" is an alias for ".word", so if true using it should yield the same overflow error.
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Alternative assembler recommendations?
64TASS- Fully featured 65816 assembler, generates correct code (duh)
- Ability to include source or binary files inline. I'd like to have human-readable definition files for some of my data.
- Ability to define RAM variables in separate files but not have to manage their starting addresses myself across these files.
- More reliable and readable macros. Additionally, syntax that would make it clear that something is a macro and not a subroutine.
- Handles ROM headers correctly. I don't know what the best practices are.
- Supports a FastROM + HiROM configuration.
- Ability to detect certain programmer mistakes at assemble time would be very nice - specifically calling a subroutine that assumes 16-bit registers when they're currently 8-bit.
- Documentation that isn't a single mile-long text file would be nice.
- Ability to see free space remaining in banks (like WLA already does) would be nice.
It has full 65816 support ( + 6502, 65C02, R65C02,W65C02,65CE02, 64dtv02, 65el02,6510, 4510 - I've asked about Hu6280 which sadly has 4 char opcodes making it harder to support at the moment ). All opcodes are supported, it will determine and work out from.databank and .dpage settings which is the correct addressing mode. It also has manual sizing and auto sizing. I have requested the ability to make auto collapsing REP/SEP statements, especially for macros. With these the assemblers build in optimiser will be able to determine if a REP/SEP is not needed and remove it automatically, so you can set them in Macros and not worry about them wasting space/clocks, Soci(the developer) has agreed and wants it, but it a little down the list at the moment. I have also added a request for special warnings that let me check that the size of a,index in code to catch such errors.
.include <- bring in a file whole
.binclude <- put everything in a file in a block basically lets you pack a file into a namespace
.binary <- brings in binary data, which you can skip bytes and only take a certian number of ie. .binary "myFile.bin",2,100 skips first 2 and brings in 100 bytes
worth noting, you can union a binary file with structures to get you labels for things in the file if you wish
.section can be added to from anywhere, and then instantiated in a location eg.
Code: Select all
*=$00
.dsection zp
then elsewhere you can do
myFun
.section zp
localVar .byte ?
localWord .word ?
.send zo
Code: Select all
Memory range: $0801-$13b3 $0bb3
Section: $0002-$0064 $0063 zp
Section: $0866-$09a4 $013f sBitmapDepack
Memory range: $0866-$09a4 $013f
Section: $09a5-$13b3 $0a0f sDuckBitmapData
Memory range: $09a5-$13b3 $0a0f
Code: Select all
fCalcBitmapAddrChar .function base,x,y
.endf base+(y*320)+(x*8)
No build in SNES header support, so it would need a macro built, the assembler has basically python levels of slicing built in, so a simple data structure could be made which a macro then spits out and converts to data in a human readable format.
With Logical, Base, Full bank support and blocks, sections it would be easy to build a full SNES ROM with it. I've used it to build a full D64 image, SNES should easily be doable. As the assembler supports atari xex and Apple][ formats, if enough of us want a SNES header, soci would probably put it in
64Tass has a variety of warnings, the best one for me is the "Did you forget to add a # for this LDA $40?", it also has page boundary crossing warnings/errors. The Optimiser ( not sure how 65816 compat it is though ) will detect other silly things, like no need to clc here, this jump can be a BNE etc. It also has build in "alias" that will chose the minimal jump you need for a sitation for 65816 the GRA opcode will translate to BRA if within range auto changing to JMP XXXX if needed or JMP XXXXXX if needed. there are GNE,GEQ,GCC... it also covers the standards, code wrap at end of 64K, multi byte char, float compare, sign mismatch on .byte, .word etc
Sadly giant monolith help doc, hyper linked though http://tass64.sourceforge.net/
if one makes each bank a section then it will show the amount used, one could use a .warn "bank " + ^* + " has " + $FFFF-* + " bytes free" to get free though.
The ability to generate a symbol file for debugging purposes.
It has 2 output formats, its own and VICE format. These are basically label name,address, it will append all sub children, local variables, members of structs, blocks, sections etc
Also worth noting it is N pass, currently I use 7 passes in my code, but it scales as needed.
It is very actively maintained and is open source, and is so pure C it will even compile for 68K on an A500.
It is also has full backwards compatibility with TASS/TASM, not that is should be an issue around here
Re: Alternative assembler recommendations?
Wow, I just skimmed through the documentation and have to say that there's certainly much to love about 64tass. I'll have to play around with it a bit for SNES use.
Really, the only thing I like about ca65 is that there's as of yet nothing I could think of that its macro language can't accomplish – but it's more through grunt and white knuckles than elegance you get things done with it a lot of the time. I do like the linker and memory configuration features, though.
Really, the only thing I like about ca65 is that there's as of yet nothing I could think of that its macro language can't accomplish – but it's more through grunt and white knuckles than elegance you get things done with it a lot of the time. I do like the linker and memory configuration features, though.
Re: Alternative assembler recommendations?
Aha! .loword is used as function syntax. Thanks for the help with the linker configuration as well - it looks like I'm set to go ahead and start porting the actual code now!Optiroc wrote:I use the ".loword" directive to get the correct bytes into the vector tables, like so.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
Re: Alternative assembler recommendations?
I have one (do chime in if I'm wrong): its C-like define cannot take more than one parameter, and the normal macro cannot be used for partial things (parameters to instructions), only full things with instructions.Really, the only thing I like about ca65 is that there's as of yet nothing I could think of that its macro language can't accomplish
That means I couldn't make a NTADR_A(x, y) macro, and instead had to make a "NTLINE_A(y) | x" workaround.
Re: Alternative assembler recommendations?
There must have been some other bug going on, as other projects do multi-parameter defines (with the same purpose) just fine.calima wrote:I have one (do chime in if I'm wrong): its C-like define cannot take more than one parameter, and the normal macro cannot be used for partial things (parameters to instructions), only full things with instructions.Really, the only thing I like about ca65 is that there's as of yet nothing I could think of that its macro language can't accomplish
That means I couldn't make a NTADR_A(x, y) macro, and instead had to make a "NTLINE_A(y) | x" workaround.
Re: Alternative assembler recommendations?
Yeah, the ca65 .define macros support multiple arguments just fine, however you must make sure not to add extra parenthesis when you call them:
EDIT: Changed the macro expression to p2+p1 to better illustrate the point. Now it expands to "22)+(11".
Code: Select all
.define foo(p1, p2) p2+p1
.byte foo 11, 22 ; ok
.byte foo(11, 22) ; not ok -- the first argument will be "(11", and then second one is "22)".
Last edited by thefox on Mon May 22, 2017 1:12 pm, edited 2 times in total.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: Alternative assembler recommendations?
Are the docs wrong?
http://cc65.github.io/doc/ca65.html#ss12.7
http://cc65.github.io/doc/ca65.html#ss12.7
I read that as saying .define only supports one parameter.Beware: Since the assembler cannot detect the end of one parameter, only the first token is used. If you don't like that, use classic macros instead:
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Alternative assembler recommendations?
They definitely support multiple parameters (e.g. I have PPU tile address macros that take X,Y parameters). I'm very confused as to what that statement is supposed to mean.calima wrote:Are the docs wrong?
http://cc65.github.io/doc/ca65.html#ss12.7I read that as saying .define only supports one parameter.Beware: Since the assembler cannot detect the end of one parameter, only the first token is used. If you don't like that, use classic macros instead:
Re: Alternative assembler recommendations?
thefox, your example confuses me because this also works without problem. (note to self: archive links)
Re: Alternative assembler recommendations?
I'm not sure what the docs are trying to say there, but the actual documentation for .define is clear cut: http://cc65.github.io/doc/ca65.html#.DEFINEcalima wrote:Are the docs wrong?
http://cc65.github.io/doc/ca65.html#ss12.7I read that as saying .define only supports one parameter.Beware: Since the assembler cannot detect the end of one parameter, only the first token is used. If you don't like that, use classic macros instead:
It happens to work by coincidence. NTXY is defined as .define NTXY(xc,yc) ((xc)|((yc)<<5)). Then, NTXY(0, 23) expands to (((0)|((23))<<5)), which happens to have nicely balanced parenthesis.nicklausw wrote:thefox, your example confuses me because this also works without problem. (note to self: archive links)
But you're right, my example was bad, because the "not OK" case compiled even though it's ill-advised. I swapped the parameters around to better illustrate the point.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Alternative assembler recommendations?
It happens to compile without error because of the balanced parentheses, but beyond that it happens to work because because "xc" is 0.thefox wrote:It happens to work by coincidence. NTXY is defined as .define NTXY(xc,yc) ((xc)|((yc)<<5)). Then, NTXY(0, 23) expands to (((0)|((23))<<5)), which happens to have nicely balanced parenthesis.nicklausw wrote:thefox, your example confuses me because this also works without problem. (note to self: archive links)
But you're right, my example was bad, because the "not OK" case compiled even though it's ill-advised. I swapped the parameters around to better illustrate the point.
In general, parentheses + defines/macros in ca65 are a bit of a landmine, unfortunately. (See also: (indirect), Y addressing.)
I find it very strange/interesting that it obviously knows that '(' is not part of the name of the define, too, so that character has a special "new token" property to it.
Maybe we should propose some changes to the documentation just to point out how weird and error prone parentheses are when used with these features?
Re: Alternative assembler recommendations?
The confusing thing is that parentheses are used when defining but not when invoking:
Code: Select all
.define foo(a, b, c) ; ...
; invoke
foo 0, 1, 2
Re: Alternative assembler recommendations?
The problem is that you aren't supposed to put parentheses around the argument list when invoking a macro (either a multiline .macro or a one-line .define). Assembler macros aren't C preprocessor macros. If you put parentheses around the argument list, the opening parenthesis gets interpreted as part of the first argument and the closing parenthesis as part of the last argument, which is almost certainly not what you want to happen.rainwarrior wrote:In general, parentheses + defines/macros in ca65 are a bit of a landmine, unfortunately. (See also: (indirect), Y addressing.)
If you want to pass an argument that contains a separator character like a comma, you put curly braces around that individual argument.
There's a clear example of this use of curly braces in the documentation (which, admittedly, is generally poorly written and unclear), under "Parametrized macros".
The definition of a one-line macro requires parentheses around the parameter list, so that the parser knows where the list of parameters ends and where the actual definition (what to expand the macro to) begins.I find it very strange/interesting that it obviously knows that '(' is not part of the name of the define, too, so that character has a special "new token" property to it.
I have no idea either what the sentence "Since the assembler cannot detect the end of one parameter, only the first token is used" is supposed to mean.