  The DOSEMU Alterer Novices Guide DANG
  Alistair MacDonald, alistair@slitesys.demon.co.uk
  For DOSEMU v0.66 pl0.0

  This Document is the DOSEMU Alterer Novices Guide. It is known as the
  DANG.
  ______________________________________________________________________

  Table of Contents:

  1.      Introduction

  2.      The Main group of Modules

  2.1.    dos.c Information

  2.1.1.  Functions in dos.c

  2.1.1.1.        dosemu

  2.2.    emu.c Information

  2.2.1.  Functions in emu.c

  2.2.1.1.        jmp_emulate

  2.2.1.2.        SIG_int

  2.2.1.3.        emulate

  2.2.2.  Remarks in emu.c

  2.3.    include/emu.h Information

  2.3.1.  Functions in include/emu.h

  2.3.1.1.        NEWSETQSIG

  2.3.2.  Remarks in include/emu.h

  3.      The DPMI group of Modules

  3.1.    dosext/dpmi/dpmi.c Information

  3.1.1.  Functions in dosext/dpmi/dpmi.c

  3.1.1.1.        dpmi_control

  3.1.1.2.        run_pm_int

  3.1.1.3.        do_default_cpu_exception

  3.1.1.4.        do_cpu_exception

  3.1.1.5.        dpmi_fault

  3.1.2.  Remarks in dosext/dpmi/dpmi.c

  3.1.3.  Items for Fixing in dosext/dpmi/dpmi.c

  3.1.4.  New Ideas for dosext/dpmi/dpmi.c

  4.      The Video group of Modules

  4.1.    env/video/vc.c Information

  4.2.    env/video/video.c Information

  4.2.1.  Functions in env/video/video.c

  4.2.1.1.        video_init

  4.2.2.  Remarks in env/video/video.c

  4.3.    env/video/X.c Information

  4.3.1.  Functions in env/video/X.c

  4.3.1.1.        get_vga256_colors

  4.3.1.2.        X_close

  4.3.1.3.        X_setmode

  4.3.1.4.        X_change_mouse_cursor

  4.3.1.5.        X_redraw_screen

  4.3.1.6.        X_update_screen

  4.3.1.7.        set_mouse_position

  4.4.    env/video/console.c Information

  4.5.    env/video/dualmon.c Information

  4.5.1.  Functions in env/video/dualmon.c

  4.5.1.1.        MDA_init

  4.5.2.  Remarks in env/video/dualmon.c

  4.6.    env/video/et4000.c Information

  4.7.    env/video/hgc.c Information

  4.8.    base/bios/int10.c Information

  4.9.    env/video/s3.c Information

  4.10.   env/video/terminal.c Information

  4.11.   env/video/trident.c Information

  4.12.   env/video/vga.c Information

  5.      The Keyboard group of Modules

  5.1.    base/keyboard/Xkeyb.c Information

  5.2.    base/keyboard/keymaps.c Information

  5.2.1.  Remarks in base/keyboard/keymaps.c

  5.3.    base/keyboard/slang-termio.c Information

  6.      The Misc group of Modules

  6.1.    dosext/misc/emm.c Information

  6.2.    dosext/misc/xms.c Information

  6.3.    arch/linux/async/sigsegv.c Information

  6.3.1.  Functions in arch/linux/async/sigsegv.c

  6.3.1.1.        dosemu_fault

  6.3.1.2.        print_exception_info

  6.4.    include/int.h Information

  6.5.    include/ports.h Information

  6.6.    base/misc/dosio.c Information

  6.7.    base/misc/disks.c Information

  6.7.1.  Functions in base/misc/disks.c

  6.7.1.1.        disk_init

  6.8.    emi-i386/cpu.c Information

  6.9.    dev/misc/lpt.c Information

  7.      The Serial group of Modules

  7.1.    base/serial/ser_defs.h Information

  7.1.1.  Remarks in base/serial/ser_defs.h

  7.2.    base/serial/ser_init.c Information

  7.2.1.  Maintainers

  7.2.2.  Functions in base/serial/ser_init.c

  7.2.2.1.        serial_init

  7.2.3.  Items for Fixing in base/serial/ser_init.c

  7.3.    base/serial/ser_ports.c Information

  7.3.1.  Functions in base/serial/ser_ports.c

  7.3.1.1.        do_serial_in

  7.3.1.2.        do_serial_out

  7.3.2.  Items for Fixing in base/serial/ser_ports.c

  7.4.    base/serial/ser_irq.c Information

  7.4.1.  Functions in base/serial/ser_irq.c

  7.4.1.1.        serial_int_engine

  7.4.1.2.        pic_serial_run

  7.4.1.3.        serial_run

  7.4.2.  Remarks in base/serial/ser_irq.c

  7.4.3.  Items for Fixing in base/serial/ser_irq.c

  8.      The Mouse group of Modules

  8.1.    base/mouse/mouse.c Information

  8.1.1.  Functions in base/mouse/mouse.c

  8.1.1.1.        mouse_init

  9.      The Bios group of Modules

  9.1.    base/bios/bios.S Information

  10.     The PIC group of Modules

  10.1.   dev/pic/pic.c Information

  10.2.   devpic/pic.h Information

  11.     The Sound group of Modules

  11.1.   dosext/sound/sound.c Information

  11.1.1. Maintainers

  11.1.2. Functions in dosext/sound/sound.c

  11.1.2.1.       sb_io_read

  11.1.2.2.       adlib_io_read

  11.1.2.3.       mpu401_io_read

  11.1.2.4.       sb_io_write

  11.1.2.5.       sb_dsp_write

  11.1.3. Remarks in dosext/sound/sound.c

  11.1.4. Items for Fixing in dosext/sound/sound.c

  12.     And Finally ...
  ______________________________________________________________________

  11..  IInnttrroodduuccttiioonn

  This document is the preliminary draft of a manual to help people
  understand the inner workings of dosemu.  It is the goal of this
  document to create new dosemu hackers.  This concept was inspired by
  the linux kernel hackers guide.

  This Guide was concieved and originally written by "Corey Sweeney"
  <corey@interaccess.com>. It has been completely revised. It is now
  generated automatically directly from the source code. Special thanks
  to "James B. MacLean" <macleajb@ednet.ns.ca> for supplying the
  original information. (It was mostly ripped out of a mail message.)
  "Jochen Hein" has made many useful comments & suggestions.

  At the end if this document is a section detailing how this guide is
  put together. This may help you when trying to locate the relevant
  pieces of code. If you add new code, it would be useful if the
  relevant markers are added where appropriate.

  This file is a collective effort. If you don't like one of the
  explanations, or want to add anything, please send me something!

  22..  TThhee MMaaiinn ggrroouupp ooff MMoodduulleess

  These files are used to start DOSEMU as well as hold globally called
  functions and global vars.

  22..11..  ddooss..cc IInnffoorrmmaattiioonn

  22..11..11..  FFuunnccttiioonnss iinn ddooss..cc

  These are the functions defined in dos.c.

  22..11..11..11..  ddoosseemmuu

  Arguments are:

  +o  argc - Count of argumnents.

  +o  argc - Actual arguments.

     Function created by entry point into libdosemu. Called to jump into
     the emulate function of DOSEMU.

  22..22..  eemmuu..cc IInnffoorrmmaattiioonn

  22..22..11..  FFuunnccttiioonnss iinn eemmuu..cc

  These are the functions defined in emu.c.

  22..22..11..11..  jjmmpp__eemmuullaattee

  call the emulate function by way of the dll headers. Always make sure
  that this line is the first of emu.c and link emu.o as the first
  object file to the lib

  22..22..11..22..  SSIIGG__iinntt

  The IRQ numbers to monitor are taken from config.sillyint, each bit
  corresponding to one IRQ. The higher 16 bit are defining the use of
  SIGIO

  22..22..11..33..  eemmuullaattee

  Arguments are:

  +o  argc - Argument count.

  +o  argv - Arguments.

     Emulate gets called from dos.c. It initializes DOSEMU to prepare it
     for running in vm86 mode. This involves catching signals, preparing
     memory, calling all the initialization functions for the I/O
     subsystems (video/serial/etc...), getting the boot sector
     instructions and calling vm86().

  22..22..22..  RReemmaarrkkss iinn eemmuu..cc

  DOSEMU must not work within the 1 meg DOS limit, so start of code is
  loaded at a higher address, at some time this could conflict with
  other shared libs. If DOSEMU is compiled statically (without shared
  libs), and org instruction is used to provide the jump above 1 meg.

  22..33..  iinncclluuddee//eemmuu..hh IInnffoorrmmaattiioonn

  22..33..11..  FFuunnccttiioonnss iinn iinncclluuddee//eemmuu..hh

  These are the functions defined in include/emu.h.

  22..33..11..11..  NNEEWWSSEETTQQSSIIGG

  Arguments are:

  +o  sig - the signal to have a handler installed to.

  +o  fun - the signal handler function to install

     All signals that wish to be handled properly in context with the
     execution of vm86() mode, and signals that wish to use non-
     reentrant functions should add themselves to the SIGNALS_THAT_QUEUE
     define and use SETQSIG(). To that end they will also need to be set
     up in an order such as SIGIO.

  22..33..22..  RReemmaarrkkss iinn iinncclluuddee//eemmuu..hh

  The `vm86_struct` is used to pass all the necessary status/registers
  to DOSEMU when running in vm86 mode.

  -----

  We assume system call restarting... under linux 0.99pl8 and earlier,
  this was the default.  SA_RESTART was defined in 0.99pl8 to explicitly
  request restarting (and thus does nothing).  However, if this ever
  changes, I want to be safe

  -----

  DOSEMU keeps system wide configuration status in a structure called
  config.

  -----

  The var `fatalerr` can be given a true value at any time to have
  DOSEMU exit on the next return from vm86 mode.

  33..  TThhee DDPPMMII ggrroouupp ooff MMoodduulleess

  DPMI is Lutz's Baby. It's a really important part of the Emulator as
  far as we are concerned, since it will allow us to run so many more
  programs and, most importantly, bcc. This is the one thing that the
  WINE developers want that we haven't been able to give them.
  If you think you can help .... "Away you Go!" (Sorry to those non-UK
  folks ...  Thats a reference to a UK kids sports programme from my
  youth ... anyway ...  enough of this banter. You'll be wanting to know
  that this is all about DPMI ...)

  33..11..  ddoosseexxtt//ddppmmii//ddppmmii..cc IInnffoorrmmaattiioonn

  33..11..11..  FFuunnccttiioonnss iinn ddoosseexxtt//ddppmmii//ddppmmii..cc

  These are the functions defined in dosext/dpmi/dpmi.c.

  33..11..11..11..  ddppmmii__ccoonnttrrooll

  This function is similar to the vm86() syscall in the kernel and
  switches to dpmi code.

  33..11..11..22..  rruunn__ppmm__iinntt

  This routine is used for running protected mode hardware interrupts
  and software interrupts 0x1c, 0x23 and 0x24.  run_pm_int() switches to
  the locked protected mode stack and calls the handler. If no handler
  is installed the real mode interrupt routine is called.

  33..11..11..33..  ddoo__ddeeffaauulltt__ccppuu__eexxcceeppttiioonn

  This is the default CPU exception handler.  Exceptions 0, 1, 2, 3, 4,
  5 and 7 are reflected to real mode. All other exceptions are
  terminating the client (and may be dosemu too :-)).

  33..11..11..44..  ddoo__ccppuu__eexxcceeppttiioonn

  This routine switches to the locked protected mode stack, disables
  interrupts and calls the DPMI client exception handler.  If no handler
  is installed the default handler is called.

  33..11..11..55..  ddppmmii__ffaauulltt

  This is the brain of DPMI. All CPU exceptions are first reflected
  (from the signal handlers) to this code.  Exception from nonprivileged
  instructions INT XX, STI, CLI, HLT and from WINDOWS 3.1 are handled
  here.  All here unhandled exceptions are reflected to
  do_cpu_exception()

  33..11..22..  RReemmaarrkkss iinn ddoosseexxtt//ddppmmii//ddppmmii..cc

  We are caching ldt here for speed reasons and for Windows 3.1.  I
  would love to have an readonly ldt-alias (located in the first 16MByte
  for use with 16-Bit descriptors (WIN-LDT)). This is on my wish list
  for the kernel hackers (Linus mainly) :-))))))).

  -----

  DPMI is designed such that the stack change needs a task switch.  We
  are doing it via an SIGSEGV - instead of one task switch we have now
  four :-(.  Arrgh this is the point where I should start to include
  DPMI stuff in the kernel, but then we could include the rest of dosemu
  too.  Would Linus love this? I don't :-((((.  Anyway I would love to
  see first a working DPMI port, maybe we will later (with version 0.9
  or similar :-)) start with it to get a really fast dos
  emulator...............

  NOTE: Using DIRECT_DPMI_CONTEXT_SWITCH we avoid these 4  taskswitches
  actually doing 0. We don't need a 'physical' taskswitch (not having
  different TSS for us and DPMI), we only need a complete register
  (context) replacement. For back-switching, however, we need the
  sigcontext technique, so we build a proper sigcontext structure even
  for 'hand made taskswitch'. (Hans Lermen, June 1996)

  -----

  Hopefully the below LAR can serve as a replacement for the KERNEL_LDT,
  which we are abandoning now. Especially the 'accessed-bit' will get
  updated in the ldt-cache with the code below.  Most DPMI-clients
  fortunately _are_ using LAR also to get this info, however, some do
  not. Some of those which do _not_, atleast use the DPMI-GetDescriptor
  function, so this may solve the problem.  (Hans Lermen, July 1996)

  -----

  Handling of the virtual interrupt flag is still not correct and there
  are many open questions since DPMI specifications are unclear in this
  point.  An example: If IF=1 in protected mode and real mode code is
  called which is disabling interrupts via cli and returning to
  protected mode, is IF then still one or zero?  I guess I have to think
  a lot about this and to write a small dpmi client running under a
  commercial dpmi server :-).

  -----

  Here we handle all prefixes prior switching to the appropriate
  routines The exception CS:EIP will point to the first prefix that
  effects the the faulting instruction, hence, 0x65 0x66 is same as 0x66
  0x65.  So we collect all prefixes and remember them.  - Hans Lermen

  33..11..33..  IItteemmss ffoorr FFiixxiinngg iinn ddoosseexxtt//ddppmmii//ddppmmii..cc

  Should we really care for the Memory info?

  -----

  We shouldn't return to dosemu code if IF=0, but it helps - WHY?

  -----

  we should not change registers for hardware interrupts

  33..11..44..  NNeeww IIddeeaass ffoorr ddoosseexxtt//ddppmmii//ddppmmii..cc

  Simulate Local Descriptor Table for MS-Windows 3.1 must be read only,
  so if krnl386.exe/krnl286.exe try to write to this table, we will bomb
  into sigsegv() and and emulate direct ldt access

  44..  TThhee VViiddeeoo ggrroouupp ooff MMoodduulleess

  All of the Video handling code is in the "video" subdirectory.

  There is one file for each video card or chipset and the master file.
  To Add a new card, it needs a set of save & restore routines putting
  in a file here.

  44..11..  eennvv//vviiddeeoo//vvcc..cc IInnffoorrmmaattiioonn

  44..22..  eennvv//vviiddeeoo//vviiddeeoo..cc IInnffoorrmmaattiioonn

  44..22..11..  FFuunnccttiioonnss iinn eennvv//vviiddeeoo//vviiddeeoo..cc

  These are the functions defined in env/video/video.c.

  44..22..11..11..  vviiddeeoo__iinniitt

  Set pointer to correct structure of functions to initialize, close,
  etc... video routines.

  44..22..22..  RReemmaarrkkss iinn eennvv//vviiddeeoo//vviiddeeoo..cc

  Here the sleeping lion will be awoken and eat much of CPU time !!!

  The result of setting VM86_SCREEN_BITMAP (at state of Linux 1.1.56):
  Each vm86 call will set 32 pages of video mem RD-only (there may be
  1000000 per second) Write access to RD-only page results in page-fault
  (mm/memory.c), which will set a bit in current->screen_bitmap and
  calls do_wp_page() which does __get_free_page(GFP_KERNEL) but frees it
  immediatly, because copy-on-write is not neccessary and sets RD/WR for
  the page.  (this could happen 32000000 per second, if the CPU were
  fast enough) It would be better to get the DIRTY-bit directly from the
  page table, isn't it?  A special syscall in emumodule could do this.

  -----

  reserve_video_memory()

  This procedure is trying to eke out all the UMB blocks possible to
  maximize your memory under DOSEMU.  If you know about dual monitor
  setups, you can contribute by putting in the correct graphics page
  address values.

  44..33..  eennvv//vviiddeeoo//XX..cc IInnffoorrmmaattiioonn

  44..33..11..  FFuunnccttiioonnss iinn eennvv//vviiddeeoo//XX..cc

  These are the functions defined in env/video/X.c.

  44..33..11..11..  ggeett__vvggaa225566__ccoolloorrss

  Allocates a colormap for 256 color modes and initializes it.

  44..33..11..22..  XX__cclloossee

  Destroys the window, unloads font, pixmap and colormap.

  44..33..11..33..  XX__sseettmmooddee

  Resizes the window, also the graphical sizes/video modes.  remember
  the dos videomodi

  44..33..11..44..  XX__cchhaannggee__mmoouussee__ccuurrssoorr

  This function seems to be called each screen_update :( It is called in
  base/mouse/mouse.c:mouse_cursor(int) a lot for show and hide.

  44..33..11..55..  XX__rreeddrraaww__ssccrreeeenn

  Redraws the entire screen, also in graphics mode Used for expose
  events etc.  returns: nothing

  Arguments are:

  +o  none

  44..33..11..66..  XX__uuppddaattee__ssccrreeeenn

  Updates, also in graphics mode Graphics in X has to be smarter and
  improved returns: 0 - nothing updated 2 - partly updated 1 - whole
  update

  Arguments are:

  +o  none

  44..33..11..77..  sseett__mmoouussee__ppoossiittiioonn

  places the mouse on the right position Not tested in X with graphics
  returns: nothing

  Arguments are:

  +o  x,y - coordinates

  44..44..  eennvv//vviiddeeoo//ccoonnssoollee..cc IInnffoorrmmaattiioonn

  44..55..  eennvv//vviiddeeoo//dduuaallmmoonn..cc IInnffoorrmmaattiioonn

  44..55..11..  FFuunnccttiioonnss iinn eennvv//vviiddeeoo//dduuaallmmoonn..cc

  These are the functions defined in env/video/dualmon.c.

  44..55..11..11..  MMDDAA__iinniitt

  Initializes the monochrome card. First detects which monochrome card
  is used, because the Hercules RamFont and the Hercules InColor need
  one more register to be initialized. If there is no monochrome card at
  all, we just think there is one and poke an peek in the void.  After
  the detection the card is initialized.  returns: nothing

  Arguments are:

  +o  none

  44..55..22..  RReemmaarrkkss iinn eennvv//vviiddeeoo//dduuaallmmoonn..cc

  After MDA_init() the VGA is configured, something in video.c or
  console.c "reprograms" the monochrome card again in such a way that I
  always have to run hgc.com before I can use any program that uses the
  monochrome card. I've spent a day trying to find it, but I can't
  figure out. Something is writing to one of the following ports: 0x3b4,
  0x3b5, 0x3b8, 0x3b9, 0x3ba, 0x3bb, 0x3bf.  The problem occurs at (at
  least) the following 2 systems:

  - AMD 386DX40, Trident 9000/512Kb ISA, Hercules Graphics Card Plus -
  Intel 486DX2/66, Cirrus Logic 5426/1Mb VLB, Hercules clone

  The problem doesn't occur when I start dosemu from a telnet connection
  or from a VT100 terminal. (Erik Mouw, jakmouw@et.tudelft.nl)

  44..66..  eennvv//vviiddeeoo//eett44000000..cc IInnffoorrmmaattiioonn

  44..77..  eennvv//vviiddeeoo//hhggcc..cc IInnffoorrmmaattiioonn

  44..88..  bbaassee//bbiiooss//iinntt1100..cc IInnffoorrmmaattiioonn

  44..99..  eennvv//vviiddeeoo//ss33..cc IInnffoorrmmaattiioonn

  44..1100..  eennvv//vviiddeeoo//tteerrmmiinnaall..cc IInnffoorrmmaattiioonn

  44..1111..  eennvv//vviiddeeoo//ttrriiddeenntt..cc IInnffoorrmmaattiioonn

  44..1122..  eennvv//vviiddeeoo//vvggaa..cc IInnffoorrmmaattiioonn

  55..  TThhee KKeeyybbooaarrdd ggrroouupp ooff MMoodduulleess

  All of the Keyboard handling code is in the "keyboard" subdirectory.

  Latest addition is SLANG.

  55..11..  bbaassee//kkeeyybbooaarrdd//XXkkeeyybb..cc IInnffoorrmmaattiioonn

  55..22..  bbaassee//kkeeyybbooaarrdd//kkeeyymmaappss..cc IInnffoorrmmaattiioonn

  55..22..11..  RReemmaarrkkss iinn bbaassee//kkeeyybbooaarrdd//kkeeyymmaappss..cc

  The DEAD codes must refer to keys that don't exist on any language
  keyboard. I hope nobody has a smily face key :-) dead_key_table is a
  list of the dead keys supported. They must be placed on the correct
  key in the keymaps above. See key_map_es_latin1.

  -----

  dos850_dead_map consists of the triple, {deadkey, letter, result}.  It
  should be correct for all the code page 850 users (Western Europe).
  If you uses a different code page, please create a map!  Jon Tombs
  jon@gtex02.us.es

  55..33..  bbaassee//kkeeyybbooaarrdd//ssllaanngg--tteerrmmiioo..cc IInnffoorrmmaattiioonn

  66..  TThhee MMiisscc ggrroouupp ooff MMoodduulleess

  These are the remaining important files, that do not really fit into
  another group. These should not be dismissed as unimportant - rather,
  they are often amongst the most important.

  66..11..  ddoosseexxtt//mmiisscc//eemmmm..cc IInnffoorrmmaattiioonn

  66..22..  ddoosseexxtt//mmiisscc//xxmmss..cc IInnffoorrmmaattiioonn

  66..33..  aarrcchh//lliinnuuxx//aassyynncc//ssiiggsseeggvv..cc IInnffoorrmmaattiioonn

  66..33..11..  FFuunnccttiioonnss iinn aarrcchh//lliinnuuxx//aassyynncc//ssiiggsseeggvv..cc

  These are the functions defined in arch/linux/async/sigsegv.c.

  66..33..11..11..  ddoosseemmuu__ffaauulltt

  All CPU exceptions (except 13=general_protection from V86 mode, which
  is directly scanned by the kernel) are handled here.

  66..33..11..22..  pprriinntt__eexxcceeppttiioonn__iinnffoo

  Prints information about an exception: exception number, error code,
  address, reason, etc.

  66..44..  iinncclluuddee//iinntt..hh IInnffoorrmmaattiioonn

  66..55..  iinncclluuddee//ppoorrttss..hh IInnffoorrmmaattiioonn

  66..66..  bbaassee//mmiisscc//ddoossiioo..cc IInnffoorrmmaattiioonn

  66..77..  bbaassee//mmiisscc//ddiisskkss..cc IInnffoorrmmaattiioonn

  66..77..11..  FFuunnccttiioonnss iinn bbaassee//mmiisscc//ddiisskkss..cc

  These are the functions defined in base/misc/disks.c.

  66..77..11..11..  ddiisskk__iinniitt

  Test by opening all floppies/hardrives configured.

  66..88..  eemmii--ii338866//ccppuu..cc IInnffoorrmmaattiioonn

  66..99..  ddeevv//mmiisscc//llpptt..cc IInnffoorrmmaattiioonn

  77..  TThhee SSeerriiaall ggrroouupp ooff MMoodduulleess

  This is the code that works our serial emulation. This needs to be
  very fast if we are to convince DOS that we have a very fast serial
  port.

  77..11..  bbaassee//sseerriiaall//sseerr__ddeeffss..hh IInnffoorrmmaattiioonn

  77..11..11..  RReemmaarrkkss iinn bbaassee//sseerriiaall//sseerr__ddeeffss..hh

  Extensions to serial debugging.

  SER_DEBUG_MAIN   (0 or 1) - extra debug output on the most critical
  information.

  SER_DEBUG_HEAVY   (0 or 1) - super-heavy extra debug output, including
  all ports reads and writes, and every character received and
  transmitted!

  SER_DEBUG_INTERRUPT   (0 or 1) - additional debug output related to
  serial interrupt code, including flagging serial interrupts, or PIC-
  driven code.

  SER_DEBUG_FOSSIL_RW   (0 or 1) - heavy FOSSIL debug output, including
  all reads and writes.

  SER_DEBUG_FOSSIL_STATUS   (0 or 1) - super-heavy FOSSIL debug output,
  including all status checks.

  You must recompile dosemu everytime one of these constants are
  modified.  Just type 'make' in the dosemu dir and it will recompile
  the changes only.

  -----

  IMPORTANT INFO about com[] variable array structure used in serial.c

  Most of the serial variables are stored in the com[] array.  The com[]
  array is a structure in itself.   Take a look at the about this.  Only
  the most commonly referenced global variables are listed here:
  config.num_ser         Number of serial ports active.
  com[x].base_port       The base port address of emulated serial port.
  com[x].real_comport    The COM port number.  com[x].interrupt
  The PIC interrupt level (based on IRQ number) com[x].mouse
  Flag  mouse (to enable extended features) com[x].fd              File
  descriptor for port device com[x].dev[]           Filename of port
  port device com[x].dev_locked      Flag whether device has been locked

  The arbritary example variable 'x' in com[x] can have a minimum value
  of 0 and a maximum value of (config.numser - 1).  There can be no gaps
  for the value 'x', even though gaps between actual COM ports are
  permitted.  It is strongly noted that the 'x' does not equal the COM
  port number.  This example code illustrates the fact, and how the
  com[] array works:

  for (i = 0; i < config.numser; i++) s_printf("COM port number %d has a
  base address of %x", com[i].real_comport, com[i].base_port);

  77..22..  bbaassee//sseerriiaall//sseerr__iinniitt..cc IInnffoorrmmaattiioonn

  77..22..11..  MMaaiinnttaaiinneerrss

  Mark Rejhon  <marky@ottawa.com>

  77..22..22..  FFuunnccttiioonnss iinn bbaassee//sseerriiaall//sseerr__iinniitt..cc

  These are the functions defined in base/serial/ser_init.c.

  77..22..22..11..  sseerriiaall__iinniitt

  This is the master serial initialization function that is called upon
  startup of DOSEMU to initialize ALL the emulated UARTs for all
  configured serial ports.  The UART is initialized via the
  initialize_uart function, which opens the serial ports and defines
  variables for the specific UART.  If the port is a mouse, the port is
  only initialized when i

  77..22..33..  IItteemmss ffoorr FFiixxiinngg iinn bbaassee//sseerriiaall//sseerr__iinniitt..cc

  This needs more work before it is implemented into /etc/dosemu.conf as
  an 'rtscts' option.

  77..33..  bbaassee//sseerriiaall//sseerr__ppoorrttss..cc IInnffoorrmmaattiioonn

  77..33..11..  FFuunnccttiioonnss iinn bbaassee//sseerriiaall//sseerr__ppoorrttss..cc

  These are the functions defined in base/serial/ser_ports.c.

  77..33..11..11..  ddoo__sseerriiaall__iinn

  The following function returns a value from an I/O port.  The port is
  an I/O address such as 0x3F8 (the base port address of COM1).  There
  are 8 I/O addresses for each serial port which ranges from the base
  port (ie 0x3F8) to the base port plus seven (ie 0x3FF).  [num =
  abritary port number for serial line, address = I/O port address]

  77..33..11..22..  ddoo__sseerriiaall__oouutt

  The following function writes a value to an I/O port.  The port is an
  I/O address such as 0x3F8 (the base port address of COM1).  [num =
  abritary port number for serial line, address = I/O port address, val
  = value to write to I/O port address]

  77..33..22..  IItteemmss ffoorr FFiixxiinngg iinn bbaassee//sseerriiaall//sseerr__ppoorrttss..cc

  Should clearing UART cause THRE int if it's enabled?

  -----

  Fix the calculation assumption

  -----

  Is this safe to put this here?

  -----

  Is this safe to put this here?

  77..44..  bbaassee//sseerriiaall//sseerr__iirrqq..cc IInnffoorrmmaattiioonn

  77..44..11..  FFuunnccttiioonnss iinn bbaassee//sseerriiaall//sseerr__iirrqq..cc

  These are the functions defined in base/serial/ser_irq.c.

  77..44..11..11..  sseerriiaall__iinntt__eennggiinnee

  This function is the serial interrupts scheduler.  Its purpose is to
  update interrupt status and/or invoke a requested serial interrupt.
  If interrupts are not enabled, the Interrupt Identification Register
  is still updated and the function returns.  See pic_serial_run() below
  it is executed right at the instant the interrupt is actually invoked.
  Since it is not possible to run the interrupt on the spot, it triggers
  the interrupt via the pic_request() function (which is in pic.c) and
  sets a flag that an interrupt is going to be occur soon.  Please read
  pic_serial_run() for more information about interrupts.  [num = port,
  int_requested = the requested serial interrupt]

  77..44..11..22..  ppiicc__sseerriiaall__rruunn

  This function is called by the priority iunterrupt controller when a
  serial interrupt occurs.  It executes the highest priority serial
  interrupt for that port. (Priority order is: RLSI, RDI, THRI, MSI)
  Because it is theoretically possible for things to change between the
  interrupt trigger and the actual interrupt, some checks must be
  repeated.

  77..44..11..33..  sseerriiaall__rruunn

  This is the main housekeeping function, which should be called about
  20 to 100 times per second.  The more frequent, the better, up to a
  certain point.   However, it should be self-compensating if it
  executes 10 times or even 1000 times per second.   Serial performance
  increases with frequency of execution of serial_run.  Serial mouse
  performance becomes more smooth if the time between calls to
  serial_run are smaller.

  77..44..22..  RReemmaarrkkss iinn bbaassee//sseerriiaall//sseerr__iirrqq..cc

  Linux code hackers: How do I detect a break signal without having to
  rely on Linux signals?  Can I peek a 'break state bit'?  Also, how do
  I 'turn on' and 'turn off' the break state, via an ioctl() or
  tcsetattr(), rather than using POSIX tcsendbrk()?

  77..44..33..  IItteemmss ffoorr FFiixxiinngg iinn bbaassee//sseerriiaall//sseerr__iirrqq..cc

  how do we cancel a PIC interrupt, when we have come this far?

  -----

  Perhaps this can be modified to limit max chain length?

  88..  TThhee MMoouussee ggrroouupp ooff MMoodduulleess

  All of the Mouse handling code is in the "mouse" subdirectory.

  There are only 2 main files, mouse.c and mouseint.c.

  88..11..  bbaassee//mmoouussee//mmoouussee..cc IInnffoorrmmaattiioonn

  88..11..11..  FFuunnccttiioonnss iinn bbaassee//mmoouussee//mmoouussee..cc

  These are the functions defined in base/mouse/mouse.c.

  88..11..11..11..  mmoouussee__iinniitt

  Initialize internal mouse.

  99..  TThhee BBiiooss ggrroouupp ooff MMoodduulleess

  All of the Bios code is in the "bios" subdirectory.

  DOSEMU requires certain code to be coded in assembler and also code to
  be located in the F000 segment. This is where all such code should be
  put.

  99..11..  bbaassee//bbiiooss//bbiiooss..SS IInnffoorrmmaattiioonn

  1100..  TThhee PPIICC ggrroouupp ooff MMoodduulleess

  All of the PIC handling code is in the "PIC" subdirectory.

  1100..11..  ddeevv//ppiicc//ppiicc..cc IInnffoorrmmaattiioonn

  1100..22..  ddeevvppiicc//ppiicc..hh IInnffoorrmmaattiioonn

  1111..  TThhee SSoouunndd ggrroouupp ooff MMoodduulleess

  The sound code provides emulation of the SB. The actual emulation
  provided depends upon the support available from the kernel sound
  driver. Because this is very OS dependant the driver code itself is
  kept in architecture specifc files under
  src/arch/osname/dosext/sound/. Communication is via a set of interface
  functions and the device independant structures.

  1111..11..  ddoosseexxtt//ssoouunndd//ssoouunndd..cc IInnffoorrmmaattiioonn

  1111..11..11..  MMaaiinnttaaiinneerrss

  Alistair MacDonald  <alistair@slitesys.demon.co.uk>
  David Brauman  <crisk@netvision.net.il>
  Rutger Nijlunsing  <rutger@null.net>

  1111..11..22..  FFuunnccttiioonnss iinn ddoosseexxtt//ssoouunndd//ssoouunndd..cc

  These are the functions defined in dosext/sound/sound.c.

  1111..11..22..11..  ssbb__iioo__rreeaadd

  Arguments are:

  +o  port - The I/O port being read from.

     This handles all of the reads for the SB emulation. The value read
     is returned. The value of 0xFF indicates an invalid read. (assumes
     the ports float high when not pulled low by the hardware.)

  1111..11..22..22..  aaddlliibb__iioo__rreeaadd

  Arguments are:

  +o  port - The I/O port being read from.

     This handles all of the reads for the adlib (FM) emulation. The
     value read is returned. The value of 0xFF indicates an invalid
     read. (assumes the ports float high when not pulled low by the
     hardware.)  The FM emulation is not written yet. The current plan
     is to use the midi emulation where available as this is the most
     common use for the FM sound.

  1111..11..22..33..  mmppuu440011__iioo__rreeaadd

  Arguments are:

  +o  port - The I/O port being read from.

     The MPU-401 functionality is primarily provided by 'midid' - a
     standalone program. This makes most of the MPU-401 code simply a
     pass-through driver.

  1111..11..22..44..  ssbb__iioo__wwrriittee

  Arguments are:

  +o  port - The I/O port being written to.

  +o  value - The value being output.

     This handles the writes for the SB emulation. Very little of the
     processing is performed in this function as it basically consists
     of a very large switch() statement. The processing here is limited
     to trivial (1 line) items and distinguishing between the different
     actions and responses that the different revisions of the SB series
     give.

  1111..11..22..55..  ssbb__ddsspp__wwrriittee

  Arguments are:

  +o  value - The value being written to the DSP.

     The SB DSP is a complete I/O system in itself controlled via a
     number of data bytes. The number of bytes depends upon the
     function. The function to be executed is determined by the first
     byte.  If there is no existing command then the command is stored.
     This then used in the switch to identify the action to be taken.
     When the command has supplied all of its arguments, or failed, then
     the command storage is cleared. Each DSP function is responsible
     for clearing this itself.  Again, this function relies on other
     functions to do the real work, and apart from storing details of
     the command and parameters is basically a large switch statement.

  1111..11..33..  RReemmaarrkkss iinn ddoosseexxtt//ssoouunndd//ssoouunndd..cc

  Write silence could probably be implemented by setting up a "DMA"
  transfer from /dev/null - AM

  1111..11..44..  IItteemmss ffoorr FFiixxiinngg iinn ddoosseexxtt//ssoouunndd//ssoouunndd..cc

  The file header needs tidying up a _LOT_ !

  -----

  Adlib status reads are unimplemented

  -----

  Advanced adlib reads are unimplemented

  -----

  CMS Writes are unimplemented.

  -----

  DSP Status is unimplemented

  -----

  Write Silence is not implemented.

  -----

  Adlib register writes are unimplemented

  -----

  Adlib data writes are unimplemented

  -----

  Advanced Adlib register writes are unimplemented

  -----

  Advanced Adlib data writes are unimplemented

  -----

  SB Midi is Unimplemented

  -----

  Sine Generation is unimplemented

  -----

  AUX Status is Unimplemented

  -----

  Stero Input is no implemented

  -----

  ADC is Unimplemented

  -----

  Stopping Auto-Init DMA is not implemented

  1122..  AAnndd FFiinnaallllyy ......

  The Following items are used to delimit the text used to create this
  file.  Whilst it is not necessary to know this, they are included
  because they may be useful for searching, as they are (at least at the
  moment) reasonably unique.

  DANG_BEGIN_MODULE / DANG_END_MODULE This will bracket a description of
  the file (normally at the start).

  DANG_BEGIN_FUNCTION / DANG_END_FUNCTION This brackets a description of
  functions (good this, isn't it!)  Not every function needs to be
  described in this way - just the major ones.

  DANG_BEGIN_REMARK / DANG_END_REMARK This brackets descriptions of
  obscure items, like data structures and architecture.

  DANG_FIXTHIS This is a one line item, indicating a an area requiring a
  fix, or redesign.

  DANG_BEGIN_NEWIDEA / DANG_END_NEWIDEA New Ideas Start Here! As Ideas
  are proposed, that get added with their description, so that future
  generations can laugh at or code the ideas ..... These bracket the
  idea description.

  DANG_BEGIN_CHANGELOG / DANG_END_CHANGELOG Changelogs - very useful for
  bug fixing, and avvailable for use with DPR (or that's the theory)

