Functional Test for the NMOS 6502 - request for verification

[Klaus2m5]

Hi everybody,

I have written a program to test a 6502 emulator. I have already run it against the emulator and fixed all bugs on both the test and the emulator. However, both have been written by me based on the same document, the MCS6500 programming manual. So there may still be errors, because I might have made the same mistake on both ends. For this reason, I have attempted to resurrect an AIM65 as a test platform with a real NMOS 6502. But after spending more then 15 years in a cellar, it didn´t work. I am without a working hardware plattform to verify correct operation of the test.

So here is my request for anybody still having some functional 65xx hardware and some spare time. Please take a look at the attached functional test. If you could get it to run on your system, I would be very grateful. Please post any results in this thread. I am willing to assist you in any reasonable way, for example in providing object code and listing according to your specifications.

The test requires a monitor program to gain access to memory and registers. The code size is 12kB, the data size is 85 Bytes zero page and 90 Bytes above zero page. It does not test any undocumented opcodes and flag behavior and should also run on processors with extended instruction set not testing the extended instructions.

cheers, Klaus

Edit: The newest version is now always 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

The test can also be found on GitHub:
https://github.com/Klaus2m5/6502_65C02_functional_tests

[BigEd]

That's excellent! How many clock cycles to run the test?

Here's something which is not well-known: the C model version of the visual6502 is now available on github at
https://github.com/mist64/perfect6502
so you can now run programs on the transistor-level NMOS device in the comfort of your fastest target machine.
(Thanks to Michael Steil and Andrzej Sliwa)

Cheers
Ed

[BigEd]

Hi Klaus
on perfect6502, the first fail is this one, before 160k clock cycles.
It looks to me that the final value expected is not 0 but the value of zp1+3.
Cheers
Ed

Code: Select all

set_stat 0
1964 : a900            >            lda #0     ;load flags
1966 : 48              >            pha         ;use stack to load status
1967 : 28              >            plp
                        
1968 : a60d                     ldx zp1+3
196a : 08                       php         ;test stores do not alter flags
196b : 8a                       txa
196c : 49c3                     eor #$c3
196e : aa                       tax
196f : 28                       plp
1970 : 8e3602                   stx abst+3
1973 : 08                       php         ;flags after load/store sequence
1974 : 49c3                     eor #$c3
1976 : aa                       tax
1977 : e400                     cpx 0       ;test result
1979 : d0fe                     bne *       ;trap

[Miles J.]

Code: Select all

set_stat 0
1977 : e400                     cpx 0       ;test result

Excuse me but should this read 'cpx $00' = $e4 $00 or 'cpx #0' = $e2 $00?

[GARTHWILSON]

Miles J. wrote:

Code: Select all

set_stat 0
1977 : e400                     cpx 0       ;test result

Excuse me but should this read 'cpx $00' = $e4 $00 or 'cpx #0' = $e2 $00?

The preceding TAX already has an implied CPX #0 included in it.  Adding another one is redundant.

[BigEd]

But the point is well made: this is probably not meant to be a comparison with location 0. Changing to #0 fixes two tests (still using perfect6502 as the platform, not a real chip)

(Simple typo, no big problem!)

Edit: also a couple of ldx 0 versus ldx #0
Edit: and a couple of cpy 0 versus cpy #0
Edit: and a couple of ldy 0 versus ldy #0
Edit: and a couple of cmp 0 versus cmp #0
Edit: and a couple of lda 0 versus lda #0

[Klaus2m5]

Thank you all for the quick responses. Thank you Ed for running it on perfect6502.

The emulator clears all memory, before it runs the test. So $0000 was really $00 and these errors went undetected. I will fix all unintentional references to location $0000, run it with data memory filled with random garbadge, check again and post the corrected version.

The test takes 52 seconds to execute on my emulator, which is supposed to run at ~2MHz (16MHz ATMega)

[BigEd]

Thanks Klaus! To my great surprise, lib6502 seems to have a problem with decimal mode, which I'll investigate. Also a couple of easy to fix issues with B and the unimplemented bit of the status reg.

I'd be very grateful if you would put some copyright license in the header.

Last I looked, perfect6502 was still running...

Cheers
Ed

[Klaus2m5]

fixed the reference to location 0 issue,
tested with non-zero data memory,
added license GPLv3

[Klaus2m5]

GARTHWILSON wrote:

Miles J. wrote:

Code: Select all

set_stat 0
1977 : e400                     cpx 0       ;test result

Excuse me but should this read 'cpx $00' = $e4 $00 or 'cpx #0' = $e2 $00?

The preceding TAX already has an implied CPX#0 included in it. Adding another one is redundant.

Thank you, for pointing this out.

Code: Select all

1970 : 8e3602                   stx abst+3
1973 : 08                       php         ;flags after load/store sequence
1974 : 49c3                  >> eor #$c3
1976 : aa                    >> tax
1977 : e000                  >> cpx #0      ;test result
1979 : d0fe                     bne *       ;trap
197b : 68                       pla         ;load status
197c : 4930                     eor #$30    ;always on bits
197e : cd0802                   cmp fLDx+3  ;test flags
1981 : d0fe                     bne *       ;trap
                        
                                set_stat $ff
1983 : a9ff            >            lda #$ff     ;load flags
1985 : 48              >            pha         ;use stack to load status
1986 : 28              >            plp
                        
1987 : a60a                  >> ldx zp1  

Yes, the compare would not be necessary and is a result of copying from the previous block(s), where it is needed. Just another case of stupid copy & paste programming.

Actually the TAX is also not required, the previous EOR sets the flags correctly and X is never used. I will look into removing these redundant instructions in later versions and modifications to the code for all compares to immediate zero, where a test of the resulting flags from a compare is actually intended.

[BigEd]

Thanks for the updated code Klaus, and for the explicit license.

perfect6502 is still running. I have a BBC micro I should be able to run on, if no-one else gets to a real CPU before I do.

Cheers
Ed

[BigEd]

Success - perfect6502 passes (my modified version, actually same as your updated version)

Great stuff - that adds confidence to the visual6502 model and to the testsuite, I think.

[Klaus2m5]

BigEd wrote:

Success - perfect6502 passes (my modified version, actually same as your updated version)

Great stuff - that adds confidence to the visual6502 model and to the testsuite, I think.

Good to hear, that it works on perfect6502. Thank you very much for your help. Just out of curiosity, how did you manage to overcome the problems with decimal mode and the break and unused bits in the status register? Did you change the model or the test?

New Version on its way to allow running the Test on higher level systems.

cheers, Klaus

[BigEd]

perfect6502 had no problems - it was Ian Piumarta's lib6502 which has problems. It's my emulator of choice, so I'd like to fix it up. I'd also like to test Mike's py65, and my own a6502. And it would be good to test Arlet's VHDL core as well!

Cheers
Ed

[BigEd]

Hmm. Running the test on a BBC Master is failing. The machine apparently has a 65C12A. But it's failing on

Code: Select all

3220:        cmp abs7f
3221-        tst_a $7f,fzc

which is pretty basic. If I comment out that test it fails on the next. If I comment out a block of compares it fails on a CPY

Code: Select all

11569-2031 : c07f                     cpy #$7f
11570:                                tst_stat ~fn

which is extra-odd because that implies it passes the tests for cpx.

Edit: see next post - this was my mistake!

My two original Beebs (with NMOS 6502) are both unserviceable right now. Sorry I hadn't quite realised that situation.