I have a classic Mac OS executable where control is given to an instruction whose hex encoding is $FBE6. I have been unable to find documentation for this F-line instruction, and it doesn't appear to be a m68881 coprocessor instruction given that the coprocessor ID, which is in bits 9-11, is 0b101 = 5.

  • do you have a piece of code with this instruction used? post a hexdump and the disassembly before/after it. Maybe post the binary if you can share it.
    – Igor Skochinsky
    Jan 17 '18 at 12:39
  • Agree with the above. Without seeing the source, it might as well be a disassembly error.
    – Jongware
    Jan 21 '18 at 15:17
  • Indeed. Looking at the source of my disassembler, it's decoding a PC-relative address incorrectly, fetching non-code data, and trying to decode that. Jan 21 '18 at 22:15

This is not a complete answer, but maybe I can shed some more light on this interesting question.

Digging through the 68030, 68040, 68851 (PMMU) and 68881/2 (FPU) manuals, it seems that the $FBE6 opcode is not a valid opcode for any known Motorola coprocessor.

As stated in the 68030 UM/AD chapter 10, coprocessor ID #5 is reserved for Motorola use. The only two IDs used by Motorola seem to be 0 (PMMU AFAIK) and 1 (FPU).

The "type" bits (8-6, see p. 10-4) have the value 7. This value does not seem to be defined, so - if I understand the documentation correctly - the CPU will throw an exception.

Looking at some proprietary source code (which I can obviously not show here) derived from Motorola's fpsp040 code indicates that coprocessor IDs other than 1 are ignored in the FPU emulation F-line handler (this excerpt is from the Motorola-licensed code):

  movel   L_SCR1(%a6),%d0  |d0 contains the fline and command word
  bfextu  %d0{#4:#3},%d1   |extract coprocessor id
  cmpib   #1,%d1           |check if cpid=1
  bne     not_mvcr         |exit if not
  moveml     USER_DA(%a6),%d0-%d1/%a0-%a1 |restore data registers
  frestore (%a7)+
  unlk   %a6
  addl   #4,%a7
  bral   real_fline

The proprietary code, however, replaces the last instruction with a jump to a user-defined F-line handler. So, there is a chance that the application or OS installed its own F-line handler for the $FBE6 opcode. It seems that the 68k emulator on PPC machines used several F-line opcodes; the article linked describes the opcode $FE02 which returns from 68k emulation to PPC code. However, this uses a coprocessor ID of 7, so $FBE6 might not be related to the emulator after all.

  • Line-A and Line-F instructions have been used for years to implement custom hooks for system calls. On the Atari ST, for example, Line-A was used to draw graphics. In the old MC68K Mac OS, Line-F was extensively used for all kinds of OS stuff - mostly undocumented. Hence OP's question.
    – Jongware
    Jan 21 '18 at 15:12
  • Indeed, my original suspicion was that I'd encountered some undocumented Line-F OS service. Alas it turned out I had a bug in my 68k disassembler that was causing it to spuriously decode data as machine code. Jan 21 '18 at 22:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.