0

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.

Improve this question
3
  • 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, 2018 at 12:39
  • Agree with the above. Without seeing the source, it might as well be a disassembly error.
    – Jongware
    Jan 21, 2018 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.
    – John Källén
    Jan 21, 2018 at 22:15

1 Answer 1

Reset to default
2

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
  ...
not_mvcr:
  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.

Improve this answer
2
  • 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, 2018 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.
    – John Källén
    Jan 21, 2018 at 22:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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