I will start by saying that altsource_probe is not an efficient way to communicate with the FPGA, so there is little practical point in optimizing its usage. I occasionally use altsource_probe in my work because it is simple to use and quick to get working.
Could another 128 bits be added as a buffer for the next nonce?
I don't quite understand this question. There are two sets of altsource_probes in the Altera targetted designs. midstate_vw_blk and data2_vw_blk provide the input the mining core needs to mine. golden_nonce_vw provide a means for the mining core to report any gloden nonces it has found (nonces which result in a share that can be submitted to a mining pool).
The way that code is designed (specifically,
this code), is that any found golden nonces are written to (and thus overwrite) the golden_nonce register. When the host computer reads the golden_nonce_vw_blk altsource_probe, it's just reading the golden_nonce register. There's no buffering or anything. So in the current design, there's no way to buffer results. Like I mentioned at the beginning of this post, this isn't meant to be efficient; just quick and simple.
What are the 384 bits for prior to the nonce and buffer?
Are you referring to
this line? Remember, all a miner is really doing is SHA-256 hashing a block header. SHA-256 requires that the input data be padded out to a multiple of 512-bits. On that line, the 384-bits are the padding that gets added to the block header. They are constant, no matter what block header is being hashed, because all block headers are (currently) the same size.
