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

Post by Vash »

Ok thanks for your help. Things get more clear now.

I have started to write the PPU and I'm still working with nestest. I'm launching nestest from the reset Vector and not from C000 anymore and the program seems to loop. Here's my log :

Code: Select all

c004 78  Set Disable Interrupt Flag A=0 X=0 Y=0 P=24 SP=fd
c005 d8  Clear Decimal Flag A=0 X=0 Y=0 P=24 SP=fd
c006 a2  Load X, Immediate ff A=0 X=ff Y=0 P=a4 SP=fd
c008 9a  Transfer X to Stack Pointer A=0 X=ff Y=0 P=a4 SP=ff
c009 ad  Load In A, Absolute @ 2002 = 80 A=80 X=ff Y=0 P=a4 SP=ff
c00c 10  Branch on Plus offset = fb A=80 X=ff Y=0 P=a4 SP=ff
c00e ad  Load In A, Absolute @ 2002 = 0 A=0 X=ff Y=0 P=26 SP=ff
c011 10  Branch on Plus offset = fb A=0 X=ff Y=0 P=26 SP=ff
c00e ad  Load In A, Absolute @ 2002 = 0 A=0 X=ff Y=0 P=26 SP=ff
c011 10  Branch on Plus offset = fb A=0 X=ff Y=0 P=26 SP=ff
c00e ad  Load In A, Absolute @ 2002 = 0 A=0 X=ff Y=0 P=26 SP=ff
c011 10  Branch on Plus offset = fb A=0 X=ff Y=0 P=26 SP=ff
c00e ad  Load In A, Absolute @ 2002 = 0 A=0 X=ff Y=0 P=26 SP=ff
c011 10  Branch on Plus offset = fb A=0 X=ff Y=0 P=26 SP=ff
At start, 2002 = 80 as we're in VBlank. So the BPL doesn't occur. Once it's read, the 7th digit got reset so 2002 = 00 and BPL always occurs.

I don't see what's going wrong here.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

nestest is not a PPU tester. Its tests are not designed to exercise the PPU in a way that yields results whose cause can be easily tracked down.
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

Your right. Except that all the PPU test roms from the wiki display their results on screen, which mean the ppu gotta work.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

Not so; the ppu_vbl_nmi test also outputs the result to $6000 (WRAM). See the readme.
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

Thanks for the info. I didn't know the output was also in the RAM.
I've tried with implied tests rom from instr_test-V2 but I've got errors :

Code: Select all


C:\Users\Vash\Desktop\Rom\instr_test-v2\rom_singles\01-implied.nes

01 de b0 61
2A ROL A
0A ASL A
6A ROR A
4A LSR A
8A TXA
98 TYA
AA TAX
A8 TAY
E8 INX
C8 INY
CA DEX
88 DEY
38 SEC
18 CLC
F8 SED
D8 CLD
78 SEI
58 CLI
B8 CLV
EA NOP
1A NOP
3A NOP
5A NOP
7A NOP
DA NOP
FA NOP

01-implied

Failed
This is weird because even the NOP is failing wheras NOP doesn't do anything.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

Argh, I hadn't put up a newer version that works around APU emulation bugs. It's up now in the CPU tests page as instr_test-v3.zip.
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

I've tried with the V3 but I still have the same output :

Code: Select all

C:\Users\Vash\Desktop\Rom\instr_test-v3\rom_singles\01-implied.nes

01 de b0 61
2A ROL A
0A ASL A
6A ROR A
4A LSR A
8A TXA
98 TYA
AA TAX
A8 TAY
E8 INX
C8 INY
CA DEX
88 DEY
38 SEC
18 CLC
F8 SED
D8 CLD
78 SEI
58 CLI
B8 CLV
EA NOP
1A NOP
3A NOP
5A NOP
7A NOP
DA NOP
FA NOP

01-implied

Failed
Does it come from my implementation? What do I have to do to make it work cause apparently it's not a CPU problem.
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

I've tried the implied test V4. It tries to execute the opcode 0x02 which is the undocumented opcode KIL. It's supposed to stop the execution of the program. I didn't implement as I don't know how to handle it.

Is it supposed to execute this instruction?
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

I'm trying to pass the cpu_interrupts test. I have a problem with the cli_latency rom. Here is the log :

Code: Select all

C:\Users\Vash\Desktop\Rom\cpu_interrupts_v2\rom_singles\1-cli_latency.nes

0B DE B0 61

Unacknowledged IRQ shouldn't let any mainline code run

1-cli_latency

Failed #11
The thing is I have no idea of what it means. What is unaknowledged IRQ?
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

An unacknowledged IRQ is one that hasn't been acknowledged yet.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Vash wrote:What is unaknowledged IRQ?
The CPU has an IRQ pin that tells it to interrupt the program execution and call the IRQ routine, and if you don't acknowledge the IRQ the state of that signal will not change, so when the IRQ routine finishes it will be called again, and again, and again, effectively locking up the program.
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

So does it mean that when $4017 throw an IRQ, we have to read $4015 at start of the IRQ?
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

When $4017 sets the IRQ flag, it will keep telling the CPU to cause an IRQ, until the CPU reads from $4015 (or writes $40 or $C0 to $4017) to tell it to stop requesting an IRQ. $4017 doesn't have any other way of knowing that the CPU handled the IRQ; it doesn't know that the CPU has entered the IRQ handler.
User avatar
Vash
Posts: 21
Joined: Sat Oct 16, 2010 2:51 pm

Post by Vash »

Ok So I guess that this error comes from the fact that something's wrong in my flag handling.
I have an other question about those two registers : 4017 an 4015.
The wiki says that when we set $4017.6, $4015.6 is cleared. Do this work the other way around too? When we read $4015, $4015.6 is cleared so $4017.6 is setted?
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

When we read $4015, $4015.6 is cleared so $4017.6 is setted?
No. There is a separate frame IRQ flag, and the bit last written to $4017.D6. If the latter was last written with a 1, the IRQ flag is never set. Reading $4015 merely clears the IRQ flag; it doesn't affect the last value written to $4017.D6. Usually the Wiki will note significant things like this.
Post Reply