bochsrc(1)

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.

OPTIONS

romimage:
    You need to load a ROM BIOS into F0000-FFFFF. The BIOS controls what the PC does when it first powers on. Normally, you can use a precompiled BIOS in the bios/ directory, named BIOS-bochs-latest. Example:
      romimage: file=bios/BIOS-bochs-970717

megs:
    Set this to the default number of Megabytes of memory you want to emulate. You may also pass the 'megs:N' option to bochs. The default is 32MB, since most OS's won't need more than that. Example:
      megs: 32

vgaromimage:
    You also need to load a VGA ROM BIOS into C0000. Example:
      vgaromimage: bios/VGABIOS-elpin-2.40

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 to use 'inserted'. Example: 2.88M 3.5" Floppy:
      floppya: 2_88=path, status=ejected 1.44M 3.5" Floppy:
      floppya: 1_44=path, status=inserted 1.2M 5.25" Floppy:
      floppyb: 1_2=path, status=ejected 720K 3.5" Floppy:
      floppya: 720k=path, status=inserted

diskc:
    or diskd: Point this at the disk image you want to use as for a hard disk. If you use bximage(1) to create the image, it will give you the required cyl, head, and spt information. diskc is the first hard drive, and diskd is the second hard drive. NOTE: You cannot use both diskd and cdromd together. Example:
      diskc: file=10M.i, cyl=306, heads=4, spt=17
      diskc: file=112M.i, cyl=900, heads=15, spt=17
      diskd: file=483.i, cyl=1024, heads=15, spt=63

com1:
    Point this at the device you want to use as your com1 serial port. The "dev=" parameter indicates which device to use. This can be a Unix pty. One way to use this would be to run bochs in one window and open a second window to use as com1. Do a `sleep 1000000' in the com1 window to prevent it's shell from getting in the way. When you run bochs, all I/O to com1 will show up in this window. Example:
      com1: dev=/dev/ttyp7

cdromd:
    Point this to a pathname of a raw CD-ROM device. There is no cdromc option, only cdromd. NOTE: You cannot use both diskd and cdromd together. Example:
      cdromd: dev=/dev/cdrom, status=inserted
      cdromd: dev=/dev/cdrom, status=ejected

newharddrivesupport:
    This setting enables support for large hard disks, better CD recognition, and various other useful functions. You can set it to "enabled=1" (on) or "enabled=0" (off). It is recommended that this setting is left on unless you are having trouble with it. Example:
      newharddrivesupport: enabled=1

boot:
    This defines your boot drive. You can either boot from 'a' or 'c'. Example:
      boot: c

log:
    Give the path of the log file you'd like Bochs debug and misc. verbage 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)

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), report (print information to the console), or ignore (do nothing). The safest setting is action=fatal. 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." Example:
      panic: action=fatal

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), report (print information to the console), or ignore (do nothing). Example:
      error: action=report

info:
    This setting tells Bochs what to do when an event occurs that generates informational messages. You can set this to fatal (that would not be very smart though), report (print information to the console), 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 fatal (but you shouldn't), report (print information to the console), 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

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: midi: The filename is where the midi data is sent. This can be a device or just a file if you want to record the midi data. midimode:
     0 = No data should be output.
     1 = output to device (system dependent - midi
     denotes the device driver).
     2 = SMF file output, including headers.
     3 = Output the midi data stream to the file
     (no midi headers and no delta times, just
     command and data bytes). wave: This is the device/file where wave output is stored. wavemode:
     0 = no data
     1 = output to device (system dependent - wave
     denotes the device driver).
     2 = VOC file output, including headers.
     3 = Output the raw wave stream to the file. log: The file to write the sb16 emulator messages to. loglevel:
     0 = No log.
     1 = Only 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. dmatimer: Microseconds per second for a DMA cycle. Make it smaller to fix non-continous sound. 750000 is usually a good value. This needs a reasonably correct setting for IPS (see below). Example:
      sb16: midimode=1, midi=/dev/midi00,
      wavemode=1, wave=/dev/dsp, loglevel=2,
      log=sb16.log, dmatimer=600000 NOTE: The example is wrapped onto three lines for formatting reasons, but it should all be on one line in the actual bochsrc file.

vga_update_interval:
    Video memory is scanned for updates and screen updated every so many virtual seconds. The default is 300000, about 3Hz. This is generally plenty. Keep in mind that you must tweak the 'ips:' directive to be as close to the number of emulated instructions-per-second your workstation can do, for this to be accurate. Example:
      vga_update_interval: 250000

keyboard_serial_delay:
    Approximate time in microseconds that it takes one character to be transfered from the keyboard to controller over the serial path. Example:
      keyboard_serial_delay: 200

keyboard_type:
    Type of emulated keyboard sent back to the OS to a "keyboard identify" command. It must be one of "xt", "at" or "mf". Example:
      keyboard_type: mf

floppy_command_delay:
    Time in microseconds to wait before completing some floppy commands such as read, write, seek, etc., which normally have a delay associated. This was previous hardwired to 50,000. Example:
      floppy_command_delay: 50000

ips:
    Emulated Instructions Per Second. This is the number of IPS that bochs is capable of running on your machine. You can recompile Bochs, using instructions included in config.h (in the source code), to find your workstation's capability. 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]
      Machine Mips --------------------------------------------------- 650Mhz Athlon K-7 with Linux 2.4.x 2 to 2.5 400Mhz Pentium II with Linux 2.0.x 1 to 1.8 166Mhz 64bit Sparc with Solaris 2.x 0.75 200Mhz Pentium with Linux 2.x 0.5
     [1] Mips are dependant on OS and compiler configuration in addition to processor clock speed. Example:
      ips: 1000000

mouse:
    This option prevents Bochs from creating mouse "events" unless a mouse is enabled. The hardware emulation itself is not disabled by this. You can turn the mouse on by setting enabled to 1, or turn it off by setting enabled to 0. Unless you have a particular reason for enabling the mouse by default, it is recommended that you leave it off. Example:
      mouse: enabled=1
      mouse: enabled=0

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

LICENSE
This program is distributed under the terms of the GNU Lesser General Public License as published by the Free Software Foundation. See the COPYING file located in /1.4/ for details on the license and the lack of warrantee.

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
The Getting Started Guide for Bochs on Linux:
        /1.4/DOC-linux.html

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 "Features."

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.