6502.org

The current version of the tests can now also be found on GitHub:
https://github.com/Klaus2m5/6502_65C02_functional_tests

Klaus2m5:

Thanks again. After reading your readme.txt file, do you think you could make a your functional test suite available for both Verilog and VHDL cores instead of just VHDL cores?

Klaus:

Succeeded in loading the 6502 functional test suite into my simulation environment. It has completed tests through number $29 (41), before it ran out of memory. I've gone back through the thread looking for the total number of tests conducted, and I can find no mention of the number of tests. I expect there to be $2A (42). Can you confirm the total number of tests conducted with this component of the functional test suite? Also, is it possible to jump into test $29? I'd like to avoid using ModelSim for the simulation.

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

Just to be above board regarding the M65C02 processor core, M65C02_Core.v, and the example soft-processor, M65C02.v, that I'm testing with Klaus' functional tests:

(1) it is not cycle accurate. It can be made that way, but that is for someone else to do. To do so would not require any Verilog source code changes.

(2) it treats subroutine calls and traps in the same manner. This means that JSR, BRK, NMI, and IRQ all require the return address to be incremented
by one on a RTS/RTI in order to point to the instruction. To change this behavior will require Verilog source code changes.

(3) it implements all undefined instructions as single cycle NOPs. It can implement the variable cycle length NOPs, but that is for someone else to do.
Again, it is possible to implement variable cycle NOPs without modifying any Verilog source code.

(4) some instructions are currently uninterruptable. That behavior can also be changed without changing the Verilog source code.

As a consequence of #2 above, I've modified the test suite's test of the BRK return address. I added a minus 1 to the constant in the test suite. Other than that, the M65C02 core and soft-processor have passed all tests as written by Klaus. I wrote an exhaustive test bench simulation for the binary and decimal adder, so I expect that there will be no issues with test numbers $29 and $2A.

sorry for that i was such an idiot, i modified your testsuite to test the next error from the t65. But for the mos6510 tests i used the same rom and so it trapped because it worked.

Hi Michael,

the test numbering is a fairly new feature and is dynamic as one could divide the test into smaller segments if memory is an issue. In the unmodified version the last test is indeed test $2a (ADC & SBC decimal all addressing modes). The purpose of the test numbers is to prevent an unintentional skip of a test and therefore would prevent you from just jumping to test $29.

In order to allow just the last two tests to be executed you need to modify the source and remove all unwanted tests leaving just the last remaining tests to be assembled into an object file. You can accomplish this eather by removing code between the next_test macros including the first macro or by using conditional assembly like: Regarding NOPs: The test does not count cycles as this would require an external timer. However it does count instruction bytes and in the 65c02 the undefined opcodes are defined NOPs of 1 to 3 bytes length. So the test will fail the NOP test in the 65c02 extended opcodes test.

By the way, Verilog cores are also supported

Xeniter,

no problem, we all have such moments from time to time. Still I wouldn't call myself or anybody else an idiot for that. It sometimes just needs another pair of eyes...

Thanks for confirming the number of tests, and that the binary and decimal mode ALU tests are not dependent on previous results.

Am putting in some conditional assembly around these two tests now. Will likely add your recommendation skip the other tests once they've been completed in an orderly manner.

Michael,

if you refer to running out of memory as reaching the maximum trace buffer in your simulation environment, changing to just running 1 of the ADC & SBC tests may not be sufficient. These tests are the only ones iterating through all possible combinations of operands, 64k in binary mode, 10k in decimal mode. All other tests run with a small number of predefined operands.

Klaus:

Yes, it's an ISim issue. It's never been a terribly well respected product, but I tend to use it because ModelSim is too expensive for the average Xilinx user to purchase. Thus, if I can simulate it with ISim, I am generally comfortable that the design can be supported by others. I've considered looking into VeriWell, Verilator, and Icarus, but just haven't found the time.

It's not my intention to abbreviate the tests. If I can't do them in the simulator, I will have to get a monitor running on my little test board. I prefer running in ISim first, and then on the target hardware. In some ways the simulator environment provides provides more debugging resources on the HW side, but it will run out of memory in those cases where long run times are necessary.

I have found that the decimal mode routines have stopped at the 199 return from the chkdad subroutine. Do you have a suggestion on how to identify the error condition.

Don't want to admit how rusty I am in programming. The adage use it or lose it is definitely true. Had to back track to your original source and start over. Now have a stable source that can be used to generate a binary image from $0000 to $FFFF. It has five small mods.

If you refer to an expected ADC result of 99 with carry the decimal test most probably stopped at the first run through chkdad. It is counting downwards with both ADC and SBC operands setup to match the expected result. You can find the expected results here:The actual result is what the accumulator contains when compared to adrl and what the processor status carry bit is by loading it into the accu and comparing it to bit 0 of adrh. The operands to ADC are ad1 (accu), ad2 (memory or immediate) and adfc (carry input). For SBC ad2 is replaced by sb2 (complement of ad2) which in turn should give the same result as ADC. The trap address would point to which opcode failed with which addressing mode and wether it was adrl (expected result) or adrh (expected carry, other flags ignored).

So you need the listing, the content of the registers (PC, accu & carry) and lower zero page memory to identify the error.

Klaus:

Thanks for the reply. I placed a counter on the RTS from "chkdad". That's how I was able to determine that the test had gone into and returned $C7 (199) times. I will use your variable locations to check for the error conditions.

If I interpret you correctly, each pass through "chkdad" essentially checks 100 operands pairs for all addressing modes of ADC and SBC. The calling test driver sets one (Accumulator) operand and the subroutine sets the other as either immediate or some memory operand..

Unfortunately, I've got work to go to later this morning. It may take a while to mod the testbench to put in the proper memory probes. Thus, it may be a day or so before I can report back on.your recommendations.

Michael,

the calling routine sets both operands, chkdad only checks 1 operand pair plus carry for all addressing modes. So after 199 calls to chkdad (2 calls per decrement with toggling carry) it has decremented ad1 (the accu operand) to 0 and added ad2=$99 + adfc=1 (carry set) (subtracted sb2=0 without borrow) = result adrl=0 with adrh=1 (carry set). 200th entry of chkdad is with ad1=0 ad2=$99 adfc=0 (carry clear) and expects adrl=$99 adrh=$00 (carry clear).

Klaus:

Am back on the trail. Unable to spend any time during the week. I have compiled the following table of results for my core using your 6502_Functional_Test.a65 program. For each of the tests that the core has completed, I've noted the execution time. Do you see any times that you would characterize as abnormal/unexpected?
Edited: Figure with the results of the decimal mode ADC/SBC tests.

Klaus:

I reached that point again in the BCD routine. Tracked the issue down to an error I introduced when I converted all of the ALU multiplexers to gated outputs and an OR gate combiner. I have corrected the error, and the functional test has passed that point. In fact, the simulation has iterated 10,000+ times. If I read your prior post correctly, it appears that a total of 20,000 calls and returns to chkdad() are required to complete this test.

I may skip the binary mode tests for this effort. If the same logic applies to both tests, I would expect that the binary mode check to be called 131,072 times. The decimal mode tests execute on the order of 25.4us/iteration, or ~512ms for the test. The binary mode tests would require about 6x as much time to complete.

I have doubts of being able to use ISim for a simulation of that length. I will likely give it a try, but I am expecting the same "out of memory" error.

I would certainly like to thank you for your 6502 functional tests. The special condition that your test helped identify would have led to some odd errors in decimal mode code. I will have to consider incorporating some of your test techniques into my functional test program that I've been using for regression testing. It certainly did not pick up on the problem your test identified. I will also have to go back a take a look at the ALU and BCD adder test benches. I did not run them again, but relied on my test program for regression testing after I changed the implementation of the bus multiplexers in the M65C02 core.

As I was writing this post, ISim completed the decimal mode test: 0.5120052 s. May let it run the binary mode tests, but it will take several hours to run and I expect it to run out of memory in the process.

Hi Michael
Did you already run Bruce's ADC and SBC tests? It's possible that they take fewer cycles than Klaus' - it would be interesting indeed if they miss some errors which Klaus does not.
See http://www.6502.org/tutorials/decimal_mode.html#B
Cheers
Ed