23 October 2019, 20:49 | #21 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,567
|
Not enough information. Downloaded binary? Used latest source? ini contents?
(if binary, I'll update it later this week) |
27 October 2019, 02:32 | #22 |
Registered User
Join Date: May 2019
Location: US
Posts: 17
|
Yes, I've used the binary. Thank you again!
|
27 October 2019, 09:27 | #23 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,567
|
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. |
28 October 2019, 22:09 | #24 |
Registered User
Join Date: May 2019
Location: US
Posts: 17
|
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!? Last edited by apolkosnik; 28 October 2019 at 22:13. Reason: attachment? |
29 October 2019, 19:04 | #25 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,567
|
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. Last edited by Toni Wilen; 30 October 2019 at 17:56. |
07 December 2019, 11:56 | #26 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,567
|
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. Last edited by Toni Wilen; 07 December 2019 at 21:25. |
30 December 2019, 09:53 | #27 |
Dirk Hoffmann
Join Date: Jun 2019
Location: Karlsruhe
Posts: 33
|
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 ?. |
30 December 2019, 11:06 | #28 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,567
|
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) |
30 December 2019, 12:40 | #29 |
Dirk Hoffmann
Join Date: Jun 2019
Location: Karlsruhe
Posts: 33
|
Works like a charm now. Thank you very much for this great tool. It's invaluable for emulator testing!
|
30 December 2019, 14:36 | #30 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,567
|
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. |
30 December 2019, 17:25 | #31 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,567
|
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. |
05 January 2020, 10:13 | #32 |
Dirk Hoffmann
Join Date: Jun 2019
Location: Karlsruhe
Posts: 33
|
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). |
05 January 2020, 10:53 | #33 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,567
|
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. |
05 January 2020, 11:07 | #34 |
Dirk Hoffmann
Join Date: Jun 2019
Location: Karlsruhe
Posts: 33
|
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 |
05 January 2020, 11:58 | #35 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,567
|
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. |
05 January 2020, 12:59 | #36 |
Dirk Hoffmann
Join Date: Jun 2019
Location: Karlsruhe
Posts: 33
|
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? |
05 January 2020, 13:34 | #37 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,567
|
Try increasing stack size. Decompression probably needs lots of stack.
EDIT: normal 4096 stack won't be enough. 10000 seems to work. |
05 January 2020, 14:06 | #38 |
Dirk Hoffmann
Join Date: Jun 2019
Location: Karlsruhe
Posts: 33
|
Increasing stack size did the job!
Now, test case ANDSR fits on a single ADF and runs just fine |
09 January 2020, 06:37 | #39 |
Registered User
Join Date: May 2019
Location: US
Posts: 17
|
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 |
09 January 2020, 07:08 | #40 |
Registered User
Join Date: Oct 2007
Location: ManCave, Canada
Posts: 1,627
|
I know this thread is about emulation but can anyone tell me a good program like this for real miggies
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
680x0 tester | JimDrew | support.WinUAE | 3 | 28 October 2014 20:44 |
Cheap dual core mobo/cpu/ram | Smiley | MarketPlace | 0 | 16 May 2012 14:23 |
Hatari now uses WinUAE CPU Core | Ian | Retrogaming General Discussion | 7 | 15 January 2012 10:36 |
Free : 680x0 CPU's | alexh | MarketPlace | 23 | 28 November 2009 12:29 |
Usung UAE CPU core | gbr | New to Emulation or Amiga scene | 3 | 12 November 2003 21:29 |
|
|