Donkey Kong Score Going the Wrong Way in Demo
Moderator: Moderators
Donkey Kong Score Going the Wrong Way in Demo
Hi All,
So, during the title screen demo, my Donkey Kong bonus score starts at 5000, but then goes to FF00, then F700, then 5800 and keeps going up. It should of course instead be going down to 4900, 4800, etc.
I think this is probably caused by a CPU bug, but I don't see an obvious bug in the tests. I remember there being an annotated version of the Donkey Kong source code somewhere? I was hoping I could look at that to see what instructions set the Bonus score. I thought it was ADC or SBC probably, but I think my implementations are okay.
Thanks in advance.
So, during the title screen demo, my Donkey Kong bonus score starts at 5000, but then goes to FF00, then F700, then 5800 and keeps going up. It should of course instead be going down to 4900, 4800, etc.
I think this is probably caused by a CPU bug, but I don't see an obvious bug in the tests. I remember there being an annotated version of the Donkey Kong source code somewhere? I was hoping I could look at that to see what instructions set the Bonus score. I thought it was ADC or SBC probably, but I think my implementations are okay.
Thanks in advance.
Re: Donkey Kong Score Going the Wrong Way in Demo
Sounds like a CPU bug. Do other games have the same problem?
Please post your CPU source code for us to review.
Please post your CPU source code for us to review.
Re: Donkey Kong Score Going the Wrong Way in Demo
Turns out it was a bug in ADC/SBC. Specifically, overflow was not set correctly. Thanks.
Re: Donkey Kong Score Going the Wrong Way in Demo
Subject of these two opcodes continues to come up over and over and over. I still maintain they're (specifically the overflow flag and two's complement) the #1 cause of frustration and bugs for people trying to emulate 65xxx series CPUs.
Anyway, reference material -- don't overlook the last line in my post: viewtopic.php?p=224802#p224802
Anyway, reference material -- don't overlook the last line in my post: viewtopic.php?p=224802#p224802
Re: Donkey Kong Score Going the Wrong Way in Demo
I agree it's the most confusing thing to implement CPU wise. I had no problem with the carry (which the linked to threads go into in some detail). I had a lot more trouble with overflow, which the linked posts go into a lot less detail about. As mentioned in the linked threads, nestest will pass, but Blargg's tests will not with an incorrect SDC/ADC in some situations. I'm passing the tests now, but it took a while, and I'm still not quite sure I understand why my original implementation didn't work.
Re: Donkey Kong Score Going the Wrong Way in Demo
You're right. But the subject has still been discussed to death on the forum. :-) Here's something more relevant for you (entire thread from this point on is useful, including some code): viewtopic.php?p=60520#p60520
Re: Donkey Kong Score Going the Wrong Way in Demo
If you still need the Donkey Kong annotated disassembly then you can find it at the below link. I used it a lot when trying to work out the bugs in my PPU.
https://www.romhacking.net/documents/540/
https://www.romhacking.net/documents/540/
Re: Donkey Kong Score Going the Wrong Way in Demo
I had so much trouble with SDC that I ended up copying a line of code from someone else's emulator to make it work. Not my proudest moment, I have attributed the line in my source code, but still.
Re: Donkey Kong Score Going the Wrong Way in Demo
Yeah same I ended up looking up the line for the overflow in mynes and attributing it in my README. Hey, by the way you inspired me by your posts to keep going and now I have sprites working in Donkey Kong—they're just the wrong colors .iOSBrett wrote:I had so much trouble with SDC that I ended up copying a line of code from someone else's emulator to make it work. Not my proudest moment, I have attributed the line in my source code, but still.
Re: Donkey Kong Score Going the Wrong Way in Demo
It's easier to implement ADC/SBC from scratch once you know that overflow or carry only occur when the sign bit changes, and that SBC is really an inverted add (a+~b+c). In C code with larger int sizes, it's easy to just check if the add result is larger than 0xFF for carry, and only otherwise can overflow occur.