It’s notable, but not entirely surprising, that the breadth of undocumented behaviour in the 68K family has yet to be fully elucidated. I suspect there are other corner cases lurking that something, somewhere, depends on.
If memory serves, didn’t early Macs use illegal instructions for what would probably be considered a syscall interface today? Obviously that’s not little-known, at all, but may be little-remembered.
I can’t remember the official description well enough to explain it thoroughly, and I think we called them “A Trap” instructions, which is not a great term for web searches. I get mostly Admiral Ackbar memes. There was even a bomb dialog that said “Unimplemented Trap”. The OS relied on them, and OS extension authors would hook in ahead of the OS reliance on them using “INIT” resources.
!!! DO NOT XEROX <— That, coupled with the tech content of the card, brought back a flood of memories.
Thank you for finding that! I used to have that exact reference card hanging next to my desk in the early 2000s. It was up there to help me troubleshoot builds for handspring PDAs. Macs had, of course, long since moved on from 68k. But there was a window of time when I looked at that card frequently. I’m pretty sure I bought it at SoftPro, in Burlington, MA. Where I also used to buy OpenBSD CDs.
I would be hesitant to call A-line traps “illegal instructions” - the construct is perfectly valid and documented, even if not every system defines every possible one of them (the “Unimplemented trap” message you saw just indicates that the exception handler doesn’t know that trap number). The same general mechanism is used for FPU instructions, which would be diverted to software using a similar method if an FPU were not present (i.e., F-line instructions).
When I had to learn assembly in school, we learned it on a weird simulated CPU, then 6502, then 68000. Without comment on the validity of the technique, my understanding of what was going on under the hood was that the 68k CPU was treating it as an illegal instruction, then the software was trapping it and keeping things moving. But it’s been a really long time, and may be just an artifact of how the professor who explained it to me understood things.
Maybe I missed it, but does this ever explain why the problem only shows up in 32-bit mode and not in 24-bit mode? Is the address masked to 0x00FFABBA and that somehow ends up being a valid address?
No, I think that’s another MAME bug, since on real hardware the same behaviour occurs in both 32-bit and 24-bit mode (if I read the article correctly).
It’s notable, but not entirely surprising, that the breadth of undocumented behaviour in the 68K family has yet to be fully elucidated. I suspect there are other corner cases lurking that something, somewhere, depends on.
If memory serves, didn’t early Macs use illegal instructions for what would probably be considered a syscall interface today? Obviously that’s not little-known, at all, but may be little-remembered.
I can’t remember the official description well enough to explain it thoroughly, and I think we called them “A Trap” instructions, which is not a great term for web searches. I get mostly Admiral Ackbar memes. There was even a bomb dialog that said “Unimplemented Trap”. The OS relied on them, and OS extension authors would hook in ahead of the OS reliance on them using “INIT” resources.
A bit of searchengineering led to [macintosh 68000 interrupt] and [macintosh 68000 vector] and this non-mac reference card has a terse paragraph or two explaining traps https://os9projects.com/CD_Archive/TUTORIAL/REF/CARD/68000_Ref_Card.pdf
!!! DO NOT XEROX <— That, coupled with the tech content of the card, brought back a flood of memories.
Thank you for finding that! I used to have that exact reference card hanging next to my desk in the early 2000s. It was up there to help me troubleshoot builds for handspring PDAs. Macs had, of course, long since moved on from 68k. But there was a window of time when I looked at that card frequently. I’m pretty sure I bought it at SoftPro, in Burlington, MA. Where I also used to buy OpenBSD CDs.
I would be hesitant to call A-line traps “illegal instructions” - the construct is perfectly valid and documented, even if not every system defines every possible one of them (the “Unimplemented trap” message you saw just indicates that the exception handler doesn’t know that trap number). The same general mechanism is used for FPU instructions, which would be diverted to software using a similar method if an FPU were not present (i.e., F-line instructions).
That is a very reasonable perspective.
When I had to learn assembly in school, we learned it on a weird simulated CPU, then 6502, then 68000. Without comment on the validity of the technique, my understanding of what was going on under the hood was that the 68k CPU was treating it as an illegal instruction, then the software was trapping it and keeping things moving. But it’s been a really long time, and may be just an artifact of how the professor who explained it to me understood things.
Maybe I missed it, but does this ever explain why the problem only shows up in 32-bit mode and not in 24-bit mode? Is the address masked to 0x00FFABBA and that somehow ends up being a valid address?
Does anybody want to port https://github.com/xoreaxeaxeax/sandsifter to the 68030? :)
No, I think that’s another MAME bug, since on real hardware the same behaviour occurs in both 32-bit and 24-bit mode (if I read the article correctly).