>It's no problem to write the patch, but it
>can't have the same entry point because then I wouldn't know which trap was
>calling my code.  So instead I stick the patch somewhere in the middle of
>the code segment and put in a GOTO statement to jump over it and write a
>few test statements in assembler.  I install the patch using traditional
>methods.
>
>The problem is:  when my new patch is called, I have almost no access to
>globals.  Nor can I call local fns.  All of these produce address or bus
>errors.

What exactly *is* your entry point? Are you using ENTERPROC, or just 
jumping into a random section of code?

The official FB way to get globals is to run into an ENTERPROC. This can 
also accept parameters. It ends with EXITPROC, which can return a value.

If you are jumping into an ENTERPROC and you aren't getting globals, 
something else is wrong.

>Walking through Macsbug shows that FB uses a6 or a4 addressing to find the
>globals.  Is there a value in a6 that I can store at startup, or a pointer
>value somewhere, which will give the base address for the globals? 

A6 is the local variable frame on the stack. It will change pretty much 
every time you get called.

A4 is the code resource global variable pointer. If you save this when 
you are in "known" code, then pull it back into A4 later, you will 
magically gain access to your globals. Of course, you have to be careful 
to save the value of A4 from when you were called so that you don't mess 
up another resource's globals.

If you have more questions please feel free to ask... I've done entirely 
too much of this kind of work... :-)

-Mars