Being totally sick of wla-dx and its "features" aka bugs I am wondering if anyone has got a clue if minus, the author of the x816 assembler is still around.I would love to contact him and ask him if he'd be willing to provide me with the sources of his assembler- As I am runnnig linux the dos binaries of his assembler are not very usable.. ;]

So..anyone happens to know about him ?

greets,
gilligan

PS:guess I should sign up here.. ;) btw..what about a #snesdev channel..anyone interested?

> Being totally sick of wla-dx and its "features" aka bugs ...

I currently use wla-dx. Can you tell me what bugs you've run across so I can know what to look out for?

Thanks.

Have you tried CA65 (http://www.cc65.org/) instead?

First of all I dont like the whole idea of a multi-platform assembler like this.
What you end up with is more complex syntax to do very basic things.

wla-dx also has this "sophisticated" rom bank/slot/memorymap system where you can specify the desired layout. I would gladly trade this for simply having to use a .lorom
and or .hirom statement plus .org directives. Thats everything you need when using a snes dedicated assembler.

Problems i've come across are things like..
SNESNATIVEVECTOR is a directive to designate the interrupt vector addressses in native mode. Unfortunately you can't specify labels as it doesnt resolve them. At least not when they are within a SECTION(another sophisticated feature). When you place a label outside of a SECTION the address it is referenced to by the assembler is utter bogus.

At some other point I used something like .dw someLabel
which unfortunately returned the address relative to the beginning of the current bank = $8000. Pretty useless.

Finally in the most recent version the lda.w / sta.l syntax was exchanged with lda $123.w and #$23.b etc. Breaking convetions with any snes assembler out there and esp. with my already written routines..

I'm in contact with the author and hope to get this stuff solved soon.
Nevertheless I wish I had x816 back..

.lorom
nmi = vblank_routine
reset = main
.org $8000

main:
.
.
.

;]

greets,
gilligan

Have you checked out SNEScom? It's an open-source SNES assembler that seems to be almost identical to x816 in syntax, the only differences seem to be that the ".8BIT" directives and such have changed their names.

http://bisqwit.iki.fi/source/snescom.html

Unfortunately, there are no binary distributions of it and I have not been able to compile it for Windows with Dev-CPP nor by cross-compiling on Linux. The sad truth about "multi-platform" programs is that the multi-platform part often only applies to those who are good enough at fiddling around with weird compiler settings. =/

If anyone has successfully compiled a win32 build of the latest version of SNEScom, I'd really like to have it.

I've used x816 for all my NES stuff. Recently though, I've been attempting to switch to WLA-DX. While it has some really nifty features (gotta love those sine table directives), there are some very annoying things that have kept me from switching:

* The complex memory model. While I do see the benefits of a dynamic linker, you don't need it in 99% of all cases and more often than not, you want your code to assemble at pre-determined address. So I would wish there was an easy way to make it default to a simple memory model that would easily let you assemble most programs with it. As there were no examples for how to write 6502 ROMs it took me several hours to just get a small program compiled with it. And I still have lots of unanswered questions about how to do different stuff, such as relocatable code and other misc. things.

* The DEF directives used for declaring variables/constants. In all 6502 assemblers, the equality operator is the standard way of doing this so it's more or less a standard that WLA-DX just ignores. Again, this makes it hard to just try it out on existing source code.

* The lack of the asterisk sign for setting/obtaining the current assembler address. This is a syntax that goes back to the old C-64 days and besides letting you use "* = $8000" instead of assembler-specific ".ORG" directives, it's also really handy for building small string tables in this way:

StringTable
StringGetReady = * - StringTable
.db "Get Ready!",0
StringGameOver = * - StringTable
.db "GAME OVER",0

While you can achieve the same thing by declaring dummy labels (and I have done this at times), that seems like an unnecessary work-around.

// Bananmos

you need gcc and mingw to compile this http://programming.ccp14.ac.uk/mingw32/~janjaap/mingw32/
have you tried it with those?

Yes. Dev-CPP equals mingw32. (+ an MSVC-like IDE) It wouldn't even get started compiling with that one. Cross-compiling on Linux got me farther, but still not across the finish line...

// Bananmos

Have you tried Cygwin, which supports more of the POSIX stuff that difficult UNIX apps need to compile?

If you have any questions about WLA DX, just ask. Several people here use it, so we can probably answer most questions.

> * The DEF directives used for declaring variables/constants.

It's not missing.
To define a constant like NUMBER_OF_LIVES, use

.DEFINE NUMBER_OF_LIVES 3

>* The lack of the asterisk sign for setting/obtaining the current assembler address.

Well, he doesn't use a nice symbol for it, but the feature is there. Use "CADDR" to represent the current address.


As for the memory map thing. I agree, it is a bit annoying to set up when you're first learning. But once you decide on a memory map you like... just make a file of it and all you need to do to your sources is .include "mem_map.inc" or something. There have been times where it was convenient to be able to tweak the memory map for certain reasons. But usually I just reuse the same mem_map.inc file.

I saw some people mentioning about the SNES vectors and whatever.
Someone other than Ville added some support for that. I don't really like how it was implemented since other ROM info is usually supplied anyways. Instead I have a standard "ROM info" piece I include and just change the values real quick when necessary. This is just a personal preference I guess, but this way starting a new file is quick and easy, and I can control any ROM info parameter I want.

If someone hasn't mentioned it yet, I like his .ENUM feature as I can quickly add and remove variables and still control where they are put (for instance into the 8kB "common" WRAM ... or into the larger/"out of program bank" 128kB WRAM).

I also love his macros. They can do practically anything.
I use them fairly extensively for including data into my programs, because then I only need to write one line to include a new file ... and the recorded "total number" as well as all my tables of pointers are automatically updated (and sometimes other miscellaneous info for each file). It also nice when some file types need info for other programs (music instruements for example), but don't need the info for the SNES program ... since I'm already using macros for including the files, I can have the macro strip off the file info I don't want included into the ROM. All in macros just a few lines long.

------

Also, I definitely like having one consistent assembler syntax for all the SNES console's CPUs. I found it annoying before switching back and forth between one assembler with such and such features for the 65816 and then another with a different set of features for the SPC700.

However, whatever assembler you feel fits your needs the best is obviously the one to work with ... each person has their own tastes. Before starting a large project I'd DEFINITELY suggest looking around and seeing all the assemblers out there. There are quite a few to choose from.

I reread this and I think I'm misunderstanding something here and was hoping you could clarify (maybe I'm missing an interesting way to code things?).

> This is a syntax that goes back to the old C-64 days and besides letting you
> use "* = $8000" instead of assembler-specific ".ORG" directives

So you want the line
* = $8000
to set the current address to $8000? Instead of
.ORGA $8000
(or .ORG $0000, or .ORG $8000 or whatever depending on what you are trying to do).
So is it just a preference of notation then? Or am I missing a feature?
I'm not sure what you mean by assembler specific since almost all assembler's support the .org feature (that I've used anyway). Although WLA does give two implementation of it, which seems weird at first :) ... just Ville's way of trying to please two coding styles at once.

(While it may seem silly to have the .ORG referring to the offset into the code bank instead of the actual address ... it does make a fair amount of sense. It allows you to say "start at the beginning of the code region" and know that you will regardless of the memory map you choose. You usually only need to refer to labels, not direct addresses. So it shouldn't affect your coding. But when you go to reuse some routines from HiROM or LoROM mappings, it's nice because you don't have to go move all your .ORG's ... for those that really detest this, there's always .ORGA which lets you specify the actual address.)

> it's also really handy for building small string tables in this way:
>
> StringTable
> StringGetReady = * - StringTable
> .db "Get Ready!",0
> StringGameOver = * - StringTable
> .db "GAME OVER",0
>
>While you can achieve the same thing by declaring dummy labels (and I have
>done this at times), that seems like an unnecessary work-around.

Those ARE dummy labels aren't they? And what is the reason for using the "current address" notation here? I'm afraid I'm misunderstanding again (sorry). I would write it like this:


StringTable
StringGetReady
.db "Get Ready!",0
StringGameOver
.db "GAME OVER",0

then later on, when I need to print the string or whatever, I just do something like
ldx #StringGameOver
jsl PrintString

---------

Thanks for pointing out that assembler. I hadn't noticed it before. I think I'll go check it out. :)

Regarding the asteriks as symbol for current address and CADDR as its equivalent..
* as symbol in that use prolly comes from the TASM on c64. Given the short length of lines on the breadbin screen the asteriks comes in handy. It's also practical for smth like..

lda $xxxx
cmp #$yy
bne *-5

(same works in WLA w/o the * tho [bne -5] )

That's imho nicer than always specifying stupid meaningless label names and of course you save the time of typing stupid label names.This is the point where it gets obvious that CADDR is ugly : its too long ;]

As for the "oversophistication" of WLA - I've been in contact with the author, ville, a nice guy. I suggested to gather macro include files with dedicated memory setups for various platforms. No more dealing with ROMBANK/SLOT etc.. just some simple macros like LOROM / BANKS 4 / RESET main_entry / whatever..

That should make life easier for first time users who dont want to spend hours to figure out how to correctly set up the mapping for [xyz] to write some hello world ROM..

PS: neviksti..did you get my email concerning the pictools? =)
PPS: #snesdev - am I the only one fancying this? =)

gilligan/TRIAD

neviksti:
> Those ARE dummy labels aren't they? And what is the reason for using the
> "current address" notation here? I'm afraid I'm misunderstanding again
> (sorry). I would write it like this:
>
>
> StringTable
> StringGetReady
> .db "Get Ready!",0
> StringGameOver
> .db "GAME OVER",0
>
> then later on, when I need to print the string or whatever, I just do
> something like
> ldx #StringGameOver
> jsl PrintString

Well, in that example I was considering 6502 code and not 65C816 code. So StringGetReady and StringGameOver are in fact 8-bit pointers that are offsets from the address StringTable. Of course, this limits the string table to 256 bytes which is only satisfactory for programs with a handful of strings. But the explicit string table was just an easy-to-understand example, and there are other uses for 8-bit relative offsets.

Not that you cannot live with declaring an extra dummy label to use in place of the '*', but it's kind of annoying. So thanks for mentioning CADDR.

I would still prefer it if it actually used the good old syntax to keep compability with other assemblers though. And that applies even more to the lack of "=" for assigning your variables to memory locations.

But it's nice to know there are people here who can help me out with understanding WLA-DX's quirks. I'm definitely going to give it another try some time. Maybe I should even consider it for the tile-based 2D-console we are making in a VHDL course in school, where we are actually going to use a 65C816. But x816/SNEScom do have the advantage of not requring me to learn anything new. :)

I think the biggest con of WLA-DX is actually that the documentation is kind of lacking, especially when it comes to code examples. I hope someone will have time to write a tutorial on how to actually write 6502 and 65C816 programs with it, demonstrating how to use some of its better features.

Btw, what is the point of "WLA-6510"'s existence? Is it just based on the misconception that the unofficial opcodes of the 6502 are only present on the 6510 rather than all NMOS-based 6502 CPUs? If so, then someone should tell Ville to ditch the "6510 assembler" and add its extra opcodes to the 6502 assembler instead. :)

gilligan:
> * as symbol in that use prolly comes from the TASM on c64. Given the short
> length of lines on the breadbin screen the asteriks comes in handy. It's also
> practical for smth like..
>
> lda $xxxx
> cmp #$yy
> bne *-5

I have to totally disagree here though. Writing code this way is both confusing and very error-prone since you have to manually count the number of bytes these opcodes take, and change the relative offset if you add or comment out operands. Just as x816, WLA-DX supports unnamed labels with the "+" and "-" signs which emiliminates any need for the above method. That's an assembler feature I cannot live without btw, and the fact that WLA-DX also supports it is the reason I was considering it as a replacement for x816 to begin with. =)

// Bananmos

Bananamos,

it doesnt take long to read instruction code length fluently. For such tiny loops for
which it is supposed to be used its simple anyway..

Concerning the lack of example code..
Better examples etc are on its way. I will contribute some snes "hello world" with
macros to easily setup ROM mapping etc. Everyone's invited to supply such examples
and macros for ROM mappnigs for other systems. NES/PCE/gb/sms/..



gilligan/TRIAD

> it doesnt take long to read instruction code length fluently. For such tiny
> loops for which it is supposed to be used its simple anyway..

I still disagree. Even if the loop is tiny, many of us (me at least) are pretty bad at remembering numbers and counting by hand. And even if you get it right 99.9% of the time, the few times you don't are likely to give you debugging headaches. Additionally this kind of kills a lot of the point of using an assembler rather than just using a hex editor.

But hey, whatever suits you is fine.

Here's an eample of how I use unnamed labels though:

TakeAwayLogoInnerLoop
ldx #0
sec
--
lda #$0F
adc ScanLineY,X
tay
lda #$00
STA ScanLineY,X

sta $2006
sty $2005
sta $2005
lda R2006BTabY,Y
sta $2006

lda _666 ;3
adc #113 ;2
bcc + ;3/2
+ sta _666 ;3 10.555...


lda LinePosHi,X
sec
SBC LineSpeedHi,X


bcS +

NOP
NOP
nop
nop

NOP
NOP


BCC ++
+

STA LinePosHi,X
tay
txa
sta ScanLineY,Y
++
cpx LineLimitHi
bMI +

ldy #4
-
dey
bne -

beq ++
+
LDA LineSpeedLo,X
ADC LineAccelHi ; #55
sta LineSpeedLo,X
lda LineSpeedHi,X
adc #0
sta LineSpeedHi,X
++
inx
bpl --

rts

Using '*' and counting opcode sizes by hand would be masochism in this case. =)

// Bananmos

>I think the biggest con of WLA-DX is actually that the documentation is kind
>of lacking, especially when it comes to code examples. I hope someone will
>have time to write a tutorial on how to actually write 6502 and 65C816
>programs with it, demonstrating how to use some of its better features.

Well, my "SNES StarterKit" uses WLA-DX, but I wouldn't consider it a tutorial.
It includes a HiROM and LoROM example, and uses some macro features. I haven't updated it in quite awhile though ... so there isn't any demonstration of newer WLA features. Also, I don't include any sound code, so there are no SPC700 examples.

I haven't done any work on the NES, but with all those different mappers, I'd think setting up different rom regions in WLA's memory map could come in handy if used correctly. But, I don't really know much about the NES ... and I'm not sure where to obtain any NES examples in WLA-DX either. So I can't really be of much help here. Sorry :(

Well as you said : "whatever suits you is fine"
But imho the use of + and ++ is *dead ugly* and unreadable ;)

especially when you dont write it in an extra line.
And finally, "+" is pretty much "hard wired" to "addition operation" in my brain..

gilligan/TRIAD

Banamos,
.DEF is now available in wla dx 9.1a - get it from the website ;]

gilligan/TRIAD

> Banamos,
> .DEF is now available in wla dx 9.1a - get it from the website ;]

Hehe, I think you all misunderstood my point. I was complaining about the lack of the EQUALITY operator (i.e. "MyVariable = $xx") for defining your memory usage rather than the .DEFINE operator. Even though my memory was lacking and I mistankenly said ".DEF" instead of ".DEFINE", my complaint was about not being able to use "=" in place of .DEFINE, not about wishing for another ".DEFINE" directive that's four letters shorter! :)

But like I said, I could live without it. I'm considering taking up WLA-DX again for our VHDL console project in school, but I'm still worried about wether I'll eventually get stuck with not being able to do certain "ugly" things because of the sophisticated memory model... =/

// Bananmos

Ah well.. .DEF is in now anyway. doesn't hurt anyone I guess ;)

As for your project- I doubt that WLA will limit you in any way.If you indeed might end up in a dead end I am sure you could get support from the author who is really very helpful.

gilligan/TRIAD

> Well, my "SNES StarterKit" uses WLA-DX, but I wouldn't consider it a tutorial.
> It includes a HiROM and LoROM example, and uses some macro features. I haven't
> updated it in quite awhile though ... so there isn't any demonstration of newer
> WLA features. Also, I don't include any sound code, so there are no SPC700
> examples.

It's quite good though IMO. After taking a quick look at it, I think I understand the syntax better, even though I'm still not sure about sections, banks and slots and their various flags.

Btw, how do you go about writing relocatable code in WLA-DX? I often use this on the NES to copy code from ROM to zero-page RAM which saves a lot of cycles in inner loops as you can replace "lda $xx" with "lda #$xx" and such. And that should be even more useful on the 65C816 where you can relocate the zero-page to anywhere within the first memory bank.

// Bananmos

Will the "hello world" cover only the 65c816 or the SPC700 as well?

>Btw, how do you go about writing relocatable code in WLA-DX?

I've written relocatable code with WLA-DX before, and it was fairly straight forward. However, I never needed to add "self-modifying code" to this though (and that seems to be where the trouble arises?).

Hmm... let me think for a bit.

I guess I'd do it something like this:
Use two lables + one definition + one label for each "modified code area"

.DEFINE CodeLocationInRAM

relocate_start:
... blah,blah...
modify_opcode:
lda #$00
... blah
relocate_end:


Then you just have a routine to copy the data from relocate_start to relocate_end into RAM starting at CodeLocationInRAM. Such as:

ldx #$0000
-
lda relocate_start,x
sta CodeLocationInRAM,x
inx
cpx relocate_end
bne -

Whenever you need to modify the code, you can refer to that location as:

sta CodeLocationInRAM+(modify_opcode+1)-relocate_start

That looks kind of messy, but isn't too hard to read.
This method would allow you to change the code or even it's location in RAM quickly without having to worry about it's consequences on the modifying code, or the code that copies the section into RAM, etc.

Obviously the idea behind this method isn't WLA specific, so it doesn't do anything special really.

I don't know... there's probably a better way to do that.
How do you currently do it?

That seems kinda strange. With self-modifying code I've written with CA65, it's kind-of the reverse of that. The loading code used the more complex expressions, while modifying it in RAM is simpler.

Like this (also ditching the compare, since that's OK here):

ldx #relocate_end-relocate_start
-
lda relocate_start-1,x
sta CodeLocationInRAM-1,x
dex
bne -

Then to modify it, just do a
sta modify_opcode+1

It seems more intuitive to me, and perhaps easier to type and read. Since you only load it once, but usually modify it in several different places.

Well I am afraid you can't make the SPC print anything on screen ;)
But seriously..personally I have no clue about SPC programming.

gilligan/TRIAD

"you can't make the SPC print anything on screen"
Can't you record a .wav of "Hello world", convert it to the DSP's BRR format, and then tell the SPC to tell the DSP to play it?

That wouldn't be that hard to do. But I didn't include any SPC700 stuff in my starterkit because I was hoping to fix up my music and sound fx code to make it easier to use, and then release that.

It doesn't look like I'm ever going to get around to that, so maybe I should make a little "hello world" example. The problem I have with this is: if you show someone how to display on the screen: backgrounds, sprites, palettes ... as well as the tools to convert formats, and along with miscellaneous info like using JoyPad data, You basically gave them all the basics to start playing with (well, except HDMA).

But if I made a "play 'hello world' demo", it would give: how to load up code/data to APU, how to start execution, how to communicate with SNES, how to play one sound, and the converter for WAV->BRR. That does sound decent, and would allow people to add sound effects to their programs ... but it's missing music. Without that it doesn't seem to be a good example of "here are all the basics, start playing". Because they'd still have to figure out how to represent music on the SNES, and decide on what music format they want to start from on the PC, and learn how to convert it.

I realize a "starter" isn't supposed to do all the work, but I feel it should give all the basics (i.e. after this, you just code for the system ... any tool you make is out of convenience instead of necessity). Just playing one sound doesn't really do that.

I don't know, is there much of a demand for a full "SNES APU starter kit"?
I think it would only take me a day's work to get it acceptable ... but I don't have a full free day for awhile. (Plus other things seem a bit more fun to work on at the moment.)
If there really is a demand for this, I'll push it up in my todo list ... I have a decent chunk of free time coming up in two weeks.
Let me know.

"it's missing music. Without that it doesn't seem to be a good example of 'here are all the basics, start playing'."
Music is nothing but a series of sound effects played at various pitches and volumes on the 8 DSP channels. If you can write a sound driver such that the 65C816 can tell the SPC700 to "play X sound effect at Y pitch and Z volume on channel C", then it wouldn't take a genius to figure out how to write a music player in 65C816 code.

I recall hearing somewhere that someone was writing an MML player for SNES (wow, that lots of details, heheh). I wonder whatever happened with that?

Playing a sample is actually pretty easy to do, initialize a sample table, set your "XYZ" parameters and give the note-on command for channel "C".

SPC assembly looks weird, but it's actually much like a 6502. Just that the syntax is different, and it has some different addressing modes. It still uses 8-bit A, X, and Y registers much in the same way as a 6502 (and I'd bet that's largely why Nintendo chose that chip, familiarity + extra features).

I would love to have a SNES APU starterkit. I've tried to get the SPC to make noise, but I really had no idea what I was doing. A kit with documentation, examples, etc. would be a huge help.

Abonetochew

> If you can write a sound driver such that the 65C816 can tell the SPC700
> to "play X sound effect at Y pitch and Z volume on channel C",

Actually, that isn't hard to do since there's a DSP register for each of those settings. Basically the DSP does all the work for you :)

> then it wouldn't take a genius to figure out how to write a music player
> in 65C816 code

(The whole point of the APU having a CPU is so that the main CPU doesn't have to waste time on that stuff. Anyway, that's not the point here.)

Sure, it wouldn't take a genius. But why have so few people done anything with it then? Because it takes a good deal of work to make a necessary set of tools before you can do much with it.

What you're saying is equivalent to if I wrote to the PPU regs just enough to display one red pixel on the screen ... and then called that a starter kit (with no graphic conversion tools or anything.)
Sure, it demonstrates the registers (which the users could just have read about by themselves) ... but it doesn't give much of a starting ground.

Actually, I take part of that back. Probably a large reason that people don't play with the APU is that they're not sure how to load code/data to it and start execution. The truth is it's not that difficult (and is documented, as well as the fact that you can just read the 64 byte boot-strap code yourself if you want), but it adds an extra layer of things to debug (i.e. what's wrong ... my loading code, or my SPC700 code?).

Anyway...
I guess it just boils down to personal preference about what is a big enough "starting ground" for a starter kit. To each his own.

Yeah, the SPC is pretty nice to work with, but I'd have to say the hardest part for me was getting it loaded to begin with. All the docs and code examples seemed very confusing and complicated, until I dissassembled that 64-byte ROM.

For what I did, which was pretty simple stuff on the SPC-side of it, everything beyond that was a breeze.

I'd be willing to write a SPC7000 disassembler that does just what SmartRENES (the NES disassembler I'm working on) is supposed to do... This would at least provide people commercial code to be used as a reference. If anyone is interested in such a tool, I'll begin coding it (as well as another for the 65c816).

hydesprojects.cjb.net