Functional Test for the NMOS 6502 - request for verification

[8BIT]

Yes, the EORZ is only for direct zero page. I replaced with EOR and the test ran to completion. Success!

So, I found problems with BBR, BBS, BIT#, TRB, TSB, and EOR (zp). I'd say your test suite has done it's job.

Next, I'll try both tests on the 65816 in emulation mode only. No native mode, I don't want to mess with changing the flags.

thanks again!

Daryl

[8BIT]

Well, I dug out SBC-4 and set up my SBC2OS running in emulation mode. Tested that BRK worked.

Ran the 6502 test suite - passed.

Ran the extended 65C02 test, failed at BBR/BBS, RMB/SMB, some NOP's. Well Duh, those aren't on the 65816. So I removed those tests (including all NOP tests - was not concerned about those), and test suite ran to Success.

Overall, I think Klaus' tests are well designed and easy to implement and I recommend anyone developing a 6502/65C02 emulator or soft core to use his suites to verify functionality.

Excellent work Klaus!

Daryl

[Klaus2m5]

Perfect! Thank you very much Daryl for verifying the test against your emulator and your SBC-4 (65816).

I have updated my website with the latest version of all 6502/65C02 functional tests. The base 6502 test now also contains the RAM check to verify that none of the opcode tests unintentionally alter memory outside their designated write area. http://2m5.de/6502_Emu/6502_functional_tests.zip

[xeniter]

Hi Klaus,

Thanks for your testsuite i tried to test my nmos6510 from a commodore with my system where i can add with a fpga board the real 6510 ic to my vhdl simulation.

Here the Signals when it get trapped:

6502.org wrote:

Image no longer available: http://image-upload.de/image/DpkcvG/d276b01148.png

3e67 : c934 cmp #$34 ;should have added interrupt disable
3e69 : d0fe bne *

Also the T65 Core from Opencores Traps here.

I have used the version from github(link from visual 6502) is this the newest?:
https://github.com/redline6561/cl-6502/ ... l_test.a65

By which opcode should he add interrupt disable flag? Is a bug from my test environment or from your testsuide? or is there a difference between 6510 and 6502?

[Klaus2m5]

You can always find the latest version here: http://2m5.de/6502_Emu/6502_functional_tests.zip Yours is quite early, nevertheless it should pass the BRK opcode test.

The IRQ vector has been called by the BRK at 131e in your version of the test. When it hits 3e69 the code in the IRQ vector has already verified this to be a genuine break call both by looking at the break flag in the saved status on the stack and by the contents of A, X, & Y register ("BRK").

However, after a BRK opcode and entering the IRQ vector interrupts should be disabled. The current processor status should contain the processor status that was set before the break (0x00) plus interrupt disable (0x04) plus the bits that are saved by PHP as always on (break, unused - 0x30). You need to look at the accumulator to determine, what the actual processor status was after the IRQ vector was entered.

[xeniter]

Hi,

At http://6502.org/tutorials/interrupts.html i have found

BRK does set the interrupt-disable I flag like an IRQ does, and if you have the CMOS 6502 (65C02), it will also clear the decimal D flag.

-> i have troubles with the 65C02 and my fpga test system, but i will report soon as i get it to run.

So it should be 0 in the brk routine and not 1 or? Have anyone other references?

I simulated with 2 real 6510 nmos which are coppled with a fpga to testbench and the t65 core from opencores.

By both is the interupt disable flag not set.

Code: Select all

                        ; break & return from interrupt
                            if ROM_vectors = 1
                                set_stat 0
                       >            load_flag 0
08ad : a900            >            lda #0             ;allow test to change I-flag (no mask)
                       >
08af : 48              >            pha         ;use stack to load status
08b0 : 28              >            plp
                        
08b1 : a942                     lda #'B'
08b3 : a252                     ldx #'R'
08b5 : a04b                     ldy #'K'        ;N=0, V=0, Z=0, C=0
08b7 : 00                       brk

Simulate your newest version with the T65 from opencores:

6502.org wrote:

Image no longer available: http://image-upload.de/image/gkn7s3/34ec2e9df2.jpg

P(2) is the I Flag which get cleard by plp

Code: Select all

35f9 :                  irq_trap                ;BRK test or unextpected BRK or IRQ
35f9 : 08                       php             ;either SP or Y count will fail, if we do not hit
35fa : 88                       dey
35fb : 88                       dey
35fc : 88                       dey
                                ;next 4 traps could be caused by unexpected BRK or IRQ
                                ;check stack for BREAK and originating location
                                ;possible jump/branch into weeds (uninitialized space)
35fd : c942                     cmp #'B'        ;registers loaded?
                                trap_ne
35ff : d0fe            >        bne *           ;failed not equal (non zero)
                        
3601 : e052                     cpx #'R'
                                trap_ne        
3603 : d0fe            >        bne *           ;failed not equal (non zero)
                        
3605 : c048                     cpy #('K'-3)
                                trap_ne
3607 : d0fe            >        bne *           ;failed not equal (non zero)
                        
3609 : 850a                     sta irq_a       ;save registers during break test
360b : 860b                     stx irq_x
360d : ba                       tsx             ;test break on stack
360e : bd0201                   lda $102,x
                                cmp_flag 0      ;break test should have B=1
3611 : c930            >            cmp #(0      |fao)&m8    ;expected flags + always on bits
                        
                                trap_ne         ; - no break flag on stack
3613 : d0fe            >        bne *           ;failed not equal (non zero)
                        
3615 : 68                       pla
3616 : c934                     cmp #$34        ;should have added interrupt disable - really?

6502.org wrote:

Image no longer available: http://image-upload.de/image/KqfaLU/fc15dc7635.jpg

[Klaus2m5]

Unfortunately I cannot see your images!

Quote:

3615 : 68 pla
3616 : c934 cmp #$34 ;should have added interrupt disable - really?

saved here (1st instruction of the IRQ vector):

Quote:

35f9 : irq_trap ;BRK test or unextpected BRK or IRQ
35f9 : 08 php ;either SP or Y count will fail, if we do not hit

Quote:

At http://6502.org/tutorials/interrupts.html i have found

BRK does set the interrupt-disable I flag like an IRQ does, and if you have the CMOS 6502 (65C02), it will also clear the decimal D flag.
...
So it should be 0 in the brk routine and not 1 or?

Interrupt disable: I flag = 1
So you are saying, you get 0x30 in the accumulator (and on the stack @ 0x100+SP)? That is definitely wrong!

[xeniter]

Quote:

Unfortunately I cannot see your images!

Sorry for that, i have reupload it now you should able to see it.

the site http://e-tradition.net/bytes/6502/6502_ ... n_set.html desribe the brk instruction also with setting the I flag but this isnt true.

Have anyone references from where the information that the brk instructions sets the I flag come from?

to prove i wrote a testprogram for the visul6502 emulator:

Code: Select all

a9 00  LDA #0    accumulator=0
48 pha push accu to stack,  top stack element = 0
28 plp pull stack to statusregister, statusregister = 0 I=0
00 brk
EA NOP

as you see after the brk instruction no I flag is set

is this proof enough or should i write a program for my c64 to test it?


http://visual6502.org/JSSim/expert.html ... EAEAEAEAEA

Here the log:

6502.org wrote:

Image no longer available: http://image-upload.de/image/o1bWlk/3beae7a95c.jpg

EDIT:
now i found out that the datasheet (http://archive.6502.org/datasheets/mos_ ... y_1976.pdf) describes that the brk instruction sets the I flag

@all with a 6502 please test it, i want to know the truth

[BigEd]

Hi xeniter
Good to see you using visual6502. If you run a little longer you'll see that I is indeed set. See also
http://visual6502.org/JSSim/expert.html ... EAEAEAEAEA

Cheers
Ed

[GARTHWILSON]

xeniter, you can put [code] and [/code] around your code to prevent the software from removing the extra spaces. This will also make that part monospaced. It makes the enclosed code green which has been a bit hard to read on the monitor I have now and on the last one I had, so I also enclose the [code]...[/code] inside [size=120] and [/size] to make it 20% larger. (The [size=120] and [/size] must go outside the [code]...[/code].)

I am not aware of any errors in the interrupts primer, but if there is something unclear that could be misinterpreted, I do want to fix that. BRK does set the interrupt-disable flag for both NMOS and CMOS 6502. It does not affect the decimal flag on the NMOS one.

Quote:

Have anyone references from where the information that the brk instructions sets the I flag come from?

Every 6502 data sheet I have ever seen, plus WDC's programming manual.

[xeniter]

thx, wasnt aware of that brk takes 7 cylces.

so the t65 core has a bug he doesnt set it

but why my simulation included 6510 per fpga trapped there?

[BigEd]

There must be someone with a C64 to try Klaus' test suite - but it would be surprising to find it was different. What are the exact markings on your 6510s?

Cheers
Ed

[xeniter]

MOS
6510 CBM
1385

TAIWAN
GH095580
5


MOS
6510 CBM
5083

KOREA
AH463853

i think the connection to the fpga is the problem, i will test it direct on the c64

[BigEd]

Thanks!

[Klaus2m5]

xeniter wrote:

i think the connection to the fpga is the problem, i will test it direct on the c64

This is not going to be easy, because interrupts are heavily used by the C64 kernal...

You would have to change the kernals' IRQ vector at $314 and the IRQ code in turn must continue any non break interrupt in the original vector without destroying any register of course. You also need to find enough space in zeropage, that is not in use by the C64 kernal. Data and program space should not be a problem, but need to be changed. I used to be able to do that twenty years ago, but not any more...

Sticking a 6510 into an SBC with a small monitor program would be much easier if one could cope with the changed pins.

However, I do not expect a deviation in the behavior of the 6510 to its brothers. The scope of the 6510 was some extra I/O pins for bank switching and the ability of tristating the address bus to allow RAM to be shared with a video controller. At the time Commodore/MOS was happy to have a working cpu core and even didn't fix known bugs on newer implementations. Why should they have messed with the interrupt mechanism?

It would have required a major change to make the 6510 handle BRK differently than the other interrupts. After all IRQ, NMI & reset use exactly the same opcode. They will jam $00 into the instruction decoder and guess what that is? A BRK!

Interrupts must be disabled at the beginning of an interrupt vector as their handler is not reentrant. For this reason NMI is of limited use, as you can only have 1 source so you don't shoot yourself in the foot.

One more thing.

Quote:

but why my simulation included 6510 per fpga trapped there?

When I look at the trace from your first post it looks as if the PLA gets 0x34 from stack at 01fc, but the compare immediate (0xc9) at 3e67 has 0x30 as the operand to compare to. Something is reversed as you seem to get the correct processor state of the stack, but the compare expects the I flag to be off????? This wouldn't match the listing, that you posted with it!