The various code sections in the enclosed *.s files are related as follows:

TESTBPIX initializes a crucial variable which adapts the driver to all gemdos
in regard to how the current drive of each running task can be found. This is
needed by Dgetdrv and Dsetdrv.

CURRBPPP shows how to initialize the pointer that keeps track of active task.
Both the functions Dsetdrv and Dgetdrv depend on that, and others depend on
them in turn.

DSGETDRV contains subroutines for Dgetdrv and Dsetdrv, which are also called
by subroutines in other sections.

DGETPATH contains subroutines for Dgetcwd and Dgetpath.
DSETPATH contains only a subroutine for Dsetpath.


The subroutines are intended to be called from a gemdos dispatcher after it has
rearranged stack data such that the arguments are on supervisor stack, in the
same order the calling APP placed them, regardless of whether it ran in super
or user mode.  This means that inside the subroutines arguments can be reached
as 4(sp) and so on, as the first 4 bytes on stack will be their return address.

Some of the subroutines may finish with a branch to a routine named E_1001_sub.
This is a special pseudo-error code which is not to be passed to the user.
It is only a flag to the dispatcher that called the subroutine that it should
jump to older gemdos and let it complete the function instead, but of course,
only after restoring the original entry conditions.

If you want I can give explicit example of the methods I use for the dispatcher
as well, although that does get a bit more complex.  That is why I left it out
this time, as I assume you already have dispatcher design that you want to
keep.  So you'll probably want to rewrite these functions instead.

Let me know if you need any more info on these routines and their operation.
