(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album
05-02-24 08:26 PM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - 65c816 ASM Confusion New poll | |
Add to favorites | Next newer thread | Next older thread
User Post
Reshaper256

190


 





Since: 11-17-05
From: United States

Last post: 6325 days
Last view: 6282 days
Posted on 03-26-06 10:57 PM Link | Quote
$06/E446...38.........SEC............................A:008C X:0001 Y:0002 D:0000 DB:05 S:01DB P:envmXdizCHC:0904 VC:031 00 FL:2889
$06/E447...E5 04....SBC $04...[$00:0004]...A:008C X:0001 Y:0002 D:0000 DB:05 S:01DB P:envmXdizCHC:0918 VC:031 00 FL:2889
$06/E449...85 02....STA $02....[$00:0002]...A:008C X:0001 Y:0002 D:0000 DB:05 S:01DB P:envmXdizCHC:0950 VC:031 00 FL:2889


(Ugh... well, sorry for the mess above. I've added periods to space it out and make it as readable as I can.) This is from a trace (via geiger's snes9x debug) of the code from Zelda 3, but there is something about this particular portion of the code that I don't understand:

The first instruction, SEC, sets the carry bit. The accumulator contains the value #$008C, and the next instruction is SBC - subtract from accumulator with carry. So, why, I'm asking, has the value in the accumulator not changed in the next instruction? With the carry bit set, shouldn't the accumulator decreased by at least one?

I'm sure I'm understanding something wrong, but could someone please explain this to me?


(edited by Reshaper256 on 03-26-06 10:08 PM)
C:/xkas bio.asm
Compiled ASM code








Since: 11-17-05

Last post: 6283 days
Last view: 6282 days
Posted on 03-26-06 11:00 PM Link | Quote
are you sure you didn't skipped the oppcode with the debugger?, if I renember correctly 'next op' skip the the current opperation and go to the next
Reshaper256

190


 





Since: 11-17-05
From: United States

Last post: 6325 days
Last view: 6282 days
Posted on 03-26-06 11:05 PM Link | Quote
Yeah, I'm fairly certain I didn't skip anything. This was taken from a trace, so I got it all at once. It would've been a huge mess to post the entire subroutine it comes out of, but I'm pretty sure that the value in $0004 is zero at the time of this instruction. Would the instruction ignore the carry if the value being subtracted is zero? I don't think it would, but that's all I can come up with at the moment.
C:/xkas bio.asm
Compiled ASM code








Since: 11-17-05

Last post: 6283 days
Last view: 6282 days
Posted on 03-26-06 11:07 PM Link | Quote
or maybe the value at $0004 is FF, when FF is increased by one, the result is 00


(edited by Bio on 03-26-06 09:07 PM)
Reshaper256

190


 





Since: 11-17-05
From: United States

Last post: 6325 days
Last view: 6282 days
Posted on 03-26-06 11:13 PM Link | Quote
$06/E439...85 04.....STA $04.....[$00:0004].....A:0000 X:0001 Y:0002 D:0000 DB:05 S:01DD P:envMXdiZcHC:0718 VC:031 00 FL:2889

This is the last instruction that wrote anything to $0004, when I scroll up a few lines in the trace. From what I can tell, it would have written #$00 to $0004, which would be what it tried to subtract from the accumulator in the instructions in my original post. When you add the carry, it should have subtracted one, the way I understand it.

OK, here's a pic of the entire subroutine:


-The top code in the blue box is the one where #$00 is written to $0004.
-The bottom code is the code in the original post.
-The yellow box shows where the accumulator didn't change.
-The yellow circle shows that the carry bit was set.

So... what's going on - why doesn't the accumulator change?



(edited by Reshaper256 on 03-26-06 09:40 PM)
C:/xkas bio.asm
Compiled ASM code








Since: 11-17-05

Last post: 6283 days
Last view: 6282 days
Posted on 03-27-06 12:31 AM Link | Quote
well, its very odd, I think its the debugger or the 65816 who got a bug with the SBC oppcode, I suggest dump RAM $0004 and $0002 when the 65816 is at this area of code


(edited by Bio on 03-26-06 10:32 PM)
(edited by Bio on 03-26-06 10:32 PM)
Reshaper256

190


 





Since: 11-17-05
From: United States

Last post: 6325 days
Last view: 6282 days
Posted on 03-27-06 01:01 AM Link | Quote
I checked the RAM during the instruction and $0004 contains #$00 when it executes. I also stepped through the instruction with BSNES's debugger and had the same result with the accumulator not changing.

Could the SBC instruction actually check the *negative* flag instead of the carry flag? Being subtraction, it might make sense that the negative flag would be checked instead. I may be way off base here, though - why would it be called 'Subtract with Carry', in that case? It might explain why the value isn't changing, though.

edit: no, after testing it, it doesn't look like it checks the negative flag. I'm quite confused.

EDIT: I figured it out!! The SBC instruction subtracts an additonal "1" whenever the carry flag is CLEAR, not when it's set. Three separate 65c816 references had it wrong.




(edited by Reshaper256 on 03-26-06 11:05 PM)
(edited by Reshaper256 on 03-26-06 11:36 PM)
(edited by Reshaper256 on 03-26-06 11:53 PM)
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6283 days
Last view: 6282 days
Posted on 03-27-06 02:27 AM Link | Quote
Thanks for figuring it out yourself . You saved me a couple minutes. For reference:

CLC
ADC (add with carry)

is the same as

ADD (pure add)

and

SEC
SBC

is the same as

SUB (pure subtraction)

Problem is the 65c816 doesn't have pure adds or subtracts, so programmers used macros similar to the ones above to achieve this. Just think how annoying it would be to have to remember CLC or SEC all the time yourself.
Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - ROM Hacking - 65c816 ASM Confusion |


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.016 seconds; used 383.61 kB (max 467.38 kB)