On Thu, Jun 18, 1998 at 02:37:39AM -0400, Michael Sokolov wrote:
>    P.S. Of all ongoing NetBSD works the one I appreciate the most is Jay
> Maynard's work on SGEC and KA670. Keep up the good work, Jay!

Thanks! This is turning into a really educational job for me - which is
exactly what I wanted. Of course, the AlphaStation 200 I bought to help the
project has been educational, as well. (Related note: Anyone have hardware
docs on the TGA boards, specifically the ZLXp-E2 24-plane version?)

> If the SGEC driver is written in a way that is tied to
> the existing KA630/650 code, NetBSD would have problems in the future if
> someone decides to support KA50, a BabyVAX system board with an SGEC chip.

I'm not planning on doing it this way, at least not explicitly. My goal, at
least for the SGEC and SHAC drivers, is to make them just another pair of
drivers that anyone can include in their system's configuration independent
of the bus type - since it's not attached to the Qbus anyway. At least for
the KA670, the SGEC is just 16 registers starting at 0x20008000; making it
work for other CPUs should be a matter of making it figure out which machine
it's on and supplying the appropriate address for the SGEC, and (possibly)
adding code to figure out what the machine's Ethernet address is (if it's
not stored in the same manner as the KA670, which has it as byte 1 of 6
longwords starting at 0x20008400).

That does bring up something, though: I should comment the driver code so
finding the spot to do both of those will be simple.

> I strongly advise you to first restructure the BabyVAX code to make it
> possible to support chips like LANCE when they are found on a Q-bus VAX
> CPU, develop full support for KA640, and only then tackle things like KA660
> and KA670, using the SHAC driver developed for KA640 and making the new
> SGEC driver applicable to both Q-bus VAXen and BabyVAXen.

Only one gotcha: I don't _have_ a KA640/KA50/whatever to play with. The only
reason I'm doing the KA670 is that I stumbled across a smoking deal to get
it. With that in mind, how would you suggest I proceed? It's kinda hard to
write driver code for a machine you don't have to test on.

If you'd like to look at my work so far, I'd be happy to accept any comments
you might have in the hope of making it better, be that in terms of making
it apply to more systems or making the existing code work better on what I
have to test on. That goes for anyone else, too. The code on my Web page (at
http://www.phoenix.net/~jmaynard/{if_ze.c,if_zereg.h} isn't up to what I
consider acceptable standards of commenting yet, and there are a few crocky
design features I'm going to clean up (WHY did I do the setup frame
processing like I did?! Argh!), but there should be enough there for people
to point and laugh at.