Page 1 of 1
Background and Sprites strange behavior
Posted: Sun Aug 29, 2010 5:46 pm
by comegordas
hi people! i'm opening this thread in order to get some help with a strange behavior of the background and the tiles in my emu. i've tested my emu with some roms and found some crazy things that couldn't figure out why happens. i.e., in Donkey Kong, the first title screen is never showed, the game goes directly the console's self-playing scene. this scene looks ok for a few seconds, and then it crashes, turning the screen into this:
the other strange thing is this:
look at the position where Mario dies
i've loaded the roms in some other emulators and in the scene he doesn't die in that position. i've made some tests with Balloon Fight too and have some similar results. i can't figure out why this is happening, so i'm asking for some hints. maybe one of you had a similar issue :\
thanks in advance for any reply!
Posted: Sun Aug 29, 2010 6:05 pm
by tokumaru
Sounds like CPU bugs to me... Are you sure your CPU code is working 100%? What kind of tests did you run?
Posted: Sun Aug 29, 2010 6:12 pm
by comegordas
i'm not 100% sure, but i guess it does. i've runned some test roms and got good results. i was wondering that maybe its a PPU register's issue. anyway i'll be cheking again the CPU core. thanks for your reply Tokumaru

Posted: Sun Aug 29, 2010 6:21 pm
by MottZilla
If game logic is failing, be certain to check CPU operation. Also be sure that your handling of memory on the NES in general in correct. Donkey Kong was pretty easy for me to get working. But you can have all sorts of weird bugs if you have a problem in your CPU core. Did you ever run the CPU test ROM? Code execution logs are a good way to spot incorrect opcode behavior or register behavior.
Posted: Sun Aug 29, 2010 6:44 pm
by blargg
tokumaru wrote:What kind of tests did you run?
comegordas wrote:i've runned some test roms and got good results.
Did these test ROMs have names?
Posted: Sun Aug 29, 2010 7:08 pm
by comegordas
Blargg: i've used "nestest.nes", the one wich recommended MotZilla.
well, by cheking again the CPU i've found a little issue, aparently with the AND instruction. i've found this on a 6502 doc:
2.2.4.1 AND--Memory with Accumulator
The AND instructions transfer the accumulator and memory to the adder which performs a bit-by-bit AND operation and stores the result back in the accumulator.
...maybe my lack of english language speaking made me loose a little detail. the operation is "ACC = ACC & src" or "ACC += (ACC & src)" (note that "+" in the ecuation). i'm asking because this is what it seems to be doing nestest :\
Posted: Sun Aug 29, 2010 7:12 pm
by MottZilla
In C, it would be ACC = ACC & SRC;
So the first one you mentioned. Not the other one.
Posted: Sun Aug 29, 2010 7:16 pm
by tepples
"Adder" in the 6502 appears to refer to the ALU (see Wikipedia
en inglés o
en español). It can do more than add, but to save space on the chip, half the logic for adding is reused. The correct operation is "ACC = ACC & src".
By the way, do you want a little help with your English?
Posted: Sun Aug 29, 2010 7:28 pm
by comegordas
i've found this in the "nestest golden log":
Code: Select all
C7FE 08 PHP A:10 X:00 Y:00 P:64 SP:FB
C7FF 68 PLA A:10 X:00 Y:00 P:64 SP:FA
C800 29 EF AND #$EF A:74 X:00 Y:00 P:64 SP:FB
C802 C9 64 CMP #$64 A:64 X:00 Y:00 P:64 SP:FB
P = 64
PHP -> value on stack = 64
PLA -> value in accumulator should 64, and ass you can see in the third line it is 74.
before pulling the value from stack the accumulator was 10. then the program pushes the processor status (wich is 64) onto the stack. then the program loads the accumulator with the value pulled from the stack. at this point accumulator should be 64, because that was the last value pushed onto the stack. unaware ass you can see the value loaded in the accumulator is 74, and not 64. who's wrong: nestest or me?
EDIT: look at this too:
Code: Select all
C824 48 PHA A:FF X:00 Y:00 P:AD SP:FB CYC: 86 SL:243
C825 28 PLP A:FF X:00 Y:00 P:AD SP:FA CYC: 95 SL:243
C826 D0 09 BNE $C831 A:FF X:00 Y:00 P:EF SP:FB CYC:107 SL:243
A = FF
PHA -> value pushed on stack is FF
PLP -> value pulled from stack is EF (not FF)

Posted: Sun Aug 29, 2010 7:31 pm
by comegordas
tepples wrote:"Adder" in the 6502 appears to refer to the ALU (see Wikipedia
en inglés o
en español). It can do more than add, but to save space on the chip, half the logic for adding is reused. The correct operation is "ACC = ACC & src".
By the way, do you want a little help with your English?
LOL, is my english so bad? XD
of course i need help with my english! but why are you offering me help? do you speak spanish? please say yes

Posted: Sun Aug 29, 2010 8:24 pm
by tepples
comegordas wrote:tepples wrote:By the way, do you want a little help with your English?
LOL, is my english so bad? XD
of course i need help with my english! but why are you offering me help? do you speak spanish? please say yes

I took some Spanish years ago in school, and yes, I can still read a little Spanish. I was asking so that I could know whether to offer help with your grammar. I know that some people like being corrected, but others don't respond well to such criticism. For example:
CATS wrote:All your base are belong to us.
We've taken over all your bases.
Back to topic: After PLA, A = $74 because
PHP and BRK push the flags OR $30. After AND #$EF, A = $64 because $74 & $EF = $64.
Posted: Sun Aug 29, 2010 8:36 pm
by comegordas
ok, didn't know that! also, by looking at the log it seems like i have to do an AND $EF when PLP. am i correct? that's its seems to be doing nestest
muchas gracias Tepples, eres muy bueno (take that as a "now it's your turn to show me how much did you learn at school"

)
Posted: Sun Aug 29, 2010 8:46 pm
by blargg
Ahhh, the hallucinated bit 4 and bit 5 status flags. The 6502 only has 6 status flags, not 8 as incorrectly documented almost eveywhere.
Posted: Sun Aug 29, 2010 8:50 pm
by comegordas
yeap, that B flag seems useless. but still BRK is giving some headaches :\