6502/CLK
1
0
Fork 0
mirror of https://github.com/TomHarte/CLK.git synced 2024-06-27 01:29:31 +00:00
Code Issues Projects Releases Wiki Activity

Improve README.

Browse Source
This commit is contained in:
Thomas Harte 2022-05-13 16:28:56 -04:00
parent dd63a6b61e
commit 7f704fdae1
1 changed files with 25 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
OSBindings/Mac/Clock SignalTests/68000 Comparative Tests/readme.md
View File

@ -1,37 +1,45 @@
# 68000 Comparative Tests
Tests contained in this folder are original to Clock Signal. All are in JSON format so there's no need to write and maintain a specialised parser.
Tests contained in this folder are original to Clock Signal. All are JSON.
Tests assume a test machine consisting of a vanilla 68000 with 16mb of RAM. For each test the 68000 should be started from power on and allowed to execute a single instruction.
Tests assume a test machine consisting of a vanilla 68000 with 16mb of RAM. For each test either:
1. start from a reset, e.g. if you have a prefetch queue you need to fill; or
2. just apply the entire initial state, which indicates the proper PC and A7 for itself.
Each file contains an array of dictionaries. Each dictionary is a single test. It includes a name, initial memory contents and register state, and any changes to memory that occur during the test plus the final register state.
Then execute to the end of a single instruction (including any generated exception).
Both the initial and final memory arrays are in the form:
Each file contains an array of dictionaries. Each dictionary is a single test and includes:
* a name;
* initial memory contents;
* initial register state;
* any changes to memory that occur during the test; and
* the final register state.
Both the initial and final memory arrays specify bytes and are in the form:
[address, value, address, value ..., -1]
All tests are randomly generated, and the end results were achieved empirically using a believed-good 68000 emulation. Nothing here is intelligent or crafted, this merely an attempt to get a lot of coverage with limited effort.
All tests are randomly generated, and the end results were achieved empirically using a believed-good 68000 emulation. Some have subsequently been patched as and when 68000 emulation faults are found. JSON formatting is not guaranteed to be consistent.
Nothing here is intelligent or crafted, it's merely an attempt to get a lot of coverage with limited effort.
## Methodology
Neither the file names nor the test names are necessarily accurate; the process taken for generating tests was:
Neither file names nor test names are necessarily accurate; process was:
* look up instruction encoding for instruction in the 68000 Programmer's Reference Manual, starting from page 8-5 (p561 of the PDF I'm using);
* those encodings will look something like: ORI -> 0000 0000 SS MMM RRR where SS = size, MMM = mode, RRR = register;
* therefore, generate the 256 possible 16-bit words that match that pattern and for each one that passes a does-this-instruction-exist test, produce a test case.
* look up an instruction encoding in the 68000 Programmer's Reference Manual, starting from page 8-5 (p561 of the PDF I'm using);
* that'll look something like: ORI -> 0000 0000 SS MMM RRR where SS = size, MMM = mode, RRR = register;
* therefore, generate the 256 possible 16-bit words that match that pattern; and
* for each one that passes a does-this-instruction-exist test, produce a test case.
However, the 68000 isn't fully orthogonal in its instruction encodings — in the ORI example above, some modes and some sizes are illegal, and those opcodes are used for other instructions. But my test generator isn't smart enough to spot that — it just spots that what it's generating is a real instruction, and therefore produces a test.
Since the 68000 isn't fully orthogonal in its instruction encodings — in the ORI example above some modes and some sizes are illegal, those opcodes being used for other instructions — the tests labelled ORI will include both: (i) all valid ORIs; and (ii) some other instructions. I didn't consider this worth fixing.
As a result, the tests labelled ORI will include all valid ORIs, plus some other instructions. I didn't consider this worth fixing, as it acts to increase my testing base.
Every generated opcode is followed by three words of mostly-random data; this data — and almost all other random numbers — never has the lowest bit set, and contains 00 where the size field would be if used for an An + Xn + d addressing mode.
I follow every generated opcode with three words of mostly-random data; this data — and almost all other random numbers — never have the lowest bit set, and supply 00 where the size field would be if they got used for an An + Xn + d addressing mode.
Similarly, all initial register contents are random except that the lowest bit is never set, just in case any of them is used to calculate an address for a word or longword.
All initial register contents are random except that the lowest bit is never set, to avoid accidental address errors.
So the output is very scattergun approach, with a lot of redundancy.
## Questionable Results
I am presently unconvinced by the results for the N flag on many of the [A/S/N]BCD results, as these often seem to conflict with Bart Trzynadlowski's 68knotes.txt.
This emulator seems not yet to generate values for the undocumented flags of DIVU and DIVS that match those listed here, but that's through lack of documentation. The objective here is to test my implementation of behaviour I am able to find descriptions of against other people's implementations of that same behaviour, to flush out errors in my comprehension and implementation.
Values for the undocumented flags of DIVU and DIVS have not yet been verified, due to a lack of documentation.