Is there a list of tests with descriptions somewhere?

My simulator is stuck on test 0x29 and keeps running chkadd.

I attach a memory map (forcibly interrupted the simulation after 10 million cycles).

_________________
6502 addict

I think you need a listing corresponding to the exact version of the test suite you're running.

See the sources at
https://github.com/Klaus2m5/6502_65C02_functional_tests

I looked at the listing and compared it to what happens in the simulator.

- Execution is not stuck on `trap` (bne * and similar)
- The addition/subtraction check test (`full binary add/subtract test`) is constantly spinning in the check loop, which means it never completes, but it doesn't cause an error (trap) either.

Maybe someone has encountered this?

_________________
6502 addict

If one of your increment or test or branch instructions is buggy, would that have this effect?
Or if an instruction changes a flag which it shouldn't, just possibly.

That's normal. It spends a lot of time in chkadd.

My simulator isn't for a standard 6502, and the timing isn't quite the same. But for what it's worth, I get 94.4 million cycles to complete the whole test (without 65C02, and without decimal mode). I'd expect a real 6502 to take a little longer, but not very much. If yours is still stuck after 150 million cycles, then something is probably wrong.

My M65C02A core reports 65,088,958 cycles to complete Klaus' basic 6502 functional tests. My core has an instruction cycle time that is approximately 1 cycle shorter on many instructions. In previous benchmark testing, my core's implementation is approximately 40% faster, on a clock cycle basis, than a standard 6502/65C02 cycle accurate implementation. Thus, I think that you should expect that Klaus' functional test will require something close to 91M clock cycles to complete for all tests of the basic functional test suite. My estimate is in good agreement with John West's measurements. So I would expect your 6502 emulation / simulation to execute about that many cycles to complete Klaus' 6502 functional test suite, or you may have an issue to find and resolve.

When initially getting my instruction set implementation to pass the tests, I had to modify Klaus' test suite such that I could execute each functional test individually. I used this approach to get all of my instructions to pass his test suite, and then I ran it all as a single test suite.

I don't recall what errors were causing me to hang in the functional test while I was debugging my implementation. One thing is for sure, you appear to be hanging in the exhaustive test for ADC / SBC, test #0x29. Try skipping that test and go to the exhaustive BCD test that follows. My data on that specific test shows that I required approximately 9.5M cycles to complete just that one test, which can seem to be an eternity, and certainly stressed the memory of my FPGA simulator and my patience.

_________________
Michael A.

Thanks for the valuable information on the number of cycles, now I understand how long to wait.

I just need to be patient

_________________
6502 addict

The test took 96241361 cycles and was successful.

If you are interested, more details about the simulator can be found here: viewtopic.php?p=90709

_________________
6502 addict

Wow - how long to run this test on a gate-level model? I wonder if you're the first to do that.

See also previously
How long should Klaus functional test take?

Debug builds take ~55 minutes. Release build with all optimizations takes ~8 minutes.

But this is considering that the execution is extremely sub-optimal (because it is executed in the debugger context), plus in a managed code environment (the debugger is written in c#). In combat conditions (native c++ emulator) it should run even faster.

_________________
6502 addict

Looking into my results more deeply, I found that I was prematurely terminating in the BCD tests for ADC / SBC due to an error in my ADC / SBC instruction models.

To correct the BCD ADC / SBC error, I incorporated the model of the adder from my FPGA implementation. This change to my simulator allowed 65c02_ft.bin to finish without error. In my simulator, 65c02_ft.bin requires 74,338,469 to finish. For this test, the savings are approximately 29.46% in comparison to org's reported cycle time above.

I may choose to use the new adder model for all arithmetic instructions: inc / dec / cmp, and adc / sbc. It is currently only being used for the decimal mode of the adc / sbc instructions. In my FPGA implementation, the adder is used for all arithmetic instructions.

Because Python does not easily implement the bit-level arithmetic used in the verilog model for the FPGA model, I expect that changing over to using the FPGA adder model will result in a decrease in simulator performance, but I haven't run a benchmark to determine the performance loss.

_________________
Michael A.