UAE CPU core based 680x0 tester/validator

[Toni Wilen]

Originally Posted by klx300r

I know this thread is about emulation but can anyone tell me a good program like this for real miggies

Why would you need it if you use real CPU? It is already guaranteed working correctly

EDIT: You can simply run it normally, it does not care if Amiga is real or less real. It does not measure any timings.

Originally Posted by apolkosnik

When I was testing TG68K lately, I've noticed in the Illegal.b test, it barks at 00BC, upon closer inspection it becomes ORI.L encapsulating two words following it.

Do you have latest version? It was known older bug (Only changed data gets saved to dat file and it has some bugs in certain situations)

[dirkwhoffmann]

Originally Posted by klx300r

I know this thread is about emulation but can anyone tell me a good program like this for real miggies

For testing my emulator, I used cputester to assemble a bunch of auto-booting ADFs. You can download them from my test repo at:

https://github.com/dirkwhoffmann/vAm...ster/cputester

Some tests require 8 MB Fast Ram, because this is where the tests are executed. All other tests are happy with 512 MB and run just fine on my original A500 (with a Gotek drive in it).

[Toni Wilen]

Real hardware users that need to use software like this will almost certainly have some kind of harddrive.

ACA500plus is really great for this purpose because it has hot swappable CF slot that accepts FAT formatted CF cards and supports many A1200 accelerators (and thanks to Individual Computers for sending me extra board that accepts 68010). It made development and testing relatively easy and quick, without it this would have never been made.

[klx300r]

@ dirkwhoffmann & Toni


thanks for the info guys

[Toni Wilen]

Test generator automatic gzipping (max compression setting) support added. Should make it easier and quicker to use without HD.

Binary updated.

[Toni Wilen]

Cycle count validation (68000, partially 68010) support is coming soon.. (Am I making it far too easy for other 68k emulator developers to make and verify cycle accurate 68000 emulation? )

I thought accurate cycle counting was impossible without extra hardware but I tried it and it does work (using $dff006 only). 4 cycle difference is immediately detected, 2 cycle difference is not always immediately detected but because tester runs same instructions multiple times (with different parameters), 2 cycle difference will be detected, sooner or later.

btw, there was only 3 timing errors in UAE 68000 cycle-exact mode that tester found: CHK.W had exception generating tests in wrong order and DIV divide by zero was 4 cycles too early and really rarely used instruction (BTST Dn,#x. Most probably does not even know it exists) was 2 cycles too fast.

[Toni Wilen]

Updated.

- cycle count validation (PAL Amiga 7MHz 68000 only, no bus errors yet due to hardware problem)
- interrupt exception testing.
- multi test set generation and testing (note: both ini and command line parameters have changed)
- gzip decompression works with 4096 byte stack.

[Toni Wilen]

New almost useless feature: full cycle-accurate 68010 tester support, including loop mode. As a "side-effect", UAE will also have cycle-accurate 68010 emulation. Probably the first ever

Some bugs also fixed, for example wrong cycle counts when tested instruction generates some exception and trace was also active.

Binary package updated.

[dirkwhoffmann]

Hi Toni,

great to hear that a cputester update is ready . I’ll continue to test my CPU asap and report any issues (if there should be any).

While waiting for the update, I've spent my time debugging interrupt timing in vAmiga. One of my test cases might be of interest for you because it shows a discrepancy between UAE and the real machine.

It’s described in more detail here

https://github.com/dirkwhoffmann/vAmiga/issues/274

It’s related to the exact timing between a write to INTREQ and the point in time where the CPU notices a change on its IPL lines.

[Toni Wilen]

68000 test is now complete and re-verified with real 68000.

Small test set that does not need extra hardware (no bus error test) is also uploaded. http://www.winuae.net/files/b/cputest_68000_data.7z (~6.0M) Unpack to "data"-directory.

Set requirements:
- 68000, PAL, 8M Fast RAM.
- KS 3.1 (40.63) (Tester uses upper 32k of address space for absolute short addressing mode tests, data must match 100%)

Use cputestgen to generate your own test set if you need different hardware config (like previously). Ini now contains different preset test set configurations that can be separately enabled or disabled.

Basic = basic instruction test, no special exceptions.
IRQ = test interrupts (INTENA/INTREQ matching exception)

Advanced tests, I am quite sure there is no emulator (except very recent UAE) or FPGA reimplementation (EDIT: except fxcast most likely) that passes all following tests. All side-effects (undocumented flags, undocumented exception stack frame, for example I/N and opcode field does not exactly work like documented) must be 100% correct or test will fail. Most likely there is no programs that care.. (except my tester!) cputest has command line parameters to disable some undocumented field checks if you only want to test that address error works and stack frame works as documented.

Tests all instruction variants and addressing modes that can cause address errors.

AE_SRC = address errors, address error caused by read.
AE_DST = address errors, address error caused by write (MOVE and MOVEM only)

ODD_STK = odd user stack pointer
ODD_EXC = odd exception vector (except address error vector)
ODD_IRQ = interrupt test + odd interrupt vectors

Add -cycles to enable cycle count verification.

[jotd]

going to adapt that to validate Musashi emulator. Can't use UAE core on my non GPL compliant project, and already found issues in Musashi that weren't in UAE core (ex: CHK2 instructions, some FPU instructions missing...)

[Toni Wilen]

Originally Posted by jotd

going to adapt that to validate Musashi emulator. Can't use UAE core on my non GPL compliant project, and already found issues in Musashi that weren't in UAE core (ex: CHK2 instructions, some FPU instructions missing...)

I am not sure 68020+ support is still working (test and report if interested enough ). I'll add full 68010 support next. Then it is time for 68020+ again.

CHK2 probably is/was wrong because almost every Motorola documentation only mentions "If Rn<LB or Rn>UB" which is not the whole truth.

[jotd]

On musashi, CHK2 was wrong because using unsigned. Thumbs up to UAE core for being to accurate (and when you check Motorola manual and UAE core code the formulas look very close. On musashi, it seems like the author reverse engineered the behaviour without reading the manual!

If I can make use of your program I'll tell you! It's going to be a fun journey trying to make musashi work on a non amiga 68040 FPU app where UAE core (basilisk actually) did a pretty good job but could not be used for legal reasons...

[dirkwhoffmann]

Originally Posted by jotd

going to adapt that to validate Musashi emulator.

I did the same when I switched from Musashi to my own CPU implementation in vAmiga. What I found out is that Musashi has cycle-counting issues with instructions that consume a variable number of cycles depending on the operands (like DIV).

Nevertheless, Musashi is a great core. What I really like about it is the very high code quality (which was one of the main reasons why I chose this core when I started vAmiga). However, at some point I had to switch to my own CPU implementation because Musashi doesn't keep track of when the CPU accesses memory (in Musashi, the clock is only incremented after a single instruction has been executed). This information is essential to accurately emulate bus sharing on the Amiga. It might not as important for other projects though.

[jotd]

for me the number of cycles or DMA stuff/access timing doesn't matter as I'm emulating the software on a custom board with a 040, not an amiga.

now to test musashi, after having read Toni docs and checked the sources, I think that the simplest way is to use the amiga binary testing program provided by Toni without any modification running under vamos executable emulator (running on musashi). I'm going to test that. That should work.

I had vamos running a few months ago. Now I have to remember how it works to make it run again on that code.

[Toni Wilen]

Small 68020+ update:

68020+ trace mode testing fixed.
68020+ test presets added (basic tests + trace bits, 68020+ only addressing modes, branch/jump address errors, odd exception vector address errors)

68020 new test presets validated on real 68EC020 (ACA1221EC connected to ACA500plus). NOTE: DIV undefined flags are still unknown. Ignore DIV reported flags if results is overflow or divide by zero.

[Toni Wilen]

New update:

If data or address register is used in test instruction (directly or in EA calculation), register's content is modified after the test. (Every register has different modification logic). This improves test coverage. Previously registers were modified only after each test round ("test_rounds" was larger than 1). Above linked 68000 test set was also regenerated.

68020+ addressing mode test preset was also improved.

Only test generator was updated. Data structures and m68k tester are unchanged.

[ceztko]

Originally Posted by Toni Wilen

68000 test is now complete and re-verified with real 68000.

A more general question: could the tester aid the rewrite of the JIT emulation, in the sense it could achieve better accuracy?

[Toni Wilen]

Originally Posted by ceztko

A more general question: could the tester aid the rewrite of the JIT emulation, in the sense it could achieve better accuracy?

If you mean timing: no because JIT can't be made to match any existing CPU timing. At least if you want it to be faster than non-JIT emulation. And timing of 68020+ is not fully known. JIT is wrong choice for this kind of emulation.

It can be used to validate if instructions are executed correctly and it has JIT loop mode option (not compatible with all instructions yet) = executes same piece of code n times because emulator usually does not do JIT compilation until it is sure code is run more than once. Compilation takes more time than emulating it normally few times.

[dirkwhoffmann]

Hi Toni,

I am playing around with the latest version of cputester. I.e., I tried this predefined profile:

; interrupt exception
[test=IRQ]
enabled=1
cpu=68000-68010
mode=nop,ext,swap
feature_interrupts=1

What does feature_interrupts exactly do if I set mode=nop. Does it run NOPs with an interrupt in between?