These issues were picked up by Toni Wilen's cputester.
Source/Destination register bits suffered from some confusion when an instructions that could only work with Data registers and had a bit set for address register. The result of this confusion was manifesting itself as wrong results or even writing the results into Address registers rather than Data registers.
This solves the texture corruption noted in:
rkrajnc#67
and I've noticed that another demo runs fine with the patch (at least on MiSTer):
https://demozoo.org/productions/32792/
According to @retrofun this has been tested on MIST and resolves the said issue. retrofun#2 (comment)
Some concrete samples of misconstructed opcodes causing issues:
Bitfield instructions:
bfchg eac0 31fe ... 2nd word should be 01fe since bits 15-12 of the second word should be 0. No dest in this opcode.
bfclr ecc2 ec68 ... 2nd word should be 0c68 since bits 15-12 of the second word should be 0. No dest in this opcode.
bfset eec0 8fc4 ... 2nd word should be 0fc4 since bits 15-12 of the second word should be 0. No dest in this opcode.
bftst e8c3 3a9a ... 2nd word should be 0a9a since bits 15-12 of the second word should be 0. No dest in this opcode.
bfexts ebc0 f094 ... 2nd word should be 7094 since bit 15 of the second word should be 0 - makes it write into An.
bfextu e9c0 116b ... bfextu d0{rkrajnc#5:d3},d1 ... if Dw(bit 5)=1 bits 4,3 should be 0. Also, if Do(bit 11)=1 bits 10,9 should be 0.
bfffo edc0 d771 ... 2nd word should be 5771 since bit 15 of the second word should be 0 - makes it write into An.
bfins efc0 7ee1 ... if Do(bit 11)=1 bits 10,9 should be 0. Also, if Dw(bit 5)=1 bits 4,3 should be 0.
Division and multiplication:
divul.l d0,d6:d0 - 4c40 000e ... Result written into A6 rather than D6.
mulu.l d0,d1:d0 - 4c00 05e9 ... A1: modified 00000080 -> 00000000 but expected no modifications
rkrajnc
commented
4 years ago
These issues were picked up by Toni Wilen's cputester. Source/Destination register bits suffered from some confusion when an instructions that could only work with Data registers and had a bit set for address register. The result of this confusion was manifesting itself as wrong results or even writing the results into Address registers rather than Data registers.
This solves the texture corruption noted in: rkrajnc#67 and I've noticed that another demo runs fine with the patch (at least on MiSTer): https://demozoo.org/productions/32792/
According to @retrofun this has been tested on MIST and resolves the said issue. retrofun#2 (comment)
Some concrete samples of misconstructed opcodes causing issues:
Bitfield instructions: bfchg eac0 31fe ... 2nd word should be 01fe since bits 15-12 of the second word should be 0. No dest in this opcode. bfclr ecc2 ec68 ... 2nd word should be 0c68 since bits 15-12 of the second word should be 0. No dest in this opcode. bfset eec0 8fc4 ... 2nd word should be 0fc4 since bits 15-12 of the second word should be 0. No dest in this opcode. bftst e8c3 3a9a ... 2nd word should be 0a9a since bits 15-12 of the second word should be 0. No dest in this opcode.
bfexts ebc0 f094 ... 2nd word should be 7094 since bit 15 of the second word should be 0 - makes it write into An. bfextu e9c0 116b ... bfextu d0{rkrajnc#5:d3},d1 ... if Dw(bit 5)=1 bits 4,3 should be 0. Also, if Do(bit 11)=1 bits 10,9 should be 0. bfffo edc0 d771 ... 2nd word should be 5771 since bit 15 of the second word should be 0 - makes it write into An.
bfins efc0 7ee1 ... if Do(bit 11)=1 bits 10,9 should be 0. Also, if Dw(bit 5)=1 bits 4,3 should be 0.
Division and multiplication: divul.l d0,d6:d0 - 4c40 000e ... Result written into A6 rather than D6. mulu.l d0,d1:d0 - 4c00 05e9 ... A1: modified 00000080 -> 00000000 but expected no modifications