Merge commit '7c5c89d' into bfgminer-2.9.x

Conflicts:
	README

API-README

@@ -11,7 +11,7 @@ running BFGMiner and reply with a string and then close the socket each time
 If you add the "--api-network" option, it will accept API requests from any
 network attached computer.
 
-You can only access the comands that reply with data in this mode.
+You can only access the commands that reply with data in this mode.
 By default, you cannot access any privileged command that affects the miner -
 you will receive an access denied status message see --api-allow below.
 
@@ -28,7 +28,7 @@ See --api-groups below to define other groups like W:
 Privileged access is checked in the order the IP addresses were supplied to
 "--api-allow"
 The first match determines the privilege level.
-Using the "--api-allow" option overides the "--api-network" option if they
+Using the "--api-allow" option overrides the "--api-network" option if they
 are both specified
 With "--api-allow", 127.0.0.1 is not by default given access unless specified
 
@@ -44,12 +44,12 @@ An IP address/subnet can only be a member of one group
 A sample API group would be:
  --api-groups P:switchpool:enablepool:addpool:disablepool:removepool:poolpriority:*
 This would create a group 'P' that can do all current pool commands and all
-non-priviliged commands - the '*' means all non-priviledged commands
+non-privileged commands - the '*' means all non-privileged commands
 Without the '*' the group would only have access to the pool commands
 Defining multiple groups example:
  --api-groups Q:quit:restart:*,S:save
 This would define 2 groups:
- Q: that can 'quit' and 'restart' as well as all non-priviledged commands
+ Q: that can 'quit' and 'restart' as well as all non-privileged commands
  S: that can only 'save' and no other commands
 
 The RPC API request can be either simple text or JSON.
@@ -95,7 +95,7 @@ The STATUS section is:
    Standard long time of request in seconds
 
   Code=N
-   Each unique reply has a unigue Code (See api.c - #define MSG_NNNNNN)
+   Each unique reply has a unique Code (See api.c - #define MSG_NNNNNN)
 
   Msg=string
    Message matching the Code value N
@@ -137,7 +137,7 @@ The list of requests - a (*) means it requires privileged access - and replies a
 
  devs          DEVS           Each available GPU, PGA and CPU with their status
                               e.g. GPU=0,Accepted=NN,MHS av=NNN,...,Intensity=D|
-                              Last Share Time=NNN, <- standand long time in seconds
+                              Last Share Time=NNN, <- standard long time in seconds
                                (or 0 if none) of last accepted share
                               Last Share Pool=N, <- pool number (or -1 if none)
                               Will not report PGAs if PGA mining is disabled
@@ -255,7 +255,7 @@ The list of requests - a (*) means it requires privileged access - and replies a
  pgaenable|N (*)
                none           There is no reply section just the STATUS section
                               stating the results of the enable request
-                              You cannot enable a PGA if it's status is not WELL
+                              You cannot enable a PGA if its status is not WELL
                               This is only available if PGA mining is enabled
 
  pgadisable|N (*)
@@ -267,13 +267,13 @@ The list of requests - a (*) means it requires privileged access - and replies a
                none           There is no reply section just the STATUS section
                               stating the results of the identify request
                               This is only available if PGA mining is enabled
-                              and currently only BFL singles support this command
-                              On a BFL single it will flash the led on the front
-                              of the device for appoximately 4s
-                              All other non BFL PGA devices will return a warning
-                              status message stating that they dont support it
+                              and currently only BitForce Singles support this command
+                              On a BitForce Single it will flash the led on the front
+                              of the device for approximately 4s
+                              All other non-BFL PGA devices will return a warning
+                              status message stating that they don't support it
                               This adds a 4s delay to the BFL share being processed
-                              so you may get a message stating that procssing took
+                              so you may get a message stating that processing took
                               longer than 7000ms if the request was sent towards
                               the end of the timing of any work being worked on
                               e.g.: BFL0: took 8438ms - longer than 7000ms
@@ -332,17 +332,15 @@ The list of requests - a (*) means it requires privileged access - and replies a
                                                        0 to 9999)
                               coinbase-sig (string)
 
-When you enable, disable or restart a GPU or PGA, you will also get Thread messages
-in the BFGMiner status window
+When you enable, disable or restart a GPU or PGA, you will also get Thread
+messages in the BFGMiner status window.
 
 The 'poolpriority' command can be used to reset the priority order of multiple
-pools with a single command - 'switchpool' only sets a single pool to first priority
-Each pool should be listed by id number in order of preference (first = most
-preferred)
-Any pools not listed will be prioritised after the ones that are listed, in the
-priority order they were originally
-If the priority change affects the miner's preference for mining, it may switch
-immediately
+pools with a single command - 'switchpool' only sets a single pool to first
+priority. Each pool should be listed by id number in order of preference (first
+= most preferred). Any pools not listed will be prioritised after the ones that
+are listed, in the priority order they were originally If the priority change
+affects the miner's preference for mining, it may switch immediately.
 
 When you switch to a different pool to the current one (including by priority
 change), you will get a 'Switching to URL' message in the BFGMiner status
@@ -356,8 +354,8 @@ showing some details of the requests received and the replies
 
 There are included 4 program examples for accessing the API:
 
-api-example.php - a php script to access the API
-  usAge: php api-example.php command
+api-example.php - a PHP script to access the API
+  usage: php api-example.php command
  by default it sends a 'summary' request to the miner at 127.0.0.1:4028
  If you specify a command it will send that request instead
  You must modify the line "$socket = getsock('127.0.0.1', 4028);" at the
@@ -365,12 +363,12 @@ api-example.php - a php script to access the API
 
 API.java/API.class
  a java program to access the API (with source code)
-  usAge is: java API command address port
+  usage is: java API command address port
  Any missing or blank parameters are replaced as if you entered:
   java API summary 127.0.0.1 4028
 
 api-example.c - a 'C' program to access the API (with source code)
-  usAge: api-example [command [ip/host [port]]]
+  usage: api-example [command [ip/host [port]]]
  again, as above, missing or blank parameters are replaced as if you entered:
   api-example summary 127.0.0.1 4028
 
@@ -400,7 +398,7 @@ Modified API commands:
 API V1.19b (BFGMiner v2.8.1)
 
 Added API commands:
- 'pgaidentify|N' (only works for BFL Singles so far)
+ 'pgaidentify|N' (only works for BitForce Singles so far)
 
 Modified API commands:
  Change pool field name back from 'Diff1 Work' to 'Diff1 Shares'
@@ -410,7 +408,7 @@ Modified API commands:
               'Last Share Difficulty'
  'pga|N' - add 'Difficulty Accepted', 'Difficulty Rejected',
               'Last Share Difficulty'
- 'notify' - add '*Dev Throttle' (for BFL Singles)
+ 'notify' - add '*Dev Throttle' (for BitForce Singles)
  'pools' - add 'Difficulty Accepted', 'Difficulty Rejected',
                'Difficulty Stale', 'Last Share Difficulty'
  'stats' - add 'Work Diff', 'Min Diff', 'Max Diff', 'Min Diff Count',
@@ -479,7 +477,7 @@ Added API commands:
 API V1.14 (BFGMiner v2.5.0)
 
 Modified API commands:
- 'stats' - more icarus timing stats added
+ 'stats' - more Icarus timing stats added
  'notify' - include new device comms error counter
 
 The internal code for handling data was rewritten (~25% of the code)
@@ -502,7 +500,7 @@ API V1.12 (BFGMiner v2.4.3)
 Modified API commands:
  'stats' - more pool stats added
 
-Support for the ModMinerQuad FPGA was added
+Support for the ModMiner FPGA was added
 
 ----------
 
@@ -546,7 +544,7 @@ API V1.8 (BFGMiner v2.3.5)
 Added API commands:
  'devdetails'
 
-Support for the ZTex FPGA was added
+Support for the ZTEX FPGA was added
 
 ----------
 
@@ -581,11 +579,11 @@ Added API commands:
  'pgacount'
 
 Modified API commands:
- 'devs' now includes Icarus and Bitforce FPGA devices
+ 'devs' now includes Icarus and BitForce FPGA devices
  'notify' added "*" to the front of the name of all numeric error fields
  'config' correct "Log Interval" to use numeric (not text) type for JSON
 
-Support for Icarus and Bitforce FPGAs was added
+Support for Icarus and BitForce FPGAs was added
 
 ----------
 
@@ -707,7 +705,7 @@ It has two levels to the security:
 
 To use miner.php requires a web server with PHP
 
-Basics: On xubuntu 11.04, to install apache2 and php, the commands are:
+Basics: On Xubuntu 11.04, to install Apache and PHP, the commands are:
  sudo apt-get install apache2
  sudo apt-get install php5
  sudo /etc/init.d/apache2 reload
@@ -794,7 +792,7 @@ Done :)
 ---------
 
 The rest of this documentation deals with the more complex
-functions of miner.php, using myminer.php, creaing custom
+functions of miner.php, using myminer.php, creating custom
 summaries and displaying multiple BFGMiner rigs
 
 ---------
@@ -817,7 +815,7 @@ $rigs = array('192.168.0.100:4028:A', '192.168.0.102:4028:B');
 #
 ?>
 
-Changes in myminer.php superscede what is in miner.php
+Changes in myminer.php supersede what is in miner.php
 However, this is only valid for variables in miner.php before the
 2 lines where myminer.php is included by miner.php:
 
@@ -834,22 +832,22 @@ So although miner.php originally contains the line
 if you created the example myminer.php given above, it would actually
 change the value of $rigs that is used when miner.php is running
 i.e. you don't have to remove or comment out the $rigs line in miner.php
-It will be superceded by myminer.php
+It will be superseded by myminer.php
 
 ---------
 
 The example.php above also shows how to define more that one rig to
 be shown my miner.php
 
-Each rig string is 2 or 3 values seperated by colons ':'
+Each rig string is 2 or 3 values separated by colons ':'
 They are simply an IP address or host name, followed by the
 port number (usually 4028) and an optional Name string
 
-miner.php displays rig buttons that will show the defails of a single
+miner.php displays rig buttons that will show the details of a single
 rig when you click on it - the button shows either the rig number,
 or the 'Name' string if you provide it
 
-PHP arrays contain each string seperated by a comma, but no comma after
+PHP arrays contain each string separated by a comma, but no comma after
 the last one
 
 So an example for 3 rigs would be:
@@ -863,7 +861,7 @@ explained before
 ---------
 
 So basically, any variable explained below can be put in myminer.php
-if you wanted to set it to something different to it's default value
+if you wanted to set it to something different from its default value
 and did not want to change miner.php itself every time you updated it
 
 Below is each variable that can be changed and an explanation of each
@@ -921,7 +919,7 @@ table of data
 Set $notify to true to attempt to display the notify command on
 the single rig page
 If your older version of BFGMiner returns an 'Invalid command'
-coz it doesn't have notify - it just shows the error status table
+because it doesn't have notify - it just shows the error status table
 
 ---------
 
@@ -936,8 +934,8 @@ This assumes shares are 1 difficulty shares
 
 Set $checklastshare to false to not do the above checks
 
-'expected' is calculated from the device MH/s value
-So for example, a device that hashes at 380MH/s should (on average)
+'expected' is calculated from the device Mh/s value
+So for example, a device that hashes at 380Mh/s should (on average)
 find a share every 11.3s
 If the last share was found more than 11.3 x 12 seconds (135.6s) ago,
 it is considered an error and highlighted
@@ -1007,7 +1005,7 @@ The numbers are integer seconds
 
 The defaults should be OK for most cases
 However, the longer SND is, the longer you have to wait while
-php hangs if the target BFGMiner isn't runnning or listening
+PHP hangs if the target BFGMiner isn't running or listening
 
 RCV should only ever be relevant if BFGMiner has hung but the
 API thread is still running, RCV would normally be >= SND
@@ -1049,7 +1047,7 @@ Auto-refresh of the page (in seconds) - integers only
 
 $ignorerefresh = true/false always ignore refresh parameters
 $changerefresh = true/false show buttons to change the value
-$autorefresh = default value, 0 means dont auto-refresh
+$autorefresh = default value, 0 means don't auto-refresh
 
 ---------
 
@@ -1133,7 +1131,7 @@ There are 2 hard coded sections:
  RIGS - displays a rig table like at the start of 'Summary'
 
 Each custom summary requires a second array, that can be empty, listing fields
-to be totaled for each section
+to be totalled for each section
 If there is no matching total data, no total will show
 
 ---------

FPGA-README

@@ -2,29 +2,29 @@
 This README contains extended details about FPGA mining with BFGMiner
 
 
-ModMinerQuad (MMQ)
-------------------
+ModMiner (MMQ)
+--------------
 
 The mining bitstream does not survive a power cycle, so BFGMiner will upload
 it, if it needs to, before it starts mining
 
 -
 
-You must make sure you have an approriate firmware in your MMQ
+You must make sure you have an appropriate firmware in your MMQ
 Read here for official details of changing the firmware:
  http://wiki.btcfpga.com/index.php?title=Firmware
 
 The basics of changing the firmware are:
- You need two short pieces of conductive wire if your MMQ doesn't have
- buttons on the "RESET" and "ISP" pads on the backplane board
+ You need two short pieces of conductive wire if your MMQ doesn't have buttons
+ on the "RESET" and "ISP" pads on the backplane board
  Cutting a small (metal) paper-clip in half works well for this
 
  Join the 2 left pads of the "RESET" pad with wire and the led will dim
- Without disconnecting the "RESET", join the 2 left pads of the "ISP" pad
- with a wire and it will stay dim
+ Without disconnecting the "RESET", join the 2 left pads of the "ISP" pad with
+ a wire and it will stay dim
  Release "RESET" then release "ISP" and is should still be dim
- Unplug the USB and when you plug it back in it will show up as a mass
- storage device
+ Unplug the USB and when you plug it back in it will show up as a mass storage
+ device
   Linux: (as one single line):
    mcopy -i /dev/disk/by-id/usb-NXP_LPC134X_IFLASH_ISP000000000-0:0
       modminer091012.bin ::/firmware.bin
@@ -49,14 +49,12 @@ This comment will be updated when others have been tested
 
 -
 
-On many linux distributions there is an app called modem-manager that
-may cause problems when it is enabled, due to opening the MMQ device
-and writing to it
+On many Linux distributions there is an app called modem-manager that may cause
+problems when it is enabled, due to opening the MMQ device and writing to it
 
-The problem will typically present itself by the flashing led on the
-backplane going out (no longer flashing) and it takes a power cycle to
-re-enable the MMQ firmware - which then can lead to the problem happening
-again
+The problem will typically present itself by the flashing led on the backplane
+going out (no longer flashing) and it takes a power cycle to re-enable the MMQ
+firmware - which then can lead to the problem happening again
 
 You can either disable/uninstall modem-manager if you don't need it or:
 a (hack) solution to this is to blacklist the MMQ USB device in
@@ -69,24 +67,22 @@ ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0003", ENV{ID_MM_DEVICE_IGNORE}="1"
 The change will be lost and need to be re-done, next time you update the
 modem-manager software
 
-TODO: check that all MMQ's have the same product ID
-
 
-Bitforce (BFL)
+BitForce (BFL)
 --------------
 
---bfl-range         Use nonce range on bitforce devices if supported
+--bfl-range         Use nonce range on BitForce devices if supported
 
-This option is only for bitforce devices. Earlier devices such as the single
+This option is only for BitForce devices. Earlier devices such as the single
 did not have any way of doing small amounts of work which meant that a lot of
-work could be lost across block changes. Some of the "minirigs" have support
+work could be lost across block changes. Some of the Mini Rigs have support
 for doing this, so less work is lost across a longpoll. However, it comes at
 a cost of 1% in overall hashrate so this feature is disabled by default. It
-is only recommended you enable this if you are mining with a minirig on
-p2pool.
+is only recommended you enable this if you are mining with a Mini Rig on
+P2Pool.
 
 BFGMiner also bundles a bitforce-firmware-flash utility on Linux. Using this,
-you can change the bitstream firmware on BitFORCE Singles. It is untested with
+you can change the bitstream firmware on BitForce Singles. It is untested with
 other devices. Use at your own risk! Windows users may use Butterfly Labs
 EasyMiner to change firmware.
 
@@ -95,8 +91,8 @@ To compile:
 To flash your BFL, specify the BFL port and the flash file e.g.:
  sudo ./bitforce-firmware-flash /dev/ttyUSB0 alphaminer_832.bfl
 It takes a bit under 3 minutes to flash a BFL and shows a progress % counter
-Once it completes, you may also need to wait about 15 seconds,
-then power the BFL off and on again
+Once it completes, you may also need to wait about 15 seconds, then power the
+BFL off and on again
 
 If you get an error at the end of the BFL flash process stating:
  "Error reading response from ZBX"
@@ -104,8 +100,8 @@ it may have worked successfully anyway.
 Test mining on it to be sure if it worked or not.
 
 You need to give BFGMiner about 10 minutes mining with the BFL to be sure of
-the MH/s value reported with the changed firmware - and the MH/s reported
-will be less than the firmware speed since you lose work on every block change.
+the Mh/s value reported with the changed firmware - and the MH/s reported will
+be less than the firmware speed since you lose work on every block change.
 
 
 Icarus (ICA)
@@ -127,8 +123,8 @@ There are two hidden options in BFGMiner when Icarus support is compiled in:
                             r  Reopen device regularly to workaround buggy Icarus USB chipset
                                (enabled by default)
 
-If you define fewer comma seperated values than Icarus devices, the last values will be used
-for all extra devices
+If you define fewer comma separated values than Icarus devices, the last values
+will be used for all extra devices
 
 An example would be: --icarus-options 57600:2:1:-r
 This would mean: use 57600 baud, the FPGA board divides the work in half however
@@ -141,49 +137,57 @@ an early CM1 Icarus copy bitstream)
            long          Re-calculate the hash time continuously
            value[=N]     Specify the hash time in nanoseconds (e.g. 2.6316) and abort time (e.g. 2.6316=80)
 
-If you define fewer comma seperated values than Icarus devices, the last values will be used
-for all extra devices
+If you define fewer comma separated values than Icarus devices, the last values
+will be used for all extra devices
 
-Icarus timing is required for devices that do not exactly match a default Icarus Rev3 in
-processing speed
-If you have an Icarus Rev3 you should not normally need to use --icarus-timing since the
-default values will maximise the MH/s and display it correctly
+Icarus timing is required for devices that do not exactly match a default
+Icarus Rev3 in processing speed
+If you have an Icarus Rev3 you should not normally need to use --icarus-timing
+since the default values will maximise the Mh/s and display it correctly
 
-Icarus timing is used to determine the number of hashes that have been checked when it aborts
-a nonce range (including on a LongPoll)
-It is also used to determine the elapsed time when it should abort a nonce range to avoid
-letting the Icarus go idle, but also to safely maximise that time
+Icarus timing is used to determine the number of hashes that have been checked
+when it aborts a nonce range (including on a longpoll)
+It is also used to determine the elapsed time when it should abort a nonce
+range to avoid letting the Icarus go idle, but also to safely maximise that
+time
 
-'short' or 'long' mode should only be used on a computer that has enough CPU available to run
-BFGMiner without any CPU delays (an active desktop or swapping computer would not be stable enough)
+'short' or 'long' mode should only be used on a computer that has enough CPU
+available to run BFGMiner without any CPU delays (an active desktop or swapping
+computer would not be stable enough)
 Any CPU delays while calculating the hash time will affect the result
-'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares
-'long' mode requires it to always be stable to ensure accuracy, however, over time it continually
-corrects itself
-
-When in 'short' or 'long' mode, it will report the hash time value each time it is re-calculated
-In 'short' or 'long' mode, the scan abort time starts at 5 seconds and uses the default 2.6316ns
-scan hash time, for the first 5 nonce's or one minute (whichever is longer)
-
-In 'default' or 'value' mode the 'constants' are calculated once at the start, based on the default
-value or the value specified
-The optional additional =N specifies to set the default abort at N 1/10ths of a second, not the
-calculated value, which is 112 for 2.6316ns
-
-To determine the hash time value for a non Icarus Rev3 device or an Icarus Rev3 with a different
-bitstream to the default one, use 'long' mode and give it at least a few hundred shares, or use
-'short' mode and take note of the final hash time value (Hs) calculated
-You can also use the RPC API 'stats' command to see the current hash time (Hs) at any time
-
-The Icarus code currently only works with an FPGA device that supports the same commands as
-Icarus Rev3 requires and also is less than ~840MH/s and greater than 2MH/s
-If an FPGA device does hash faster than ~840MH/s it should work correctly if you supply the
-correct hash time nanoseconds value
-
-The timing code itself will affect the Icarus performance since it increases the delay after
-work is completed or aborted until it starts again
-The increase is, however, extremely small and the actual increase is reported with the
-RPC API 'stats' command (a very slow CPU will make it more noticeable)
+'short' mode only requires the computer to be stable until it has completed
+~315 difficulty 1 shares
+'long' mode requires it to always be stable to ensure accuracy, however, over
+time it continually corrects itself
+
+When in 'short' or 'long' mode, it will report the hash time value each time it
+is re-calculated
+In 'short' or 'long' mode, the scan abort time starts at 5 seconds and uses the
+default 2.6316ns scan hash time, for the first 5 nonces or one minute
+(whichever is longer)
+
+In 'default' or 'value' mode the 'constants' are calculated once at the start,
+based on the default value or the value specified
+The optional additional =N specifies to set the default abort at N 1/10ths of a
+second, not the calculated value, which is 112 for 2.6316ns
+
+To determine the hash time value for a non Icarus Rev3 device or an Icarus Rev3
+with a different bitstream to the default one, use 'long' mode and give it at
+least a few hundred shares, or use 'short' mode and take note of the final hash
+time value (Hs) calculated
+You can also use the RPC API 'stats' command to see the current hash time (Hs)
+at any time
+
+The Icarus code currently only works with an FPGA device that supports the same
+commands as Icarus Rev3 requires and also is less than ~840Mh/s and greater
+than 2Mh/s
+If an FPGA device does hash faster than ~840Mh/s it should work correctly if
+you supply the correct hash time nanoseconds value
+
+The timing code itself will affect the Icarus performance since it increases
+the delay after work is completed or aborted until it starts again
+The increase is, however, extremely small and the actual increase is reported
+with the RPC API 'stats' command (a very slow CPU will make it more noticeable)
 Using the 'short' mode will remove this delay after 'short' mode completes
 The delay doesn't affect the calculation of the correct hash time
 

README

@@ -55,7 +55,7 @@ Dependencies:
 	(libudev-dev - only required for multi-FPGA auto-detection on Linux)
 
 	usb dev library     http://www.libusb.org/
-	(libusb-dev  - only required for Ztex and X6500 support)
+	(libusb-dev  - only required for ZTEX and X6500 support)
 
 
 BFGMiner specific configuration options:
@@ -66,7 +66,7 @@ BFGMiner specific configuration options:
 	--disable-icarus        Compile support for Icarus (default enabled)
 	--disable-modminer      Compile support for ModMiner (default enabled)
 	--disable-x6500         Compile support for X6500 (default enabled)
-	--disable-ztex          Compile support for Ztex (default if libusb)
+	--disable-ztex          Compile support for ZTEX (default if libusb)
 	--enable-scrypt         Compile support for scrypt mining (default disabled)
 	--without-curses        Compile support for curses TUI (default enabled)
 	--without-libudev       Autodetect FPGAs using libudev (default enabled)
@@ -214,7 +214,7 @@ SCRYPT only options:
 See SCRYPT-README for more information regarding (non-bitcoin) scrypt mining.
 
 
-FPGA mining boards (BitForce, Icarus, ModMiner, X6500, Ztex) only options:
+FPGA mining boards (BitForce, Icarus, ModMiner, X6500, ZTEX) only options:
 
 --scan-serial|-S <arg> Serial port to probe for FPGA mining device
 
@@ -227,17 +227,17 @@ On Ubuntu: sudo usermod <username> -a -G dialout
 Note that on GNU/Linux systems, you will usually need to login again before
 group changes take effect.
 
-By default, BFGMiner will scan for autodetected FPGAs unless at least one
--S is specified for that driver. If you specify -S and still want BFGMiner
-to scan, you must also use "-S auto". If you want to prevent BFGMiner from
-scanning without specifying a device, you can use "-S noauto". Note that
-presently, autodetection only works on Linux, and might only detect one
-device depending on the version of udev being used. If you want to scan all
-serial ports, you can use "-S all"; note that this may write data to
-non-mining devices which may then behave in unexpected ways!
-
-On linux <arg> is usually of the format /dev/ttyUSBn
-On windows <arg> is usually of the format \\.\COMn
+By default, BFGMiner will scan for autodetected FPGAs unless at least one -S is
+specified for that driver. If you specify -S and still want BFGMiner to scan,
+you must also use "-S auto". If you want to prevent BFGMiner from scanning
+without specifying a device, you can use "-S noauto". Note that presently,
+autodetection only works on Linux, and might only detect one device depending
+on the version of udev being used. If you want to scan all serial ports, you
+can use "-S all"; note that this may write data to non-mining devices which may
+then behave in unexpected ways!
+
+On Linux, <arg> is usually of the format /dev/ttyUSBn
+On Windows, <arg> is usually of the format \\.\COMn
 (where n = the correct device number for the FPGA device)
 
 The official supplied binaries are compiled with support for all FPGAs.
@@ -318,8 +318,8 @@ The list of proxy types are:
 
 Proxy support requires cURL version 7.21.7 or newer.
 
-If you specify the --socks-proxy option to BFGMiner, it will only be applied to all pools
-that don't specify their own proxy setting like above
+If you specify the --socks-proxy option to BFGMiner, it will only be applied to
+all pools that don't specify their own proxy setting like above
 
 READ WARNINGS AND DOCUMENTATION BELOW ABOUT OVERCLOCKING
 
@@ -436,7 +436,8 @@ The BFGMiner status line shows:
 
 TQ is Total Queued work items.
 ST is STaged work items (ready to use).
-SS is Stale Shares discarded (detected and not submitted so don't count as rejects)
+SS is Stale Shares discarded (detected and not submitted so don't count as
+rejects)
 DW is Discarded Work items (work from block no longer valid to work on)
 NB is New Blocks detected on the network
 GW is GetWork requested (work items from pools)
@@ -542,9 +543,10 @@ P:Pool, T:Test Pool, L:LP or B:Benchmark,
 then D:d.ddd is the difficulty required to get a share from the work,
 then G:hh:mm:ss:n.nnn, which is when the getwork or LP was sent to the pool and
 the n.nnn is how long it took to reply,
-followed by 'O' on it's own if it is an original getwork, or 'C:n.nnn' if it was
-a clone with n.nnn stating how long after the work was recieved that it was cloned,
-(m.mmm) is how long from when the original work was received until work started,
+followed by 'O' on its own if it is an original getwork, or 'C:n.nnn' if it was
+a clone with n.nnn stating how long after the work was recieved that it was
+cloned, (m.mmm) is how long from when the original work was received until work
+started,
 W:n.nnn is how long the work took to process until it was ready to submit,
 (m.mmm) is how long from ready to submit to actually doing the submit, this is
 usually 0.000 unless there was a problem with submitting the work,
@@ -607,9 +609,9 @@ For example, to keep the 2nd GPU to its default clocks:
 --gpu-engine 950,0,930,960 --gpu-memclock 300,0,300,300
 
 AUTO MODES:
-There are two "auto" modes in BFGMiner, --auto-fan and --auto-gpu. These can
-be used independently of each other and are complementary. Both auto modes
-are designed to safely change settings while trying to maintain a target
+There are two "auto" modes in BFGMiner, --auto-fan and --auto-gpu. These can be
+used independently of each other and are complementary. Both auto modes are
+designed to safely change settings while trying to maintain a target
 temperature. By default this is set to 75 degrees C but can be changed with:
 
 --temp-target
@@ -628,11 +630,11 @@ e.g.
 Fan control in auto fan works off the theory that the minimum possible fan
 required to maintain an optimal temperature will use less power, make less
 noise, and prolong the life of the fan. In auto-fan mode, the fan speed is
-limited to 85% if the temperature is below "overheat" intentionally, as
-higher fanspeeds on GPUs do not produce signficantly more cooling, yet
-significanly shorten the lifespan of the fans. If temperature reaches the
-overheat value, fanspeed will still be increased to 100%. The overheat value
-is set to 85 degrees by default and can be changed with:
+limited to 85% if the temperature is below "overheat" intentionally, as higher
+fanspeeds on GPUs do not produce signficantly more cooling, yet significantly
+shorten the lifespan of the fans. If temperature reaches the overheat value,
+fanspeed will still be increased to 100%. The overheat value is set to 85
+degrees by default and can be changed with:
 
 --temp-overheat
 e.g.
@@ -645,15 +647,15 @@ e.g.
 --auto-gpu --gpu-engine 750-950,945,700-930,960
 
 GPU control in auto gpu tries to maintain as high a clock speed as possible
-while not reaching overheat temperatures. As a lower clock speed limit,
-the auto-gpu mode checks the GPU card's "normal" clock speed and will not go
-below this unless you have manually set a lower speed in the range. Also,
-unless a higher clock speed was specified at startup, it will not raise the
-clockspeed. If the temperature climbs, fanspeed is adjusted and optimised
-before GPU engine clockspeed is adjusted. If fan speed control is not available
-or already optimal, then GPU clock speed is only decreased if it goes over
-the target temperature by the hysteresis amount, which is set to 3 by default
-and can be changed with:
+while not reaching overheat temperatures. As a lower clock speed limit, the
+auto-gpu mode checks the GPU card's "normal" clock speed and will not go below
+this unless you have manually set a lower speed in the range. Also, unless a
+higher clock speed was specified at startup, it will not raise the clockspeed.
+If the temperature climbs, fanspeed is adjusted and optimised before GPU engin
+e clockspeed is adjusted. If fan speed control is not available or already
+optimal, then GPU clock speed is only decreased if it goes over the target
+temperature by the hysteresis amount, which is set to 3 by default and can be
+changed with:
 --temp-hysteresis
 If the temperature drops below the target temperature, and engine clock speed
 is not at the highest level set at startup, BFGMiner will raise the clock speed.
@@ -671,9 +673,9 @@ Sets card 0 cutoff temperature to 95 and card 1 to 105.
 
 --gpu-memdiff -125
 This setting will modify the memory speed whenever the GPU clock speed is
-modified by --auto-gpu. In this example, it will set the memory speed to
-be 125 MHz lower than the GPU speed. This is useful for some cards like the
-6970 which normally don't allow a bigger clock speed difference.
+modified by --auto-gpu. In this example, it will set the memory speed to be 125
+MHz lower than the GPU speed. This is useful for some cards like the 6970 which
+normally don't allow a bigger clock speed difference.
 
 
 CHANGING SETTINGS:
@@ -758,7 +760,7 @@ Note the number of devices here match, and the order is the same. If devices 1
 and 2 were different between Tahiti and Cayman, you could run BFGMiner with:
 --gpu-map 2:1,1:2
 And it would swap the monitoring it received from ADL device 1 and put it to
-opencl device 2 and vice versa.
+OpenCL device 2 and vice versa.
 
 If you have 2 monitors connected to the first device it would look like this:
 
@@ -812,7 +814,7 @@ the command line or via the menu after startup and choose settings->write
 config file and the file will be loaded one each startup.
 
 Q: The build fails with gcc is unable to build a binary.
-A: Remove the "-march=native" component of your CFLAGS as your version of gcc
+A: Remove the "-march=native" component of your CFLAGS as your version of GCC
 does not support it.
 
 Q: The CPU usage is high.
@@ -864,9 +866,8 @@ The defaults are very sane and I have very little interest in changing this
 any further.
 
 Q: Can you change the autofan/autogpu to change speeds in a different manner?
-A: The defaults are sane and safe. I'm not interested in changing them
-further. The starting fan speed is set to 50% in auto-fan mode as a safety
-precaution.
+A: The defaults are sane and safe. I'm not interested in changing them further.
+The starting fan speed is set to 50% in auto-fan mode as a safety precaution.
 
 Q: Why is my efficiency above/below 100%?
 A: Efficiency simply means how many shares you return for the amount of work
@@ -924,11 +925,11 @@ A: Try "export DISPLAY=:0" before running BFGMiner.
 Q: My network gets slower and slower and then dies for a minute?
 A; Try the --net-delay option.
 
-Q: How do I tune for p2pool?
-A: p2pool has very rapid expiration of work and new blocks, it is suggested you
+Q: How do I tune for P2Pool?
+A: P2Pool has very rapid expiration of work and new blocks, it is suggested you
 decrease intensity by 1 from your optimal value, and decrease GPU threads to 1
 with -g 1. It is also recommended to use --failover-only since the work is
-effectively like a different block chain. If mining with a minirig, it is worth
+effectively like a different block chain. If mining with a Mini Rig, it is worth
 adding the --bfl-range option.
 
 Q: Are kernels from other mining software useable in BFGMiner?
@@ -942,13 +943,13 @@ A: http://us.php.net/manual/en/sockets.installation.php
 
 Q: What is a PGA?
 A: At the moment, BFGMiner supports 5 FPGAs: BitForce, Icarus, ModMiner, X6500,
-and Ztex.
+and ZTEX.
 They are Field-Programmable Gate Arrays that have been programmed to do Bitcoin
 mining. Since the acronym needs to be only 3 characters, the "Field-" part has
 been skipped.
 
 Q: How do I get my BFL/Icarus/Lancelot/Cairnsmore device to auto-recognise?
-A: On linux, if the /dev/ttyUSB* devices don't automatically appear, the only
+A: On Linux, if the /dev/ttyUSB* devices don't automatically appear, the only
 thing that needs to be done is to load the driver for them:
 BFL: sudo modprobe ftdi_sio vendor=0x0403 product=0x6014
 Icarus: sudo modprobe pl2303 vendor=0x067b product=0x230
@@ -958,9 +959,10 @@ On windows you must install the pl2303 or ftdi driver required for the device
 pl2303: http://prolificusa.com/pl-2303hx-drivers/
 ftdi: http://www.ftdichip.com/Drivers/VCP.htm
 
-Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL/MMQ FPGA, but
+Q: On Linux I can see the /dev/ttyUSB* devices for my ICA/BFL/MMQ FPGA, but
 BFGMiner can't mine on them
-A: Make sure you have the required priviledges to access the /dev/ttyUSB* devices:
+A: Make sure you have the required priviledges to access the /dev/ttyUSB*
+devices:
  sudo ls -las /dev/ttyUSB*
 will give output like:
  0 crw-rw---- 1 root dialout 188, 0 2012-09-11 13:49 /dev/ttyUSB0
@@ -974,8 +976,8 @@ A: Stratum is a protocol designed to reduce resources for mining pools at the
 cost of keeping the miner in the dark and blindly transferring his mining
 authority to the pool. It is a return to the problems of the old centralized
 "getwork" protocol, but capable of scaling to hardware of any speed like the
-standard GBT protocol. If a pool uses stratum instead of GBT, BFGMiner
-will automatically detect it and switch to the support as advertised if it can.
+standard GBT protocol. If a pool uses stratum instead of GBT, BFGMiner will
+automatically detect it and switch to the support as advertised if it can.
 Stratum uses direct TCP connections to the pool and thus it will NOT currently
 work through a http proxy but will work via a socks proxy if you need to use
 one. If you input the stratum port directly into your configuration, or use the

SCRYPT-README

@@ -24,7 +24,7 @@ NOTE that if it does not fail at startup, the presence of hardware errors (HW)
 are a sure sign that you have set the parameters too high.
 
 
-Step 1 on linux:
+Step 1 on Linux:
 export GPU_MAX_ALLOC_PERCENT=100
 If you do not do this, you may find it impossible to scrypt mine. You may find
 a value of 40 is enough and increasing this further has little effect.
@@ -37,7 +37,7 @@ may help CPU usage a little as well.
 is a new option where you tell BFGMiner how many shaders your GPU has. This
 helps BFGMiner try to choose some meaningful baseline parameters. Use this table
 below to determine how many shaders your GPU has, and note that there are some
-variants of these cards, and nvidia shaders are much much lower and virtually
+variants of these cards, and Nvidia shaders are much much lower and virtually
 pointless trying to mine on.
 
 GPU  Shaders
@@ -74,7 +74,7 @@ all you will need to set.
 
 --intensity XX
 
-Just like in bitcoin mining, scrypt mining takes an intensity, however the
+Just like in Bitcoin mining, scrypt mining takes an intensity, however the
 scale goes from 0 to 20 to mimic the "Aggression" used in mtrlt's reaper. The
 reason this is crucial is that too high an intensity can actually be
 disastrous with scrypt because it CAN run out of ram. Intensities over 13

configure.ac

@@ -263,21 +263,21 @@ fi
 AM_CONDITIONAL([HAS_X6500], [test x$x6500 = xyes])
 
 AC_ARG_ENABLE([ztex],
-	[AC_HELP_STRING([--disable-ztex],[Compile support for Ztex (default if libusb)])],
+	[AC_HELP_STRING([--disable-ztex],[Compile support for ZTEX (default if libusb)])],
 	[ztex=$enableval],
 	[ztex=auto]
 	)
 if test "x$ztex$libusb" = xyesno; then
-	AC_MSG_ERROR([Could not find libusb, required for Ztex support])
+	AC_MSG_ERROR([Could not find libusb, required for ZTEX support])
 elif test "x$ztex" = xauto; then
 	ztex="$libusb"
 	if test "x$libusb" = xno; then
-		AC_MSG_WARN([Could not find libusb, required for Ztex support])
+		AC_MSG_WARN([Could not find libusb, required for ZTEX support])
 		ztexwarn=yes
 	fi
 fi
 if test "x$ztex" = xyes; then
-	AC_DEFINE([USE_ZTEX], [1], [Defined to 1 if Ztex support is wanted])
+	AC_DEFINE([USE_ZTEX], [1], [Defined to 1 if ZTEX support is wanted])
 fi
 AM_CONDITIONAL([HAS_ZTEX], [test x$ztex = xyes])
 
@@ -660,11 +660,11 @@ else
 fi
 
 if test "x$ztex" = xyes; then
-	echo "  Ztex.FPGAs...........: Enabled"
+	echo "  ZTEX.FPGAs...........: Enabled"
 elif test "x$ztexwarn" = xyes; then
-	echo "  Ztex.FPGAs...........: Disabled (libusb not found)"
+	echo "  ZTEX.FPGAs...........: Disabled (libusb not found)"
 else
-	echo "  Ztex.FPGAs...........: Disabled"
+	echo "  ZTEX.FPGAs...........: Disabled"
 fi
 
 if test "x$bitforce$modminer" != xnono; then