Working out the kinks, where to go first.

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
MatthewCallis
Posts: 82
Joined: Sat Sep 22, 2007 8:32 am
Location: Seattle, WA
Contact:

Working out the kinks, where to go first.

Post by MatthewCallis »

After many days of browsing and casually working on my emulator I've managed to fix many things and get some game working more than they already were (without breaking those that already work). But now I'm working at many different areas all at once, and I'd just like some advice as to where to go next. Any advice is welcome as to which test to work towards passing next or why I should do them in a certain order would be helpful or any other good test ROMs or games.

I'm basing my progress on the pass / fail test of many test ROMs below. Yes, I do realize some test must be PASSED IN ORDER and some older test might not pass at all (NESstress), they're here for further updates as test become fixed.

Code: Select all

nestest:
   branch test:         ok
   flag test:           ok
   immediate test:      ok
   implied test:        ok
   stack test:          ok
   accumulator test:    ok
   (indirect,X) test:   ok
   zeropage test:       ok
   absolute test:       ok
   (indirect),Y test:   ok
   absolute,Y test:     ok
   zeropage,X test:     ok
   absolute,X test:     ok

   NOP:           ok
   LAX:           ok
   SAX:   89      SAX (indr,x) failure
   SBC:           ok
   DCP:   A0      DCP (indr),y failure
   ISB:   B8      SAX zp,y failure
   SLO:           ok
   RLA:   E8      RLA abs,x failure
   SRE:   FD      SRE abs,x failure
   RRA:   15      RRA abs,x failure

====================

NEStress (PD) [a1]:
   PPU Normal Write/Read            OK
   PPU Write Read Write             OK
   PPU First Read Then Write        OK
   PPU First Read Correct           OK
   PPU Mixed Address / Data Write   Error   PPU address isn't changed before both bytes are written to the address register
   PPU $3000 Mirroring              Ok
   PPU $3FFF-$0000 Wrap Around      OK
   Mix writes to $2005/$2006        OK
   Read $2002 to reset latch        OK
   Use $2002/5 to set address       OK
   PPU Palette Write / Read         Error   At least the Dr. PC Jr has this memory before the "pipe"
   VBL test, bit 7 of $2002         OK

   CPU:   47/48 (CPU RAM Error, Mirror OK though...)

====================

Overflow Test (Alastair Bridgewater, 2001 Oct 19):
   ADC 00
   SBC 00
   * Passes but it's totally white since I've fixed NESStress and blargg's PPU test, before is was shown.

====================

NES Test Cart (Official Nintendo) (U) [!]:
   Video RAM (U4):   OK
   Work RAM (U1):    OK
   Controller:       OK
   Obj Test:         OK
   Pallette:         OK (I guess?)
   Squares:          OK (I guess?)

====================

Port Test Cartridge (U):
   "NES Controll Deck Test"
   Charactor      Error
   Video RAM      *Doesn't geth this far
   Work RAM       *Doesn't geth this far
   Input Port     *Doesn't geth this far

====================

POWERPAD.NES:
   Doesn't work, doesn't even display right.

====================

read2004.nes:
   AA AA ...
   AA AA 00 00 00 00

====================

Scanline PPU Test by Quietust (PD) [a1]:
   Stars for first paragraph
   Stars for second prargraph and incomplete paragraph display
   No more paragraphs

blargg_apu_2005.07.30:
   01.len_ctr               $04               Writing $80 to $4017 should clock length immediately
   02.len_table             $F8 $FF $1E $02   Difference of 7
   03.irq_flag              $04               Flag should be set in $4017 mode $00
   04.clock_jitter          $03               Frame irq is set too late
   05.len_timing_mode0      $02               First length is clocked too soon
   06.len_timing_mode1      $02               First length is clocked too soon
   07.irq_flag_timing       $03               Flag first set too late
   08.irq_timing            $04               Never occurred
   09.reset_timing          $04               Fourth step occurs too late
   10.len_halt_timing       $03               Length should be clocked when halted at 14915
   11.len_reload_timing     $02               Reload just before length clock should work normally

blargg_ppu_tests_2005.09.15b:
   palette_ram              $01      OK
   sprite_ram               $01      OK
   vram_access              $01      OK
   vbl_clear_time           $03      VBL flag cleared too late
   power_up_palette         $02      Palette differs from table
   ---
   http://nesdev.com/bbs/viewtopic.php?t=567
   http://www.slack.net/~ant/nes-tests/
   Palette at power-up:
   0x09,0x01,0x00,0x01,
   0x00,0x02,0x02,0x0D,
   0x08,0x10,0x08,0x24,
   0x00,0x00,0x04,0x2C,
   0x09,0x01,0x34,0x03,
   0x00,0x04,0x00,0x14,
   0x08,0x3A,0x00,0x02,
   0x00,0x20,0x2C,0x08

branch_timing_tests:
   Branch_Basics:          #3   NMI period is too too long
   Backward_Branch:        xx
   Forward_Branch:         xx
   ---
   http://nesdev.com/bbs/viewtopic.php?t=1843

CLI Latency Test:
   cli_latency:         #3   APU should generate IRQ when $4017 = $00
   ---
   http://nesdev.com/bbs/viewtopic.php?t=2697

NES 6502 Timing Test:
   cpu_timing_test:       Basic timing wrong
   cpu_timing_test4:      Basic timing wrong
   cpu_timing_test5:      Basic timing wrong
   cpu_timing_test6:      Basic timing wrong
   ---
   http://nesdev.com/bbs/viewtopic.php?t=2691

MMC3:
   1.Clocking            #3*   Should decrement when A12 is toggled via $2006
   2.Details             #2   Counter isn't working when reloaded with 255
   3.A12 Clocking        #4   Should be clocked when A12 changes to 1 via $2006 write
   4.Scanline Timing     **   CRASH
   5.MMC3 Rev A          OK*   Pass
   6.MMC3 Rev B          #2*   Should reload and set IRQ every clock when reload is 0
   * Crashes or garbage
   ---
   http://nesdev.com/bbs/viewtopic.php?t=2895

PPU Sprite 0 Test:
   01.basics          OK
   02.alignment       #3   Sprite should miss left side of bg tile
   03.corners         OK
   04.flip            OK
   05.left_clip       Left-edge clipping occurs when $2001 is not $1e
   06.right_edge      OK
   07.screen_bottom   Can hit when Y < 239
   08.double_height   Lower sprite tile should hit bottom of bg tile
   09.timing_basics   Upper-left corner too late
   10.timing_order    Upper-left corner too late
   11.edge_timing     OK

Sprit 0 Hit Timing:
   sprite_hit_timing   #5   Sprite 0 hit was set too late
   ---
   Tests sprite 0 hit timing to within 4 CPU clocks (12 PPU clocks).
   Tests time it's cleared each frame, time it's set at upper-left corner, time for each PPU pixel, and time for each PPU scanline.
   Depends on proper PPU frame length (less than 29781 CPU clocks).

PPU Sprite Overflow Flag Test:
   1.Basics      #3   Reading $2002 shouldn't clear flag
   2.Details     #2   Should be set even when sprites are under left clip (X = 0)
   3.Timing      #4   Set too early for first scanline
   4.Obscure     #2   Checks that second byte of sprite #10 is treated as its Y
   5.Emulator    #3   Disabling rendering didn't recalculate flag time
   ---
   http://nesdev.com/bbs/viewtopic.php?t=3307
   http://nesdev.com/bbs/viewtopic.php?t=2294
   http://nesdevwiki.ath.cx/wiki/index.php/NES_PPU#Sprite_evaluation

VBL/NMI Timing Tests:
   1.frame_basics       #2   VBL flag isn't being set
   2.vbl_timing         #2   Flag should read as clear 3 PPU clocks before VBL
   3.even_odd_frames    #2   Pattern ----- should not skip any clocks
   4.vbl_clear_timing   #3   Cleared 2 PPU clocks too early
   5.nmi_suppression    #2   Reading flag 3 PPU clocks before set shouldn't suppress NMI
   6.nmi_disable        #3   NMI should occur when disabled 3 PPU clocks after VBL
   7.nmi_timing         #2   NMI occurred 3 or more PPU clocks too early
   ---
   http://nesdev.com/bbs/viewtopic.php?t=2616 
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch »

Definately focus on the CPU first and foremost. Any other test can give you a false result if CPU emulation is incorrect. This is doubly true when it comes to timing. A lot of blargg's tests focus on getting the timing right down to the cycle (or very close to it), so if your instructions are running longer or shorter than they should, those tests will be unreliable.
User avatar
blargg
Posts: 3717
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

Like Disch says, errors in a more fundamental area will cause bogus errors in other areas. Many of my test ROM sets are numbered such that failure of an earlier test means that later ones will give bogus failures as well. The CPU timing test result for your emulator means that something basic isn't timed right, or the 60 Hz frame (which it uses as a basis for timing) is way off.
tepples
Posts: 22345
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Disch wrote:Definately focus on the CPU first and foremost. Any other test can give you a false result if CPU emulation is incorrect. This is doubly true when it comes to timing.
Do the test ROMs require proper operation of undocumented instructions, except for those specifically designed for testing undocumented instructions?
User avatar
hap
Posts: 355
Joined: Thu Mar 24, 2005 3:17 pm
Contact:

Post by hap »

no
Post Reply