Here is a piece of good news about NuBus video: I have the new version
of the code!  I used the -current sources as of Oct 18 07:40:20 1996 and
put in my old code with some important changes. Here are my
comments, notes and questions (at the end), I will prepare the diffs
and build the GENERIC kernel. In short, if the colorkit kernel did not
work for you, this one may work (or not).

I actually have disassemled the driver and I know by 75% how it
works. The leftover 25% are related to the data dumped into registers
and some bits in flags that I do not understand. I am waiting for intvid
sources to see if I can gain some insight for Michael Zucca's knowledge.

The driver source makes amusing readings. Only from the driver source I
could deduce what SGetBlock trap should return (it does not return the
length field, only the data, Inside Macintosh tells otherwise). Also,
the driver allocates memory and the deallocates it after adding
something to the pointer:

ptr = NewPtr(size);
ptr+= number;
DisposePtr(ptr);

The old macrom routine with malloc/free pair would definitely choke on
that code. I put in some extra alignment in those routines to make them
work under such a stress. This terrible code is in open() routine and
'ptr' above is the gamma table pointer.

In another point the codem in the close() routine, the buffer is freed by
DisposeHandle trap and only after that the pointers in the buffer are
used to free space. I do not know how MacOs memory management system
handles those tricks, fortunately, we never need to close() the driver.

I use now the data for a display specified by get_vrsrcid() which in
turn receives the display type from MacOS. If this sounds obscure, here
is the simpler explanation: I put in some numbers in the code without
knowing that they are related to the display type. I guessed wrong, so
the driver defaulted to some type. It happened to be close to
the display I have.

As a side effect, the gamma table is loaded correctly. (The was *no*
gamma table correction in the previous version due to bugs)

I got the video interrupts working correctly. I had to comment out
panic() call in macrom.c:jswapmmustopper() for that. This function is
harmless, it is supposed to switch 24<->32 bit addressing, why the
panic? 

I still need two extra pieces of code that does not yet exist:
1) After mode change ite must be told of new video parameters. There is
no such function now. I feel that itecninit() is slightly different from
what I want.
2) I have to map NuBus space exactly as it is, to 0xF?000000. Why this
space is mapped to kernel virtual space and not to its physical
equivalent? 


I have interesting historical question: 

In the grf_mv.c:grfmv_intr() function, char 0 in put in
slotbase[0xA0000]. Where did this address come from? Is is a guess or
some card requires it? On my card, long 1 should go into
slotbase[0x200148]. If this code is not removed, the kernel hangs as
soon as interrupts are enabled. (In addition to enable_nubus_intr() call
the card must be told to generate them, 
slotbase[0x20013c] = (long)5 
on my card or enable VBL interrupts from the Booter).