I was spending most of the time today disassembling the on-board
device driver on my XCEED SE/30 video card, hoping to make a
substantial progress towards color X server support.  As the result, I
got these ROM calls (er.. what's the "correct" term for these?) called
by the on-board device driver:

_DisposHandle
_DisposPtr
_HLock
_NewHandle
_NewPtrSysClear
_ResrvMem
_SIntInstall
_SIntRemove

_NewPtr(SysClear) and _DisposPtr are already supported by MRG.  I
figured _HLock isn't a problem since nobody messes around anybody
else's memory under NetBSD.  _SInt{Install,Remove} wouldn't work
anyway, unless we make drastic changes in the interrupt handlers,
so I guess it's okay if they are just stubs doing nothing.

What I'm unconfortable with are _ResrvMem, _NewHandle and
_DisposHandle.  They are called like this:

In the driver's video open routine:
	...
	moveq	#VidLocalSize,d0	; size of driver's private storage
	_ResrvMem
	moveq	#VidLocalSize,d0
	_NewHandle	,SYS,CLEAR
	bnes	OpError
	_HLock
	...

In the driver's video close routine:
	...
	movel	dCtlStorage(a1),a0
	_DisposHandle			; dispose of the private storage
	...

It seems to me that _ResrvMem could be just a stub routine, too, since
it doesn't seem to really allocate anything.  As for _NewHandle and
_DisposHandle, I know a handle is a double pointer, but is _NewHandle
supposed to allocate a block of the given size and a pointer to it,
and return the pointer to the pointer (i.e. a handle)?  I think it
makes sense, but I've never programmed anything on MacOS.

I've done some programming on declaration ROM parser, and it works
well so far.  It won't be much trouble to load the on-board driver
from the declaration ROM and call it from grf driver once the issue
above is resolved.

BTW, full utilization of the declaration ROM would obsolete the ae
driver's guessing the buffer RAM address and the address of Ethernet
(MAC) address, and it might make those non-working 8390-based cards
just work (well, at least I hope it will).

What? _SlotManager? er... yeah, I guess I'll have to implement that...

ken