nesdev.org

OK, I'm trying to compile 6502 code in WLA for the NES, and I'm having some difficulty:

http://www.geocities.com/beneficii/test.zip (change ext to .nes)
http://www.geocities.com/beneficii/Test.asm

Because of the lack of documentation, I'm not sure what I'm doing wrong. When I look in the test.nes file, there is a bunch of crap before it gets to what I had assembled, containing the names of the source files. That is an issue. I think the purpose is for a linker? Even with that though, the ORGA'ing is done wrong if you look at the code, the first bank is missing and it omits a lot of bytes to fill the bank and the JMP statement goes to $0000 as opposed to $E000. Pay attention also to the ';'s throughout, which are omitted lines of code.

I haven't used WLA, so take everything I say with a grain of salt.... but from looking at the binary it seems pretty clear to me that this is an object file and not a complete .nes file. The "WLAK" header was the first giveaway -- followed by filenames, etc.

beneficii wrote:I think the purpose is for a linker?

Bingo. The linker will tie this (and any other files you assemble) into the finalized ROM. This file by itself is more or less totally useless before being run through the linker.

Even with that though, the ORGA'ing is done wrong if you look at the code, the first bank is missing and it omits a lot of bytes to fill the bank and the JMP statement goes to $0000 as opposed to $E000.

Updating addresses to point to labels, tying files together, filling in patches, etc -- that is exactly what the linker is for. Those addresses may change in the finalized ROM. This could be assembling properly... but assembling is only half the process.

What you're looking at is not really 6502 machinecode... it's WLA pseudo-code with fillers and identifiers unique to WLA. Identifiers to tell the linker what label points where and what addresses reference what so that the linker can fill in all the blanks when combining several files.

Also -- don't .db the iNES header. The header is not something you want to assemble (it's not part of the PRG). If WLA does not include the header in the finalized binary, make an extra 16 byte file that contains the header and combine it with a copy /B line in a batch file or something.



But again -- my total experience with WLA is zero -- so take this for what it's worth: pure speculation. Perhaps someone else here has experience with it and can help out more.

Yes, using the linker worked a bit better. It looks like a MAKEFILE is more or less required to finish this. But thank you. Now to figuring out how to add vectors without multiple memory issues. ^_^

OK, I'm trying to do this now:
Which is including the vectors at the bottom. Unfortunately, I keep getting "Origin ($6) overflows from bank (2)" messages. This is clearly not a way to add vectors understood by the assembler, so I'm a bit confused: How would I add them?

BTW, thank you Disch![/code]

You need to keep the vectors in the same bank as your main code. This is what I do (at the end of your main code bank):
Also, have you checked out this?

Check out section on .SECTION. You'll eventually want to take your MEMORYMAP and ROMBANKMAP and put it in a separate file. This way you can .INCLUDE them in all your future files.

Yes I had. And I had read the section on ".SECTION" but I wasn't sure what to make of it. Thank you so much for you help!

This is a bit more powerful!

You are actually forced to put every stuff you want to oupout to the final image into sections. In a signle section, everything will get aliged as-it (in the same order it's written), and section can be arranged like the assembler wants.

Bregalad,

I figured as much. ^_^ Hey, I'm having one issue on the linker that I think might be a problem with the coding of the linker itself:
This is made into an object file fine, but when I link it, it says:

test.o:test.asm:38: FIX_REFERENCES: Value ($2002) of "PPU_READ" is too
much to be a 8bit value.

I know that if I put '.w' after the LDA in the LDA statement, it will resolve the problem, but I think the linker should know that LDA can be 16-bit and that what it's accessing is a 16-bit address, so I don't have to put '.w' after the statement every time I want to access a .RAMSECTION in 16-bit addressing.

Then again, I am wondering how the author would fix the problem.

EDIT: BTW, this is with both versions 9.2 and the "experimental" release 9.4a.

beneficii wrote:Bregalad,

I figured as much. ^_^ Hey, I'm having one issue on the linker that I think might be a problem with the coding of the linker itself:

Code: Select all

.EMPTYFILL	$FF

.MEMORYMAP
SLOTSIZE	$2000
DEFAULTSLOT	0
SLOT 0		$8000
SLOT 1		$A000
SLOT 2		$C000
SLOT 3		$E000
SLOT 4		$2000
.ENDME

.ROMBANKMAP
BANKSTOTAL	4
BANKSIZE	$2000
BANKS		4
.ENDRO

.RAMSECTION "Stuff" SLOT 4
PPU_SET1:		DB
PPU_SET2:		DB
PPU_READ:		DB
.ENDS

.BANK	0	SLOT	0
.ORGA	$8000

.BANK	1	SLOT	1
.ORGA	$A000

.BANK	2	SLOT	2
.ORGA	$C000

.BANK	3	SLOT	3
.ORGA	$E000

main:
	lda PPU_READ
	jmp main

.ORGA 	$FFFA
.SECTION "Vectors" FORCE
.DW	main, main, main
.ENDS

This is made into an object file fine, but when I link it, it says:

test.o:test.asm:38: FIX_REFERENCES: Value ($2002) of "PPU_READ" is too
much to be a 8bit value.

I know that if I put '.w' after the LDA in the LDA statement, it will resolve the problem, but I think the linker should know that LDA can be 16-bit and that what it's accessing is a 16-bit address, so I don't have to put '.w' after the statement every time I want to access a .RAMSECTION in 16-bit addressing.

Then again, I am wondering how the author would fix the problem.

EDIT: BTW, this is with both versions 9.2 and the "experimental" release 9.4a.

add a ".w" after the "lda PPU_READ". Some kind of bug or something with WLA that you have to tell it the value is 16bit.

lynxsolaris,

I knew that. ^_^ I explained it in the post. I guess I should send an e-mail to the author.

beneficii wrote:lynxsolaris,

I knew that. ^_^ I explained it in the post. I guess I should send an e-mail to the author.

Yeah, sorry. I saw that after I posted.

lynxsolaris,

That's OK, thank you. ^_^ I just sent an e-mail to the author about that. I'm actually wondering if he's not already aware of the issue.

That's OK, thank you. ^_^ I just sent an e-mail to the author about that. I'm actually wondering if he's not already aware of the issue.

I've awared him for the issue about 1.5 year ago, and he fixed half of the opcodes (such as sta) leaving the others unafected. I think it'd be good if more people are asking him

Bregalad wrote:

That's OK, thank you. ^_^ I just sent an e-mail to the author about that. I'm actually wondering if he's not already aware of the issue.

I've awared him for the issue about 1.5 year ago, and he fixed half of the opcodes (such as sta) leaving the others unafected. I think it'd be good if more people are asking him

Cool. I emailed him about it as well.

Bregalad wrote:

That's OK, thank you. ^_^ I just sent an e-mail to the author about that. I'm actually wondering if he's not already aware of the issue.

I've awared him for the issue about 1.5 year ago, and he fixed half of the opcodes (such as sta) leaving the others unafected. I think it'd be good if more people are asking him

Mmhmm, it would. But just so you know, I'm having the same problem with sta. I think it goes for any opcode that can be 8-bit or 16-bit: I guess the wla-6502 just assumes when an opcode accesses .RAMSECTION that it can do 8-bit addressing. Oops.

Still waiting for a response from him.

EDIT: I think that is the issue. Because whenever you load from .RAMSECTION, WLA-6502 puts in an 8-bit opcode, which of course can't take a 16-bit address.

Sorry for the long reply, but the person had responded a while ago and it was fairly discouraging. But here was his message:

Sorry dude, but no matter how I look at that LDA and the situation, I
can't think of anything that wouldn't break compability. It would also
mean that I would have to do the same for quite a many other opcodes that
are like LDA, and I'd have to move some code from the linker to the
assembler.

Currently the assembler doesn't understand labels. It can spot a label,
but doesn't know anything about it, and only the linker places the labels
into the memory etc...

Anyway, sorry, but you'll have to cope with WLA-DX the way it is.

It's doable as is, but there is that sort of teeth-clenching about having to remember to add ".w" after each opcode.

Unfortunately, this is otherwise among the best assemblers, allowing you to choose your emptyfill, allowing so many ways of accessing memory, allowing you to embed multiple source files and do stuff with them. How discouraging.

Still, I've been looking at the source code too and it looks like any sort of check in the assembler would be difficult and would require duplicating code from the linker. Still, I intend to modify the assembler myself to add that compatibility.