UAE CPU core based 680x0 tester/validator

[Toni Wilen]

Interrupt test does this:

- SR interrupt mask is 7
- Single INTENA and matching INTREQ bit is set (one by one)
- RTE to test code which lowers interrupt mask
- test instruction (NOP or whatever) and/or interrupt runs.
- tester checks that correct interrupt exception runs and stacked SR and PC are correct and so on.

[slingshot]

Is it possible to run the tests with relocated VBR? I suspect that something wrong with that in the TG68K softcore, would be good to run the tests with a non-zero value.

[Toni Wilen]

Originally Posted by slingshot

Is it possible to run the tests with relocated VBR? I suspect that something wrong with that in the TG68K softcore, would be good to run the tests with a non-zero value.

VBR is always moved if 68010+. If VBR move wouldn't work, tester would hang/crash immediately.

Better download latest version (updated in July), use ini that comes with the download, then adjust memory size/etc options. Then generate and run all 68020+ preset basic tests. (BASIC, IRQ, EXTSRC, EXTDST) If I don't remember wrong , for example default sr_mask wasn't testing all SR combinations in older versions and PC field in some exceptions wasn't checked.

Add also -noundefined option to disable checking of undefined DIV, CHK and CHK2 flags.

btw, test result in github shows MOVEC SFC bits being stuck at zero (Possibly others too but because SFC test returned error, later MOVEC registers were skipped, especially CACR bit handling must be exactly right or some CPU detection code might fail). SFC and DFC should keep the written value, even if it does nothing.

[slingshot]

Thanks for the info!

Yepp, MOVEC is only partially implemented, everything else than VBR, CACR and USP is not doing anything.

[Toni Wilen]

Originally Posted by slingshot

Yepp, MOVEC is only partially implemented, everything else than VBR, CACR and USP is not doing anything.

MSP and ISP most likely is also important in some specific cases.

[slingshot]

Yes, I just didn't found any software (including Amiga OS) which sets the M bit, where the difference between ISP and MSP counts. Or I just looked for it in a bad way...

[Toni Wilen]

AmigaOS never uses it but there was at least one game (I don't remember which one) that sets M-bit and requires working MSP.

One possibility is that some game uses ISP instead of A7 to modify (or read) supervisor stack pointer. (if ISP is not implemented). ISP == supervisor stack pointer if M=0.

[slingshot]

Would be interesting to know which one sets the M bit. I only found some which set MSP but never set the M-bit. Don't ask me why.
Actually implementing ISP (x)or MSP would be not too hard, but implementing both and do the switching at correct times seems more cumbersome.

[Toni Wilen]

Originally Posted by slingshot

Would be interesting to know which one sets the M bit. I only found some which set MSP but never set the M-bit. Don't ask me why.
Actually implementing ISP (x)or MSP would be not too hard, but implementing both and do the switching at correct times seems more cumbersome.

I found it: Quik the Thunder Rabbit (for example "Quik the Thunder Rabbit (1994)(Titus)(Disk 1 of 3)[cr PDY].zip"). M-bit and MSP is set before "Loading" screen appears and stays set in Start Game/Password/Normal screen.

EDIT: I recommend first implementing only "storage" for those registers so that MOVEC to <currently unimplemented 68020 register> filters unused bits and MOVEC from same register returns stored value. Then run tester MOVEC test again.

[slingshot]

Thanks! I've already added SFC and DFC storing/retrieval. Currently I'm fighting with some stack frame issues, then I'll try to implement MSP/ISP/M-bit.

[slingshot]

These two issues are remaining with exceptions:
DIVU.W (default):
DIVU.W/0000.dat (default). 0...

0087ffa0 84c1 divu.w d1,d2
0087ffa2 4afc illegal
S 0088201a 62.1f.2e.bd.00.f2*a5.6a.1f.b1.1e.00.0b.00.9b.00.bc.00.00.3a
Exception stacked CCR (8014) != CCR (2010) at start of exception handler!
Trace (5 stacked) SR mismatch: 2010 != 8014
Registers before:
D0: 00002020 D1: 00000000 D2: f7ffff7f D3: fffec23f
D4: 815544a0 D5: 000d0d0d D6: 02000202 D7: 2319bf41
A0: 00000000 A1: 0000008d A2: 0000801b A3: 00007fff
A4: 7fffff52 A5: 03fffffc A6: 0087fea0 A7: 00860400
SR:!801f PC: 0087ffa0 ISP: 00860800
T1=1 T0=0 S=0 M=0 X=1 N!1 Z!1 V*1 C*1
Registers after:
SR:!8014/2010 PC: 0087ffa2 ISP: 00860800
T1=1 T0=0 S=0 M=0 X=1 N!0 Z!1 V*0 C*0
INTREQ: c000 INTENA: c000
3322 (1/2) S=0 E05=25 E09=25 E25=645 E26=215 E27=645 E28=860 E29=430 E30=430
CPUlvl=1, Mask=ffffffff Code=0087ffa0 SP=00860400 ISP=00860880
Low: 00000000-00007fff High: ffffffff-fffffffe
Test: 00860000-008fffff Safe: ffffffff-fffffffe

ILLEGAL (default):
ILLEGAL/0000.dat (default). 0...

0087ffa0 0abc
0087ffa2 4afc illegal
Exception stacked CCR (801f) != CCR (2018) at start of exception handler!
Registers before:
D0: 00000010 D1: 00000000 D2: ffffffff D3: ffffff00
D4: ffff0000 D5: 80008080 D6: 00010101 D7: aaaaaaaa
A0: 00000000 A1: 00000078 A2: 00007ff0 A3: 00007fff
A4: fffffffe A5: ffffff00 A6: 0087fea0 A7: 00860400
SR: 801f PC: 0087ffa0 ISP: 00860800
T1=1 T0=0 S=0 M=0 X=1 N=1 Z=1 V=1 C=1
Registers after:
SR: 801f/2018 PC: 0087ffa0 ISP: 00860800
T1=1 T0=0 S=0 M=0 X=1 N=1 Z=1 V=1 C=1
INTREQ: c000 INTENA: c000
OK: exception 4 80.1f.00.87.ff.a0.00.10
: 0087ffa2 ISP: 00860800
T1=1 T0=0 S=0 M=0 X=1 N!0 Z!1 V*0 C*0
INTREQ: c000 INTENA: c000
1952 (1/2) S=0 E04=122 E25=366 E26=122 E27=366 E28=488 E29=244 E30=244
CPUlvl=1, Mask=ffffffff Code=0087ffa0 SP=00860400 ISP=00860880
Low: 00000000-00007fff High: ffffffff-fffffffe
Test: 00860000-008fffff Safe: ffffffff-fffffffe

I wonder what's the meaning of these. Something with trace?

[Toni Wilen]

It means CCR content (SR low 8 bits) at the start of exception routine was different than SR low 8 bits that was stored to exception stack frame.

[slingshot]

Hmm, but where the 2018 value comes from?
Registers after:
SR: 801f/2018 PC: 0087ffa0 ISP: 00860800
T1=1 T0=0 S=0 M=0 X=1 N=1 Z=1 V=1 C=1
It looks like 801F from the detailed flags, which is stored in the stack frame.

I also wonder about the ISP value, since ISP is not implemented + test was executed in 68010 mode.

[Toni Wilen]

Originally Posted by slingshot

Hmm, but where the 2018 value comes from?
Registers after:
SR: 801f/2018 PC: 0087ffa0 ISP: 00860800
T1=1 T0=0 S=0 M=0 X=1 N=1 Z=1 V=1 C=1
It looks like 801F from the detailed flags, which is stored in the stack frame.

801f is stacked SR. 2018 is SR at the start of exception (tester saves SR at the start of its exception handler). High 8 bits are correct (T cleared, S set) but CCR part should be identical.

I also wonder about the ISP value, since ISP is not implemented + test was executed in 68010 mode.

Moving to/from A7 in supervisor mode equals MOVEC to/from ISP.

[slingshot]

I see. Seems the lower 3 bits are reset. Without your CPU tester, these bugs would never come to the surface.

[Toni Wilen]

Stacked SR vs current SR check was added only few months ago because at least 68040 has some weird edge case bug where they actually are different!

- 68040 RTR and RTE with odd return address in stack: address error stacked SR contains contents before RTR/RTE SR modifications. SR register contents when address error exception starts has correct contents.

[slingshot]

Here's another, which I don't understand. DIVL.L expects a CHK expection? Then OK: No exception generated. I would expect an 5, as D1 is zero.

DIVL.L (default):
DIVL.L/0000.dat (default). 0...

40850000 4c7b 1fbf 7666     divs.l   (lab_4085006a,pc,d7.w*8),d7:d1
40850006 4afc     illegal
S 4086b782 39.49.00.00.e4.00*b3.00.86.00.00.8c.13.15.c4.59.00.00.00.65
SR: expected 801f -> 8010 but got 801a (fff2)
Trace (6 stacked) SR mismatch: 8010 != 8010
Trace (6 stacked) PC mismatch: 40850004 != 40166b4c
Exception: expected 6 but got no exception.
Registers before:
D0: 000014aa D1:*00000000 D2: 7fff777e D3: 0ffff7d0
D4: 95555080 D5: 80810100 D6: 00010101 D7:*dc6f36e3
A0: 00000000 A1: 0000008c A2: 0000801e A3: 00007fff
A4: 7fffff0a A5: c03fffff A6: 4084ff00 A7: 40800400
SR:!801f      PC: 40850000 ISP: 40800800 MSP: 40800880
T1=1 T0=0 S=0 M=0 X=1 N!1 Z*1 V!1 C*1
Registers after:
D0: 000014aa D1:*763f4285 D2: 7fff777e D3: 0ffff7d0
D4: 95555080 D5: 80810100 D6: 00010101 D7:*e42e6200
SR:!801a/201a PC: 40850006 ISP: 40800800 MSP: 00000000
T1=1 T0=0 S=0 M=0 X=1 N!1 Z*0 V!1 C*0
INTREQ: c000 INTENA: c000
OK: No exception generated
3983 (1/2) S=0 E05=6 E09=6 E25=771 E26=257 E27=771 E28=1028 E29=514 E30=514
CPUlvl=2, Mask=ffffffff Code=40850000 SP=40800400 ISP=40800880
 Low: 00000000-00007fff High: ffffffff-fffffffe
Test: 40800000-4089ffff Safe: ffffffff-fffffffe

[slingshot]

Or maybe the main problem is that the stacked PC is at the middle of the DIVS instruction (40850004).

[Toni Wilen]

I am not sure. It looks like trace works incorrectly when combined with DIV.L.

btw, make sure to use -skipexcccr (ignores undefined flags) because DIV + divide by zero combinations has few undefined flags.

[dirkwhoffmann]

Hi. I'm trying to generate some 68010/68020 tests with the latest version of CPU tester. I've dowloaded the latest source code from GitHub and successfully built the "cputester" executable locally on my Mac with the Amiga gcc toolchain. Is there some official place to download an up-to-date "cputestgen.exe"? (If possible I'd like to avoid compiling it myself, because I can only run Windows in a VM and I had all kinds of issues with my Windows installations in the past).

In post 1, this link is given: http://www.winuae.net/files/b/cputester.7z

Is it still up-to-date?