  The DOSEMU Alterer Novices Guide DANG
  Alistair MacDonald, aalliissttaaiirr@@sslliitteessyyss..ddeemmoonn..ccoo..uukk
  For DOSEMU v0.63.1

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

  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@>. 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

  Requires the sig/sillyint.o driver loaded (using NEW modules package),
  or a kernel patch (implementing sig/int.c driver).  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.

  -----

  At this time we have to use SIGALRM in addition to SIGIO I don't (yet)
  know why the SIGIO signal gets lost sometimes (once per minute or
  longer). But if it happens, we can retrigger this way over SIGALRM.
  Normally SIGIO happens before SIGALARM, so nothing hurts. (Hans)


  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 nonpriveleged
  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...............


  -----

  Handling of the virtuell interruptflag 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 :-).


  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

  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 scaned by the kernel) are handled here.






  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  <markg@magmacom.com>
  Mark Rejhon  <ag115@freenet.carleton.ca>

  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..  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)
























