[Videogamer555]

I can find tons of stuff on WLA  but XKAS usually seems to be used by SMW hackers for making patches. But I want some help using it as a real assembler for writing a game. A tutorial would be nice.

Some things I can't figure out in XKAS
Sections (.section was the command in WLA and .ends ended it, but what about XKAS?)
Macros (.macro was the command in WLA and .endm ended it, but what about XKAS?)

What about banks and slots (.BANK 0 SLOT 0 was used in InitSNES.asm for WLA, but how do I port this to XKAS compatible code? XKAS spits out TONS of errors for InitSNES.asm, How do I port InitSNES.asm to XKAS? I'll need it to JUST START UP THE SNES SYSTEM ITSELF. Please help me port this file to XKAS)

Note: I thought the concept of assembly language was supposed to be a STANDARD SET OF INSTRUCTIONS, but I'm getting tons of incompatiabilities here between WLA and XKAS. I want to work with XKAS cause its A LOT EASIER TO USE, but first I have to figure out how to port the code (most of which is meant for WLA, and only WLA in its current form) to XKAS.

Please help.

[LostTemplar]

xkas has been superseded by bass, so you should probably look into the latter if you plan to do any SNES assembly. However, both have been designed to operate as a patching assembler, i.e. change and insert relatively short assembly snippets into already existing ROMs. I guess it's still possible to program something from scratch, but it might be missing some important features. For example, I'm pretty sure neither xkas nor bass have support for sections (bass has support for macros, though).

As far as I know there isn't any extensive documentation beyond the material that accompanies xkas/bass.

Another advice: If you're struggling to port InitSNES.asm from one assembler's syntax^* to another's you're probably not ready yet to create complex programs in assembly only. You should maybe experiment a bit with existing code, or try to change behaviour in existing games. Well, you can still try of course, but be prepared for it not to be easy.

^*) even if the instructions themselves are the same, different assemblers very often differ in syntax, for example in what format the instruction's arguments are specified, or everything "meta" like macro syntax

[furrykef]

Well, I'm glad you're not trying to use WLA, because it's such a heap of garbage that I've given up on my Lupin project until I've written my own assembler (I don't like xkas or bass either, and there are no other 65816 assemblers designed to patch ROMs that I know of).

Note: I thought the concept of assembly language was supposed to be a STANDARD SET OF INSTRUCTIONS, but I'm getting tons of incompatiabilities here between WLA and XKAS.

A standard set of machine instructions, yes. Standardization on anything else is a luxury. The world of x86 is still divided (after all these years!) between AT&T syntax and Intel syntax. The GNU assembler takes AT&T syntax; NASM takes Intel syntax (as do the most popular assemblers of old, MASM and TASM). It's even worse for other platforms, where there often isn't a standard assembler that everybody imitates. byuu's bass is worse than most others about it, though; his syntax strikes me as just insane.

Guess what? My assembler will be different from other assemblers too. I mean, that's rather the point of writing one, right? But in mine, there's a mitigating factor: you can use or write plugins to mimic features from other assemblers, minimizing the amount of tweaking you have to do to assemble code written for another assembler.

But don't hold your breath on me getting around to releasing it very soon, because I've been procrastinating on it for like two years now. *sigh*

[LostTemplar]

I'm curious, can you give an example of how the syntax would look like for your assembler?

[Nightcrawler]

Your problems don't lay in assembly language, rather the assembler commands specific to that assembler. They are in no way standard at all. You're learning quickly why many around here don't use WLA either. Too much red tape junk. A 'slot'? Really WLA? Most of those WLA commands are junk and have no direct translation with other assemblers.

Instead of sections, banks, slots, or other WLA junk, You'll want to replace that stuff with simple org directives telling the assembler where you want the code to go.

It doesn't seem like you're ready to port anything because you don't yet understand what you need to do with either assembler nor what you need to get a ROM going from scratch.

If you're using xkas, you can simply do something like this:

Code: [Select]

hirom

;add a quick header to the ROM. For HiROM mapping, it is expected to be at $ffc0 in the first bank.
;You should also be able to use use $00ffc0, but I forget if xkas maps that correctly offhand.
org $c0ffc0
  db 'ROM TITLE            '
  db $31   ;lorom ($31 = hirom)
  db $02   ;rom+save ram
  db $0a   ;8mbit rom
  db $03   ;64kb sram
  db $00   ;japan
  db $00   ;no developer
  db $01   ;version 1.1
  dw $0000 ;inverse checksum
  dw $ffff ;checksum

  dw $ffff,$ffff,$ffff
  dw $ffff ;brk
  dw $ffff
  dw $8800 ;nmi
  dw $ffff
  dw $8800 ;irq
  dw $ffff,$ffff
  dw $ffff ;cop
  dw $ffff,$ffff,$ffff
  dw $8000 ;reset
  dw $ffff

;Your nmi and interrupt vectors point here. Right now, it does nothing but return in the event they run.
org $c08800
        rti

;Your reset vector points here. This is thus the beginning of code execution.
org $c08000
sei             ;disable interrupts
clc                     
xce ;switch to native mode
        jsl $c10000 ;jump to initialization routine.
loopme:
jmp loopme

org $c10000
;Your Initialization Code Could Go Here.
        rtl

Macros are in the documentation, but I wouldn't complicate matters with those yet.

You should probably work on understanding this tiny framework I've laid out there so you understand what's necessary and what's going on. That should actually compile into a working ROM that you should be able to use the debugger on. However, it doesn't actually do anything visual of course.

[UltimateUrinater]

Lol...so does the snes not care what the checksum is?..cause u just assigned it some random value.

[Disch]

The SNES doesn't care about anything in the header.... it never even looks at it.

Emulators, though, often use the placement of the header to determine the mapping of the ROM (Ex:  LoROM vs. HiROM).  And no, they don't care about checksums.

[Nightcrawler]

You'd put the correct checksum in when your ROM is ready for release. You're not typically going to calculate it every time you add a few lines of code and run it. Second, it is there as a placeholder, and an external utility can handle that part automatically. This is done after the ROM is assembled rather than putting it in the source code (which is what I do).

Since emulators nor hardware care about the checksum, I did not think it relevant to discuss in detail for this discussion. Why did you dig up a 3 year old topic for this?