Has anyone ran this on a real 6502? I'm trying to ballpark how long this test program would take on say, 1MHz 6502 processor. Before I start counting cycles, I was curious if anyone had a cycle count or estimate as to how long this program generally takes.

Yes, it's been run on a real 6502. The runtime should be of the order of a few minutes, I think.


That's from the original thread at viewtopic.php?f=2&t=2241 - the test will have changed since that statement but I'd assume it's around the same runtime.

Does anyone know the exact number of CPU cycles that Klaus' test is suppose to take from the first instruction until the last store to $0200?

Several of us are making 6502 emulators (debuggers as well), and all of our times are different.

In Kowalski running the binary from Github with $3399 patched to $BB (stop), $36E4 patched to $10 (to circumvent the BRK flag flaw in Kowalski) and PC set to $400 the CLK counter stops at 92322648. But why on earth is that important?

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

For a cycle exact emulation, you need the number of cycles to match! I have sub-cycle accuracy requirements for 6522VIA emulation. Arthur's CBM prg Studio (http://www.ajordison.co.uk/index.html) has a REALLY nice 6502 assembler/debugger where you can walk through the code and see the exact number of cycles for each instruction, and he wants to get that correct. For things like raster interrupts, serial transfer routines, etc. cycle time is critical.

It's not all about going as fast as you can in some cases. With a PIC CPU I am averaging 19 cycles per 6502 instruction emulation. At 70MIPS, you get 70 cycles for every 1us. So when emulating a 1MHz 6502 with a simple 2 cycle instruction (like NOP - 2us), I have 140 instructions worth of time available to perform the instruction, but in the case of NOP I need just 7 cycles to perform the instruction. I figure my 6502 core emulation is around 12MHz using the 70MIPs CPU if I run it flat out without waiting on the true cycle time timer to expire and trigger the next fetch. I don't need the speed to be that fast, but the cycle time really matters for the accuracy of the emulation it is being used with.

Is there any sort of benchmarking program that has been written yet to determine the emulation speed?

I'd recommend checking out Matt Godbolt's BBC emulation - it runs every software protection scheme and game and is probably the most accurate emulation of a Beeb. It has to be cycle-accurate to manage this, although there could still be errors.
http://bbc.godbolt.org/
http://xania.org/Emulation
https://github.com/mattgodbolt/jsbeeb

Running Klaus' tests, and adding instrumentation to the emulator, shouldn't be too difficult.

Edit: MESS emulates NES and C64, and I think the same engine can emulate for example Asteroids, so the 6502 model in there must be very accurate.
http://www.mess.org/mess/howto#getting_started
https://github.com/mamedev/mame/tree/ma ... /cpu/m6502
But, that said, I can't see any handling of cycle counts, which is a bit odd.

The functional test is not suitable as a benchmark. It spends most of its time executing a small subset of instructions required by the test harness. Even a benchmark will not help as it gives you only an overall performance index but no idea of which individual instruction is too slow or too fast.

A test for cycle time accuracy could easily be made, if a timer (16 bit or larger) with the host CPU's clock resolution is available from inside the emulated machine. A test harness would store the timer before and after an instruction is executed. The difference minus the clocks that the empty test harness would take should give you the exact amount of host clocks an instruction takes.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

It's not a bad timing accuracy test, in some ways - it does run lots of instructions, and if you get the "wrong" cycle count then your emulation is wrong. On the other hand, if you get the right count you still might have compensating errors, and also, this test (I think) doesn't take care to cover both page-crossing and not page-crossing cases, where that makes a difference.

The BBC is a poor environment for timing tests because the CPU runs at 2MHz and the counters at 1MHz. The C64, if I'm not mistaken, steals cycles using RDY at least in some modes. In both cases, you'd need to take care to suppress interrupts - but without relying on the I bit, which is modified during the test.

Something like a PET or KIM would be better.

My 6502 (not 65C02) emulation has to be cycle exact for Commodore 1541/1571/1581 drive emulations. The timing with other emulated parts (6522, 6526, WD1770, GCR data separator) require sub-cycle accuracy. The 6502 instruction emulation is interrupt driven, based on a 1us cycle clock. So, when the timer expires (set by the last instruction's required cycle time) the interrupt launches and the next instruction is processed. The main loop just handles a LCD screen and SD card, interrupts handle everything thing else. I handle the page boundary crossing issues for increased cycle time, but I am trying to find a way to verify the accuracy. Arthur also wants to make sure his debugger is fully accurate. Right now, we have been just running large sections of code and comparing it to VICE's monitor and adjusting things as needed.

My 6502 emulation passes the Klaus test up to $2A, where it fails because of the decimal mode is not being handled correctly for the flags. So, I am working on that currently to resolve the issues.

In this context (cycle count accuracy) I'd say Klaus's test is another choice of a large section of code. Unless you've got some measure of coverage, you can't know whether you've found the last bug. But every bit of testing helps, up to a point.

Yes, I agree completely - which is why I wanted to know how many cycles it actually takes (including the BRK/RTI). I guess I could try replacing VICE's (C64 emulator) ROMs with custom code that copies the Klaus test code to $0000 where it belongs and then pokes in the NMI, RESET, and IRQ vectors that it uses. VICE's monitor has a cycle counter built-in that I am pretty sure is accurate.

Klaus earlier gave the cyclecount in Kowalski's emulator - if that agrees with VICE, there's a good chance they are both right. It's probably worth trying a few short cases in both first. (http://exifpro.com/utils.html)

I've started a new topic for instruction timing tests: please see
viewtopic.php?f=8&t=3340

I have created a wrapper for Klaus' code (latest release). This creates a 16K ROM that resides at $C000-$FFFF. This can be incbin'd into any emulator and when the CPU is reset, the reset vector jumps to code that moves the Klaus test suite from this ROM to $0000-$3FFF in RAM. This is done in two steps, the first moves 54 pages from $C200 to $0200 using indirect indexing ($xx),y... and the second step moves $C000-$C1FF to the zero page/stack area using ABS,Y. This method keeps the code small, and the 2nd step is needed to prevent the zero page and stack from changing values during the copy. After the move is complete, it clears A/X/Y (not needed really) and jumps to $0400 to start the test suite. This will be able to test any 6502 emulation core that has 16K of RAM from $0000-$3FFF and 16K of ROM from $C000-$FFFF. We should also be able to use this as a basis for testing total instruction times. BRK/RTI is supported in this code! So, your 6502 emulation needs to support these instructions!

ROM image and CBM prg Studio project is attached.

I downloaded the latest Klaus functional test from Github this evening. I want to test my newly designed CRC65 which has a W65C02 and 58K of RAM. The top 6K are I/O and ROM. So I modified the 6502_functional_test.a65:
ROM_vectors = 0 (ROM vector is not writable)
report = 1 (include report.i65)
I also edited report.i65 for my hardware specific I/O.
assembled it:
as65 -l -s2 -x 6502_functional_test.a65

It generates the .hex file and I load and run it on CRC65 and get this result:

So that's all good. Now I did the same with 65C02_extended_opcodes_test.a65c
ROM_vectors = 0
report = 1
assembled it:
as65 -l -s2 -x 65c02_extended_opcodes_test.a65c

But received this error messages:
File 65c02_extended_opcodes_test.a65c, Line 2694 : Undefined label brk_ret0
File 65c02_extended_opcodes_test.a65c, Line 2728 : Undefined label brk_ret1

I don't understand why the error messages because I can see the label brk_ret0 and brk_ret1 in the source. I use the as65 included in the GIT download. Help!
Bill