3 ms·

> I’ve discovered an undocumented MC68030 instruction that performs a read-modify-write bus cycle and also changes the value of the A1 register. Rather than a

> I’ve discovered an undocumented MC68030 instruction that performs a read-modify-write bus cycle and also changes the value of the A1 register. Rather than a "real" instruction that CPU designers consciously created and which was meant to do something useful but wasn't documented, it could just be that this is an illegal instruction and the logic in the CPU is doing whatever it happens to do when given don't-care inputs. (Maybe this is what the author meant, and I'm just catching up.) Normally the CPU would detect illegal instructions and cause an exception. This would mean there are certain situations where it doesn't. I found a manual at https://www.nxp.com/docs/en/reference-manual/MC68030UM.pdf https://www.nxp.com/docs/en/reference-manual/MC68030UM.pdf. On page 8-9 of the manual (which is page 276 in the PDF file), it says: > An illegal instruction is an instruction that contains any bit pattern in its first word that does not correspond to the bit pattern of the first word of a valid MC68030 instruction or is a MOVEC instruction with an undefined register specification field in the first extension word. Note "in its first word". According to the write-up, the instruction is 3 words long. The first word is normal, and the weird bits occur in the second word. So quite possibly the 68030 doesn't validate this second word, just plows forward with the logic that implements the CAS instruction, and lets whatever happens happen. (Great write-up and amazing dedication, by the way!)

rep_lodsb 2y ago
It looks to me (not being an 68k expert) that only the first word is considered the "opcode": the second word just selects what "D" registers are used for the CAS operation. Normally one would expect the zero bits to be completely ignored in that case, since they don't have any role in the instruction. But maybe on the 68030 in this case, the bits must be zero even if they have no documented use, because there is hardwired logic for another instruction that is activated by those bits being set, somewhat like the 6502 illegal opcodes?
- userbinator 2y ago
  This is the closest I could find to what the 68000 opcode map looks like: http://goldencrystal.free.fr/M68kOpcodes-v2.3.pdf http://goldencrystal.free.fr/M68kOpcodes-v2.3.pdf It's reminiscent of ARM, but the relevant part is that the CAS instruction's second word bits 5:0 look like a "modrm" (to use the x86 terminology) where the officially documented values select only Dn, but the undocumented variant would correspond to (d16,An). At least, that's my theory for why A1 gets modified.
  - userbinator 2y ago
    Update: from the linked thread at https://68kmla.org/bb/index.php?threads/classic-ii-possible-rom-bug-weird-68030-instruction.49071/ https://68kmla.org/bb/index.php?threads/classic-ii-possible-... there is this quote that supports my theory: This seems to put something into A1 [...]If you clear bit 3 from the second word of the instruction this stops happening.
    - dougg3 2y ago
      It also appears that I may not have been the first one to discover that something odd was going on with that bit, causing it to use A0-A7 (with weird results) instead of D0-D7: https://eab.abime.net/showthread.php?t=119675 https://eab.abime.net/showthread.php?t=119675
sowbug 2y ago
In college, I took a computer architecture course that briefly went into CPU microcode. The fake CPU we studied divided opcodes into bit fields where a certain bit caused a certain primitive operation, like maybe triggering an adder. From this you could see that a specific opcode was just a particular composition of the right primitives. "Valid" opcodes were simply the combinations that were useful enough to document, and "invalid" ones were superfluous or meaningless combinations. Once you understand this, illegal/invalid/mystery opcodes are a lot less surprising; rather, they're inevitable. I was also taking a logic course at the time and dreaming in terms of truth tables, so it was quite a formative time in my early understanding of processor architecture.

rep_lodsb 2y ago

It looks to me (not being an 68k expert) that only the first word is considered the "opcode": the second word just selects what "D" registers are used for the CAS operation. Normally one would expect the zero bits to be completely ignored in that case, since they don't have any role in the instruction. But maybe on the 68030 in this case, the bits must be zero even if they have no documented use, because there is hardwired logic for another instruction that is activated by those bits being set, somewhat like the 6502 illegal opcodes?

userbinator 2y ago
This is the closest I could find to what the 68000 opcode map looks like: http://goldencrystal.free.fr/M68kOpcodes-v2.3.pdf http://goldencrystal.free.fr/M68kOpcodes-v2.3.pdf It's reminiscent of ARM, but the relevant part is that the CAS instruction's second word bits 5:0 look like a "modrm" (to use the x86 terminology) where the officially documented values select only Dn, but the undocumented variant would correspond to (d16,An). At least, that's my theory for why A1 gets modified.
- userbinator 2y ago
  Update: from the linked thread at https://68kmla.org/bb/index.php?threads/classic-ii-possible-rom-bug-weird-68030-instruction.49071/ https://68kmla.org/bb/index.php?threads/classic-ii-possible-... there is this quote that supports my theory: This seems to put something into A1 [...]If you clear bit 3 from the second word of the instruction this stops happening.
  - dougg3 2y ago
    It also appears that I may not have been the first one to discover that something odd was going on with that bit, causing it to use A0-A7 (with weird results) instead of D0-D7: https://eab.abime.net/showthread.php?t=119675 https://eab.abime.net/showthread.php?t=119675

sowbug 2y ago

In college, I took a computer architecture course that briefly went into CPU microcode. The fake CPU we studied divided opcodes into bit fields where a certain bit caused a certain primitive operation, like maybe triggering an adder. From this you could see that a specific opcode was just a particular composition of the right primitives. "Valid" opcodes were simply the combinations that were useful enough to document, and "invalid" ones were superfluous or meaningless combinations. Once you understand this, illegal/invalid/mystery opcodes are a lot less surprising; rather, they're inevitable. I was also taking a logic course at the time and dreaming in terms of truth tables, so it was quite a formative time in my early understanding of processor architecture.