ADC Home > Reference Library > Technical Notes > Legacy Documents > Hardware & Drivers >

Legacy Documentclose button

Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.

Current information on this Reference Library topic can be found here:

Docking Manager Q&As


This Technical Note contains a collection of archived Q&As relating to a specific topic--questions sent the Developer Support Center (DSC) along with answers from the DSC engineers. Current Q&As can be found on the Macintosh Technical Q&As web site.

[May 01 1993]

DockingDispatch trap supervisor mode bug and workaround

Date Written: 12/29/92

Last reviewed: 6/24/93

We're having a fatal problem using the DockingDispatch ($AA57) trap to get information about the Duo environment. When we call with a 'hdwr' selector, running virtual memory on a Duo 230 and a Duo Dock, we get a privilege violation on a

    MOVEC   VBR,A0

in some sort of patch (dock handler?) in the system heap. The 68030 isn't in supervisory mode. When we run without VM in the same setup, the 68030 is in supervisory mode and all is copacetic. When we try VM on a dockless Duo, or on a PowerBook 180 (with or without external video) the 'hdwr' selector works fine. Is there any documentation or guidance about which traps aren't safe to call because they require supervisory mode?


We recently discovered a bug in the configuration ROM on the Duo Dock. The bug is with a call to the _DockingDispatch trap using the hardware attribute selector when VM is on (only on the Duo Dock). The docking handler doesn't go into supervisor mode when running its hardware detection tests, and so when that call is made while running in user mode, the machine crashes, justifiably so, with a privilege error.

The declaration ROM can't be patched at this point, so the only alternative is to surround the _DockingDispatch call with code to force entry into supervisor mode, as shown in the code fragment below.

; Input:       None
; Destroys:    D0/A1
; Function:    When VM is running we must switch to supervisor mode so
;              that we may run necessary privileged instructions.
      MOVE.L  (SP)+,A1          ; Save a copy of return address-we might switch stacks
      MOVEQ  #8,D0              ; Set selector to Set Supervisor Mode for VM
      _DebugUtil                ;

      CMPI.W  #paramErr,D0      ; IF VM is on THEN  D0 = Status Register

      BNE.S  @Cont              ; ELSE
      MOVE.W  SR,D0             ;   Save the current Status Register
   ANDI.W  #$EFFF,SR            ; Make sure that we're in the interrupt stack
      JMP    (A1)               ; Get out of here

Upon returning from _DockingDispatch, return to user mode is different because there's only a selector to _DebugUtil to go into supervisor mode--no selector to return or set user mode. That you'd have to do manually with the status register. Here's an example from some system code:

    move.l  sp,usp            ; set the usp to the current stack
    move.l  4(sp),sp
    andi.w  #($FFFF-$2000),sr ; throw me into user mode (and onto usp)
    rts                       ; and return on usp

Back to top

dockHardwareAttr dockHasVideo bit

Date Written: 11/4/92

Last reviewed: 6/14/93

What are the implications of returning (or not returning) true for dockHasVideo in dockHardwareAttr? Is it sufficient to statically indicate that a bar supports a monitor? After all, the video driver can later determine whether a monitor is actually attached. Or is there an added benefit to reporting the presence of a monitor when DockingDispatch is called?


The dockHasVideo bit is used by the Docking Manager to determine whether or not it's reasonable to go to sleep. Sleeping is prevented under the following circumstances: the dockNoSleep bit is set in dockDockingAttr; the dockHasVideo bit is set in dockHardwareAttr; or the dockHasFPU bit is set in dockHardwareAttr. Apple's docking bars don't set the sleep bit in dockDockingAttr, but the two hardware bits are set. This way, sleep can work differently in the future without having to change the bars.

The determination of whether a bar can go to sleep or not is made at docking initialization time. This occurs before slot PrimaryInits are run, so the video driver isn't yet up and running. If the hardware bit is set statically, that will indicate to the Docking Manager that video always exists, as in the case of the DuoDock. This will currently prevent the possibility of putting the system to sleep. Apple's MiniDock handles this situation by running through a very stripped down version of PrimaryInit with the sole purpose of determining whether or not a monitor is physically attached.

Back to top

dockingAttr dockingStation bit

Date Written: 11/4/92

Last reviewed: 3/1/93

Does dockingStation true in DockingAttr imply enclosure (no LCD), AC power, SCC and modem port blocked, or what?


Our equates don't refer to dockingStation. Setting bit 3, dockNoLCDScreen, means that the internal LCD screen on the Duo shouldn't be used.

Bit 4, dockEnclosingBar, means that the unit is physically enclosed by the bar, as in the case of the DuoDock. We're not aware of that information being used for anything specific. It implies the ports on the back are blocked, but that's a secondary implication. Certainly the MiniDock blocks the ports on the back as well, and it's not considered a docking station, so its dockEnclosingBar bit isn't set.

Back to top

dockSoundAttr dockHeadphoneAttached bit

Date Written: 11/4/92

Last reviewed: 6/14/93

What are the implications of reporting dockHeadphoneAttached in dockSoundAttr? This seems superfluous because the presence of a headphone is directly detected at the main expansion connector, thus enabling or disabling power to sound portions of the bar via +5V SOUND.


Currently, there are no implications for either setting or clearing that bit. In the future, this may change, but neither DuoDock nor MiniDock set this bit, primarily for the reason you mention.

Back to top


Acrobat gif

Acrobat version of this Note (52K)


Back to top

Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.