  This information will hopefully be of use to anyone trying to make the
play routine work under Watcom (I don't have it or use it). Some steps have
already been taken in that direction based on the reports of a user (whom I
haven't been able to contact recently).

  In the globals.h file there is a set of preprocessor directives that
identify what compiler the code is being compiled with. I've taken a wild
guess that __WATCOMC__ is defined under the Watcom compiler. It probably
isn't, so you'll need to change that to the correct constant name.

  To work in protected mode, the playroutine needs to interact with the DPMI
server to allocate conventional memory and hook hardware interrupts. It does
this by using a set of functions that start with _go32. ("go32" was the name
of the DOS extender that came with DJGPP 1.x. Under 2.x the extender is part
of the executable program, but the function names are the same.) Most of the
_go32 functions are just wrappers; the real functionality is provided by the
DPMI server. I assume the same sorts of functions exist under Watcom, though
with different names.
  The places in the playroutine where you would need to add code are marked
with three asterisks (this is my personal notation for something that needs
to be done). They're uncommented so they will block compilation until
they're dealt with. If you need me to explain how any of the code works in
more detail, just ask.
	
  In Appendix C of the GMS manual there is a discussion of hardware
interrupts and virtual memory. Something like _CRT0_FLAG_LOCK_MEMORY should
exist under Watcom; if it doesn't that is a Very Bad Thing.

  Watcom 10.5a has a bug which forces you to compile all modules containing
interrupt handlers with the /zu option. This causes the compiler to complain
about some variables, but can be worked around by adding the static modifier
to those variables. I've added the static modifier to the variables I was
told to, but there have been changes to the play routine code since then,
so it may not be enough.
