At 4:43 PM -0400 6/26/00, Hauke Fath wrote:
>>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".

I'm guessing that none of the drivers recognize it and so the system just
punts and skips that sResource and moves on to the next one.

>>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].

Yeah. Our serial and scsi drivers aren't yet set up to work with anything
but obio devices. The duo isn't the only thing that would benefit from a
conversion. There are several NuBus serial and SCSI cards that could
probably work easily if we converted the code to be more generic.

>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. 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!)

Oh yeah, there's also the problem of ejecting the Duo. In that respect we
have to sort of treat it as a dynamic bus like USB, or do you have to power
down to eject?

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

This is not so good for video because the sResources are often used to hold
register programming information for different VRAM/Monitor types and so
there are a dozen or so copies of sResources. During secondary (or is it
primary?) init the driver is supposed to shut off the sResources its not
using. This makes sense because you figure out what your situation with the
hardware is and then just shut off the stuff you don't need. Then the rest
of the time you just pluck info out of your active sResource. Too bad we
don't have that luxury.

However, maybe what we could do is this: Rather than do one driver = one
sResource, scan the sResources and look for common ones. Then package the
repeats up into a grouping and then do one driver = one grouping. The
driver could then pick the right info from the sResource grouping, store
the relevant info in its private data, and then go about its business. The
NuBus code could then toss the sResource grouping.

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

Ok, I've seen this technique before in the RBV driver on the II's. There is
no "interrupt" per se. A timer event is setup to write a value into a known
RAM location periodically. Sort of a soft retrace register. It just so
happens that on the II's the 60 Hz timer lines up with the video nicely.
Maybe on the Duos the timer event is attached to some clock onboard the
dock.

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

>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.  [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?

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.

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

Good hunting!

____________________________________________________________________
 Michael Zucca - mrz5149@acm.org - http://www.mdc.net/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
____________________________________________________________________