Register | Login | |||||
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
| |
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: 6467 days Last view: 6424 days |
| ||
$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: 6424 days Last view: 6424 days |
| ||
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: 6467 days Last view: 6424 days |
| ||
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: 6424 days Last view: 6424 days |
| ||
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: 6467 days Last view: 6424 days |
| ||
$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: 6424 days Last view: 6424 days |
| ||
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: 6467 days Last view: 6424 days |
| ||
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: 6424 days Last view: 6424 days |
| ||
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 | | |