UAE CPU core based 680x0 tester/validator

[Toni Wilen]

Not enough information. Downloaded binary? Used latest source? ini contents?
(if binary, I'll update it later this week)

[apolkosnik]

Yes, I've used the binary. Thank you again!

[Toni Wilen]

7z archive updated. It is really easy to break something without noticing because re-testing all CPU models takes many hours..

Note that 68020/030 DIVU and DIVS now reports some undefined flag errors. Ignore them. Internal logic is not fully known and it seems to have multiple "early exit" conditions that affect flags.

[apolkosnik]

Toni
I'm Still running into some issues with cputestgen.exe

I get the following by commenting out the high memory + switching to 68020 and 32bit, 256MB of FASTMEM is at 0x40000000, I bump the
test_memory_start to 0x41000000

data/68020/RTR
- 256 tests
data/68020/JSR
Test instruction didn't finish in single step in non-loop mode!?

when I set "feature_full_extension_format=1"
I get the following:

data/68020/MVPMR.W
- 3162 tests
data/68020/MOVE.L
Test instruction didn't finish in single step in non-loop mode!?

[Toni Wilen]

I can't duplicate first error (perhaps you got older cached archive?). Second is fixed now.

Also includes single feature change: "feature_flags_mode=1" mode also generates every CCR combination (instead of only all zeros and all ones) if instruction is "cc"-type (Bcc, DBcc etc).

btw, feature_full_extension_format=1 needs better randomizer. Plain random can't generate enough indirect modes.

EDIT: Added 68010+ exception vector vs vector offset validation.

[Toni Wilen]

Some update news:

http://atari-forum.com/viewtopic.php?f=68&t=37890 special case is now tested and verified. This required change to generate test instruction structure because this behavior depends on following instruction. Now test instruction structure alternates between NOP/ILLEGAL and ILLEGAL/NOP (swapping words was easiest solution):

<test instruction>
ILLEGAL
NOP

and

<test instruction>
NOP
ILLEGAL

Same alternating code structure is also used when generating any branch instruction target. ILLEGAL is used because test code always needs to end in some type of exception. ILLEGAL (4afc) and PC matching expected end means "test finished normally"

Trace testing (if enabled) is also now much better. For example previously trace stacked on top of other exception was ignored. It is fully verified now. Trace after above NOP is also verified.

Some 68000 address error fixes. 68000 bus errors are partially supported (reads only, write bus errors are not yet tested and results are not accurate)

68020 trace modes are also fully verified now. (if enabled)

Target EA mode now also works with all branch instructions, including RTS/RTR/RTE/RTD.

To recap most important changes:

68000 test should be 100% when CPU is used in unmodified Amigas (=bus errors not used).

68020 check is also improved. Some branch instruction address error stack frame fixes. DIV undefined flags are still wrong (This is almost impossible to fix without knowing which kind of internal algorithm is used)

Other CPUs are not yet retested. (This is painfully slow operation..)

EDIT: 68000 write bus errors are now added and should be fully accurate.

[dirkwhoffmann]

It seems like cputester doesn't work properly on my Windows machine. I downloaded the zip file (via the link in the first entry of this thread) and run cputestgen. In the shell that comes up, the tool iterates through all instructions, but it creates 0 test cases for each instruction (I didn't change the .ini file). A screenshot is located here:

https://github.com/kstenerud/Musashi/issues/63

Hope somebody can help me out ?.

[Toni Wilen]

Binary has been randomly updated, it probably had some issue in normal test mode because recently I have been mainly testing address and bus errors using special modes designed for exception testing.

Current version seems to work, binary updated. (Note that ini has new entries, most of them are disabled).

Some notes:

68000 bus and address error tests are now completely implemented. Includes all found side-effects and undocumented behavior (Partially updated registers, partially updated SR/CCR, unexpected stack frame I/N field, unexpected stack frame opcode field and so on)

[dirkwhoffmann]

Works like a charm now. Thank you very much for this great tool. It's invaluable for emulator testing!

[Toni Wilen]

Great. "Unfortunately" in this case it uses emulation core to generate all test cases so it can only work correctly if emulation is correct. Which means I had to run the test on real 68000 and if some result is wrong, emulation/tester needed fixes

btw, when all "basic" tests pass, you can increase "difficulty" by setting "feature_sr_mask=0x8000" to enable trace mode tests.

Address error testing is not very useful at the moment because afaik no emulator (except now UAE) does not emulate address (and bus) error undocumented behavior, mainly because no one depends on it, not even any protections for some odd reason.

I guess bus/address error tester really needs "basic" mode which only checks if exception is generated when expected and stack frame fields are almost correct (for example opcode field is not always current opcode) and ignore all partially set registers and CCR.

[Toni Wilen]

Optional bus/address error "basic" checking added.

"basicexc" command line parameter, if enabled and exception is 2 or 3, partial register/ccr changes are ignored (SR part is still checked) and stack frame opcode field always accepts both current and next opcode, stack frame N/I bit is ignored. 68000 only.

[dirkwhoffmann]

Hi Toni,

is it possible to limit the number of test cases generated by cputester or split them? I am facing the problem that I need to copy the generated tests to ADFs (which works pretty well for most instructions). Unfortunately, the test cases are too large in some cases. E.g., cputester generates about 200000 tests for ANDSR which results in very large 000x.dat files (about 1MB each).

[Toni Wilen]

All "special" instructions (OR x,SR,STOP etc..) that take 16 bit word test all possible 65536 combinations. I don't want to change it but I can add support for gzipped dat files (gzip is already used in ussload).

Does gzipping them make them small enough? You can also add HD floppy support if you want more space

EDIT: STOP becomes about 400k, others probably are too big because they have multiple addressing modes but you can use feature_addressing_modes_src/feature_addressing_modes_dst to limit which modes are used.

[dirkwhoffmann]

Gzipping would help! The files shrink to about 15% of their original size

Before:

-rwxr-xr-x 1 hoff staff 80 5 Jan 09:43 0000.dat
-rwxr-xr-x 1 hoff staff 930046 5 Jan 09:43 0001.dat
-rwxr-xr-x 1 hoff staff 930038 5 Jan 09:43 0002.dat
-rwxr-xr-x 1 hoff staff 792571 5 Jan 09:43 0003.dat

After:

-rwxr-xr-x 1 hoff staff 70 5 Jan 09:43 0000.dat.gz
-rwxr-xr-x 1 hoff staff 123841 5 Jan 09:43 0001.dat.gz
-rwxr-xr-x 1 hoff staff 120100 5 Jan 09:43 0002.dat.gz
-rwxr-xr-x 1 hoff staff 102110 5 Jan 09:43 0003.dat.gz

[Toni Wilen]

Done

All data files can be gzipped now. (EDIT: but note that if tmem.dat is packed, it needs temp memory to unpack)

EDIT2: if file is gzipped, it must have .gz extension.

[dirkwhoffmann]

By gzipping the files, I managed to pack everything on a single ADF, but I have trouble to boot it in UAE.

It starts by saying:
Decompressing ‚data/68000/lmem.dat.gz‘ (25292 -> 32768)

After that, I get a "Software error -task held" box.

I guess the issue is somehow related to memory usage. My UAE settings are: 512 Chip, 512 Slow, 8 MB Fast.

In cputestgen.ini, I used:

test_memory_start=0x800000
test_memory_size=0x60000

I had to reduce the size form 0x80000 (default value) to 0x60000 to make it fit on a single ADF. Could this be the problem?

[Toni Wilen]

Try increasing stack size. Decompression probably needs lots of stack.

EDIT: normal 4096 stack won't be enough. 10000 seems to work.

[dirkwhoffmann]

Increasing stack size did the job!

Now, test case ANDSR fits on a single ADF and runs just fine

[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.

00BC
4EFC
4E71

[klx300r]

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