Functional Test for the NMOS 6502 - request for verification

[Klaus2m5]

Hi all,

a new version of the test now includes macros to insert custom error handling.
I did a bit of cleanup, as this is going to be the final version for now.

Next on my list is a test to check IRQ, NMI and reset. However, this will be a separate program as it requires some minimal hardware to allow the test to wiggle the CPUs interrupt and reset lines.

Once again, thank you very much for your continuous support, Big Ed.

cheers, Klaus

[BigEd]

Thanks Klaus - great to have such a program. I will bring it to the attention of the good people at StarDot.org.uk
Cheers
Ed

[BigEd]

Good news - user 'sweh' has run your test on an original beeb with NMOS 6502 and it passed!
http://stardot.org.uk/forums/viewtopic. ... 874#p49874

Cheers
Ed

[Arlet]

I'm testing the code with my verilog implementation, and discovered a bunch of mistakes (in my code, not in the test program!)

First one was because bit 4 and bit 5 of the P register default to "0" rather than "1". It can be argued whether they should be tested, because bit 5 is reserved for future use, and the value is undefined. As far as I understand, bit 4 (the BRK bit) is also undefined, since the code isn't running as part of a BRK/IRQ handler. I changed my code to default these bits to "1". It requires the same amount of logic, and there's no harm in matching the NMOS 6502 better.

Second trap was due to overzealous 'load_reg' pattern match. Specifically, the IR=xxxx_10x0 also includes the NOP instruction, which caused the Z/N flags to be modified.

Third trap was due to a mistake in the ALU for the "V" flag calculation. Instead of BI[7], it should use temp_BI[7].

Fourth trap was in decimal ADC with (ind, X) addressing mode. Adding the X register was accidentally done in decimal mode.

After fixing these, the latest test ran successfully. I've pushed the fixes to github.

[BigEd]

Great - I've merged into my fork's 65Org16-master branch, although without any testing.
Did you test with RDY randomly activating?
Cheers
Ed

[Arlet]

BigEd wrote:

Did you test with RDY randomly activating?

No, but I'll do that right now.

Update: simulation just finished successfully, with RDY toggling randomly.

[BigEd]

Excellent. This testsuite has really helped!

[Klaus2m5]

Good to hear that the program is of some use...

Arlet wrote:

First one was because bit 4 and bit 5 of the P register default to "0" rather than "1". It can be argued whether they should be tested, because bit 5 is reserved for future use, and the value is undefined. As far as I understand, bit 4 (the BRK bit) is also undefined, since the code isn't running as part of a BRK/IRQ handler. I changed my code to default these bits to "1". It requires the same amount of logic, and there's no harm in matching the NMOS 6502 better.

As for the flags I am not absolutely sure, if I should impose the unused/break bits to be read back as 1 when they have been pushed by PHP. The programming manual states:

Quote:

3.5 EXPANSION BIT
The next bit in the flag register is an unused bit. It is most likely that this bit will appear to be on when one is analysing the bit pattern in the processor status register; however, no guarantee as to its state is made as this bit will be used in expanded versions of the microprocessor

The break bit behavior during a PHP is not documented in the manual. However, it is also an unused flag in the processor status register and should behave the same as the other unused bit if not modified. Visual6502 sheds some light onto why the break bit is only off during hardware IRQ or NMI. http://visual6502.org/wiki/index.php?ti ... _and_B_bit
Only during a hardware interrupt, bit 4 of the data bus is pulled low during the cycle when the CPU writes the processor flags to the stack.

All of this is not strictly a "documented" behavior of the 6502. Should I put in an option to disable the checking of the unused and break bits? I think, at least they should be consistant - always one or always zero after PHP.

cheers, Klaus

[BigEd]

I think the present check is perfect - it matches the NMOS 6502, and thanks to visual6502, we know why. Sometimes a program might do PHP/PLA and so passing such a test does improve a model.

That said, it is extra work to model these bits correctly! I still haven't fixed up a6502.

[Arlet]

BigEd wrote:

I think the present check is perfect - it matches the NMOS 6502, and thanks to visual6502, we know why. Sometimes a program might do PHP/PLA and so passing such a test does improve a model

Agreed. It's just a small change to correct the default value to match the NMOS 6502, and no good reason not to do it.

[BigEd]

I found and fixed some problems in the easy6502 simulator, which Nick has now updated.
http://skilldrick.github.com/easy6502/#first-program

[blurry]

Hey, thanks Klaus for the test code! Also thanks to Ed for pointing me this way.

I wrote a test harness to run this against the 65c02 emulation in Jace (java apple computer emulator) and I was able to iron out some mishandling of the B and I flags that have always eluded me to some extent.

I know that this test is for vanilla 6502, but my 65c02 emulator code passes the test also just as long as I do not touch the D flag on BRK (the 65c02 also resets D on the BRK opcode)

[BigEd]

Jace passes now? Excellent! Glad to be of service.
(I've just posted a new thread about it)
Klaus has given the community something really valuable here - thanks Klaus!
(I added a link to the collection on the visual6502 wiki - we should perhaps have a reference section on this site too.)
Cheers
Ed

[zellyn]

Just FYI, I managed to pass the latest version of the 6502 functional tests with a broken PLA opcode: it was not changing the NZ flags at all.

Makes for weird errors: boots an Apple ][+ just fine, lets you enter basic programs, but can't list them

Once again, thanks for the fantastic tests!

Zellyn

[Klaus2m5]

Hi Zellyn, thank you for the bug report. I am going to fix it over the weekend.