65816 Test Suite

[8BIT]

Hi all,

I needed a test suite for the Kowalski 65816 Simulator and found one on an NES Dev Forum. As it was originally written for an NES platform, I had to reconfigure the IO to work with the Kowalski Terminal IO. It has over 1600 tests that cover almost every instruction and every addressing mode, including many fringe cases and some undocumented anomalies.

I wanted to run this on my SBC-4 just to ensure all test pass on a real 65816. However, My IO map is currently in the way.

I'm placing the modified test suite here if anyone wants to give it a go on their system. It needs RAM from $008000 to $07FFFF. It also needs RAM at $000000 - $000300. IO can be a simple ASCII output and waiting input. See the "how to.txt" in the zip file.

The source was modified to assemble with the Kowalski Simulator.

thanks!
Daryl

EDIT: I forgot to mention, the "tests-full.txt" is a description of each test, input data and expected results. This was very helpful in debugging my simulator.

Daryl

[dominicbeesley]

Hi, I'm experimenting with a 65816 vhdl core at the moment and this looks like just the thing to test it out. Do you have a link to the original as I didn't turn the up during my searches.

Thanks to BigEd for the pointer to this thread

D

Edit: I've found the original git by searching properly! https://github.com/gilyon/snes-tests and it's MIT licenced so that fits with my project nicely!

[8BIT]

I also put a link to the NES Dev forum in the "how to.txt" file.

Daryl

[BigEd]

Nice find Daryl!

[8BIT]

I hope others here will find it useful. It helped me for sure.

See my edit to the top post. That txt file was really helpful.

Daryl

[dominicbeesley]

Yes, thanks Daryl.

I've got a way to go before my core is quite ready to tackle these tests (it passes Dormann NMOS and CMOS tests currently) but I'm looking forward to having a good test of edge cases. I'd particularly forgotten about the PLB wrap "feature"!

D

[Yuri]

I have to ask, did you add tests for the BCD mode? The Ricoh 65xx variants stripped out decimal mode, so those should allow the flag to be set, but ignore it when it is.

[8BIT]

I did not write these tests... I only modified the existing tests. BCD is tested, but those tests were placed at the end and would be easy to exclude in the source.

Specifically, Test 05ac is the first BCD test. You would just add "JML success" right before label "test05ac:" in "tests-full.inc" and BCD would not be tested.

Daryl

[hoglet]

dominicbeesley wrote:

I'd particularly forgotten about the PLB wrap "feature"!

Indeed, that reminds me the 65816 emulation in the 6502Decoder still had a couple of TODO's regarding the stack wrapping of new instructions (like PHB/PLB) in emulation mode. Let me know when you hit these bugs and I'll try to fix them.

Dave

[dominicbeesley]

Thanks Hoglet,

Are the known differences listed anywhere?

I got a lot further than I expected yesterday evening and I'm on to the stack relative addressing modes now - I'm not clear when or how these should wrap in Emulation mode. Should the behaviour in 6502decoder be right for these cases. If you're not sure I'll break out the Blitter/real hardware.... its just bit of a pita moving the lx2 between the fpga rig and the BBC Micro...

I'm hoping I'll have a build of these tests before the weekend and can do a full run with Hoglets decoder hooked up. That should test both functionality _and_ cycle accuracy of all the edge cases. I'll run the test suite on real hardware too hopefully fully verify decode6502?

One thing that might slow me down a little is memory. I'm using a Gowin fpga which has roughly 128k of block RAM so and I'm limited to using just block RAM when hooked up to the logic analyser for want of pins. So I'm going to have to look at how I can limit the test suite to need fewer banks (or smaller memory fragments in each bank) or if that isn't possible I'll need to swap to a different fpga board. I think I'll need to have a closer look at the .py file.

How full is the 32k ROM? I'll be able to omit the fonts and init code as my test bed is just s dead simple memory+uart system

D

[hoglet]

dominicbeesley wrote:

Thanks Hoglet,
Are the known differences listed anywhere?

So far, every 65816 question I've had has been answered by Bruce Clark's document:
http://www.6502.org/tutorials/65c816opcodes.html

Stack relative addressing is covered in section 5.10.

The appendix covers the foibles of emulation mode.

If this excellent document doesn't answer your question, I suspect you'll need to resort to checking real hardware.

Dave

[8BIT]

There was also this in the Test Suite Readme:

Code: Select all

What undocumented behavior is testsed?
In emulation mode with S=$1FF, the PLB instruction should read from $200 instead of $100. This is despite the fact that the CPU manual doesn't list it with the instructions that can access outside the stack page.
In emulation mode when the low byte of D is nonzero, the (direct,X) addressing mode behaves strangely:
The low byte of the indirect address is read from direct_addr+X+D without page wrapping (as expected). The high byte is read from direct_addr+X+D+1, but the +1 is done with wrapping within the page. For example: Emulation=1, D=$11A, X=$EE, and the instruction is lda ($F7,X). Here $F7 + $11A + $EE = $2FF. The low byte of the address is read from $2FF and the high byte from $200. This behavior only applies to this addressing mode, and not to other indirect modes.
The behavior of decimal mode isn't fully documented. See appendix A of this document for a full specification.   http://www.6502.org/tutorials/decimal_mode.html#A 

Also, many of the new addressing modes have unexpected behavior in emulation mode. I found the "tests-full.txt" and reading the assembly code for the specific test that failed helped me understand the expected operation better.

Daryl

[BigDumbDinosaur]

8BIT wrote:

Also, many of the new addressing modes have unexpected behavior in emulation mode.

...which is why I strongly recommend not operating the 816 in emulation mode unless absolutely necessary.  There are too many ambiguities in emulation-mode behavior.

[BigEd]

Well, that's a preference BDD, but it's absolutely against my preference and recommendation. Indeed, we have a thread about this sub-topic. Perhaps that's a better place to discuss it.

(Just writing this as a counter-point - your recommendations and strong recommendations are, of course, only yours. I wouldn't want your opinions to be taken as consensus.)

[GARTHWILSON]

I think people can figure that out, Ed.  They don't need your interpretation on everything.