Subject: Re: QuadraLink (was: Re: macbsd.com upgrade)
To: Michael R. Zucca <mrz5149@acm.org>
From: Bill Studenmund <wrstuden@nas.nasa.gov>
List: port-mac68k
Date: 06/07/1999 15:56:16
On Sun, 6 Jun 1999, Michael R. Zucca wrote:

> At 6:07 AM -0400 6/6/99, Ken Nakata wrote:
> 
> >> Using MacsBug and the Slots program, I've located the control and data
> >> registers on the UARTs, and know how to read these off the card via
> >> the sResource dir.  That's as far as I've gotten so far, though.
> >
> >Sounds like the rest should not be that hard.  You should be able to
> >write a NuBus attachment for the MI zs driver, and that should be
> >pretty much it.
> 
> A driver would be a snap since the chip should work with the zs driver but
> I think I remember somebody mentioning that the serial code needed some
> adjustment to deal with attachers who were not "onboard". I.e. the driver
> code may be hacked to deal specifically with the onboard serial chips.

It's not "hacked" to deal specifically w/ on-board chips, it's designed to
only work w/ on-board chips. :-)

> At worst you could just copy the generic zs code and make a NuBus zs driver
> to see what needs to change and to get the board up. Would that be zn? :-)

Ick. What'd work better is if we split the mac68k-specific zs driver into
an obio & nubus part. For that to really work right, Jason needs to make
the MI 8530 driver work w/ multiple attachments. That's because it's not
certain that the NuBus cards enforce the 2 us delay between operations the
chip needs. MacOS hardware does. We'd need explicit routines if it didn't.

Also, we need to create a number of queues, one per interrupt source. So
that's one for the obio hardware interrupt (at interrupt 4), one per NuBus
card, and a general one for software interrupts. The latter was the design
problem I ran into when I was trying to do this. My dissertation got busy
before I could finish. :-(

Take care,

Bill