Problem with nestest

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Problem with nestest

Post by Vash »

Hi guys!

I'm developing a nes emulator. I tested it with nestest on automation (I don't have any PPU, just the CPU working). I got a problem with this line :
CDAD BA TSX A:00 X:00 Y:99 P:27 SP:FB CYC: 58 SL:257

The result is that the X register has the value : 0xFB.

It's not working on my emulator because the value 0xFB is never pulled on the stack. Even with the log I can't find where it's pulled.

So can someone tell me what I miss there?

Thanks.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

TSX copies the stack pointer itself, not any specific value from the stack, into X.

SP:FB + TSX = X:FB
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!

Now it makes sense.

Thanks for your help. I would have never figured it out by myself, I was so focused on the fact that everything was about push and pop that I didn't even read the doc correctly.
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

Ok now all the opcodes work correctly but can someone explain me what is CYC and SL in the nestest log. First I thought that CYC was the number of cycle but it doesn't seem to be that.

Thanks for your help.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Vash wrote:can someone explain me what is CYC and SL in the nestest log.
Given that CYC wraps around at 341, I'd say that's the PPU cycle within the scanline, which is what SL means.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

That log really shouldn't be like that. It should either have just a cycle counter that never rolls over, or no cycles at all, since it's not a timing test anyway.
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

Thank you for your answer.

So if I got it right, the CYC is the number of cycle of the opcodes wraped around at 341.
I don't understand how SL is calculated cause in the nestest log, it begins at 241 and sometimes goes back to -1.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Vash wrote:So if I got it right, the CYC is the number of cycle of the opcodes wraped around at 341.
Each scanline is 341 PPU cycles long, no matter if the console is NTSC (where each CPU cycle equals 3 PPU cycles) or PAL (where each CPU cycle equals 3.2 PPU cycles).
I don't understand how SL is calculated cause in the nestest log, it begins at 241 and sometimes goes back to -1.
There are 262 scanlines in a frame, 240 of those are visible. The log probably starts at 241 because that's the start of VBlank. The one numbered -1 is the pre-render scanline.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

I was going to remove that from the log (and zip it), but then I noticed that it has a disassembly, and even shows what is read from memory by read instructions. We really should have a log that just shows PC, A, X, Y, P, S, with no disassembly or anything else. That'd be much easier to generate for someone just getting their CPU core working.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

blargg wrote:We really should have a log that just shows PC, A, X, Y, P, S, with no disassembly or anything else.
It looks like a job for a Perl one-liner.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

Well, yeah, it's simple to do with a regexp-style replacement. But we must first agree on the format before updating it. Here's one I used to give the following format:

Code: Select all

find: (....)  ............................              (.........................)[^\r]+
replace: PC:\1 \2
Also went and made these replaceents, since P doesn't implement bits 4 and 5:

" P:2" " P:0"
" P:6" " P:4"
" P:A" " P:8"
" P:E" " P:C"

Changed SP to S, since S is the proper name of the register.

Changed : to = sign, the proper mathematical symbol.

We end up with this:

PC=C000 A=00 X=00 Y=00 P=04 S=FD

Any other changes before I update the Wiki with this one?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

blargg wrote:Well, yeah, it's simple to do with a regexp-style replacement. But we must first agree on the format before updating it.
My idea was that each emulator author would make his own RE to thin the log down to the data he needs. On the other hand, the ability to disassemble is a good first step toward making a debugger.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

OK, maybe I'll post a zip of the full log, and this condensed version. No reason not to provide the latter, as a starter that's trivial to compare with.
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

Well now I have my CPU working so I will start the PPU now but there is something I don't understand.

When is frame rendered?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

The PPU renders continuously, from line 0 through line 239, at one dot per CYC in the log (three dots per NTSC CPU cycle). A few fetches for line 0 are performed at the start of line -1.
Post Reply