Functional Test for the NMOS 6502 - request for verification

[Klaus2m5]

Dennis wrote:

Thanks Klaus for your testing suite. I'm currently stuck on my 6502 emulator, and can't find out what's wrong. It runs till test 42 ($3249) and halts on ($335A), using the the functional test bin found in the NESkell https://github.com/blitzcode/neskell/tr ... onal_tests source. I've used that bin because they've included a vis6502 trace cpu listing which helped me finding another bug by comparing my cpu trace to that trace. unfortunately it doesn't run beyond test 40. Could someone provide a complete trace of this test suite (along with the binary+listing, if not default found under bin_files\ )? That would be really great (I've failed setting up vis6502 for trace logging, after some hours it just fails - looks like my potato computer isn't powerful enough . Thank you!

As Ed mentioned the last test is for decimal mode. In case of a stop at $335a (decimal SBC immediate result) you find

• the immediate operand at label sb2 ($12)
  the operand loaded to the accumulator at label ad1 ($0d)
  the carry bit before SBC at (SP+2)
  the expected result at label adrl ($0f)
  the actual result in the accumulator.
  the carry bit after SBC at (SP+1)

The same operands seem to give a correct result for SBC zp and SBC abs as the previous part of the test was passed without stop.

[Dennis]

thank you both for your suggestions. Using Bruce Clarks test ($12-$21=$91 SBC decimal) I've managed to find a small typo. Now the test completes! I still recommend providing a complete trace log of the test suite, it surely helps to find those bugs far easier! Thanks Klaus again for your effort building such a test suite.

[Chromatix]

I've just used these tests to verify (and debug!) my new emulator, which is essentially a C++ version of lib6502. It supports all of the 65C02 instructions, except for WAIT and STOP (which await my adding a proper interrupt mechanism). I found quite a few lib6502 bugs, as well as a few of my own.

In the process, I have generated detailed traces of both tests, along with a straightforward source-code example of how to run the tests within an emulator with tracing. These traces are one line per instruction executed, showing the PC, then all registers and flags at the beginning of the instruction, followed by all memory accesses performed during the instruction (including instruction/operand fetches):

Code: Select all

        fetch FFFC -> 00        fetch FFFD -> 00        fetch FFFC -> A3        fetch FFFD -> 37
0400: A=00 X=00 Y=00 S=00    I          fetch 0400 -> D8
0401: A=00 X=00 Y=00 S=00    I          fetch 0401 -> A2        fetch 0402 -> FF
0403: A=00 X=FF Y=00 S=00 N  I          fetch 0403 -> 9A
0404: A=00 X=FF Y=00 S=FF N  I          fetch 0404 -> A9        fetch 0405 -> 00
0406: A=00 X=FF Y=00 S=FF    IZ         fetch 0406 -> 8D        fetch 0407 -> 00        fetch 0408 -> 02        store 0200 <- 00
0409: A=00 X=FF Y=00 S=FF    IZ         fetch 0409 -> A2        fetch 040A -> 05
040B: A=00 X=05 Y=00 S=FF    I          fetch 040B -> 4C        fetch 040C -> 33        fetch 040D -> 04
0433: A=00 X=05 Y=00 S=FF    I          fetch 0433 -> D0        fetch 0434 -> F4
0429: A=00 X=05 Y=00 S=FF    I          fetch 0429 -> CA
  [...]
3448: A=4C X=0E Y=FF S=FB  VD           fetch 3448 -> 48        store 01FB <- 4C
3449: A=4C X=0E Y=FF S=FA  VD           fetch 3449 -> 08        store 01FA <- 78
344A: A=4C X=0E Y=FF S=F9  VD           fetch 344A -> D8
344B: A=4C X=0E Y=FF S=F9  V            fetch 344B -> 40        fetch 01FA -> 78        fetch 01FB -> 4C        fetch 01FC -> 34
344C: A=4C X=0E Y=FF S=FC  VD           fetch 344C -> A9        fetch 344D -> 55
344E: A=55 X=0E Y=FF S=FC  VD           fetch 344E -> 69        fetch 344F -> 55
3450: A=10 X=0E Y=FF S=FC  VD  C        fetch 3450 -> C9        fetch 3451 -> 10
3452: A=10 X=0E Y=FF S=FC  VD ZC        fetch 3452 -> D0        fetch 3453 -> FE
3454: A=10 X=0E Y=FF S=FC  VD ZC        fetch 3454 -> 40        fetch 01FD -> 70        fetch 01FE -> 55        fetch 01FF -> 34
3455: A=10 X=0E Y=FF S=FF  V            fetch 3455 -> A9        fetch 3456 -> 55
3457: A=55 X=0E Y=FF S=FF  V            fetch 3457 -> 69        fetch 3458 -> 55
3459: A=AA X=0E Y=FF S=FF NV            fetch 3459 -> C9        fetch 345A -> AA
345B: A=AA X=0E Y=FF S=FF  V  ZC        fetch 345B -> D0        fetch 345C -> FE
345D: A=AA X=0E Y=FF S=FF  V  ZC        fetch 345D -> AD        fetch 345E -> 00        fetch 345F -> 02        fetch 0200 -> 2B
3460: A=2B X=0E Y=FF S=FF  V   C        fetch 3460 -> C9        fetch 3461 -> 2B
3462: A=2B X=0E Y=FF S=FF  V  ZC        fetch 3462 -> D0        fetch 3463 -> FE
3464: A=2B X=0E Y=FF S=FF  V  ZC        fetch 3464 -> A9        fetch 3465 -> F0
3466: A=F0 X=0E Y=FF S=FF NV   C        fetch 3466 -> 8D        fetch 3467 -> 00        fetch 3468 -> 02        store 0200 <- F0
3469: A=F0 X=0E Y=FF S=FF NV   C        fetch 3469 -> 4C        fetch 346A -> 69        fetch 346B -> 34
3469: A=F0 X=0E Y=FF S=FF NV   C

The total size of the uncompressed traces is almost 4GB. Consequently, I'm running them through the best text compression I know of (xz), which is taking much longer than actually running the tests! I'm wondering where it might be useful to upload them.

[BigEd]

Welcome! Always good to shake the bugs out of a new emulator. Do you plan to share your sources?

[Chromatix]

Eventually, I'm sure. There's a number of features I need to flesh out before it's ready for prime time. Right now it's literally just a CPU with a templated memory model, and only the "pure 64K RAM" memory model is actually tested.

I'm hoping to build up a "high speed" and "mostly compatible" multithreaded BBC Master+Tube emulator. The Tube half of it should be feasible to slot into PiTubeDirect (and be 100% compatible), but I don't have a physical Beeb to test it with, hence the other half. Perhaps I'll talk more about it in another thread.

[BigEd]

Sounds good to me!

[Jokse]

I've written my own 65C02 emulator for my ongoing 8bit project, but I seem to be stuck with running this test at the BEQ range test.

Code: Select all

046a : a0fe                     ldy #$fe        ;testing maximum range, not -1/-2 (invalid/self adr)
046c :                  range_loop
046c : 88                       dey             ;next relative address
046d : 98                       tya
046e : aa                       tax             ;precharge count to end of loop
046f : 1008                     bpl range_fw    ;calculate relative address

from what I can tell, that basically preps the accumulator as well as X and Y register with $FD

Code: Select all

047e : 497f                     eor #$7f        ;complement except sign
0480 : 8d0c05                   sta range_adr   ;load into test target
0483 : a900                     lda #0          ;should set zero flag in status register
0485 : 4c0b05                   jmp range_op

Then this loads $82 into the immediate address of BEQ at 050c

Code: Select all

050b :                  range_op                ;test target with zero flag=0, z=1 if previous dex
050c =                  range_adr   = *+1       ;modifiable relative address
050b : f03e                     beq *+64        ;+64 if called without modification

and that then adds $82(-126) to the program counter and then jumps there... But then fails

Code: Select all

0591 : f008                     beq range_ok    ;+127 - max forward
                                trap            ; bad range
0593 : 207b44          >        jsr report_error

with A being $02

So my question here is, is it supposed to only jump -126 or was it supposed to jump -128, but something was lost along the way?

[Chromatix]

Look carefully at the addresses - the jump is at $050B but you land at $0591, which is clearly a jump forward. In other words, you have added $82 instead of ($82 - $100) as is required for the two's-complement branch offset.

[BigEd]

Ah, chromatix has probably got it while I was posting this:

Branch offsets are relative to the following instruction, so for example F0 00 would be a no-op. Most likely if you are adrift by 2 it's because you've used the address of the branch as the basis. (Another possibility is that you've got special treatment of negative offsets, and haven't quite got it right.)

[Jokse]

So negative branch offset start would be the beq address, but positive branch offset would be the next instruction address?

[Chromatix]

No, the offset is always from the following opcode address. You just have to treat the offset itself as a signed number (signed char, in C). As far as the CPU is concerned, an offset of $FF or $FE is perfectly valid; the latter results in an infinite loop if the condition is true, and this is widely used in the test suite as an error trap.

Perhaps the easiest way to handle a signed number, without resorting to casting, is to "sign extend" the value to the width of the address. In this case, that means making the high byte $00 if the top bit of the offset is cleared, and $FF if it is set. You can then just add that 16-bit offset to the 16-bit address and let it wrap around.

[Jokse]

Ahhh yes, that makes sense now... Thanks

[Jokse]

This is really bothering me...

Code: Select all

processor 6502
	org $0
	.byte $00

	seg CODE
	org $0400
.start
	lda #$23
	tax
	tay
	lda #0
	jmp .jmptst
.fisk   stx $f001
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
.jmptst 
	lda #0
	beq .fisk
	ldx #$2A
	stx $f001
.loop
	jmp .loop
	org $fffc
	.word .start
	.word .start

will run without any problems and jump relatively, but the test suite is still 2 stops short...

[Chromatix]

JMP does not perform a relative jump, but an absolute or indirect jump. Only the Bxx instructions use the PC-relative addressing mode.

[Jokse]

Jokse wrote:

will run without any problems and jump relatively, but the test suite is still 2 stops short...

By jump relatively, I of course mean the BEQ...