Make wrapping consistent at 79-80 characters per line

API-README

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

FPGA-README

@@ -15,16 +15,16 @@ 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
@@ -93,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"
@@ -102,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)
@@ -125,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 separated 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
@@ -139,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 separated 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 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)
+'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

@@ -225,17 +225,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.
@@ -316,8 +316,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
 
@@ -434,7 +434,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)
@@ -518,8 +519,9 @@ 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 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,
+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,
@@ -582,9 +584,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
@@ -603,11 +605,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.
@@ -620,15 +622,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.
@@ -646,9 +648,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:
@@ -733,7 +735,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:
 
@@ -787,7 +789,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.
@@ -839,9 +841,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
@@ -923,7 +924,7 @@ 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
@@ -933,9 +934,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
@@ -949,8 +951,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

libblkmaker

@@ -1 +1 @@
-Subproject commit ca3cf0173806d39d2b3a1400de3fa4bec7ab772a
+Subproject commit 19847fbab02450fb0db2ae519a35808cdc091991