>Okay, you talked me into it, I'll try and get ENTERPROC% to work.  But
>already I'm confused.  I used Macsbug to step through the entry to my
>ENTERPROC% and, contrary to the online help, did not see ENTERPROC% saving
>the registers--in fact, it doesn't touch the stack at all.  It just seems
>to be setting up its own a4 addressing.   Do I have to save the registers
>myself from within the ENTERPROC%?

There is a subtle but critical difference between ENTERPROC% (with the 
percent sign) and ENTERPROC (without). There can only (safely) be one 
ENTERPROC% per program. But there can be as many ENTERPROCs as you like.

ENTERPROC% is the code resource's main entry point. For an INIT, this 
represents the code that will be called at startup. All ENTERPROCs are 
alternate entry points - they can be called at any time.

> I was hoping to do a test patch like this:
>
>"My Patch"
>ENTERPROC%
>  ` move.l  ^gOldTrapAddr&,-(sp)
>EXITPROC%
>RETURN
>
>But even this doesn't work.   I'm starting to miss Fantasm...

I suggest putting the setup/cleanup code outside of the ENTERPROC. 
Whenever there are register-based traps, at least, that's the only way to 
do it. I did something like the following for a jGNEFilter a while back:

"jGNEFilter"
`  move.l A1,-(sp)
`  move.l D0,-(sp)

ENTERPROC
  FN goDoMyFBCodeNow(REGISTER(A1))
EXITPROC

`  move.l (sp)+,D0
`  move.l (sp)+,A1
"returnoperation"
`  jmp $00000000

And that's it. I pointed the jGNEFilter to LINE "jGNEFilter". Then I 
poked the previous jGNEFilter value into the address LINE 
"returnoperation"+2. This way, when the jmp executed, its argument was 
the old address that the code was supposed to go to.

Something similar should work in an ordinary stack-based trap patch.

-Mars