- Let's assume the opcodes timing are correct, but still giving errors in the test ROM. If this is the case, so what could it be? Interrupts timing, as RESET/IRQ/NMI? I can't think another thing...
I'm not sure. The test is quite lenient in its NMI timing requirements, allowing for around 16 CPU cycles error in either direction. I forget, what result do you get when you run it?
Opcode 01h with timing 7, should be 6.
Did it mention "WITH PAGE CROSS" or not? Post the relevant code that emulates opcode $01 in your emulator (ORA indirect,x). It should always take 6 CPU clocks.
Sorry to bother you, I already found the "extra" cycle. My bad, thanks anyway. The test has PASSED. ^_^
The "extra" was in the addressing mode, an ugly bug.
Nice to hear you're passing the CPU timing test. Seems like you spent a lot of time tracking down problems a month or two ago.
Along the lines of this test, I recently wrote a Z80 emulator (an ugly, ugly processor) and found a great test suite called
zexall which tries millions of test cases on all instructions and catches very obscure problems. I want to figure out how it works and write an equivalent for the 6502. The beauty of its design is that it just takes a 32-bit checksum of every intermediate processor state and compares these with the correct value when run on the real thing, so the code itself is quite short. Unfortunately it can't give you much detail on the problem, so you have to run in parallel with a CPU core that passes the test.
Sounds similar to the testsuite that i used to use for my 6502 emulator. Wolfgang Lorenz (PC64) wrote a whole bunch of C64 6510 tests, each opcode having its own test binary. John Saeger (z26) pointed me towards these tests.
If i wasn't lazy, the right thing to do would have been to just disassemble them and extract the actual code, creating a megatest for all ops. But, i'm lazy, so i wrote a minimalist C64 emulation shell which had a simple memory map and handled the "output a string" system call.
If folks are interested, i can disassemble the code for all the tests and build a rom image.
So i was able to find the original disk images of the CPU tests i spoke of above. I converted from .D64 -> Turbo Macro Pro assembler .ASM format, then to plaintext assembler. It should be relatively easy to convert this to something that will assemble for nes.
You can find them here:
http://www.baisoku.org/pc64test.zip
If anyone makes something useful out of this, let me know. I might get a wild hair and do something myself.
Wait...
Are there TWO versions of that 6502 timing test? One says "Official instructions only" (16 seconds) 09/20/2006, and PASSED. The other says 12 seconds (09/14/2006) and it gives error on opcode 04h (emulator 4, correct 3).
So... what's up??? -_-;;
Opcode 4 is an undocumented zeropage NOP. Perhaps another bug in the addressing mode?
Zero page? Not implicit? So, I guess... Fixed.
Guess I'll take a break about unimplemented opcodes... 0Ch.
There are three different tests that can be performed based on what buttons you hold when the test is starting: official opcodes only, official + the various NOPs, and all (except branches, since I released a separate test for them). The readme summarizes how the NOPs behave, and they're simple to implement. The verified timing tables are there too.
baisoku, yeah, the zexall test also used one BIOS routine at address 5 to print characters and strings, so I had to write a simple shell for it. Simpler than tracking down a Z80 assembler and getting the sources reassembled.
blargg, wow zexall is crazy. that wild hair is bugging me and i think i'll put together an NES image of W.L.'s tests once i dequeue enough other high priority tasks.
And yes, z80 is an ugly, ugly thing.