On 26. Juni 2000 7:15 Uhr, Michael R. Zucca <mailto:mrz5149@acm.org> wrote:

>>Why does the DuoDock's ethernet adapter not show up?
>
>I think it's one card = one device right now. We find the first good
>sResource and then pass that info onto the first appropriate driver. So if
>we find the video card first, that gets passed on and we're done.

OK. That was the impression that I got, too.

>
>>Why don't I see the Dock itself probed?
>
>Dunno. What does the sResource look like?

For the DuoDock II, 'slots' shows me "0020 0001 0001 0002" as ID (the first
"0020" is probably "class Dock") and the tag
"Dock_Station_Apple_DuoDockII". The sResource is in directory slot "FD".

>>Are we able to handle "multi function cards"? Or do we take the first
>>device only from any Nubus slot?
>
>I think the dock is going to require special handling and I think it's
>going to require that the drivers in question use bus-spaces correctly and
>not assume they have the whole slot available to them.

OK. I think that may be relevant for zs and [sbc|ncrscsi].

>I think if somebody patches up the NuBus code to scan for multiple devices
>and pass on the right bus-space info to the drivers, I'll bet it could be
>made to work in a relatively straight forward way.

I can see two ways from here:

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.

2) have the nubus attach code activate all it finds in a nubus slot instead
of grabbing the first known device as it appears to happen now.

I like 2) better. If we attach the dock itself (see the resource above) we
can trigger a probe for all the devices that may be in the dock but are not
listed in the ROM: SWIM II, 53c80, SCC, sound controller.

>I wonder what the interrupt handling on such a multi-function device would
>be like. After all, I think there's only one interrupt per slot unless the
>Duos do something special. If it's a one-interrupt model then they
probably
>figured the video retrace interrupt wasn't worth the bother or the
overhead
>when the same interrupt was necessary to service the ethernet and any
other
>cards on the dock. I'll bet the palette reloading code polls a register in
>the Jet controller rather than waiting for a video interrupt to occur. Try
>disassembling the palette code and see if you can find a little loop like
>that. If that's the case, there's probably no video interrupt.

Well, that's an interesting point...
In the case of the Apple MiniDock where the slot ROM lists only one device
-- the video controller -- I cannot even find where the MacOS driver
[un]registers a slot interrupt. It deals with the Time Manager, that's all.

In the case of the DuoDock where we have two devices competing for the slot
interrupt (SONIC and JET) the JET driver has code similar to what Allen's
"Delving for Video Interrupt Information" document lists. There actually is
a 'clr.b offset(reg)' where we expect it, only the base address is obtained
"very indirectly".  [Looking through the "PowerBook Duo Dock II Developer
Note" I see a Time Manager task mentioned for dimming the screen, but not a
word about interrupts. Sigh.] Probably SONIC bypasses the Nubus interrupt
controller and behaves like an obio device?

But actually, the dock declaration ROMs do provide detailed information
about what is where in the dock. Must do some more reading...

>Hope this helps!

Definitely. Thanks a lot!

	hauke

-- 
begin  LOVE-LETTER-FOR-YOU.txt.vbs
This message was created and sent using the Apple Cyberdog Mail System
End