Page 2 of 2
Posted: Sat Feb 24, 2007 3:56 am
by Bregalad
Well, if the 65816 is actually buggy, that's a lot of trouble for SNESdev, but not so much trouble for NESdev. What kind of bugs did it have ?
And about the list file, effectivly it seems to be lacking, but I never use them anyway.
I haven't noticed inability to detect zero page, however you have to tell manually to reduce instruction on zero page when one is found, with the instuction '.8bit'. It just doesn't do it automatically.
The only real annoayance with WLA-DX is that after the .8bit directive some instuctions (but not all of them) will try to force themselves to 8bit when you exept to adress memory with all 16 bits with them, generating a linking error... So you have to manually place a ".w" after memory location with some operands, wich is anoying, but you get quickly used to it.
What I really like with it is to tell you how many bytes are free in each rombank each time you compile your code. Usefull to plan ROM space efficiently.
Posted: Sat Feb 24, 2007 9:47 am
by Bananmos
To be honest, I can't even remember what bugs it had anymore. Think it had something to do with it changing some instructions depending on 8/16-bit mode which should be indifferent to it. But like I said, I can't really remember now. What I do remember though, is that it was royal PITA trying to find track the bugs when the list files weren't working properly. To begin with, they contained no address information whatsoever. Also, some things like macros would put the list generator in some crazy state where it seemed to output nonsense data for lines until it somehow got on the right track again. Here's an excerpt from a list file to illustrate my point:
Code: Select all
$8D $81 $40 isrSplitScreen
$A9 $80 phb
$8D $82 $40 phk
$20 $CD $D1 plb
$68 pha
$A8 txa
$68 pha
$AA tya
$68 pha
$AB
$40
$8B ; lda.b #0
$4B ; sta GPU_RenderFlags
$AB
$48
$8A lda.b #0
$48 sta GPU_hBlankStatus
$98 ; sta GPU_hBlankStatus
$48 ; sta GPU_hBlankStatus
$A9 $00 ; sta GPU_hBlankStatus
$8D $82 $40
$A5 $42 lda Joypad
$0A asl
$10 $02 bpl +
$C6 $59 dec scroll2
+
$A5 $59 lda scroll2
$AA tax
$BD $66 $CE lda SineTable.w,X
$8D $00 $40 sta GPU_ScrollXLo
;asl
$A5 $59 lda scroll2
$18 clc
$69 $57 adc.b #$57
$AA tax
$BD $66 $CE lda SineTable.w,X
$8D $02 $40 sta GPU_ScrollYLo
Like I mentioned earlier, I consider list files to be absolutely vital when you need to examine and/or debug the assembled code. I don't know how you get by without them...
And yes, the "operande hints" you mentioned was one of the biggest problems with WLA-DX that I experienced. In the 65C816 mode, the size of addresses (which translate to different opcodes) and size of operands (which depend on wether the 65C816 is in 8-bit index/accumulator mode) were treated equally. On a 6502 you don't have separate CPU modes, but having to manually specify the size of your addresses on each instruction is just not worth the effort, and something you shouldn't "get used to". That's the assemblers job.
Like I said, I did like a lot of features in WLA-DX that other assemblers lack, and the good part was that Ville Helin is very responsive to mails and fixed a lot of the problems in the assembler that I mailed him about. But in the end, there were just too many of them and fixing all of them would require a total rewrite where many of the linker's responsibilities would need to be transferred to the assembler.
Therefore, I don't consider WLA-DX a wise choice for 6502/65C816 development. It might still be good for Z80 development though. (that's what Ville Helin made it for after all) But I haven't written enough Z80 code to be able to judge that properly.
Posted: Sat Feb 24, 2007 10:15 am
by Bregalad
Like I mentioned earlier, I consider list files to be absolutely vital when you need to examine and/or debug the assembled code. I don't know how you get by without them...
I don't know either, but at least I've no trouble doing so. The list file shows your code, that you can see in your source instead, and the binary data that you can see in the compiled binary file. The only interesting thing you can see is the corelation between both, but WLA can create a symol list, wich is much more handy when you want to know wich variable has been assigned with wich location or something like that, but I don't use it often because you usually see it immediately when tracing your code in FCEU. If you trace code you just wrote, then you can immediately see wich variables are in wich location, but if you trace code you wrote long ago, it may be worth looking at the symbol table so that you can see the correlation between your code in your source and in FCEU.
Aside of that I guess most bugs have been corected since. Anyway, what I like most with WLA-DX is that the author is very open to corrections and sugetions, and that no other assembler I know have that strong point.
Posted: Sun Feb 25, 2007 1:30 am
by AWal
I have found a fondness to FCEUXD(SP) for it's debug capabilities. I've been hex hacking (mostly game genie codes) for a lot longer than I've been actualy writing code, so seeing the hex numbers for common things like LDA $xxxx, STA #$xx, and BEQ $xx are just natural for me.
Of course I have the .asm file to the side of the emulator, just in case I run into some deep trouble.
I've been using the same recycled code snippets for some time, so most minor code flaws are not much of an issue to me.
P.S.: Am I the only person still using TASM to compile code?
Posted: Sun Feb 25, 2007 7:23 pm
by Anders_A
Uhm, bananmos examples in ca65-syntax using anonymous labels:
Code: Select all
:
lda DecrunchingState
beq :-
bpl :-
lda DecrunchingBank
jsr MMC1_WriteRegister3
lda #<DecrunchedTune
sta TempWord2
lda #>DecrunchedTune
sta TempWord2+1
ldx CrunchedTune
ldy CrunchedTune+1
jsr DecodeLZ77
lda #$01
sta DecrunchingState
:
lda DecrunchingState
bne :-
jmp :--
Code: Select all
ldx #8
:
lda _666addHi
beq :+
:
lda _666 ;3
clc
adc _666add
bcs :+ ;3/2
: sta _666 ;3 19.xxx/18.xxx
dex
bne :---
You use n + or - to reference the n'th anonymous label forward or backwards. The implementation of this was buggy in older versions though.
I prefer ca65 syntax, since a label isn't really anonymous if you have to name it -- or -. And could just aswell have been named @loop1 and @loop2 or whatever (using ca65 syntax for local labels)
If you have a large chunk of code, ca65 syntax will ofcourse get harder to follow, but you shouldn't really use anonymous labels for jumps longer then a couple of rows anyway IMO.
Posted: Sun Feb 25, 2007 7:35 pm
by tepples
Anders_A wrote:You use a number of + or - to go forth or back a number of anonymous lables.
But then you have to count the labels, and adding another anonymous label inside the loop throws off the count.
If you have a large chunk of code, ca65 syntax will ofcourse get harder to follow, but you shouldn't really use anonymous labels for jumps longer then a couple of rows anyway IMO.
Like the outer loops in the examples.
Posted: Mon Feb 26, 2007 7:13 am
by Bananmos
On the other hand, since ca65 is open-source, I guess you could hack in x816-style anonymous labels into it in a few rainy days. Since the convention it uses seems to be mutually exclusive to x816's convention, it looks to me like it could be added without interfering with ca65's existing anonymous labels-conventions at all. (correct me if I'm wrong)
Posted: Mon Feb 26, 2007 7:21 am
by albailey
Whats interesting about the direction this thread took, is that its relevant to a debugging problem I encoutnered this weekend (and fixed).
I use CA65 and had some subroutines something like this
foo:
... do some stuff...
bne :+
... do some more stuff...
:
rts
bar:
... do some stuff...
bne :-
... do some more stuff...
:
rts
Well, I meant to say bne :+ in the subroutine "bar"
My code compiled fine because I had another anonymous label in subroutine "foo" declared before these and since both had an rts, I wasnt getting stack issues.
The actual code pertained to my input handling.
The code "appeared to work" in FCEU both in memory and in the final output. (which doesnt make any sense)
But the bug revealed itself in Nintendulator, and several other emulators I downloaded. I only was able to find it by scanning my code line by line (again back to my problem debugging)
So, I no longer trust FCEU as much as I used to. And I run everything
in both it and Nintendulator now.
Al
Posted: Mon Feb 26, 2007 11:41 am
by tepples
albailey wrote:My code compiled fine because I had another anonymous label in subroutine "foo" declared before these and since both had an rts, I wasnt getting stack issues.
The actual code pertained to my input handling.
The code "appeared to work" in FCEU both in memory and in the final output. (which doesnt make any sense)
But the bug revealed itself in Nintendulator, and several other emulators I downloaded. I only was able to find it by scanning my code line by line (again back to my problem debugging)
So, I no longer trust FCEU as much as I used to. And I run everything
in both it and Nintendulator now.
That's a good idea.
In general: If one emulator's behavior differs markedly from that of the top-tier emulators, write a test case that amplifies this behavior difference and post it on a web site. Have the experts here on nesdev try it out on an NES, and you'll know which emulators are misbehaving and where to report the bug. I've done this several times for differences between VisualBoyAdvance and the GBA hardware.
Posted: Tue Feb 27, 2007 11:49 am
by albailey
Here is a chunk of broken code:
getJoyPad1Input:
LDA CURRENT_JOY1_STATUS
STA LAST_JOY1_STATUS
;LDA CURRENT_JOY2_STATUS
;STA LAST_JOY2_STATUS
; strobe joypad
ldx #$09 ; bit zero is 1
stx JOY1
DEX
stx JOY1 ; bit 0 is zero
; Now we read 8 times from Joy1
: lda JOY1
LSR A
ROR CURRENT_JOY1_STATUS
;lda JOY2
;AND #$03
;CMP #$01
;ROL CURRENT_JOY2_STATUS
DEX
BNE :-
rts
processAButton:
; Check if the A button was pressed
LDA #JOY_A_MASK
STA ACTIVE_MASK
jsr checkChangeForInput
LDA MASK_RESULT
CMP #$01
BNE :- ; This is the error line. It should be BNE :+
; To Do: process A button
:
rts
You can see the problem. Normally I jsr getJoyPad1Input and later jsr processAButton (I didnt include all that code).
The bug means I query JOY1 (4016) some more. Since I dont know what X is set to, it queries it an indeterminate number of times and causes my CURRENT_JOY1_STATUS variable to have an altered result. So later when I want to move left, it thinks I've moved right, etc..
Nintendulator and Nestopia process the input in a backwards fashion(expected behaviour)
FCEU doesnt show me an error (although it should)
RockNES and JNES just ignore my input.
If anyone would like the .nes file, let me know and I can email it to them or if anyone knows a free hosting service. My geocities site doesnt allow it
I cant post a link to the the .nes file (I have a geocities account and they seem to be blocking it)
Al