On Sat, 6 Apr 1996, Ken Nakata wrote:

> substantial progress towards color X server support.  As the result, I
> got these ROM calls (er.. what's the "correct" term for these?) called

Tool traps..  Actually most of what you listed are system traps.  They 
are traps because they are actual instruction words (as there are no 
valid opcodes for them), and they all begin with $Axxx, and are sometimes 
called A-Traps or A-line traps or instructions.  They are thus used to 
make quick calls to system routines, because the processor does most of 
the overhead...  But they shouldn't be called ROM calls, because every 
one of them can be patched in RAM, though most point to valid ROM 
routines anyway... (unless you got a "fully configured", er patched, 
system like mine)

> _DisposHandle
> _DisposPtr
> _HLock
> _NewHandle
> _NewPtrSysClear
> _ResrvMem

All these are memory manager traps

> _SIntInstall
> _SIntRemove

slot manager traps...  (I hate those)  They are equivalent to VInstall 
and VRemove (from the verticle retrace manager), but they are to be used 
in conjunction with slots, or basically graphics devices (video cards).  
They make better timing than the standard ~60 Hz VBL timing...

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

Yeah, well it may be important.  Handles are usually areas of memory 
which are free to move around as the memory manager sees fit (to make 
room for other chunks of memory).  They will move around a lot and when 
you need to access the data of that memory chunk, you're supposed to lock 
it's position in memory, so it doesn't move around underneath you.  
That's all HLock does (MacOS).  Be careful if you take this one out!

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

Isn't there some sort of pseudo slot manager in BSD?

> 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

prepares for the next call, because ReserveMem moves relocatable blocks 
of memory around in this call in preparation for memory which will be 
fixed (always locked to one place).  It isn't necessary, but it's 
useful.  I'm not sure how BSD's memory handling would use that, however.

> 	moveq	#VidLocalSize,d0
> 	_NewHandle	,SYS,CLEAR
> 	bnes	OpError
> 	_HLock

then it allocates and fixes the handle in the system's heap, clearing the 
memory first...

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

don't want to leave it sitting around forever...

> It seems to me that _ResrvMem could be just a stub routine, too, since
> it doesn't seem to really allocate anything.

But it moves around memory in preparation...  personally, I think it's a 
stupid call.  This should be included automatically w/ NewHandle...

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

Basically, handles are pointers to pointers, but those first pointers are 
located in the master pointer records (see MoreMasters...) and contain 
more information than just the pointer itself, like whether it's 
purged,locked, a resource, etc.  I don't think BSD uses handles, but I've 
been wrong before...

What I think you should do is not worry about the Handle and just 
allocate a Ptr, since the block of memory looks to be fixed (locked) the 
whole time anyway.  Then you won't have to mess with master pointers 
either.  BTW:  Whatever happened to malloc()?

-- the Macintosh Man, AKA
--Rick C. Petty,  aka Snoopy             <blink>I hate Netscape</blink>
_______________________________________________________________________
SQL/Perl/Java/HTML/C++ programmer  http://www.itlabs.umn.edu/~pett0019/
pett0019@gold.tc.umn.edu, pett0019@itlabs.umn.edu, rpetty@future.i5.com