Quote from: cscape on March 31, 2014, 04:47:34 AM

Quote from: ckolivas on March 30, 2014, 10:03:14 PM

Quote from: cscape on March 23, 2014, 04:04:46 PM

The protocol is exactly the same as for the bi*fury devices (and also the same for the One String Miner), so cgminer already supports them.

The code assumes 2 job queues so I assume you worked within that framework despite the extra chips?

Not sure where the 2 job queues come from, but the firmware internally uses a single queue with room for 4 jobs. That's the same on bi-fury and hex-fury. The only difference is that the hex-fury jobs are processed faster because there are more chips, but this should be transparent for the driver.

I wrote the driver for BXF aka Bi*fury at the time and while it sends enough work based on the request for more work, it stores data in its API assuming 2 chips exist because that's all the original devices had. As I said earlier, it probably only affects the data that's shown in the API. A string of invalid chip number messages in verbose mode and lack of debug support for the extra chips is likely the only consequence, but I don't know how many people ever looked at the API output of these devices which I originally added to aid debugging of which chip was doing what:

Code:

[STATS3] =>
(
   [STATS] => 3
   [ID] => BXF0
   [Elapsed] => 79099
   [Calls] => 0
   [Wait] => 0.000000
   [Max] => 0.000000
   [Min] => 99999999.000000
   [Version] => 1.2
   [Revision] => 1
   [Chips] => 2
   [NonceRate] => 0.663417
   [NoMatchingWork] => 0
   [Temperature] => 48.400000
   [Max DeciTemp] => 525
   [Clock] => 54
   [Core0 hwerror] => 598
   [Core1 hwerror] => 142
   [Core0 jobs] => 8458
   [Core1 jobs] => 8227
   [Core0 submits] => 5239
   [Core1 submits] => 5581
   [USB Pipe] => 0
   [USB Delay] => r0 0.000000 w0 0.000000
   [USB tmo] => 46161 0
)

EDIT: Shouldn't be hard for me to generically change it to as many chips are reported in chips, but I believe some earlier samples/firmware didn't report that so I'll add a workaround.