XID      XGE INPUT DRIVER

The decision to include a loadable input driver specification
stemmed from the fact that after playing with lots of games
sometimes i found the code driving input devices was very poorly
written (my favorite source of quirks are the joystick drivers)
because it considerated only the test machines.
Future releases of 386P may be capable to run on nearly everything
provided they have "interface drivers" capable to connect 386P+XGE to the host
so it was a good thing to add more flexibility to the input section.

What's more, if you know how directly interface to an input device
you will be able to do it, gaining speed and/or finer control.

This release DOES NOT provide "XID" drivers
(sorry not enough spare time available)
but here follows what I PLAN to do for release 3.00
(by the way, look into 386keyb.asm 386joy.asm and 386mouse.asm
 and you will see that i started some preliminary work about it)

XID will support the following input devices:

Device:      Practical implementation:
2D POINTER   "a mouse"
4D POINTER
3D POINTER   "a 3D dataglove position sensor"
6D POINTER   "dataglove with roll,pitch&yaw data"

2D STICK     " a plain joystick"
4D STICK
3D STICK     "joystick + thrust forward/backward switches"
6D STICK     " Logitech Cyberman"

KEYBOARD     "raw keyboard i/o, a pad of button with a "raw input"
             and a tty-like input capability"

a 2D device provides X,Y   info 
            plus buttons
            
a 4D device provides X,Y   info 
            plus ROLL&PITCH   (x,y axis rotation)
            plus buttons            
            
a 3D device provides X,Y,Z info 
            plus buttons
            
a 6D device provides X,Y,Z (position) info 
            plus ROLL,PITCH,YAW (direction) (x,y,z axis rotation) info
            plus buttons.
            
The number of buttons can vary between 0 to 4.
Not present buttons must look as "not pressed"
and buttons must be assigned by default following
a "most useful" allocation order.

A POINTER device gives position and direction data using ABSOLUTE values.
Instead a STICK device gives only ON/OFF values
(like "moving up,moving right,not moving, etc. etc.")

A KEYBOARD device is just a collection of N buttons, with some of them
with a predefinite value you can trust exist
(the F1 ... F10 keys, the CURSOR keys,the SPACEBAR key ,the ENTER key
the PLUS and MINUS keys,the ALT,CTRL,SHIFT keys, the NUMERIC keys and at last
the ESC key).

PREDEFINITED & ADDITIONAL DRIVERS

The resident XID code will support 2 predefinited 2D stick devices
(KEYBOARD_JOYSTICK & IBM_JOYSTICK )
(supporting FOUR subdevices each)
        (release 2.00 supports IBM_JOYSTICK only)
3 predefinited 2D pointer devices 
(KEYBOARD_MOUSE,JOYSTICK_MOUSE & MICROSOFT_MOUSE)
        (release 2.00 supports MICROSOFT_MOUSE only)
and 1 predefinited keypad device (IBM_KEYBOARD).
For every XID device class there are FOUR available slots
(except the keyboard device)
( minus the already defined ones, for example, you can add only other
 two NEW joystick devices without "overwriting" the existing ones).

As i said above, you can add a new device OR "overwrite"
a previous device entry substituting it with a better one.

For example, my IBM_JOYSTICK device is designed for VCPI, if you 
want to add something working better under DPMI or Windows
you will be able to make one yourself and load&link it at runtime).

When you read a device you read ALL the subdevices 
(i.e. reading IBM_JOYSTICK you poll the status of up to four
      joysticks)
This means that you have to IGNORE the status of not-selected subdevices
or you'll get erratic results
I remember when i tried a game that insisted reading
my second joystick when my joystick port supported only one stick. 
the result was an  unplayable game (the second player moved erratically 
and the selection  menu bar was always moving).

LOADING THE DRIVER

a) It must have .XID file type (i.e MMOUSE.XID) and it should use
   and unique name (i know it's hard, but here comes some help).
b) Every XID driver must follows the following naming conventions

   device:        private filename:   loaded devices:  

   keyboard       ???????K.XID        1
   2d joystick    ???????J.XID        4
   4d joystick    ???????J.XID        4
   3d joystick    ???????J.XID        4
   6d joystick    ???????J.XID        4
   2d pointer     ???????P.XID        4
   4d pointer     ???????P.XID        4
   3d pointer     ???????P.XID        4
   6d pointer     ???????P.XID        4
      
   As i said above, there can be up to 4 devices of the same class
   (except for the keyboard device).
   You can always trust there are AT LEAST
   the keyboard and all the devices emulated from it.
   
c) If the program using XIDs found some XIDs into its home directory
   (the one the program file is loaded from) it loads 'em all
   up to the previous limit of 4 (or 1)
   
d) A SPECIAL FIELD into the XID header tells if the driver is a
   "substitution driver" for an already resident driver or if it is
   an additional driver.

e) There are three classes JOYSTICK, MOUSE and KEYBOARD
   and every device "look the same" of others in the same class
   (i.e. an ibm joystick (2D joystick)
         provides info for x,y,z,roll,pitch,yawn
         and the four buttons, but "returns info" only for
         x,y and two buttons)