Transition from WLA

[Khaz]

I wanted to ask some things and I can't find an appropriate thread for it so here's one. I hate WLA. I can't find any real documentation of its syntax and it gives me problems trying to get the right opcode in constantly. All I know about it I've learned by example.

I hear everyone saying to switch to ca65. From what I've seen it seems radically different from WLA. My project at this point is getting massive, and the thought of rewriting the entire thing just to transfer to a new assembler is painful. I also have a bit of a deadline coming up where I'd like to have something to show for all my work. It took me a good month just to understand WLA to begin with; if it takes another month to learn ca65 then I'm screwed and better off patching around WLA's stupidity for the time being.

Can anyone comment on how difficult it is to transfer code between the two, and exactly what is required to do so? Is there official documentation on ca65 so that I can just look up my answers and never deal with this guessing ever again? Does it have annoying bugs too? Is there anything better than ca65?

How come I can't make WLA use opcode 9D: STA addr,X (Absolute Indexed,X), with A in 8-bit mode? It defaults to direct page, x.

[93143]

It seems ca65 has some trouble with direct page. It only knows about zero page, so you can't move it. I haven't gotten around to trying ca65 yet, so I don't know if this is a hard limitation or a convenience issue. (I mean, it can't be a hard hard limitation, as long as you can Define Byte, but that's kinda...)

And I know nothing whatever about bass, except that it probably makes a lot more sense to byuu than either WLA DX or ca65.

How come I can't make WLA use opcode 9D: STA addr,X (Absolute Indexed,X), with A in 8-bit mode? It defaults to direct page, x.

How big is the operand? WLA tends to assume a value is as small as it can be, but you can force it to use a certain addressing mode by appending .b, .w, or .l to the opcode to specify byte, word, or long (using the suffix on the operand itself doesn't always work).

We did recently run across a weird bug where it was using 8-bit addressing for addresses that didn't fit into 8-bit numbers, which probably calls for the same fix...

[koitsu]

1. The documentation for WLA DX is here. It is badly organised, and as I've ranted about here already, is very unclear in many regards: https://github.com/vhelin/wla-dx/blob/master/README

2. I would suggest given your "deadlines" that you continue to stick to WLA DX. Use ca65 for your next project. Don't get hung up on creating blockers (the need to move to ca65) right now, especially if time is important. If you want to migrate to ca65 for this project later, i.e. after it's release, then wait until after its release. Stay focused on what you're already doing. :-)

3. I can comment on moving from WLA DX to ca65 because I did so for Espozo and his SNES project recently. I mention this because if I remember right *your* project is SNES, and that matters. His very small project took me probably 3-4 full hours. Most of that is because I lacked familiarity with ca65 (huge thanks to Tepples and his ca65 LoROM template), but some of it was also because ca65 has "mostly good" support for the 65816 but not entirely (its concept of direct page is not very good; ca65 is very much "6502-centric").

You aren't being very forthcoming with WLA DX features you're using. For example, WLA DX has the abiliyt to do "overwrap maps" or something, where you can literally use WLA DX to patch/replace/inject code into existing ROM files. ca65 does not have this. This is just one of many things.

WLA DX and ca65 use substantially incompatible pseudo-ops (assembler directives), and addressing mode directives (for things like getting the lower 16-bit portion of an address, vs. getting bank, etc.) differ greatly as well.

ca65 has "complexities" understanding direct page fully -- I've complained about this in other recent threads several times and am getting tired of digging up the posts -- but my most recent feedback/view of this is here: viewtopic.php?p=141784#p141784 -- I'm thus of the opinion while its memory/segment stuff doesn't have full comprehension of direct page, the actual assembly it generates is okay.

The one huge (and I mean HUGE HUGE HUGE) advantage ca65 has over WLA DX is that it's listing generation mode *actually works*, while WLA DX acts like a complete moron when you use .include (or is it .incsrc) within an assembly file -- the listing generation contains interspersed output (and this is still the case on the most recent WLA DX github build too). I STRONGLY advocate using listing files, because they help you diagnose issues in your code; "I expected the assembler to do this, but it's doing this instead".

And finally, there are known, very scary bugs in WLA DX.

4. WLA DX is trying to be "extra smart" about optimising. See the WLA DX documentation, section 14.5 ("65816"), and read it in full. If you need additional insights, see the .8BIT and .16BIT directives. .ACCU and .INDEX are also worth looking at. Just be aware of what it is you're doing with those directives or size modifiers (e.g. .w) if you use them -- use assembly listings (oh wait those are crap on WLA DX if you use include ;-) ) to determine if it's doing what you want.

[Khaz]

Okay, thank you 93143, the .w fixed it. I thought I tried that already, maybe I didn't hit save or something... I guess I will be sticking with WLA for the time being.

The one huge (and I mean HUGE HUGE HUGE) advantage ca65 has over WLA DX is that it's listing generation mode *actually works*, while WLA DX acts like a complete moron when you use .include (or is it .incsrc) within an assembly file -- the listing generation contains interspersed output (and this is still the case on the most recent WLA DX github build too). I STRONGLY advocate using listing files, because they help you diagnose issues in your code; "I expected the assembler to do this, but it's doing this instead".

Can you explain a bit more what you mean by listing generation/files? This is new to me. So far the only way I've really been directly examining my code is by running it and reading a trace log.

As for the very scary bugs, I read that thread over several times and as far as I can tell it's not so much a "bug" as that WLA required the .w to specify which operation? (It's definitely still an error-likely design choice...)

[93143]

No, that was the one where it was apparently taking a value of $1808 and deciding it was fine to just use one byte to represent it. Pretty egregious on the face of it...

[Khaz]

Ah, I see what you mean. I, uh, guess I just got used to that behaviour...

[koitsu]

Can you explain a bit more what you mean by listing generation/files? This is new to me. So far the only way I've really been directly examining my code is by running it and reading a trace log.

Full details (you need to slowly read my entire post): viewtopic.php?p=139495#p139495

Short version: if any of your programs use .include, then listing file generation will be completely bogus, with interspersed hex bytes into the "main file" that actually correlate with code from the included files. I can understand from a programming perspective how this could happen (it indicates extremely poor design choices) -- and yes it can be fixed but it isn't my problem to fix. This, compounded with other bugs, just make me dismiss the entire assembler. I like ca65 a lot more now that I've gotten more used to it, but its memory/segment template stuff (while extremely useful) still makes me shake my head a bit. (What can I say, I like KISS/bare-bones stuff)

That bug psychopathicteen found is an absolute total disgrace. There's nothing to "get used to" -- it's a downright bug and I feel sorry for anyone getting bit by it.

[tepples]

It seems ca65 has some trouble with direct page. It only knows about zero page, so you can't move it.

I'm pretty sure you can move direct page, as my init code does just that for writes to the PPU MMIO ports at $002100-$00213F, and I verified its correctness in NO$SNS's debugger. You just have to subtract the value in D from each address you use with a direct page addressing mode, either with subtraction or with the < (low 8 bits) operator.

WLA DX has the abiliyt to do "overwrap maps" or something, where you can literally use WLA DX to patch/replace/inject code into existing ROM files. ca65 does not have this.

There's no explicit for this "overwrap" as you call it in ca65, but I've got it to work in my UNROM hack of ccovell's Solar Wars.

[Khaz]

Hm. Is there a way to bypass this garbage data problem, while still using WLA? Something other than .INCLUDE? (Other than just put all my code in one text file)

I'm also not sure how you get a listing file in the first place. The wla setup I'm using just creates then deletes a .prj and an .obj file, neither of which seems very legible.

[Drew Sebastino]

I'm also not sure how you get a listing file in the first place.

ca65 outputs them whenever you assemble a file. I don't remember anyone talking about listing files on WLA. Basically from what I've seen (and experienced) ca65 > WLA.

[koitsu]

Hm. Is there a way to bypass this garbage data problem, while still using WLA? Something other than .INCLUDE? (Other than just put all my code in one text file)

I'm also not sure how you get a listing file in the first place. The wla setup I'm using just creates then deletes a .prj and an .obj file, neither of which seems very legible.

Make sure you don't .include any files that actually contain code (e.g. a file filled with equates should be safe), and assemble all files with actual code in them individually (i.e. a separate call to wla-65816.exe for each file -- don't forget the -i flag so that listing file generation can be done by wlalink.exe later). This should (if the person writing the build script did it right/specified the right arguments to wla-65816.exe) generate a whole series of .o files. These should be linked together with wlalink.exe (don't forget the -i flag) and through use of its "link file" of what objects/libraries/etc. it should refer to (see docs, section 10, "Linking", for all of this -- you must read the entire section, not skim it).

Again: nobody realises WLA DX can do any of this because the docs are so badly formatted and disorganised.

Earlier when you said "So far the only way I've really been directly examining my code is by running it and reading a trace log", I took that to mean some kind of "log" that WLA DX was generating, but now I realise you're probably talking about a SNES9x trace log. That's a fine approach if you enjoy sifting through enormous log files (I deal with it when doing romhacking, albeit painfully). I prefer to use an emulator to see what the behaviour is, use its debugger to figure out what might be going on, and if something looks totally amiss with the code that was run, start looking at the generated listing files of the assembler to find out what it (or I) did wrong.

I cannot stress enough the importance of assembly listing generation especially during development, or when a person is not familiar with all the quirks/behaviours of their assembler (or when learning (or migrating to) another assembler). When something anomalous begins happening in your work, you can go immediately to the assembly listing and say "...there! Damn, that should have been a 24-bit load, not 16-bit" or "Gah, I obviously meant rep #$20 not rep #$10".

ca65 (not ld65 (linker)) will output listing files when using the -l (dash-lowercase-ELL) argument with a specified filename, e.g. ca65.exe -l main.lst main.asm -o main.obj will generate an assembly listing (main.lst) and a resulting object file (main.obj) for use with ld65 (linker) later.

@Espozo -- what are you talking about, re: "I don't remember anyone talking about listing files on WLA" -- that's the entire reason I got you off WLA DX and over to ca65, and I even linked in my previous post here in this thread the post in *your* thread about that problem in WLA DX. How can you say you don't remember anyone talking about listing files when they were what I talked about for a page or more?

[Drew Sebastino]

@Espozo -- what are you talking about, re: "I don't remember anyone talking about listing files on WLA" -- that's the entire reason I got you off WLA DX and over to ca65, and I even linked in my previous post here in this thread the post in *your* thread about that problem in WLA DX. How can you say you don't remember anyone talking about listing files when they were what I talked about for a page or more?

What I meant to say is that WLA doesn't output them.

[koitsu]

What I meant to say is that WLA doesn't output them.

It doesn't by default, but it does if you give it the arguments I just described. ca65 doesn't output listing files by default either, unless you give it the arguments I also just described. *confused look*

[Drew Sebastino]

I'm guessing the arguments are in build.bat? I'm really not thinking very well at the moment.

[koitsu]

For your project: where else does ca65.exe or ld65.exe get run?! Of course. :P You really need to get familiar with that script. It's actually legible and followable since I rewrote it for you. DOS batch is never pretty, but what I wrote you is pretty clean. But I'm not going to get into discussing that here because it's unrelated to what this thread is about. (There have been _WAY_ too many threads in the past few weeks which have derailed)