Functional Test for the NMOS 6502 - request for verification

[redline6561]

Thanks, BigEd! I actually spent the last two weeks optimizing and performance has improved by a factor of 4. So instead of 13 seconds to run the test suite, it takes about 2 and a half. I'm still nowhere near lib6502 but I'm gonna take a break for a few weeks. At 762 lines, I think I've at least got the smallest implementation. Oh, there's also a readable book of the source now. http://redlinernotes.com/docs/cl-6502.pdf

Happy hacking!

[BigEd]

I saw the book - nicely done. Thanks for the credit too!

[Klaus2m5]

I have written two additional tests. However, they have only been verified with a self written emulator and not with real hardware and may therefore contain bugs. So I am eager to hear of your experience with these tests to help me improve them.

The first added test is aimed at verifying the interrupt system in both the classic NMOS 6502 and the newer 65C02. It requires a feedback register to self-inject IRQ and optionally NMI requests. A register port and optionally a DDR address must be configured. In addition you can choose wether the output is push/pull or totem pole (inverted, driving the DDR if present). 3 handloops with usage instructions assist in testing the WAI and the STP instruction.

The second added test verifies the extended functionality of the 65C02. There are options to configure testing of the additional opcodes not present on all versions of the 65C02. The basic funtional test for the NMOS cpu is a prerequisite to the 65C02 test as it tests only the added opcodes, addressing modes and functional differences.

As always, the tests can be downloaded here: http://2m5.de/6502_Emu/6502_functional_tests.zip

Good luck debugging your emulator, simulator, vhdl core, discrete logic implementation or whatever you have!

[8BIT]

Thanks for creating those tests Klaus!

I will have to run both on my AVR65C02 Emulator, as soon as I get some time.

Daryl

[8BIT]

Hi Klaus,

I tried the 65c02 extended opcode test today. I pasted in the same trap macros that I used from the original test. That provides a BRK for each trap which dumps the registers to the screen. However, I'm getting "branch too far" errors at the BRA commands just after label bra2 and bra0. I presume this is because my macros consume more bytes that yours did.

Here are my macros:

Code: Select all

trap    macro
        brk           ;failed anyway
        endm
trap_eq macro
	local trend
	code
        bne trend           ;failed equal (zero)
	brk
trend
        endm
trap_ne macro
	local trend
	code
        beq trend           ;failed not equal (non zero)
	brk
trend
        endm
trap_cs macro
	local trend
	code
        bcc trend           ;failed carry set
	brk
trend
        endm
trap_cc macro
	local trend
	code
        bcs trend           ;failed carry clear
	brk
trend
        endm
trap_mi macro
	local trend
	code
        bpl trend           ;failed minus (bit 7 set)
	brk
trend
        endm
trap_pl macro
	local trend
	code
        bmi trend           ;failed plus (bit 7 clear)
	brk
trend
        endm
trap_vs macro
	local trend
	code
        bvc trend           ;failed overflow set
	brk
trend
        endm
trap_vc macro
	local trend
	code
        bvs trend           ;failed overflow clear
	brk
trend
        endm
success macro
        brk               ;test passed, no errors
        endm

Any ideas for a workaround?

thanks!

Daryl

[Klaus2m5]

Hi Daryl,

you can remove the crazy branch test for now until I find a way to dynamically limit the BRA range.

Simply remove the code lines including the next_test macro just ahead of the crazy branch test comment until the next occurence of the next_test macro. There is still enough code left (BRA integrity, BRA shortrange) to test the opcode.

Thank you for letting me know!

cheers, Klaus

[8BIT]

Thanks for the work around. I will give that a try.

Daryl

[Klaus2m5]

Hi Daryl,

I have an intermediate version of the test now with the BRA test shrunk to allow that the trap macros could at least contain a JSR plus a skipping branch. It is now on my list of things to test prior to any new release.

The test also has a new RAM integrity test which should detect unintentional RAM writes during the opcode tests. However, it is by default disabled since it requires that absolutely no other program in the background will write to RAM while the test is running. And it is going to be a pain to debug if you find a problem with it.

65C02_extended_opcodes_test.zip

(13.4 KiB) Downloaded 129 times

cheers, Klaus

[Arlet]

Klaus2m5 wrote:

And it is going to be a pain to debug if you find a problem with it.

It's going to be an even bigger pain without the test suite to point it out.

[8BIT]

Hi again Klaus,

Your BRA fixes did not cause errors - good news.

The test ran down to the BBR/BBS tests and pointed out some bugs in my emulator. Those fixed, it proceeded to the BIT tests. I had trouble with the BIT # code. After some studying, I think the error is in your code: (see the label at the bottom for a positive location in the source file)

Code: Select all

        set_a $ff,0
        bit #$00    ;00 - should set Z
        tst_a $ff,fz 
        dex
        set_a 1,0
        bit #$41    ;41 - should clear Z
;        tst_a 1,0
	tst_a 1,fv  ; should set v bit
        dex
        set_a 1,0
        bit #$82    ;82 - should set Z
;        tst_a 1,fz
        tst_a 1,fnz  ; should set n&z bit
        dex
        set_a 1,0
        bit #$c3    ;c3 - should clear Z
;        tst_a 1,0
        tst_a 1,fnv  ; should set n&v bit
        
        set_a 1,$ff
        bit #$c3    ;c3 - clear Z
        tst_a 1,~fz
        inx
        set_a 1,$ff
        bit #$82    ;82 - should set Z
;        tst_a 1,$ff
        tst_a 1,~fv  ; should clear v bit
        inx
        set_a 1,$ff
        bit #$41    ;41 - should clear Z
;        tst_a 1,~fz
        tst_a 1,~fnz  ; should clear n&z bit
        inx
        set_a $ff,$ff
        bit #$00   ;00 - should set Z
;        tst_a $ff,$ff
        tst_a $ff,~fnv  ; should clear n&v bit
        
        cpx #3
        trap_ne     ;x altered during test
        cpy #$42
        trap_ne     ;y altered during test 
        tsx
        cpx #$ff
        trap_ne     ;sp push/pop mismatch

; testing TRB, TSB - zp / abs

trbt    macro       ;\1 = memory, \2 = flags   

I commented out some tst_a macro calls with inaccurate parameters and replaced with ones I think have the correct parameters. Please check me - my tests now pass through to the TRB code. I probably have more errors in my emulator but that will have to wait for another day.

Great work by the way. This kind of code is very hard and tedious to write. My thanks to you for your hard work!

Daryl

[Klaus2m5]

Hi Daryl,

thank you, for taking the time to run the test and reporting the problems with it.

The BIT immediate tests also failed initially on my emulator - and they fail on the Kowalski simulator. But I checked again against WDCs programming reference manual http://www.westerndesigncenter.com/wdc/ ... manual.pdf and it states on page 333:

Quote:

When the BIT instruction is used with the immediate addressing mode, the n and v flags are unaffected.

and

Quote:

Flags Affected: n v - - - - z - (Other than immediate addressing)
_____________ - - - - - - z - (Immediate addressing only)

This is consistent with Bruce Clarks' tutorial about 65C02 opcodes on this website: http://www.6502.org/tutorials/65c02opcodes.html#2

It seems, the BIT immediate opcode is an exception in that it effects different flags than the rest of the BIT addressing modes. This makes perfect sense since on an immediate operand you always know what bit 7 & 6 are going to be. At this time I don't think it's a bug in the test.

cheers, Klaus

update: I have browsed a few more datasheets now and the result is ambiguous. Rockwell said M7 & M6 (N & V) is undefined after BIT #. GTE said no change of N & V. Some others, even WDCs' own datasheet didn't mark any deviation between the addressing modes. I may put in a switch to select which behavior you like best. ... and make you sign a "proceed at your own risk agreement" of course.

[8BIT]

Wow, you have really done your homework! It does make sense that an immediate value is known and setting bits 6&7 is useless. I had that same thought while figuring out the mismatches.

Thanks for the great explanation! I will make the changes on my emulator.

Daryl

[8BIT]

I made more progress last night. I corrected the BIT # handling in my Emulator and moved on to the TRB/TSB problems. This time I looked them up on the programming reference and found that the Z flag is set according to the results of the memory location and accumulator being AND'ed -even though the results of the AND are not stored. I has assumed the Z flag was set with the results of the ~A^M (TRB) or the AvM (TSB) operation. I corrected that in my emulator also.

The next problem occurred with the EOR (zp) test. I will look into that further next time. Again, great work with this test suite Klaus!

I am planning to dust off my SBC-4 and play with these tests on the 65816 using both emulation and native modes. I don't have any of my 65c02 boards anymore or I would try them on a WDC 65c02 also.

Daryl

[Klaus2m5]

8BIT wrote:

I am planning to dust off my SBC-4 and play with these tests on the 65816 using both emulation and native modes. I don't have any of my 65c02 boards anymore or I would try them on a WDC 65c02 also.

It would be really great, if the test could be verified with the real thing. On the 65816 I would only expect the emulation mode to be compatible with the test as long as you remove the NOP tests. Additionally in native mode the load_flag macros must be changed to force the M & X bits always set to 8-bit mode. I don't know the 65816 well enough to anticipate further obstacles.

good luck, Klaus

[Klaus2m5]

8BIT wrote:

The next problem occurred with the EOR (zp) test.

If you compare

Code: Select all

_EOR_IND:				;52
	movw	zl, XL
	_IZPG
	_EORZ
	EXEC

with

Code: Select all

_AND_IND:				;32
	movw	zl, XL
	_IZPG 
	_AND
	EXEC