6502 Beeb instruction timing tester

[scarybeasts]

Turns out may machine matches your machines so I've updated the ssds.

Here's what beebjit thinks of 6502timing1M.ssd.
jsbeeb and b2 give the same results.

So the emulators agree which instructions are the wild ones! Some of the usual 6502 resources also have caveats about these instructions. e.g. http://www.oxyron.de/html/opcodes02.html opines about SHY / SHX / AHX:
"Also page boundary crossing will not work as expected"

Fortunately we have visual 6502. From a quick look at SHX in visual 6502, it looks like the page crossing case cases a read of the uncarried address, followed by a write of (addr & 0x00FF), i.e. a zero page write.


Cheers
Chris

[dp11]

Would any beeb owners possible test the current version of the two 6502 test suites in github in the first post ? It would be good to get a wider set of test cases.

[dp11]

So looking at visual 6502 we get

Code: Select all

cycle	ab	db	rw	Fetch	pc	a	x	y	s	p
0	0000	a0	1	LDY #	0000	aa	00	00	fd	nv‑BdIZc
0	0000	a0	1	LDY #	0000	aa	00	00	fd	nv‑BdIZc
1	0001	01	1		0001	aa	00	00	fd	nv‑BdIZc
1	0001	01	1		0001	aa	00	00	fd	nv‑BdIZc
2	0002	9e	1	unknown	0002	aa	00	01	fd	nv‑BdIzc
2	0002	9e	1	unknown	0002	aa	00	01	fd	nv‑BdIzc
3	0003	ff	1		0003	aa	00	01	fd	nv‑BdIzc
3	0003	ff	1		0003	aa	00	01	fd	nv‑BdIzc
4	0004	fc	1		0004	aa	00	01	fd	nv‑BdIzc
4	0004	fc	1		0004	aa	00	01	fd	nv‑BdIzc
5	fc00	00	1		0005	aa	00	01	fd	nv‑BdIzc
5	fc00	00	1		0005	aa	00	01	fd	nv‑BdIzc
6	0000	00	0		0005	aa	00	01	fd	nv‑BdIzc
6	0000	00	0		0005	aa	00	01	fd	nv‑BdIzc

So the SHX ( 9E ) should be 5 cycles + 1 or 2 cycles of 1MHz stretch . My test suite which has previously synchronised to the 1MHz clock assumes 1 cycle of stretch .

[hoglet]

-

Would any beeb owners possible test the current version of the two 6502 test suites in github in the first post ? It would be good to get a wider set of test cases.

I've just tried v0.14 (built yesterday morning) in a Model B with various proecessors:
- R6502A - passed
- SY6502A - passed
- UM6502CE - passed
- R65C02P2 - passed, apart from the NOP tests where it gets stuck on the Rockwell instructions (SMB/RMB at x7 and BBRS/BBS at xF)

I think you need a special build for the latter case.

Dave

[dp11]

Excellent thanks Dave. 65C02 will need a different build.

[tom_seddon]

BBC B, issue 7, R6502A:

Cold:

* 6502timing - passed
* 6502timing1M - opcode &9B = &FE

After 5 minutes:

* 6502timing - passed
* 6502timing1M - opcodes &9E, &9C, &9B = &FE

(b2 opcode failures are &9F, &93, &9E, &9C, &9B - based on the above results, I think I'm going to ignore &9B, &9C and &9E...)

--Tom

[tom_seddon]

BBC Master, issue 1, G65SC12

* 65C12timing - pass
* 65C12timing1M - pass

(Multiple failures in b2 for these. Looks like I have some work to do!)

--Tom

[dp11]

BBC B, issue 7, R6502A:

Cold:

* 6502timing - passed
* 6502timing1M - opcode &9B = &FE

After 5 minutes:

* 6502timing - passed
* 6502timing1M - opcodes &9E, &9C, &9B = &FE

(b2 opcode failures are &9F, &93, &9E, &9C, &9B - based on the above results, I think I'm going to ignore &9B, &9C and &9E...)

--Tom

Thanks for the testing. 9E 9C 9B failure are down to instability in of the high byte of the second memory access with page crossing is in the 1MHz clock stretch region or not. I think I've found I a can bias the tas instruction to take one path or the other depending on the value of the stack pointer . Lots more testing to do to understand it in more detail.

[dp11]

New versions added.

This fixes (indirect,X) not accessing the stretched area of memory for the 1MHz tests.

Also I think I have biased the unstable 6502 instructions into stable states.

If anyone can test on real hardware that would be good. These all pass clean on my machines , but other machine testing would be good. Thanks again to all the people who have already tested the code.

[tom_seddon]

New versions added.

This fixes (indirect,X) not accessing the stretched area of memory for the 1MHz tests.

Also I think I have biased the unstable 6502 instructions into stable states.

If anyone can test on real hardware that would be good. These all pass clean on my machines , but other machine testing would be good. Thanks again to all the people who have already tested the code.

BBC Master, issue 1, G65SC12:

65C12timing passes
65C12timing1M passes

BBC B, issue 7, R6502A:

6502timing, one failure:

Code: Select all

&A3 LAX (indirFE+1,X)               01

6502timing1M, passes

--Tom

[dp11]

Thanks for your testing I know what's wrong with LAX can easily fix.

[dp11]

LAX should now be fixed. Runs clean on my hardware

[scarybeasts]

9E 9C 9B failure are down to instability in of the high byte of the second memory access with page crossing is in the 1MHz clock stretch region or not.

For the purposes of emulation, I decided to "copy what Visual 6502 makes of these". Fortuitously, that was sufficient to get the 6502timing1M.ssd test passing in beebjit.


Cheers
Chris

[dp11]

A few updates :

USBC instruction added for 6502
BIT abs,X added for 65C12

Added 65C02 test suite for beebs and masters modified with a 65C02 CPU. This isn't for the tube.

[tom_seddon]

I've got the 65C02 tests passing on b2 now. Two things I noticed:

1. The tests have the 3-byte, 4-cycle NOP addressing mode as abs,X. But it must be abs, surely?

2. Anybody know what the 65c02 actually reads during the dead cycle while processing BCD instructions? The dead cycles PDF says it's the PBA, but that doesn't seem to be right, as doing that breaks the addrFF,X tests with D=1. What I've done for now is make it read from the program counter. (I'll try to put together a test for this at some point - or maybe have a go with my logic analyzer, but it's only 8 channels so answering this sort of question is tedious.)

Thanks for putting this test together! I'll be adding it to the b2 test set.

--Tom

[dp11]

I've got the 65C02 tests passing on b2 now. Two things I noticed:

1. The tests have the 3-byte, 4-cycle NOP addressing mode as abs,X. But it must be abs, surely?

Thanks for noticing without feedback issues just fester.

I've taken the info from https://www.masswerk.at/6502/6502_instr ... .html#NOPs but happy to change.

2. Anybody know what the 65c02 actually reads during the dead cycle while processing BCD instructions? The dead cycles PDF says it's the PBA, but that doesn't seem to be right, as doing that breaks the addrFF,X tests with D=1. What I've done for now is make it read from the program counter. (I'll try to put together a test for this at some point - or maybe have a go with my logic analyzer, but it's only 8 channels so answering this sort of question is tedious.)

I fully expected the tests to generate discussion/ questions . Sorry I don't have the answer

[tom_seddon]

I've got the 65C02 tests passing on b2 now. Two things I noticed:

1. The tests have the 3-byte, 4-cycle NOP addressing mode as abs,X. But it must be abs, surely?

Thanks for noticing without feedback issues just fester.

I've taken the info from https://www.masswerk.at/6502/6502_instr ... .html#NOPs but happy to change.

Ah, sorry for being unclear - my comment applies to 65c02 only, for which these are documented as being 3-byte, 4-cycle NOPs and the test has them down as both taking the same amount of time. (See https://github.com/bitshifters/bbc-docu ... 65c02s.pdf page 30)

For 6502, where these are illegal opcodes, I assume abs,X is correct. The two cases certainly pass on my BBC B and the tets has them down as taking different amounts of time (as you'd expect due to the indexing).

--Tom

[dp11]

Got it. Fixed on my local version I'll push an update soon.

If b2 isn't far off I'd like to use it to run the test suite to check I have broken anything as I refine the tests and add extra targets.

[scarybeasts]

Got it. Fixed on my local version I'll push an update soon.

If b2 isn't far off I'd like to use it to run the test suite to check I have broken anything as I refine the tests and add extra targets.

On the topic of this test vs. the emulators, would it be ok to check it into the beebjit test SSD directory (with appropriate credit and lineage of course)? The existing test suite doesn't cover everything, particularly the 65c02 quirks and 6502 undocumented timings.


Cheers
Chris

[dp11]

On the topic of this test vs. the emulators, would it be ok to check it into the beebjit test SSD directory (with appropriate credit and lineage of course)? The existing test suite doesn't cover everything, particularly the 65c02 quirks and 6502 undocumented timings.


Cheers
Chris

Certainly, If there is a sensible way of running then as a test suite with beebjit to check I don't break things in the future that would be good too.

[scarybeasts]

Certainly, If there is a sensible way of running then as a test suite with beebjit to check I don't break things in the future that would be good too.

I attempted to script the test, with an eye to adding it to the functional tests.

Currently, the test itself appears to fail on the "RMB" / "SMB" instructions. It's unclear to me if these instructions leaked through to the 65c12 test from the 65c02 test, or if my 1-cycle NOP modeling for these is incorrect.

Here's a sample of scripting this test:

Code: Select all

./beebjit -master -0 ~/Downloads/65C12timing1M.ssd -debug -commands "b 49cf commands q;b 4a00 expr '(flags&2)==0' commands bail;c" -autoboot -headless -fast -accurate

(Needs the latest GitHub code for the new debug command "bail".)

It's fragile because it relies on exact PCs.
If execution arrives at $49CF, this is considered success because that is where "Done." is printed. I would have stopped later, at the final RTS, but the test turns on text output pagination, and the "Done." crosses the page threshold and makes the test pause. The script exits with a success code if this condition is hit.
If execution arrives at $4A00, and the Z flag is clear, this state indicates a timing mismatch. The script aborts if this condition is hit.

Similar to the discussion with Tom on another thread, one way to make the test reliably scriptable would to copy an RTS opcode to (e.g.) $6000 and $7000. If the test detects an error, throw in a JSR $6000. As the test is exiting, throw in a JSR $7000.


Cheers
Chris

[dp11]

Certainly, If there is a sensible way of running then as a test suite with beebjit to check I don't break things in the future that would be good too.

I attempted to script the test, with an eye to adding it to the functional tests.

Currently, the test itself appears to fail on the "RMB" / "SMB" instructions. It's unclear to me if these instructions leaked through to the 65c12 test from the 65c02 test, or if my 1-cycle NOP modeling for these is incorrect.

Opps fixed in version 0.20 , they did indeed leak across, sorry.

[dp11]

version 0.22 at the end of the tests stores the number of failures at &FCD0 so emulators can trap this to detect pass or fail.

[Matt Godbolt]

With huge thanks to dp11 (and a little reference to scarybeast's beebjit code), I think jsbeeb now passes all the tests now too.

[dp11]

With huge thanks to dp11 (and a little reference to scarybeast's beebjit code), I think jsbeeb now passes all the tests now too.

Yay! This test suite has been a little rabbit hole for me. What started out as one thing which I need to get back too, developed into learning about corners of the 6502 . I'm pleased you found it useful, so far every beeb/master emulator I've come across has needed it's help

[Coeus]

Thanks, dp11, for a very useful tool.

One query, though. On this screen for B-Em before I applied some more fixes, it shows an LAX instruction, opcode &B7, with the addressing mode zpx. When I went to look at the code b-em was actually adding Y to the ZP address. As far as I can see it is part of a set of instructions that normally use X as the index register unless X is involved in the transfer in which Y is used as the index register instead.

With Y as the index register, B-Em passed Tom's undocumented instructions test at https://github.com/tom-seddon/6502-tests:

P.S. a version of B-Em with the timing of undocumented 6502 opcodes fixes is at: https://github.com/stardot/b-em/tree/sf/cpuclocks

[tom_seddon]

Bit of a late update, but thanks from me as well for producing this test, which is very easy to run and doesn't take long. It ended up getting me back into doing some actual b2 development again, after a bit of a break!

The current release of b2 doesn't pass the tests, but the next release will. And the NMOS 6502 timing tests will be run as part of b2's CI tests in future, so, fingers crossed, if I break anything it won't stay like that for long: https://github.com/tom-seddon/b2/blob/w ... Timing.cpp

I noticed while writing this post that I didn't bother creating an equivalent test for the 65c02, but I'll fix that now.

--Tom