It is fixed in the newest version dated 02-mar-2013.

I added a push pull test to verify flags and registers are not altered by PHA, but are correctly altered by PLA.

The new version is now on my 6502 emulation project page http://2m5.de/6502_Emu/index.htm
and the direct download link is http://2m5.de/6502_Emu/6502_functional_tests.zip

These links should always have the newest version from now on.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Fantastic!

As an aside, have you thought about putting the test suite on github? I've noticed myself (and seen links posted by others) pulling up https://github.com/redline6561/cl-6502/ ... l_test.a65 in a browser, just because it's easy to check quickly without downloading and unzipping. Hosting it there would give a nice, visible, linkable canonical location.

Also, it would allow people to send you pull requests

(I've sent a pull request to redline6561 - whatever Klaus chooses to do, it would be good to have redline's version up to date)

Klaus: thanks, of course, for the extra check!

Cheers
Ed

Edit: my pull request was merged. Quick work!

Thank you Ed for sending the pull request and getting the github version updated. I am currently not planning to put it up on github myself.

cheers, Klaus

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

I did run Klaus's test on Arlets core and it passed. Here is the code coverage report
from covered. I will try to see if I can extract the untouched code.

John Eaton



Covered covered-0.7.10 -- Verilog Code Coverage Utility
Written by Trevor Williams (phase1geo@gmail.com)
Freely distributable under the GPL license

:::::::::::::::::::::::::::::::::::::::::::::::::::::
:: ::
:: Covered -- Verilog Coverage Summarized Report ::
:: ::
:::::::::::::::::::::::::::::::::::::::::::::::::::::


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GENERAL INFORMATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Report generated from CDD file : Arlet_6502_cpu_def.cdd

* Reported by : Module

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LINE COVERAGE RESULTS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Module/Task/Function Filename Hit/ Miss/Total Percent hit
---------------------------------------------------------------------------------------------------------------------
$root NA 0/ 0/ 0 100%
Arlet_6502_cpu_def cpu_def.v 375/ 5/ 380 99%
Arlet_6502_ALU_def cpu_def.v 30/ 0/ 30 100%
---------------------------------------------------------------------------------------------------------------------
Accumulated 405/ 5/ 410 99%


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TOGGLE COVERAGE RESULTS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Toggle 0 -> 1 Toggle 1 -> 0
Module/Task/Function Filename Hit/ Miss/Total Percent hit Hit/ Miss/Total Percent hit
---------------------------------------------------------------------------------------------------------------------
$root NA 0/ 0/ 0 100% 0/ 0/ 0 100%
Arlet_6502_cpu_def cpu_def.v 222/ 30/ 252 88% 224/ 28/ 252 89%
Arlet_6502_ALU_def cpu_def.v 79/ 1/ 80 99% 79/ 1/ 80 99%
---------------------------------------------------------------------------------------------------------------------
Accumulated 301/ 31/ 332 91% 303/ 29/ 332 91%


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ COMBINATIONAL LOGIC COVERAGE RESULTS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Logic Combinations
Module/Task/Function Filename Hit/Miss/Total Percent hit
---------------------------------------------------------------------------------------------------------------------
$root NA 0/ 0/ 0 100%
Arlet_6502_cpu_def cpu_def.v 582/ 92/ 674 86%
Arlet_6502_ALU_def cpu_def.v 96/ 1/ 97 99%
---------------------------------------------------------------------------------------------------------------------
Accumulated 678/ 93/ 771 88%

The code coverage test is interesting. Did you run with RDY toggling ? If you can find out what wasn't tested, we could find ways to improve the test suite.

I checked on that. The only lines that were never executed involved RDY , IRQ and NMI. They were all tied off. Looks like the only improvement would be to add a reference design capable of controlling these ports.



John Eaton

I have done a test with RDY randomly toggling while performing the test suite, using $random. That's easy to test, because it doesn't require any cooperation from the test suite. For IRQ/NMI it's a little harder because it needs to be synchronized with the test suite. For instance, by writing to a special IO location to trigger an IRQ or NMI, preferably with a controlled delay.

I don´t think, the delay is all that important. The only reason for a controlled delay would be to test, wether interrupts are synchronized with the beginning of the next instruction and you don't get halfway executed opcodes. Wether an interrupt is taken on the next instruction or on the instruction after that will not cause any problems by itself if the interrupt works correctly.

The rest only needs a simple feedback register to NMI/IRQ. That will allow you to test propper use of the stack and that nothing gets modified except the I-bit and the PC.

I will look into adding a register and bit definition to run at least a static test.

To test with more specific external hardware like a timer should be in a separate test.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

While you're in there changing things, I had one other idea: I find myself recompiling the latest version of your test, then checking the listing to set the "success" address in my test code (https://github.com/zellyn/go6502/blob/m ... al_test.go). How about putting the "success address" at a known location near the beginning of the file, so it stays consistent?

(Eventually, I plan on writing my own assembler, so I can just load the .a65 file directly, and then I can find out the label addresses easily. But that might take a while... I'm working on a golang translation of perfect6502 first, and the Apple ][+ emulator might prove more interesting than an assembler for a while.)

You may not have noticed, but success is a macro! You can make it play "we are the champions" if you want. So you could replace the builtin success macro with your own like:

To keep the changes for upcoming versions you either need to replace this macro every time or you copy all configurable items to a separate include file and edit the new source to refer to the include file.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Aah. Of course. Thanks!

I'll probably just write a sed script to stick that in there each time.

fyi, right now I'm running your test suite against my first pass at a naive go-language translation of perfect6502. I expect it to take somewhere around three days, although I might get bored and start optimizing before then.

I just ran the test suite on my 6502 Sandbox with W65C02 processor, and it passed. I did have ROM_vectors = 0.

FYI, I am currently running my gate-level emulation in parallel with my instruction-level emulation, and finding discrepancies. Most are missing ignored reads.

However, it appears I managed to pass the functional tests with ZP,x and ZP,y instructions that would read from page 1 when the ZP address and x/y added to more than 0xFF.

Missing ignored reads are nothing, that a test program could find. Ignored reads don't make it into a register to be checked by following instructions. They are overridden by the next valid read of the same instruction or even not gated to a register. Of course an instruction level emulation would not emulate overhead like ignored reads or double writes. In conjunction with IO registers they could actually lead to unexpected behavior and really are bugs in the original design. Even on later designs like the 65C02 these are ironed out without compromising functional compatibility with the original design.


Wraparound is tested only with loads and stores assuming that the identical address generate logic is applied to all instructions potentially wrapping around. I would need a bit more information about which instruction is illegaly not wrapping around and wether you have changed the starting location of the page zero data segment (zero_page = $a ;is the default).

_________________
6502 sources on GitHub: https://github.com/Klaus2m5