Provided by: bochs_2.7+dfsg-4build1_amd64 bug

NAME

       bochsrc - Configuration file for Bochs.

DESCRIPTION

       Bochsrc   is  the   configuration   file  that specifies where  Bochs should look for disk
       images,  how the Bochs emulation layer   should   work,   etc.    The   syntax   used  for
       bochsrc   can also be used as command line  arguments for Bochs. The .bochsrc  file should
       be placed either in the  current   directory   before  running   Bochs  or  in  your  home
       directory.

       Starting  with  Bochs  1.3,  you  can  use  environment variables in the bochsrc file, for
       example:

         floppya: 1_44="$IMAGES/bootdisk.img", status=inserted

       Starting with version 2.0, two environment variables have a built-in default  value  which
       is  set  at  compile  time.   $BXSHARE  points to the "share" directory which is typically
       /usr/local/share/bochs on UNIX machines.  See the $(sharedir) variable in the Makefile for
       the  exact  value.  $BXSHARE is used by disk images to locate the directory where the BIOS
       images and keymaps can be found.  If $BXSHARE  is  not  defined,  Bochs  will  supply  the
       default  value.   Also,  $LTDL_LIBRARY_PATH  points to a list of directories (separated by
       colons if more than one) to search in  for  Bochs  plugins.   A  compile-time  default  is
       provided if this variable is not defined by the user.

OPTIONS

       #include
              This option includes another configuration file. It is possible to put installation
              defaults in a global config file (e.g. location of rom images).

              Example:
                #include /etc/bochsrc

       plugin_ctrl:
              Controls the presence of optional device plugins. These plugins are loaded directly
              with  this  option  and some of them install a config option that is only available
              when the plugin device is loaded. The value "1" means to load the  plugin  and  "0"
              will unload it (if loaded before).

              These  plugins  will  be  loaded  by  default (if present): 'biosdev', 'extfpuirq',
              'gameport', 'iodebug','parallel', 'serial', 'speaker' and 'unmapped'.

              These plugins are also supported, but they are usually loaded directly  with  their
              bochsrc option: 'e1000', 'es1370', 'ne2k', 'pcidev', 'pcipnic', 'sb16', 'usb_ehci',
              'usb_ohci', 'usb_uhci', 'usb_xhci' and 'voodoo'.

              Example:
                plugin_ctrl: unmapped=0, e1000=1 # unload 'unmapped' and load 'e1000'

       config_interface:
              The configuration interface is a series of menus or dialog boxes that allows you to
              change  all  the settings that control Bochs's behavior.  Depending on the platform
              there are up to 3 choices of configuration interface: a text  mode  version  called
              "textconfig"  and  two  graphical versions called "win32config" and "wx".  The text
              mode version uses stdin/stdout or gui console (if available / runtime  config)  and
              is  always  compiled  in,  unless  Bochs  is  compiled  for  wx  only.  The  choice
              "win32config" is only available on win32/win64 and  it  is  the  default  on  these
              platforms.  The choice "wx" is only available when Bochs is compiled with wxWidgets
              support. If you do not write a config_interface line, Bochs will choose  a  default
              for you.

              NOTE:  if  you  use  the  "wx"  configuration interface, you must also use the "wx"
              display library.

              Example:
                config_interface: textconfig

       display_library:
              The display library is the code that displays the Bochs VGA screen.   Bochs  has  a
              selection  of  about  10  different  display  library implementations for different
              platforms.   If  you  run   configure   with   multiple   --with-*   options,   the
              display_library  command lets you choose which one you want to run with.  If you do
              not write a display_library line, Bochs will choose a default for you.

              The choices are:
                x           X windows interface, cross platform
                win32       native win32 libraries
                carbon      Carbon library (for MacOS X)
                macintosh   MacOS pre-10
                amigaos     native AmigaOS libraries
                sdl         SDL 1.2.x library, cross platform
                sdl2        SDL 2.x library, cross platform
                term        text only, uses curses/ncurses library, cross platform
                rfb         provides an interface to AT&T's VNC viewer, cross platform
                vncsrv      use LibVNCServer for extended RFB(VNC) support
                wx          wxWidgets library, cross platform
                nogui       no display at all

              NOTE: If you use the "wx" configuration interface,  you  must  also  use  the  "wx"
              display library.

              Specific  options:  Some  display libraries now support specific options to control
              their behaviour. These options are supported by more than one display library:

                "cmdmode"     - call a headerbar button handler after pressing F7 (x, sdl, sdl2)
                "fullscreen"  - startup in fullscreen mode (sdl, sdl2)
                "gui_debug"   - use GTK debugger gui (sdl, sdl2, x)
                "hideIPS"     - disable IPS output in status bar (rfb, sdl, sdl2,  term,  vncsrv,
              wx, x)
                "nokeyrepeat" - turn off host keyboard repeat (sdl, sdl2, x)
                "no_gui_console"  -  use system console instead of builtin gui console (rfb, sdl,
              sdl2, vncsrv, x)
                "timeout"     - time (in seconds) to wait for client (rfb, vncsrv)

              NOTE: Setting up options without specifying display library is also supported.

              Examples:
                display_library: x
                display_library: sdl2, options=fullscreen,hideIPS
                display_library: options=cmdmode

       cpu:   This defines cpu-related parameters inside Bochs:

              model:

              Selects CPU configuration  to  emulate  from  pre-defined  list  of  all  supported
              configurations.  When  this  option  is  used  and  the  value  is  different  from
              'bx_generic', the parameters of the CPUID option have no effect  anymore.  See  the
              bochsrc sample for supported values.

              count:

              Set  the  number  of  processors:cores per processor:threads per core when Bochs is
              compiled for SMP emulation. Bochs currently supports up to 14 threads (legacy APIC)
              or  254  threads  (xAPIC  or  higher)  running simultaniosly.  If Bochs is compiled
              without SMP support, it won't accept values different from 1.

              quantum:

              Maximum amount of instructions allowed to execute  by  processor  before  returning
              control  to  another cpu. This option exists only in Bochs binary compiled with SMP
              support.

              reset_on_triple_fault:

              Reset the CPU when triple fault  occur  (highly  recommended)  rather  than  PANIC.
              Remember  that  if you trying to continue after triple fault the simulation will be
              completely bogus !

              cpuid_limit_winnt:

              Determine whether to limit maximum CPUID function to 2. This mode  is  required  to
              workaround WinNT installation and boot issues.

              mwait_is_nop:

              When  this  option  is enabled MWAIT will not put the CPU into a sleep state.  This
              option exists only if Bochs compiled with --enable-monitor-mwait.

              msrs:

              Define path to user CPU Model Specific Registers (MSRs) specification.  See example
              in msrs.def.

              ignore_bad_msrs:

              Ignore  MSR  references  that  Bochs  does  not understand; print a warning message
              instead of generating #GP exception. This option is enabled by default but will not
              be available if configurable MSRs are enabled.

              ips:

              Emulated  Instructions Per Second.  This is the number of IPS that Bochs is capable
              of running on your machine.  You can recompile Bochs with --enable-show-ips  option
              enabled,  to  find  your workstation's capability.  Measured IPS value will then be
              logged into your log file or status bar (if supported by the gui).

              IPS is used  to  calibrate   many   time-dependent  events    within    the   bochs
              simulation.   For  example,  changing IPS affects the frequency of VGA updates, the
              duration of time before a key  starts  to  autorepeat,   and  the  measurement   of
              BogoMips and other benchmarks.

              Example Specifications[1]

              Bochs   Machine/Compiler                           Mips
              ──────────────────────────────────────────────────────────────
              2.4.6   3.4Ghz Core i7 2600 w/ Win7x64/g++ 4.5.2   85-95 Mips
              2.3.7   3.2Ghz Core 2 Q9770 w/ WinXP/g++ 3.4       50-55 Mips
              2.3.7   2.6Ghz Core 2 Duo w/ WinXP/g++ 3.4         38-43 Mips
              2.2.6   2.6Ghz Core 2 Duo w/ WinXP/g++ 3.4         21-25 Mips
              2.2.6   2.1Ghz Athlon XP w/ Linux 2.6/g++ 3.4      12-15 Mips

               [1]   IPS  measurements  depend  on OS and compiler configuration  in addition  to
              processor clock speed.

              Example:
                cpu: count=2, ips=10000000, msrs="msrs.def"

       cpuid: This defines features and functionality supported by Bochs emulated CPU:

              level:

              Set emulated CPU level information returned by CPUID. Default value  is  determined
              by  configure  option  --enable-cpu-level.  Currently  supported  values are 5 (for
              Pentium and similar processors) and 6 (for P6 and later processors).

              family:

              Set family information returned  by  CPUID.  Default  family  value  determined  by
              configure option --enable-cpu-level.

              model:

              Set model information returned by CPUID. Default model value is 3.

              stepping:

              Set stepping information returned by CPUID. Default stepping value is 3.

              vendor_string:

              Set  the  CPUID  vendor  string  returned  by CPUID(0x0).  This should be a twelve-
              character ASCII string.

              brand_string:

              Set the CPUID vendor string returned  by  CPUID(0x80000002  ..  0x80000004).   This
              should be at most a forty-eight-character ASCII string.

              mmx:

              Select MMX instruction set support.  This option exists only if Bochs compiled with
              BX_CPU_LEVEL >= 5.

              apic:

              Select APIC configuration (LEGACY/XAPIC/XAPIC_EXT/X2APIC).  This option exists only
              if Bochs compiled with BX_CPU_LEVEL >= 5.

              sep:

              Select  SYSENTER/SYSEXIT instruction set support.  This option exists only if Bochs
              compiled with BX_CPU_LEVEL >= 6.

              simd:

              Select         SIMD         instructions         support.           Any          of
              NONE/SSE/SSE2/SSE3/SSSE3/SSE4_1/SSE4_2/AVX/AVX2/AVX512 could be selected.

              This  option exists only if Bochs compiled with BX_CPU_LEVEL >= 6.  The AVX choises
              exists only if Bochs compiled with --enable-avx option.

              sse4a:

              Select AMD SSE4A instructions support.  This option exists only if  Bochs  compiled
              with BX_CPU_LEVEL >= 6.

              misaligned_sse:

              Select  AMD Misaligned SSE mode support.  This option exists only if Bochs compiled
              with BX_CPU_LEVEL >= 6.

              aes:

              Select AES instruction set support.  This option exists only if Bochs compiled with
              BX_CPU_LEVEL >= 6.

              sha:

              Select SHA instruction set support.  This option exists only if Bochs compiled with
              BX_CPU_LEVEL >= 6.

              movbe:

              Select MOVBE Intel(R) Atom instruction support.  This option exists only  if  Bochs
              compiled with BX_CPU_LEVEL >= 6.

              adx:

              Select  ADCX/ADOX  instructions support.  This option exists only if Bochs compiled
              with BX_CPU_LEVEL >= 6.

              xsave:

              Select XSAVE extensions support.  This option exists only if  Bochs  compiled  with
              BX_CPU_LEVEL >= 6.

              xsaveopt:

              Select  XSAVEOPT  instruction  support.   This option exists only if Bochs compiled
              with BX_CPU_LEVEL >= 6.

              avx_f16c:

              Select AVX float16 convert instructions support.  This option exists only if  Bochs
              compiled with --enable-avx option.

              avx_fma:

              Select  AVX fused multiply add (FMA) instructions support.  This option exists only
              if Bochs compiled with --enable-avx option.

              bmi:

              Select BMI1/BMI2 instructions support.  This option exists only if  Bochs  compiled
              with --enable-avx option.

              fma4:

              Select AMD four operand FMA instructions support.  This option exists only if Bochs
              compiled with --enable-avx option.

              xop:

              Select AMD XOP instructions support.  This option exists  only  if  Bochs  compiled
              with --enable-avx option.

              tbm:

              Select  AMD  TBM  instructions  support.  This option exists only if Bochs compiled
              with --enable-avx option.

              x86_64:

              Enable x85-64 and long mode support.  This option exists  only  if  Bochs  compiled
              with x86-64 support.

              1g_pages:

              Enable  1G  page  size  support  in  long  mode.   This option exists only if Bochs
              compiled with x86-64 support.

              pcid:

              Enable Process-Context Identifiers (PCID) support in long mode.  This option exists
              only if Bochs compiled with x86-64 support.

              smep:

              Enable  Supervisor  Mode  Execution  Protection (SMEP) support.  This option exists
              only if Bochs compiled with BX_CPU_LEVEL >= 6.

              smap:

              Enable Supervisor Mode Access Prevention (SMAP) support.  This option  exists  only
              if Bochs compiled with BX_CPU_LEVEL >= 6.

              mwait:

              Select  MONITOR/MWAIT  instructions  support.   This  option  exists  only if Bochs
              compiled with --enable-monitor-mwait.

              vmx:

              Select VMX extensions emulation support.  This option exists only if Bochs compiled
              with --enable-vmx option.

              svm:

              Select  AMD SVM (Secure Virtual Machine) extensions emulation support.  This option
              exists only if Bochs compiled with --enable-svm option.

              Example:
                cpuid: mmx=1, sep=1, sse=sse4_2, xapic=1, aes=1, movbe=1, xsave=1

       memory:
              Set the amount of physical memory you want to emulate.

              guest:

              Set amount of guest physical memory to emulate. The default is  32MB,  the  maximum
              amount limited only by physical address space limitations.

              host:

              Set  amount  of  host  memory  you want to allocate for guest RAM emulation.  It is
              possible to allocate less memory than you want to emulate  in  guest  system.  This
              will  fake  guest  to  see  the  non-existing memory. Once guest system touches new
              memory block it will be dynamically taken from the memory pool. You will be  warned
              (by  FATAL  PANIC)  in  case guest already used all allocated host memory and wants
              more.

              Example:
                memory: guest=512, host=256

       megs:  The 'megs:' option sets the 'guest' and 'host' memory parameters to the same value.
              In all other cases the 'memory' option should be used instead.

              Example:
                megs: 32

       romimage:
              The  ROM BIOS controls what the PC does when it first powers on.  Normally, you can
              use a precompiled BIOS in the source  or  binary  distribution  called  BIOS-bochs-
              latest.  The default ROM BIOS is usually loaded starting at address 0xfffe0000, and
              it is exactly 128k long. The legacy version of the Bochs  BIOS  is  usually  loaded
              starting  at  address  0xffff0000,  and  it  is  exactly 64k long.  You can use the
              environment variable $BXSHARE to specify the location of the BIOS.   The  usage  of
              external  large  BIOS  images  (up  to 512k) at memory top is now supported, but we
              still recommend to use the BIOS distributed  with  Bochs.   The  start  address  is
              optional,  since  it  can  be calculated from image size.  The Bochs BIOS currently
              supports only the option "fastboot" to skip the boot menu delay.

              Examples:
                romimage: file=bios/BIOS-bochs-latest, options=fastboot
                romimage: file=$BXSHARE/BIOS-bochs-legacy
                romimage: file=mybios.bin, address=0xfff80000

       vgaromimage:
              You also need to load a VGA ROM BIOS into 0xC0000.

              Examples:
                vgaromimage: file=bios/VGABIOS-elpin-2.40
                vgaromimage: file=bios/VGABIOS-lgpl-latest
                vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest

       optromimage1: , optromimage2: , optromimage3: or optromimage4:
              You may now load up to 4 optional ROM images. Be sure  to  use  a  read-only  area,
              typically  between  C8000 and EFFFF. These optional ROM images should not overwrite
              the rombios (located at F0000-FFFFF) and the videobios  (located  at  C0000-C7FFF).
              Those  ROM  images  will  be  initialized  by  the  bios  if they contain the right
              signature (0x55AA).  It can also be a  convenient  way  to  upload  some  arbitrary
              code/data in the simulation, that can be retrieved by the boot loader

              Example:
                optromimage1: file=optionalrom.bin, address=0xd0000

       vga:   This defines parameters related to the VGA display.

              extension:

              Here  you  can  specify the display extension to be used. With the value 'none' you
              can use standard VGA with no extension. Other supported values are 'vbe' for  Bochs
              VBE, 'cirrus' for Cirrus SVGA support and 'voodoo' for Voodoo Graphics support (see
              'voodoo' option).

              update_freq:

              This parameter specifies the number of display updates per second.  The VGA  update
              timer  by default uses the realtime engine with a value of 5. This parameter can be
              changed at runtime.

              realtime:

              If set to 1 (default), the VGA timer is based on realtime, otherwise it  is  driven
              by  the  cpu  and  depends  on  the  ips  setting.  If  the  host is slow (low ips,
              update_freq) and the guest uses HLT appropriately, setting this to  0  and  "clock:
              sync=none"  may  improve  the  responsiveness  of  the  guest GUI when the guest is
              otherwise idle.

              ddc:

              This parameter defines the behaviour of the DDC emulation that returns the  monitor
              EDID  data.  By  default  the  'builtin'  values for 'Bochs Screen' are used. Other
              choices are 'disabled' (no DDC emulation) and 'file' (read monitor EDID from file /
              path name separated with a colon).

              Examples:
                vga: extension=none, update_freq=10, realtime=0, ddc=disabled
                vga: extension=cirrus, update_freq=30, ddc=file:monitor.bin
                vga: extension=vbe

       voodoo:
              This  defines  the  Voodoo  Graphics  emulation (experimental). Currently supported
              models are 'voodoo1', 'voodoo2', 'banshee' and 'voodoo3'.  The Voodoo2  support  is
              not  yet  complete,  but  almost  usable.  The  Banshee  / Voodoo3 support is under
              construction, but basically usable. The 2D/3D cards require an  external  VGA  BIOS
              the  vga  extension  option  to  be  set to 'voodoo'.  If the i440BX PCI chipset is
              selected, they can be assigned to AGP (slot #5).  The gui screen update timing  for
              all models is controlled by the related 'vga' options.

              Example:
                voodoo: enabled=1, model=voodoo1

       keyboard:
              This defines parameters related to the emulated keyboard:

              type:

              Type  of  keyboard  return  by  a  "identify  keyboard"  command  to  the  keyboard
              controller. It must be one of "xt", "at" or "mf".  Defaults to "mf". It  should  be
              ok for almost everybody. A known exception is french macs, that do have a "at"-like
              keyboard.

              serial_delay:

              Approximate time in microseconds that it takes one character to be transferred from
              the keyboard to controller over the serial path.

              paste_delay:

              Approximate  time  in  microseconds  between  attempts  to  paste characters to the
              keyboard controller. This leaves time for the guest os to deal  with  the  flow  of
              characters.   The  ideal  setting  depends  on  how your operating system processes
              characters.  The default of 100000 usec (.1 seconds) was chosen  because  it  works
              consistently in Windows.

              If  your  OS is losing characters during a paste, increase the paste delay until it
              stops losing characters.

              keymap:

              This enables a remap of a physical localized keyboard to a virtualized us keyboard,
              as the PC architecture expects.

              user_shortcut:

              This  defines  the keyboard shortcut to be sent when you press the "user" button in
              the header bar. The shortcut string is a combination of maximum 3 key names (listed
              below) separated with a '-' character.

              Valid key names:

              "alt",  "bksl",  "bksp",  "ctrl",  "del",  "down", "end", "enter", "esc", "f1", ...
              "f12", "home", "ins", "left", "menu", "minus", "pgdwn",  "pgup",  "plus",  "power",
              "print", "right", "scrlck", "shift", "space", "tab", "up" and "win".

              Examples:
                keyboard: type=mf, serial_delay=200, paste_delay=100000
                keyboard: keymap=gui/keymaps/x11-pc-de.map
                keyboard: user_shortcut=ctrl-alt-del

       mouse: This  defines  parameters  for  the  emulated mouse type, the initial status of the
              mouse capture and the runtime method to toggle it.

              type

              With the mouse type option you can select  the  type  of  mouse  to  emulate.   The
              default  value  is  'ps2'.  The  other  choices  are 'imps2' (wheel mouse on PS/2),
              'serial',  'serial_wheel',   'serial_msys'   (one   com   port   requires   setting
              'mode=mouse')  'inport'  and  'bus' (if present). To connect a mouse to a USB port,
              see the 'usb_uhci', 'usb_ohci', 'usb_ehci' or 'usb_xhci' option (requires  PCI  and
              USB support).

              enabled

              The  Bochs  gui creates mouse "events" unless the 'enabled' option is set to 0. The
              hardware emulation itself is not disabled by this.  Unless you  have  a  particular
              reason  for enabling the mouse by default, it is recommended that you leave it off.
              You can also toggle the mouse usage at runtime (RFB, SDL, Win32, wxWidgets and  X11
              - see below).

              toggle

              The  default method to toggle the mouse capture at runtime is to press the CTRL key
              and the middle mouse button ('ctrl+mbutton'). This  option  allows  to  change  the
              method to 'ctrl+f10' (like DOSBox), 'ctrl+alt' (like QEMU) or 'f12'.

              Examples:
                mouse: enabled=1
                mouse: type=imps2, enabled=1
                mouse: type=serial, enabled=1
                mouse: enabled=0, toggle=ctrl+f10

       pci:   This defines the parameters to set up the Bochs PCI emulation:

              enabled

              If Bochs is compiled with PCI support, it is enabled by default.

              chipset

              Currently  the  chipsets  i430FX, i440FX and i440BX (limited) are supported and the
              default is i440FX.

              slotX

              It is possible to specify the devices connected to PCI slots. Up  to  5  slots  are
              available.  For  combined PCI/ISA devices assigning to slot is mandatory if the PCI
              model should be emulated (cirrus, ne2k and pcivga). Setting up  slot  for  PCI-only
              devices  is  also  supported,  but  they are auto-assigned if not specified (e1000,
              es1370, pcidev, pcipnic, usb_ehci, usb_ohci, usb_xhci, voodoo). All  device  models
              except  the  network  devices  ne2k  and  e1000  can  be used only once in the slot
              configuration. In case of the  i440BX  chipset,  the  slot  #5  is  the  AGP  slot.
              Currently only the 'voodoo' device can be assigned to AGP.

              advopts

              With  the  advanced  PCI options it is possible to control the behaviour of the PCI
              chipset. These options can be specified as comma-separated values.  By default  the
              "Bochs  i440FX"  chipset  enables  the  ACPI  and HPET devices, but original i440FX
              doesn't support them. The options 'noacpi' and 'nohpet' make it possible to disable
              them.  The  option  'noagp'  disables  the  incomplete  AGP subsystem of the i440BX
              chipset.

              Example:
                pci: enabled=1, chipset=i440fx, slot1=pcivga, slot2=ne2k, advopts=noacpi

       clock: This defines the parameters of the clock inside Bochs.

              sync

              This defines the method how to synchronize the Bochs internal time  with  realtime.
              With  the  value  'none'  the  Bochs  time relies on the IPS value and no host time
              synchronization is used. The 'slowdown' method sacrifices performance  to  preserve
              reproducibility  while  allowing  host  time  correlation.  The  'realtime'  method
              sacrifices reproducibility to preserve performance and host-time  correlation.   It
              is possible to enable both synchronization methods.

              rtc_sync

              If  this option is enabled together with the realtime synchronization, the RTC runs
              at realtime speed. This feature is disabled by default.

              time0

              Specifies the start (boot) time of  the  virtual  machine.  Use  a  time  value  as
              returned  by the time(2) system call or a string as returned by the ctime(3) system
              call. If no time0 value is set or if time0 equal to 1 (special case)  or  if  time0
              equal  'local',  the  simulation will be started at the current local host time. If
              time0 equal to 2 (special case) or if time0 equal 'utc',  the  simulation  will  be
              started at the current utc time.

              Syntax:
                clock: sync=[none|slowdown|realtime|both], time0=[timeValue|local|utc]

              Default value are sync=none, rtc_sync=0, time0=local

              Example:
                clock: sync=realtime, time0=938581955   # Wed Sep 29 07:12:35 1999
                clock: sync=realtime, time0="Sat Jan  1 00:00:00 2000" # 946681200

       cmosimage:
              This  defines  a  binary image file with size 128 bytes that can be loaded into the
              CMOS RAM at startup. The rtc_init parameter controls  whether  initialize  the  RTC
              with  values  stored in the image. By default the time0 argument given to the clock
              option is used. With 'rtc_init=image' the image is the source for the initial time.

              Example:
                cmosimage: file=cmos.img, rtc_init=time0

       private_colormap:
              Requests that the GUI create and use it's  own non-shared colormap.  This  colormap
              will   be used when in the bochs window. If not enabled, a shared  colormap  scheme
              may be used.  Once again, enabled=1  turns on this feature  and 0 turns it off.

              Example:
                private_colormap: enabled=1

       floppya: or floppyb:

              Point  this to  the pathname of a floppy image file or   device.   Floppya  is  the
              first  drive, and  floppyb is the  second drive.  If  you're booting from a floppy,
              floppya should point to a bootable disk.

              You can set the initial status of the media to 'ejected' or 'inserted'. Usually you
              will want to use 'inserted'.

              The  parameter  'type'  can  be  used  to enable the floppy drive without media and
              status specified. Usually the drive type is set up based on the media type.

              The optional parameter 'write_protected' can be used to  control  the  media  write
              protect switch. By default it is turned off.

              Example:

              2.88M 3.5" media:
                floppya: 2_88=path, status=ejected

              1.44M 3.5" media (write protected):
                floppya: 1_44=path, status=inserted, write_protected=1

              1.2M  5.25" media:
                floppyb: 1_2=path, status=ejected

              720K  3.5" media:
                floppya: 720k=path, status=inserted

              360K  5.25" media:
                floppya: 360k=path, status=inserted

              Autodetect floppy media type:
                floppya: image=path, status=inserted

              Use directory as 1.44M VFAT media:
                floppya: 1_44=vvfat:path, status=inserted

              1.44M 3.5" floppy drive, no media:
                floppya: type=1_44

       ata0: , ata1: , ata2: or ata3:

              These  options  enables  up  to  4  ata  channels. For each channel the two base io
              addresses and the irq must be specified.  ata0 and ata1  are  enabled  by  default,
              with the values shown below.

              Examples:
                 ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14
                 ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15
                 ata2: enabled=1, ioaddr1=0x1e8, ioaddr2=0x3e0, irq=11
                 ata3: enabled=1, ioaddr1=0x168, ioaddr2=0x360, irq=9

       ata[0-3]-master: or ata[0-3]-slave:

              This defines the type and characteristics of all attached ata devices:
                 type=       type of attached device [disk|cdrom]
                 path=       path of the image
                 mode=                                    image                              mode
              [flat|concat|sparse|vmware3|vmware4|undoable|growing|volatile|vpc|vbox|vvfat], only
              valid for disks
                 cylinders=  only valid for disks
                 heads=      only valid for disks
                 spt=        only valid for disks
                 status=     only valid for cdroms [inserted|ejected]
                 biosdetect= type of biosdetection [auto|cmos|none]
                 translation=type    of    translation    of    the    bios,   only   for   disks
              [none|lba|large|rechs|auto]
                 model=      string returned by identify device command
                 journal=    optional filename of the redolog for undoable,  volatile  and  vvfat
              disks

              Point  this  at a hard disk image file, cdrom iso file, or a physical cdrom device.
              To create a hard disk image, try running bximage.  It will help you choose the size
              and then suggest a line that works with it.

              In  UNIX  it  is  possible  to  use a raw device as a Bochs hard disk, but WE DON'T
              RECOMMEND IT.

              The path is mandatory for hard disks. Disk geometry autodetection works with images
              created by bximage if CHS is set to 0/0/0 (cylinders are calculated using  heads=16
              and spt=63). For other hard disk images and modes the cylinders, heads, and spt are
              mandatory.  In  all  cases  the  disk  size reported from the image must be exactly
              C*H*S*512.

              The mode option defines how the disk image is handled. Disks can be defined as:
                - flat : one file flat layout
                - concat : multiple files layout
                - sparse : stackable, commitable, rollbackable
                - vmware3 : vmware3 disk support
                - vmware4 : vmware4 disk support (aka VMDK)
                - undoable : flat file with commitable redolog
                - growing : growing file
                - volatile : flat file with volatile redolog
                - vpc : fixed / dynamic size VirtualPC image
                - vbox : fixed / dynamic size Oracle(tm) VM VirtualBox image (VDI version 1.1)
                - vvfat: local directory appears as read-only VFAT disk (with volatile redolog)

              The disk translation scheme (implemented in legacy int13 bios functions,  and  used
              by older operating systems like MS-DOS), can be defined as:
                - none : no translation, for disks up to 528MB (1032192 sectors)
                - large : a standard bitshift algorithm, for disks up to 4.2GB (8257536 sectors)
                -  rechs : a revised bitshift algorithm, using a 15 heads fake physical geometry,
              for disks up to 7.9GB (15482880 sectors). (don't use  this  unless  you  understand
              what you're doing)
                -  lba  :  a  standard  lba-assisted  algorithm,  for disks up to 8.4GB (16450560
              sectors)
                - auto : autoselection of best translation  scheme.  (it  should  be  changed  if
              system does not boot)

              Default values are:
                 mode=flat, biosdetect=auto, translation=auto, model="Generic 1234"

              The biosdetect option has currently no effect on the bios

              Examples:
                 ata0-master: type=disk, path=10M.sample, cylinders=306, heads=4, spt=17
                 ata0-slave:  type=disk, path=20M.sample, cylinders=615, heads=4, spt=17
                 ata1-master: type=disk, path=30M.sample, cylinders=615, heads=6, spt=17
                 ata1-slave:  type=disk, path=46M.sample, cylinders=940, heads=6, spt=17
                 ata2-master: type=disk, path=62M.sample, cylinders=940, heads=8, spt=17
                 ata2-slave:  type=disk, path=112M.sample, cylinders=900, heads=15, spt=17
                 ata3-master: type=disk, path=483M.sample, cylinders=1024, heads=15, spt=63
                 ata3-slave:  type=cdrom, path=iso.sample, status=inserted

       boot:  This  defines the boot sequence. Now you can specify up to 3 boot drives, which can
              be 'floppy', 'disk', 'cdrom' or 'network' (boot ROM).  Legacy 'a' and 'c' are  also
              supported.

              Example:
                boot: cdrom, floppy, disk

       floppy_bootsig_check:
              This  disables  the 0xaa55 signature check on boot floppies The check is enabled by
              default.

              Example:
                floppy_bootsig_check: disabled=1

       log:   Give the path of the log file you'd like Bochs  debug  and  misc.  verbiage  to  be
              written to.   If you really don't want it, make it /dev/null.

              Example:
                log: bochs.out
                log: /dev/tty               (unix only)
                log: /dev/null              (unix only)

       logprefix:
              This  handles  the  format  of  the string prepended to each log line : You may use
              those special tokens :
                %t : 11 decimal digits timer tick
                %i : 8 hexadecimal digits of cpu0 current eip
                %e : 1 character event type ('i'nfo, 'd'ebug, 'p'anic, 'e'rror)
                %d : 5 characters string of the device, between brackets

              Default : %t%e%d

              Examples:
                logprefix: %t-%e-@%i-%d
                logprefix: %i%e%d

       panic: If Bochs  reaches  a condition  where  it  cannot  emulate  correctly,  it  does  a
              panic.  This  can be a configuration problem (like a misspelled bochsrc line) or an
              emulation problem  (like an  unsupported video  mode).  The   "panic"  setting   in
              bochsrc  tells  Bochs  how  to respond to a panic.   You  can  set  this  to  fatal
              (terminate   the  session),  ask  (ask  user  how  to  proceed)  or  report  (print
              information to the log file).

              The  safest setting is action=fatal or action=ask. If you are  getting  panics, you
              can try action=report instead.  If you allow  Bochs  to  continue  after  a  panic,
              don't   be  surprised   if  you  get strange behavior or crashes if a panic occurs.
              Please report panic messages unless it is just a configuration  problem like "could
              not find hard drive image."

              Examples:
                panic: action=fatal
                panic: action=ask

       error: Bochs   produces   an   error   message  when  it  finds  a condition  that  really
              shouldn't  happen,  but doesn't endanger the  simulation.  An example of  an  error
              might be  if the  emulated  software  produces an illegal disk command.

              The  "error"   setting  tells  Bochs  how to respond to an error condition. You can
              set  this  to fatal  (terminate the  session), ask (ask user how to proceed),  warn
              (show  dialog   with  message   and  continue),  report  (print information  to the
              log file),  or ignore  (do nothing).

              Example:
                error: action=report
                error: action=warn

       info:  This  setting  tells Bochs  what  to  do  when  an event  occurs    that  generates
              informational  messages.  You can set this  to report (print information to the log
              file), or  ignore (do nothing). For general usage, the "report" option is  probably
              a good choice.

              Example:
                info: action=report

       debug: This   setting   tells   Bochs   what   to  do  with messages intended to assist in
              debugging.  You can set  this  to report (print  information to  the log file),  or
              ignore  (do  nothing).  You  should generally set this  to  ignore, unless  you are
              trying to diagnose a particular problem.

              NOTE: When  action=report,   Bochs   may  spit  out thousands of debug messages per
              second, which can impact performance and fill up your disk.

              Example:
                debug: action=ignore

       debugger_log:
              Give  the  path  of  the  log file you'd like Bochs to log debugger output.  If you
              really don't want it, make it '/dev/null', or '-'.

              Example:
                log: debugger.out
                log: /dev/null              (unix only)
                log: -

       com1: , com2: , com3: or com4:
              This defines a serial port (UART type 16550A). In the 'term' mode you can specify a
              device  to  use  as  com1.  This can be a real serial line, or a pty.  To use a pty
              (under X/Unix), create two windows (xterms, usually).  One of them will run  bochs,
              and  the  other  will act as com1. Find out the tty the com1 window using the `tty'
              command, and use that as the `dev' parameter.  Then do `sleep 1000000' in the  com1
              window  to  keep  the  shell  from  messing with things, and run bochs in the other
              window.  Serial I/O to com1 (port 0x3f8) will all go to the other window.

              In socket* and pipe* (win32 only) modes  Bochs  becomes  either  socket/named  pipe
              client  or  server.  In  client  mode  it connects to an already running server (if
              connection fails Bochs treats com port as not connected). In server mode  it  opens
              socket/named  pipe  and  waits  until  a  client  application connects to it before
              starting simulation. This mode is useful for remote  debugging  (e.g.   with  gdb's
              "target   remote   host:port"   command   or   windbg's   command  line  option  -k
              com:pipe,port=\.ipeipename).
              Socket modes use simple TCP communication, pipe modes use duplex byte mode pipes.

              Other serial modes are 'null' (no input/output), 'file' (output to a file specified
              as the 'dev' parameter and changeable at runtime), 'raw' (use the real serial  port
              -  partly implemented on win32) and 'mouse' (standard serial mouse - requires mouse
              option setting 'type=serial', 'type=serial_wheel' or 'type=serial_msys')

              Examples:
                com1: enabled=1, mode=term, dev=/dev/ttyp7
                com2: enabled=1, mode=file, dev=serial.out
                com1: enabled=1, mode=mouse

       parport1: or parport2:
              This defines a parallel (printer) port. When  turned  on  and  an  output  file  is
              defined the emulated printer port sends characters printed by the guest OS into the
              output file. On some platforms a device filename can be used to send  the  data  to
              the  real  parallel port (e.g. "/dev/lp0" on Linux). The output file can be changed
              at runtime.

              Examples:
                parport1: enabled=1, file=parport.out
                parport2: enabled=1, file="/dev/lp0"
                parport1: enabled=0

       sound: This defines the lowlevel sound driver(s) for the wave (PCM) input / output and the
              MIDI output feature and (if necessary) the devices to be used.  It can have several
              of  the  following  properties.   All  properties  are   in   the   format   sound:
              property=value

              waveoutdrv:
                This defines the driver to be used for the waveout feature.
                Possible values are 'file' (all wave data sent to file), 'dummy' (no
                output) and the platform-dependant drivers 'alsa', 'oss', 'osx', 'sdl'
                and 'win'.

              waveout:
                This defines the device to be used for wave output (if necessary) or
                the output file for the 'file' driver.

              waveindrv:
                This defines the driver to be used for the wavein feature.
                Possible values are 'dummy' (recording silence) and platform-dependent
                drivers 'alsa', 'oss', 'sdl' and 'win'.

              wavein:
                This defines the device to be used for wave input (if necessary).

              midioutdrv:
                This defines the driver to be used for the MIDI output feature.
                Possible values are 'file' (all MIDI data sent to file), 'dummy' (no
                output) and platform-dependent drivers 'alsa', 'oss', 'osx' and 'win'.

              midiout:
                This defines the device to be used for MIDI output (if necessary).

              driver:
                This defines the driver to be used for all sound features with one
                property. Possible values are 'default' (platform default) and all
                other choices described above. Overriding one or more settings with
                the specific driver parameter is possible.

              Example for one driver (uses platform-default):
                sound: driver=default, waveout=/dev/dsp Example for different drivers:
                sound: waveoutdrv=sdl, waveindrv=alsa, midioutdrv=dummy

       speaker:
              This  defines the PC speaker output mode. In the 'sound' mode the beep is generated
              by the square wave generator which is a part of the lowlevel sound support. In this
              mode  the  'volume'  parameter  can  be used to set the output volume (0 - 15). The
              'system' mode is only available on Linux and Windows. On Linux /dev/console is used
              for  output and on Windows the Beep() function. The 'gui' mode forwards the beep to
              the related gui methods (currently only used by the Carbon gui).

              Example:
                speaker: enabled=1, mode=sound, volume=15

       sb16:  This  defines the SB16 sound emulation. It  can  have  several  of  the   following
              properties. All properties are in this format:
                sb16: property=value

              PROPERTIES FOR sb16:

              enabled:

                This optional property controls the presence of the SB16 emulation.
                The emulation is turned on unless this property is used and set to 0.

              midimode:

                This parameter specifies what to do with the MIDI output.

                0 = no output
                1 = output to device specified with the sound option (system dependent)
                2 = MIDI or raw data output to file (depends on file name extension)
                3 = dual output (mode 1 and 2 at the same time)

              midifile:

                This is the file where the midi output is stored (midimode 2 or 3).

              wavemode:

                This parameter specifies what to do with the PCM output.

                0 = no output
                1 = output to device specified with the sound option (system dependent)
                2 = VOC, WAV or raw data output to file (depends on file name extension)
                3 = dual output (mode 1 and 2 at the same time)

              wavefile:

                This is the file where the wave output is stored (wavemode 2 or 3).

              log:

                The file to write the sb16 emulator messages to.

              loglevel:

                0 = No log.
                1 = Resource changes, midi program and bank changes.
                2 = Severe errors.
                3 = All errors.
                4 = All errors plus all port accesses.
                5 = All  errors and port  accesses plus a lot
                    of extra information.

                It is possible to change the loglevel at runtime.

              dmatimer:

              Microseconds  per  second  for  a DMA cycle.  Make it smaller to fix non-continuous
              sound.  750000 is  usually  a  good value.   This   needs   a  reasonably   correct
              setting   for  the  IPS  parameter of the CPU option.  It is possible to adjust the
              dmatimer at runtime.

              Examples for output modes:
                sb16: midimode=2, midifile="output.mid", wavemode=1 # MIDI to file
                sb16: midimode=1, wavemode=3, wavefile="output.wav" # wave to file and device

       es1370:
              This defines the ES1370 sound emulation (recording and playback - except  DAC1+DAC2
              output  at  the  same  time).  The parameter 'enabled' controls the presence of the
              device. The wave and MIDI output can be sent to device,  file  or  both  using  the
              parameters  'wavemode',  'wavefile', 'midimode' and 'midifile'. See the description
              of these parameters at the SB16 directive.

              Example for using 'sound' parameters:
                es1370: enabled=1, wavemode=1 Example for sending output to file:
                es1370: enabled=1, wavemode=2, wavefile=output.voc

       ne2k:  Defines the characteristics of an attached ne2000 isa card :
                 card=CARD,
                 type=TYPE,
                 ioaddr=IOADDR,
                 irq=IRQ,
                 mac=MACADDR,
                 ethmod=MODULE,
                 ethdev=DEVICE,
                 script=SCRIPT,
                 bootrom=BOOTROM

              PROPERTIES FOR ne2k:

              CARD: This is the zero-based card number to configure with this ne2k  config  line.
              Up  to  4  devices  are  supported  now  (0...3).  If  not specified, the following
              parameters apply to card #0.

              TYPE: This is the card type to emulate ('isa' or 'pci'). If not specified, card  #0
              defaults  to  'pci'  if  assigned  to a pci slot. For the additional cards the type
              parameter should be set up.

              IOADDR, IRQ: You probably won't need to change ioaddr and irq, unless there are IRQ
              conflicts.  These parameters are ignored if the NE2000 is assigned to a PCI slot.

              MAC:  The  MAC address MUST NOT match the address of any machine on the net.  Also,
              the first byte must be an even number (bit 0 set means a  multicast  address),  and
              you  cannot  use  ff:ff:ff:ff:ff:ff  because that's the broadcast address.  For the
              ethertap module, you must use fe:fd:00:00:00:01.  There may be  other  restrictions
              too.  To be safe, just use the b0:c4... address.

              ETHMOD:  The  ethmod value defines which low level OS specific module to be used to
              access physical ethernet interface. Current implemented values include
               - fbsd      : ethernet on freebsd and openbsd
               - linux     : ethernet on linux
               - win32     : ethernet on win32
               - tap       : ethernet through a linux tap interface
               - tuntap    : ethernet through a linux tuntap interface
               - slirp     : built-in Slirp support with DHCP / TFTP servers

              If you don't want to make connections to any physical networks,  you  can  use  the
              following 'ethmod's to simulate a virtual network.
               - null   : All packets are discarded, but logged to a few files
               - vde    : Virtual Distributed Ethernet
               - vnet   : ARP, ICMP-echo(ping), DHCP, DNS, FTP and TFTP are simulated
                          The virtual host uses 192.168.10.1
                          DHCP assigns 192.168.10.15 to the guest
                          The FTP and TFTP servers use 'ethdev' for the root directory
                          TFTP doesn't overwrite files, DNS for server and client only
               - socket : Connect up to 6 Bochs instances with external program 'bxhub'
                          (simulating an ethernet hub). It provides the same services as the
                          'vnet' module and assigns IP addresses like 'slirp' (10.0.2.x).

              ETHDEV:  The  ethdev  value  is  the  name  of  the  network interface on your host
              platform.  On UNIX machines, you can get the name by running ifconfig.  On  Windows
              machines,  you must run niclist to get the name of the ethdev.  Niclist source code
              is in misc/niclist.c and it is included in Windows binary releases.   The  'socket'
              module  uses  this  parameter  to  specify  the  UDP port for receiving packets and
              (optional) the host to connect.

              SCRIPT: The script value is optional, and is the name of a script that is  executed
              after  bochs initialize the network interface. You can use this script to configure
              this network interface, or enable masquerading.  This  is  mainly  useful  for  the
              tun/tap  devices that only exist during Bochs execution. The network interface name
              is supplied to the  script  as  first  parameter.  The  'slirp'  module  uses  this
              parameter  to  specify a config file for setting up an alternative IP configuration
              or additional features. The 'vnet' module also uses this  parameter  to  specify  a
              config file similar to slirp, but with only a few settings.

              BOOTROM:  The  bootrom value is optional, and is the name of the ROM image to load.
              Note that this feature is only implemented for the PCI version of the NE2000.

              Examples:
                ne2k: ioaddr=0x300, irq=9, mac=b0:c4:20:00:00:00, ethmod=fbsd, ethdev=xlo
                ne2k: ioaddr=0x300, irq=9, mac=b0:c4:20:00:00:00, ethmod=linux, ethdev=eth0
                ne2k: ioaddr=0x300, irq=9, mac=b0:c4:20:00:00:01, ethmod=win32, ethdev=MYCARD
                ne2k: ioaddr=0x300, irq=9, mac=fe:fd:00:00:00:01, ethmod=tap, ethdev=tap0
                ne2k:     ioaddr=0x300,     irq=9,     mac=fe:fd:00:00:00:01,      ethmod=tuntap,
              ethdev=/dev/net/tun0, script=./tunconfig
                ne2k:      ioaddr=0x300,      irq=9,      mac=b0:c4:20:00:00:01,      ethmod=vde,
              ethdev="/tmp/vde.ctl"
                ne2k: ioaddr=0x300, irq=9, mac=b0:c4:20:00:00:01, ethmod=vnet, ethdev="c:/temp"
                ne2k: mac=b0:c4:20:00:00:01, ethmod=socket, ethdev=40000 # use localhost
                ne2k: card=0, mac=b0:c4:20:00:00:01, ethmod=socket, ethdev=mymachine:40000
                ne2k:       mac=b0:c4:20:00:00:01,        ethmod=slirp,        script=slirp.conf,
              bootrom=ne2k_pci.rom

       pcipnic:
              To  support  the  Bochs/Etherboot  pseudo-NIC,  Bochs  must  be  compiled  with the
              --enable-pnic configure option. It  accepts  the  same  syntax  (for  mac,  ethmod,
              ethdev,  script,  bootrom)  and  supports the same networking modules as the NE2000
              adapter.

              Example:
                pnic: enabled=1, mac=b0:c4:20:00:00:00, ethmod=vnet

       e1000: To support the Intel(R) 82540EM Gigabit Ethernet adapter, Bochs  must  be  compiled
              with  the  --eanble-e1000  configure option. The E1000 accepts the same syntax (for
              card, mac, ethmod, ethdev,  script,  bootrom)  and  supports  the  same  networking
              modules as the NE2000 adapter.

              Example:
                e1000: card=0, enabled=1, mac=52:54:00:12:34:56, ethmod=slirp, script=slirp.conf

       usb_uhci:
              This option controls the presence of the USB root hub which is a part of the i440FX
              PCI chipset. With the portX parameter you can connect devices to the hub (currently
              supported:  'mouse',  'tablet',  'keypad',  'keyboard',  'disk', 'cdrom', 'floppy',
              'hub' and 'printer').

              If you connect the mouse or tablet to one of the ports, Bochs  forwards  the  mouse
              movement  data  to  the  USB  device  instead  of  the  selected  mouse type.  When
              connecting the keypad to one of the ports, Bochs forwards the input of the  numeric
              keypad to the USB device instead of the PS/2 keyboard. If the keyboard is selected,
              all key events are sent to the USB device.

              To connect a disk image as a USB hardisk you can use the  'disk'  device.  Use  the
              'path'  option in the optionsX parameter to specify the path to the image separated
              with a colon. To use other disk  image  modes  similar  to  ATA  disks  the  syntax
              'path:mode:filename' must be used (see below).

              To  emulate a USB cdrom you can use the 'cdrom' device and the path to an ISO image
              or raw device name can be set with the 'path' option in the optionsX parameter also
              separated with a colon. An option to insert/eject media is available in the runtime
              configuration.

              To emulate a USB floppy you can use the 'floppy' device and the path  to  a  floppy
              image  can be set with the 'path' option in the optionsX parameter separated with a
              colon. To use the VVFAT  image  mode  similar  to  the  legacy  floppy  the  syntax
              'path:vvfat:directory'  must  be used (see below).  An option to insert/eject media
              is available in the runtime configuration.

              The device name 'hub' connects an external hub with max. 8 ports  (default:  4)  to
              the  root hub. To specify the number of ports you have to use the 'ports' option in
              the optionsX parameter with the value separated with a colon.   Connecting  devices
              to the external hub ports is only available in the runtime configuration.

              The  device 'printer' emulates the HP Deskjet 920C printer. The PCL data is sent to
              a file specified in the 'file' option with the  optionsX  parameter.   The  current
              code appends the PCL code to the file if the file already existed.  The output file
              can be changed at runtime.

              The optionsX parameter can be  used  to  assign  specific  options  to  the  device
              connected  to the corresponding USB port. The option 'speed' can be used to set the
              speed reported by device ('low', 'full', 'high' or 'super').  The  available  speed
              choices  depend on both HC and device. The option 'debug' turns on debug output for
              the device at connection time. The option 'pcap' turns on packet  logging  in  PCAP
              format.  For the USB 'disk' device the optionsX parameter can be used to specify an
              alternative redolog file (journal) of some image modes. For 'vvfat' mode USB  disks
              the  optionsX parameter can be used to specify the disk size (range 128M ... 128G).
              If the size is not specified, it defaults to 504M.  For the USB 'floppy' device the
              optionsX  parameter can be used to specify an alternative device ID to be reported.
              Currently only the model "teac" is supported (can fix hw detection  in  some  guest
              OS).  The USB floppy also accepts the parameter "write_protected" with valid values
              0 and 1 to select the access mode (default is 0).

              Examples:
                usb_uhci: port1=mouse, port2=disk, options2="path:usbstick.img"
                usb_uhci: port1=hub, options1="ports:6"
                usb_uhci: port2=disk, options2="path:undoable:usbdisk.img, journal:u.redolog"
                usb_uhci: port2=disk, options2=""path:usbdisk2.img, sect_size:1024"
                usb_uhci: port2=disk, options2="path:vvfat:vvfat, debug, speed:full"
                usb_uhci: port2=cdrom, options2="path:image.iso"
                usb_uhci: port1=printer, options1="file:printdata.bin"
                usb_uhci: port2=floppy, options2="path:vvfat:diskette, model:teac"

       usb_ohci:
              This option controls the presence of the USB OHCI host  controller  with  a  2-port
              hub.  The portX parameter accepts the same device types with the same syntax as the
              UHCI controller (see above). The optionsX parameter is also available on OHCI.

              Example:
                usb_ohci: enabled=1

       usb_ehci:
              This option controls the presence of the USB EHCI host  controller  with  a  6-port
              hub.  The portX parameter accepts the same device types with the same syntax as the
              UHCI controller (see above). The optionsX parameter is also available on EHCI.

              Example:
                usb_ehci: enabled=1, port1=tablet, options1="speed:high"

       usb_xhci:
              This option controls the presence of the USB xHCI host  controller  with  a  4-port
              hub.  The portX parameter accepts the same device types with the same syntax as the
              UHCI controller (see above). The optionsX parameter  is  also  available  on  xHCI.
              NOTE:  port 1 and 2 are USB3 and only support super-speed devices, but port 3 and 4
              are USB2 and support speed settings low, full and high.

              Example:
                usb_xhci: enabled=1

       pcidev:
              Enables the mapping of a host PCI hardware device within the PCI subsystem  of  the
              Bochs x86 emulator. This feature requires Linux as a host OS.

              Example:
                pcidev: vendor=0x1234, device=0x5678

              The  vendor  and  device  arguments  should  contain the vendor ID respectively the
              device ID of the PCI device you want to map within Bochs.  The PCI mapping is still
              very experimental and not maintained yet.

LICENSE

       This program  is distributed  under the terms of the  GNU Lesser General Public License as
       published  by  the  Free Software  Foundation.  See the LICENSE and COPYING files  located
       in /usr/share/doc/bochs/ for details on the license and the lack of warranty.

AVAILABILITY

       The latest version of this program can be found at:
         http://bochs.sourceforge.net/getcurrent.html

SEE ALSO

       bochs(1), bochs-dlx(1), bximage(1)

       The Bochs IA-32 Emulator site on the World Wide Web:
               http://bochs.sourceforge.net

       Online Bochs Documentation
            http://bochs.sourceforge.net/doc/docbook

AUTHORS

       The    Bochs   emulator  was   created   by  Kevin   Lawton (kevin@mandrakesoft.com),  and
       is  currently  maintained by the  members of  the  Bochs x86 Emulator  Project.   You  can
       see a current roster of members at:
         http://bochs.sourceforge.net/getinvolved.html

BUGS

       Please    report   all   bugs  to  the  bug  tracker   on   our   web  site.  Just  go  to
       http://bochs.sourceforge.net, and click "Bug Reports" on the sidebar under "Feedback".

       Provide a detailed description of the bug, the version of the program you are running, the
       operating  system  you  are  running the program on  and  the  operating   system  you are
       running in the emulator.