But of course. It would be a self-fulfilling donation then which is better than just giving me the equivalent amount of BTC, as was the 7970 donation and much better cgminer support for GCN cards as a result. Continuing to support would be guaranteed if I owned one of the devices.

Much appreciated, thanks 

By the way, I'm having great trouble justifying the FPGA support in cgminer. It's taking me a fair amount of time vetting all the code that comes in, dealing with the drama of different coders not getting on, and that I don't have an FPGA so the code does not benefit me, nor am I earning anything off supporting FPGAs. So once again I find myself in a quandary about whether I should even be supporting them at all or not (like CPU mining, but for precisely the opposite reason!). So unless this gets easier, and it looks like it will only get harder, there is a very real possibility that someone like Luke-jr will fork the FPGA code into a separate project (he has even suggested he will) and I'll stop supporting it. I'm just giving advance warning here to people about this issue. I know it's just me whining, and harsh, but the fact is that the effort has to come from somewhere, and I do not have infinite time on my hands.

First cgminer release (2.3.4) with limited ztex support for 1.15x is out.

NEW VERSION - VERSION 2.3.4, 25 APRIL 2012

The release archive for this is much bigger because of included firmware for ztex boards. The version number is only a minor increment because it is mostly bugfixes for any features already working, and extra features should not affect existing working code.

Human readable summary:
Status window fixes for >8 devices.
Ztex support
Information at startup if config file is loaded
(advanced) gpu-map option for when OpenCL and ADL disagree on device numbering
API thread will restart properly if cgminer is restarted from the menu, and this hopefully will fix the ADL deciding to stop reporting fanspeeds by successfully restarting cgminer.
More information is given off with -n on the command line now.
You can increase the queue much more than 10 now if so desired.
Updated miner.php
Better Icarus support
First ZTEX FPGA support.

Full changelog:
- Extensively document the cause of GPU device issues and the use of --gpu-map.
- Support for share logging
- Detect poorly performing combination of SDK and phatk kernel and add verbose
warning at startup.
- Icarus update to new add_cgpu()
- Icarus driver working with Linux and Windows
- api.c fix unused variable compile warning
- Display all OpenCL devices when -n is called as well to allow debugging of
differential mapping of OpenCL to ADL.
- Add a --gpu-map option which will allow arbitrarily mapping ADL devices to
OpenCL devices for instances where association by enumeration alone fails.
- Increase upper limit on number of extra items to queue as some FPGA code can't
yet reliably keep many devices busy.
- Display configuration file information when -c option is passed and only when
file exists on loading default config file.
- Display configuration file loaded, if any, and debug output if configuration
file parsing failed.
- Add missing ztex header to Makefile for distribution.
- Document long-form COM port device names on Windows, required to specify
serial ports above 9
- Include ztex bitstreams firmware in distribution and install if configured in.
- Style police on driver-ztex.c
- work_restart should only be changed by cgminer.c now
- Shut down the api cleanly when the api thread is cancelled. This should allow
the api socket to be closed successfully to next be reopened with app_restart.
- Make a union for cgpu device handles, and rename "device" to "device_ztex"
since it's Ztex-specific
- Initialise name variable.
- Remove unnecessary check for variable that always has memory allocated.
- Bugfix: Missing "break" no-op in default case
- Make the status window and log window as large as can fit on startup,
rechecking to see if it can be enlarged after the fact. This allows any number
of devices to be displayed provided the window is made long enough without
corrupting the output.
- Style police on libztex.c.
- API add removepool like the screen interface
- api.c escape required characters in return strings + pools returns the
username
- Set lp_path to NULL after free for consistency.
- Removing dmalloc import left behind by mistake
- Fixing leak in resp_hdr_cb
- miner.php warning highlight GPU stats if they are zero (e.g. ADL not enabled)
- miner.php highlight any device that isn't 'Enabled'
- miner.php highlight any Status that isn't 'Alive'
- miner.php optionally support multiple rigs
- Initial Ztex support 1.15x board.

I commented on a couple of minor issues with his code, he modified it, and I've included it in my git tree now.

It's only money and you've already given some of it to luke who did the work. Why should I make you pay more than you originally offered? Luke's code is fine, but if you want me to include it, it'll have to be a proper pull request and fully documented as well since he'll get even more bounty according to your original offer if I include the code.

Gotta be quick to get the quick bucks it seems. I'll go back to the boring slow grind work instead

That's fine. How would you want the difficulty displayed? I'm not really sure I understand the (0.999985) type value you're displaying in your sample.

I might have to restructure that input as it predates my ability to parse multiple inputs with the one argument. I should change it to  -d 0,1,3,4,5 . Not even sure if you can put multiple -d on the config file, but if so, you'd just put in each -d entry on a separate line.

I can do it. Just trying to decide if it should be this way for everyone. Be aware that rejects are almost always rejected while meeting the target. They're rejected for other reasons.

The dependencies listed are for release versions, not for compiling from git. Autotools are required only for git development versions of cgminer. It is assumed anyone brave enough to be compiling from git actually knows a thing or two of what he's doing, especially since incremental versions may be broken before the final release.

I still have trouble caring about FPGAs, and am happy to leave that to outsiders to work on. GPUs are far more interesting to me. (No I wasn't trying to start a debate about the relative pros/cons of each as we're all well aware of them by now).

I know that goddamnit LOL.

Why hasn't anyone responded to this comment? I'm trying to say I'd prefer not to do this as I can't guarantee any reasonable time frame.

I thought you might be interested in coding up this x6500 support instead of me. I did not expect you to come here and complain about your relationship with Luke-jr, as this is not the thread for it. As far as I was aware he addressed everything you told him to address and have included his code on that expectation, while withholding his code that touched your API code unnecessarily. If you wish to discuss this further, talk to me in private, or in another thread. No point taking your frustration with Luke-jr out on this thread.

I missed all of that so cannot pass judgement on it.

This still stands by the way. However if you really can't find anyone and manage to put together the bounty, I will still do it, but there may be some delay in getting the support since I'll be busy and intermittently away.

It almost looks like you're taking this to heart too much, as though it's a vote against MPBM, which it isn't. I could ask precisely the same question about GPU mining apps as to why people use anything but cgminer, but I don't. People just want options, and one person's idea of what fits is never going to be the same for everyone. Almost certainly, the vast majority will want it to consolidate their software with GPU+FPGA miners, but it could just be they like cgminer and it fits.

Try deleting any .bin files you have in the cgminer directory and starting again. If that fails, try specifying a different worksize for the 57x0 to the 58x0 (eg -w 256,256,128 if the 5750 is last).