The tools suck - NESdev BBS

by koitsu on 2012-07-29 (#97270)

It sounds like the general complaint then is with the tools (assemblers) used, and not so much with the architecture.

I haven't messed around with WLA DX (I've downloaded it but it has been many years since I've tinkered with it), and the whole CA65/CC65 suite I avoid like the plague (personal choice, not worth debating/discussing please). I tend to stick to Norman Yen's x816 DOS-based assembler, although people end up trying to do crazy things with it like assemble source files which are >1MByte in size (not enough XMS memory for that; it doesn't use EMS to my knowledge), blah blah. There are ways around that too.

Anyway, yep, the tools suck. I'm hearing you on FM. But there are workarounds for all of them to accomplish what you need, and that's pretty much what you're going to have to do.

by byuu on 2012-07-29 (#97271)

> BASS is harder than XKAS as it is not in the original syntax.

Different, not harder. You can even make it the same by dynamically adding instructions to the table file, or specifying your own table. I'll probably allow for the "lda.b" style syntax with v08 out of the box. There's really just no "nice" way of handling lda 0 being ($00, $0000, $000000) or lda #0 being (#$00 or #$0000). You either fuck up vertical alignment (.b, .w, .l) or you harm readability (#<0, #>0)

The only real limitation is that bass is a patching assembler, and not a linker. It has always been intended to aid in translating JRPGs that you don't have the source to.
This makes it hard to make full-fledged games, because you don't get nice exports between ASM files. So to do that, you have to make a shared header for globals, and a calling system for functions between objects.

Or you can do what I do, and just invoke bass one time, and have that file incsrc all the others. Along with namespace support, bass has no problems assembling 10MB+ of ASM code in under a second.

WLA can link, but the mapping red tape compared to ... everything else, ever ... is far greater than the difference between MASM and YASM.

> I tend to stick to Norman Yen's x816 DOS-based assembler

Nobody ever moves from their original software. I am just as guilty, I use Hex Workshop v2.54 and Winamp 2. At least you aren't using TRASM :D

SNES assemblers in particular have tended to click with interesting cliques.

Demo scene: x816
Homebrew scene: WLA-DX
ROM hacking scene: xkas v06
blargg alone: CA65
Anyone who has written their own assembler: their own assembler (for me, this is bass); userbase size: 1

by Hamtaro126 on 2012-07-29 (#97273)

X816 has no use anymore for me, Even in dosbox! Because Dos is practically not used anymore,

About BASS: Comment Syntax Formatting also the problem, Converting practically might overwrite some ASM that can use the '';'' symbol when you convert to the C-based ''//'' and ''/* */'' formats,

Plus defines and macros use a wierder format, I perfer this, for example:

MACRO value1, value2
LDA #value1
STA store1
LDA #value2
STA store2
ENDMACRO ; or ENDM as an alias

EDIT: Seperate Assembler-related problems to another post if needed.

by koitsu on 2012-07-29 (#97274)

Tepples, did you do this? Split this thread off from the other? The Subject made me RL LOL. You bastard you!

by byuu on 2012-07-30 (#97294)

Quote:
Converting practically might overwrite some ASM that can use the '';'' symbol

Replace ";" with "//"
Replace " : " with "; "
Done.

Quote:
Plus defines and macros use a wierder format, I perfer this, for example:

MACRO (you forgot name) value1, value2
LDA #value1

Me too, but it's far more limited.

Let's say you wanted a macro that loads #$xx00.

lda #$value00 //whoops, value00 not found
lda #${value}00 //hooray, works fine

Let's say you have a macro inside a macro, so you want to build a label from two values.

lda value1value2 //whoops, value1value2 not found
lda x{value1}{value2}y //hooray, works fine

What happens if you use a simple value name? Like say:

Code:
macro add x, y
lda x; clc; adc y; sta $00,x //whoops, the x in sta $00,x gets replaced too
lda {x}; clc; adc {y}; sta $00,x //works fine
endmacro

Now imagine that at the global scope?
define x $00 //prepare for hell

What if I wanted a macro that turns another macro into a function?
(This is a great way to have a huge library of functions and only pay for what you use in ROM space.)

Code:
macro import name, arg1, arg2
{name}:; {{name} {arg1}, {arg2}}; rts
endmacro

macro importas alias, name, arg1, arg2
{alias}:; {{name} {arg1}, {arg2}}; rts
endmacro

{import add, $10, $20}
{importas add2, add, $30, $40}
jsr add
jsr add2

How do you handle inline arguments?
lda #square(16) //wait, is () part of an expression?
lda #{square 16} //fully unambiguous

How do you tell the difference between a label and define/macro quickly?

And now I can't have labels that have the same name as defines or macros. The two are very different. A label can be defined after it is used (two pass assembly), a define must be declared first, and can be redeclared later on. Labels are value substitions (no formatting: lda label == lda 123); defines/macros are string substitutions (formatting: lda {defiine} = lda $0123)

Bumpers on the left *and* right allow you a lot more control than no bumpers at all. Since macros are meant to generate code, they should have them. Since labels are meant to reference functions, they can omit them.