Trying again (repeat with me: Sending binary attachments to mailing lists 
is _bad_  ;):

On 27. Juni 2000 3:12 Uhr, Michael R. Zucca <mailto:mrz5149@acm.org> wrote:
 >At 4:43 PM -0400 6/26/00, Hauke Fath wrote:
 >>1) Attach a "dockbus" to nubus (the docks I have seen map to
 >>nubus slot E). Then, attach whatever the dock contains (SCC, SWIM II,
 >>53c80, SONIC, video] to dockbus.
 >
 >Well, I was sort of against this method for a while but I'm beginning to
 >think it's not such a bad idea. What's happening here is that the NuBus is
 >acting sort of like bridge for the "dockbus" if you will. The dockbus
 >could then contain a bridge to another NuBus.

Making my way through Apple's "Developer Note Macintosh Duo System" [1] I
get a somewhat different picture: The Note goes to great lengths explaining
that for the sake of flexibility a Dock looks like a big Nubus card to the
Duo. The Dock ROM has all the drivers for the attached peripherals (with
the exception of .Sony), and it officially reserves slot E.

A way to handle this situation could be to have the Nubus code scan a slot
for an sResource category of "CatDock" (0x20) first. When it finds a Dock,
it should ignore all the other sResources for the Nubus slot and hand over
control to the dockbus probe routines.

 >Actually, I'm kind of interested in
 >how NuBus devices on the dock appear to the Duo. I wonder if there is some
 >kind of windowing going on or something. In that case we'll definitely
 >have to do some kind of crazy sub bus stuff and put in logic to handle the
 >bridge chip and windowing. (Ugh!)

According to [2] (see <http://www.tangro.de/~hf/macbsd/> ), all the dock
hardware (with the exception of the SWIM which is handled by the Duo ROM
anyway) is situated in slot E space. Nothing crazy in sight.  ;)

 >>There actually is
 >>a 'clr.b offset(reg)' where we expect it, only the base address is
 >>obtained "very indirectly".
 >
 >Yeah, this is the same as the RBV. I was seriously confused because it
 >seems to go through all of the trouble of "clearing interrupt register".
 >All it's doing is dropping a zero in the location. When the palette loads,
 >the code scans that RAM location waiting for the timer event to write into
 >the location.
 >
 >Can you  get the address of that value? Is it in NuBus space? If so, then
 >maybe I'm wrong and it's a weird hardware thing. Though, I'll bet its just
 >like the II's.

[2] suggests it's in slot E space. I have no evidence one way or another -
as I said, the interrupt routine uses a base address set up elsewhere, in a
place I haven't found yet. I can send you the driver resource, if you feel
you cannot resist.  ;)

 >What's the pinout on the dock? Maybe there's more than one interrupt pin.
 >That way, the interrupts can be serviced, as you say, as obio interrupts.

The Duo connects over a 152 pin connector -- essentially a PDS slot. But I
suppose the Nubus interrupt controller VIA is in the dock.

	hauke

--
[1] Macintosh Developer Notes, Number 2: Macintosh Duo System,
	APDA publication number R0457LL/A

[2] "PowerBook Duo Dock II Hardware"

--
Hauke Fath                        Tangro Software Components GmbH
                                         D-69115 Heidelberg
hf@Tangro.DE                       Ruf +49-6221-13336-35, Fax -21