I agree to let the funds to be paid out.
I have a stable and good speed bitstream working (hashvoodoo175) on my 2 boards.
They do not appear to like the faster ones, but with so many reporting good reports for the faster ones I can't blame the bitstream.
So it's achieved what I want and I do look forward to improvements.

are u growing hydroponic carrots?

Because I had no idea that there still were hardware manufacturers that wouldn't support Linux by default today. Especially in this very case: addressing the Bitcoin mining community: many (most?) of us have Linux rigs some even use the RasperryPi or home routers to connect to their FPGAs. Bitcoin is open-sourced at its roots.
The only question that I asked myself is if the board could be updated via USB (this is why I didn't purchase a JTAG cable). Even the documentation of the controller programming interface would be enough. In fact no Linux support isn't the problem, having to rely on an obscure utility that only runs on some OS versions without the safety net of documentation of the interfaces it uses is a recipe for transforming anything in a paper weight mid or longterm.
This is not the first time I purchase hardware for which I have to code the driver or some tools myself: you can still grep my name in the Linux kernel for the support of some long forgotten IDE controllers. So usually I'm not especially worried, but reading that there is some IP in there that can't be disclosed to build the tools I need is worrying me.


We knew very little of the details when we pre-ordered. Everyone took a risk, myself included.
But having the thing closed to me because I can't have access to the information I need to make it work the way I want is exasperating. I'm a tinkerer : if I can't hack it I won't like it and it better make itself forgotten (which it doesn't do well currently). It's already too bad that Xilinx won't sell you the right to hack the Spartan6 with it but separately. I already had difficulties wrapping my mind around this fact, seems the FPGA world is not for me.


That's a good alternative thanks for the heads up.

"Whitelisted addresses" does not equate to "only government-mined coins are good"

Sorry, you cannot bend Bitcoin to your socialist dream. If you want something like that, go make SocialistCoin.

cgminer also supports scrypt now

I have been wondering on this topic since about a month after I opened the pool
whoever solves this could become very wealthy

We have a huge resource thats great for sha256, how can we use this resource for other applications. And more importantly how do we sell this to the market we identify
"Hi I have a bunch of home computers in a distributed computing network, can I sell you some hashpower" - sounds legit

Well if you are using cgminer - you can check on the FPGA's with the API (I wrote the API)

But that only tells you info from what cgminer knows, it won't know about the leds on the CM1
(NFI if you can even get that info from a CM1)

However, relying on U is not ideal ...
U is random - and can drop and rise - however, it should normally stay within 10% of the expected value after an hour or more runtime.
But there is no guarantee it will (independent of MH/s)

Really you should be tuning the parameters (--icarus-timing and --icarus-options) to cgminer and make sure the MH/s value is correct.
"--icarus-timing long" would keep the performance correct as long as the machine it's running on isn't CPU starved in any way

I'd go as far as saying that there is actually no reason that MH/s should be wrong any more if you use the correct parameters
... though, even that takes a while to settle, since the device reports results back at a different timing to the MH/s calculations so it takes a while

What are your per worker U values? U=17.5 on 2 boards looks like 1 fpga isn't hashing which is a common issue with that bitstream.