Re: [hatari-devel] 68030 undocumented instruction

[Toni Wilen <twilen@xxxxxxxxxx>]

I noticed similar side-effects when I did my tests few years ago:

"- 68020+ instructions that have extra opword field with zero bit followed by 3-bit REG (data register 0 to 7) field: If zero bit is set to one, REG field becomes address register field! Unfortunately it also seems to make instruction to return incorrect results, it looks like some internal operations use it as DREG and some as AREG. "Zero" bit appears to be not fully supported A/D select bit. (For example MUL.L, DIV.L, CAS2)"

I decided to ignore it because it is probably almost impossible to fully emulate without microcode listings.

(Strangest 020/030 feature I found: DIVS.W causing divide by zero: undefined V flag state appears to be random!)

---

From: Christian Zietz <czietz@xxxxxxx>
Sent: 26 January 2025 10:37
To: hatari-devel@xxxxxxxxxxxxxxxxxxx <hatari-devel@xxxxxxxxxxxxxxxxxxx>
Cc: Toni Wilen <twilen@xxxxxxxxxx>
Subject: Re: [hatari-devel] 68030 undocumented instruction

 

Thomas Huth schrieb:

> Am Sat, 25 Jan 2025 23:28:01 +0100
> schrieb Adam Klobukowski <adamklobukowski@xxxxxxxxx>:
>
>> has been found:
>> https://www.downtowndougbrown.com/2025/01/the-invalid-68030-instruction-that-accidentally-allowed-the-mac-classic-ii-to-successfully-boot-up/
>
> Thanks for the pointer, that's an interesting article! CC:-ing Toni, maybe
> he's interested in having a look for improving the emulation of the CAS
> instruction.
Imho, there is a lot of undefined/undocumented behavior, with regards to
the second word of the instruction in the 68030. See, for example, this
thread I stated about a year ago:
https://www..atari-forum.com/viewtopic.php?t=43642. It would be a
herculean task to emulate all reserved bits correctly

Regards
Christian