[comp.sys.amiga.tech] Exiting, but leaving some code "resident"

andrew@teslab.lab.OZ (Andrew Phillips 289 8712) (08/08/89)

I am looking to write a software "disk drive active light", because my hard
disk has no drive light (its just a card in my SideCar).  To do this
I just need a little bit of code to hook into a device and turn on
a sprite (already positioned in a corner of the screen) when the
drive access begins and turn it off again when the access is completed.
It could also be used as a RAM disk drive light.

Most of the program will be concerned with setting up the sprite etc
and just a little bit will need to remain resident after the setup is
complete.  Under MSDOS it is quite easy to set up a TSR (terminate,
stay resident) program that leaves a part of itself at the top of memory
and frees the memory occupied by all of its initialization code back to DOS.
I'm not sure, however, what the best way to do this is on the Amiga.

My first thought was to look at how some PD programs such as Popcli do it.
To my surprise Popcli never frees anything back to the OS, instead it goes
through some incredible contortions to make itself as small as possible.
Surely it would be preferable to only leave the relevant code in memory.
This would save more memory than Popcli now does and still let the program 
be more "conventional" and hence more readable and portable.

The only way I can think to do it is to allocate a bit of memory which is
never freed.  The program will allocate this memory, copy some machine
code to it, redirect a few functions (BeginIO for the device?) into this code
and then terminate.  Is there a proper way to do it or is there at least
a *better* way to do it?

Andrew.
-- 
Andrew Phillips (andrew@teslab.lab.oz{.au}) Ph. +61 (Aust) 2 (Sydney) 289 8712

darin@nova.laic.uucp (Darin Johnson) (08/11/89)

In article <188@teslab.lab.OZ> andrew@teslab.lab.OZ (Andrew Phillips) writes:
>Most of the program will be concerned with setting up the sprite etc
>and just a little bit will need to remain resident after the setup is
>complete.  Under MSDOS it is quite easy to set up a TSR (terminate,
>stay resident) program that leaves a part of itself at the top of memory
>and frees the memory occupied by all of its initialization code back to DOS.
>I'm not sure, however, what the best way to do this is on the Amiga.

Look at DMouse.  I used the same technique in MyMenu and it isn't that
hard - no fiddling with segment lists, etc.

Basically, you have 2 programs.  The first program is the one that the
user uses.  It parses the command line, does all the tedious setup,
etc.  Then it creates a named port to communicate with the second
program.  The first program will LoadSeg the first program.  The
segment list loaded, and any other data you want to pass to the second
program is hooked onto the named port.  Then you start the second
program as a process or task.  The second program will then look for
name port to get the information that it needs.  To make things safe,
the first program should signal the second and wait for a reply to make
sure that the second program is working.  After that, the first
program can exit, leaving the second program/process free to do what
it does.

Then, when you want to terminate the second program, you send a
'terminate' signal to the second program.  The second program will
then clean up, signal back, and exit (do a Forbid before sending the
reply signal and then immediately exit so that the first program will
not get the signal until the second one is dead).  The first program
then UnloadSeg's the second program (you saved the segments in the
named port, remember?), does whatever other cleanup it needs, and then
exits.

This allows you to make the second program as small as possible, since
memory allocation, command line parsing, setup, etc. can be done in
the first program with the appropriate data passed by being hung
off the message port.  Basically, declare the port as:

  struct myport {
    struct MsgPort port;
    BPTR segments;
    whatever else you want;
  }

(also, you could send the data with a startup message, but I haven't
tried that).  Also, no poking around any segment lists are required.

Both DMouse and MyMenu have shown up in comp.sources.amiga in the past.
Other programs do similar things, so poke around.

Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com)
	We now return you to your regularly scheduled program.