Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
bochsrc(5)		       The Bochs Project		    bochsrc(5)

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 com-
       mand line  arguments for	Bochs. The .bochsrc  file should be placed ei-
       ther  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 ma-
       chines.	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. loca-
	      tion 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 un-
	      load 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 "textcon-
	      fig" and two graphical versions called "win32config"  and	 "wx".
	      The  text	 mode version uses stdin/stdout	and is always compiled
	      in, unless Bochs is compiled for wx only.	The choice  "win32con-
	      fig"  is	only  available	 on win32 and it is the	default	there.
	      The choice "wx" is only available	when you  use  "--with-wx"  on
	      the  configure  command.	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 li-
	      brary  implementations for different platforms.  If you run con-
	      figure with multiple --with-* options, the display_library  com-
	      mand  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:

		"gui_debug"   -	use GTK	debugger gui (sdl, sdl2, x)
		"hideIPS"     -	disable	IPS output in status  bar  (rfb,  sdl,
	      sdl2, vncsrv, wx,	x)
		"nokeyrepeat" -	turn off host keyboard repeat (sdl, sdl2, x)
		"timeout"      -  time	(in  seconds) to wait for client (rfb,
	      vncsrv)

	      See the examples below for other currently supported options.

	      Examples:
		display_library: x
		display_library:  sdl,	options="fullscreen"   #  startup   in
	      fullscreen mode
		display_library:  sdl2,	 options="fullscreen"	#  startup  in
	      fullscreen mode

       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 is-
	      sues.

	      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) specifi-
	      cation.  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 avaiable 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 re-
	      compile 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 Intel Core i7 2600 with Win7x64/g++	4.5.2 85 to 95
	      Mips
	       2.3.7 3.2Ghz Intel Core 2 Q9770 with WinXP/g++ 3.4     50 to 55
	      Mips
	       2.3.7 2.6Ghz Intel Core 2 Duo with WinXP/g++ 3.4	      38 to 43
	      Mips
	       2.2.6 2.6Ghz Intel Core 2 Duo with WinXP/g++ 3.4	      21 to 25
	      Mips
	       2.2.6 2.1Ghz Athlon XP with Linux 2.6/g++ 3.4	      12 to 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  emu-
	      lated CPU:

	      level:

	      Set  emulated  CPU  level	information returned by	CPUID. Default
	      value is determined by configure option --enable-cpu-level. Cur-
	      rently  supported	 values	are 5 (for Pentium and similar proces-
	      sors) 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 ex-
	      ists 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	 --en-
	      able-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 em-
	      ulation.	 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 im-
	      ages (up to 512k)	at memory top is now supported,	but  we	 still
	      recommend	to use the BIOS	distributed with Bochs.	 The start ad-
	      dress 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 op-
	      tional 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 and 'cirrus' for	Cirrus
	      SVGA support.

	      update_freq:

	      Specifies	the number of display updates per second.  This	param-
	      eter can be changed at runtime. The default value	is 5.

	      realtime:

	      If set to	1, the VGA timer is based on realtime, otherwise it is
	      based on the ips setting.	If the host  is	 slow  (low  ips,  up-
	      date_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. The default value is
	      1.

	      Examples:
		vga: extension=none, update_freq=10, realtime=0
		vga: extension=cirrus, update_freq=30
		vga: extension=vbe

       voodoo:
	      This defines the Voodoo Graphics emulation (experimental).  Cur-
	      rently supported models are 'voodoo1' and	'voodoo2'. The Voodoo2
	      support is not yet complete.

	      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".  De-
	      faults 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 char-
	      acters 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 vir-
	      tualized 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	combi-
	      nation 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', 'se-
	      rial_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 (re-
	      quires 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 DOS-
	      Box), '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  option  controls  the  presence of a PCI chipset in	Bochs.
	      Currently	it only	supports the i430FX and	i440FX	chipsets.  You
	      can  also	 specify  the  devices connected to PCI	slots. Up to 5
	      slots are	available. For these combined PCI/ISA devices  assign-
	      ing  to  slot is mandatory if you	want to	emulate	the PCI	model:
	      cirrus, ne2k and pcivga. These PCI-only devices  are  also  sup-
	      ported,  but  they  are  auto-assigned if	you don't use the slot
	      configuration:  e1000,  es1370,	pcidev,	  pcipnic,   usb_ohci,
	      usb_ehci and usb_xhci.

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

       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	repro-
	      ducibility  while	allowing host time correlation.	The 'realtime'
	      method sacrifices	reproducibility	to  preserve  performance  and
	      host-time	 correlation.	It is possible to enable both synchro-
	      nization methods.

	      rtc_sync

	      If this option is	enabled	together with  the  realtime  synchro-
	      nization,	 the  RTC runs at realtime speed. This feature is dis-
	      abled 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 con-
	      trols  whether  initialize the RTC with values stored in the im-
	      age. By default the time0	argument given to the clock option  is
	      used. With 'rtc_init=image' the image is the source for the ini-
	      tial time.

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

       private_colormap:
	      Requests that the	GUI create and use it's	 own  non-shared  col-
	      ormap.   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 'in-
	      serted'. 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|exter-
	      nal|dll|sparse|vmware3|vmware4|undoable|grow-
	      ing|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 phys-
	      ical cdrom device.  To create a hard disk	image, try running bx-
	      image.  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 autodetec-
	      tion 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
		- external : developer's specific, through a C++ class
		- dll :	developer's specific, through a	DLL
		- 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 sec-
	      tors)
		- 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  cor-
	      rectly,  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 pro-
	      ceed) 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 al-
	      low 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	condi-
	      tion  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  ses-
	      sion), 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 re-
	      port (print information to the log file),	or  ignore  (do	 noth-
	      ing).  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  in-
	      tended  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 try-
	      ing 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	 mess-
	      ing  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=se-
	      rial_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 charac-
	      ters printed by the guest	OS into	the output file. On some plat-
	      forms 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) in-
	      put / output and the MIDI	output feature and (if necessary)  the
	      devices  to be used.  It can have	several	of the following prop-
	      erties.  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	neces-
	      sary) 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	neces-
	      sary).

	      midioutdrv:
		This  defines  the  driver to be used for the MIDI output fea-
	      ture.
		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	neces-
	      sary).

	      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. The 'system' mode	is only	avail-
	      able on Linux and	Windows. On Linux  /dev/console	 is  used  for
	      output  and  on Windows the Beep() function. The 'gui' mode for-
	      wards the	beep to	the related gui	methods	(currently  only  used
	      by the Carbon gui).

	      Example:
		speaker: enabled=1, mode=sound

       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  emu-
	      lation.
		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 ex-
	      tension)
		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 'en-
	      abled' 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  de-
	      scription	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 :
		 ioaddr=IOADDR,
		 irq=IRQ,
		 mac=MACADDR,
		 ethmod=MODULE,
		 ethdev=DEVICE,
		 script=SCRIPT,
		 bootrom=BOOTROM

	      PROPERTIES FOR ne2k:

	      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... ad-
	      dress.

	      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 net-
	      work.
	       - null	: All packets are discarded, but logged	to a few files
	       - vde	: Virtual Distributed Ethernet
	       - vnet	: ARP, ICMP-echo(ping),	DHCP and TFTP are simulated
			  The virtual host uses	192.168.10.1
			  DHCP assigns 192.168.10.2 to the guest
			  The TFTP server use 'ethdev' for the root  directory
	      and doesn't
			  overwrite files
	       -  socket  : Connect up to 6 Bochs instances with external pro-
	      gram '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 in-
	      terface. You can use this	script to configure this  network  in-
	      terface,	or enable masquerading.	 This is mainly	useful for the
	      tun/tap devices that only	exist during Bochs execution. The net-
	      work  interface  name is supplied	to the script as first parame-
	      ter. The 'slirp' module uses this	parameter to specify a	config
	      file  for	 setting  up  an alternative IP	configuration or addi-
	      tional features. The 'vnet' module uses this parameter to	 spec-
	      ify an alternative log file name.

	      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,	  eth-
	      mod=linux, ethdev=eth0
		ne2k:	ioaddr=0x300,	irq=9,	 mac=b0:c4:20:00:00:01,	  eth-
	      mod=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=tun-
	      tap, 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:	mac=b0:c4:20:00:00:01,	 ethmod=socket,	  ethdev=myma-
	      chine: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 com-
	      piled with the --enable-pnic configure option.  It  accepts  the
	      same  syntax (for	mac, ethmod, ethdev, script, bootrom) and sup-
	      ports 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 mac, ethmod, ethdev,  script,
	      bootrom)	and supports the same networking modules as the	NE2000
	      adapter.

	      Example:
		e1000:	 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',  '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.

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

	      To emulate a USB cdrom you can use the 'cdrom' device  name  and
	      the  path	to an ISO image	or raw device name 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 with the
	      path to the image	separated with a colon.	To use the VVFAT image
	      mode  similar  to	the legacy floppy the syntax 'floppy:vvfat:di-
	      rectory' 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 add the value separated with a colon. Connecting devices
	      to the external hub ports	is only	available in the runtime  con-
	      figuration.

	      The  device  'printer' emulates the HP Deskjet 920C printer. The
	      PCL data is sent to a file specified in bochsrc.txt. The current
	      code  appends  the  PCL code to the file if the file already ex-
	      isted. 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. Currently
	      this feature is used to set the speed reported by	device ('low',
	      'full', 'high' or	'super'). The availabe speed choices depend on
	      both HC and device. The option 'debug' turns on debug output for
	      the  device  at  connection time.	 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. Cur-
	      rently 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: enabled=1, port1=mouse, port2=disk:usbstick.img
		usb_uhci:   enabled=1,	 port1=hub:7,  port2=disk:growing:usb-
	      disk.img
		usb_uhci:  enabled=1,	port2=disk:undoable:usbdisk.img,   op-
	      tions2=journal:redo.log
		usb_uhci:   enabled=1,	port2=disk:vvfat:vvfat,	 options2="de-
	      bug,speed:full"
		usb_uhci:	enabled=1,	  port1=printer:printdata.bin,
	      port2=cdrom:image.iso
		usb_uhci:    enabled=1,	   port2=floppy:vvfat:diskette,	   op-
	      tions2="model:teac"

       usb_ohci:
	      This option controls the presence	of  the	 USB  OHCI  host  con-
	      troller  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 con-
	      troller 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  con-
	      troller  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 re-
	      spectively  the  device  ID  of  the  PCI	device you want	to map
	      within Bochs.  The PCI mapping is	still  very  experimental  and
	      not maintained yet.

       user_plugin:
	      Load user-defined	plugin.	This option is available only if Bochs
	      is compiled with plugin support. Maximum 8 different plugins are
	      supported.   See the example in the Bochs	sources	how to write a
	      plugin device.

	      Example:
		user_plugin: name=testdev

LICENSE
       This program  is	distributed  under the terms of	the  GNU  Lesser  Gen-
       eral  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@man-
       drakesoft.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.

bochsrc				  28 Mar 2017			    bochsrc(5)

NAME | DESCRIPTION | OPTIONS | LICENSE | AVAILABILITY | SEE ALSO | AUTHORS | BUGS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=bochsrc&sektion=5&manpath=FreeBSD+12.2-RELEASE+and+Ports>

home | help