About the R register on a real Z80:
But is the 8th bit actually used?
Yes, it's freely available and won't be touched by any instruction except loading R.
Is its behaviour undocumented or can it only be altered by loading it with a value from the accumulator
It's well documented and can be used as assumed. When loaded all 8 bits from A are stored in R - and likewise returned when A is loaded from R. Thus it can be used for example as 'secret' flag to store a single bit value.
which is used for some kind of software tricks?
Software (like above) as well as hardware. After all, it gets put on the bus in each M1 cycle during refresh, thus it may also be used as a singe-bit output port.
About emulated use:
Is there an even more convoluted reason? Some kind of compatibility with older snapshot file formats?
I do not have any hard evidence, only an educated guess based on why an emulator might want to handle them differently.
In Ye Olde Days (tm) computers weren't many thousand times faster than the emulated target, so it was a good idea to keep the instruction path needed to perform short - especially at the core points like instruction decoding.
When trying to emulate a Z80, the R register needs to be incremented with every M1 cycle. That's essentially every instruction as well as any prefix within. To handle R like on a real Z80, the op code fetch would have to
- select bit 7,
- save it,
- increment R,
- mask out bit 7 and
- reinsert the saved value.
Depending on the CPU the emulator was made for, this can be many operations.
Now, if Bit 7 is handled separately, R can be defined as a simple 8-bit unsigned integer and operation during M1 is reduced to
- Increment R (value at offset 11)
That's about as short as it can get. All other handling is postponed to the times R get transferred from or to A. When setting, Bit 7 will be selected and stored at offset 12 (*1), while reading means combining these two values into one and storing in A.
Even in tight programs these instructions occur rather seldom, so this optimization will speed up emulation notably.
File formats are often direct images of memory structures, thus the 'convoluted storage' may simply be an artefact of how the emulator was optimized.
Do some emulators actually use offset 11 bit 7?
Not really. It simply happens. As the documentation says: don't care. It's an artefact. Nice but meaningless.
I have at least one Manic Miner .z80 that has offset 11 bit 7 set but offset 12 bit 0 unset.
Well, this seams to be simply a side-effect of the mentioned optimization. When that snapshot was taken, R had already (at least once) overflown into bit 7.
*1 - Using bit 0 to store bit 7 seems somewhat odd at first, but it allows extraction and insertion with shift instruction.
To extract, the (source) value of A is first stored at location 11, then shifted right into carry (or another register) and stored at location 12.
For example on a 8086 this can be done in 3 machine instructions
* AL containing the value of Z80 register A
SHL AX * Extract the value of bit 7 to AH
SHR AL * Reconstruct value for storing
MOV AX,loc11 * storing both in Loc 11/12
(Shifting back and using a 16 bit store is faster than two 8 bit store instructions - even with misalignment.)
To restore it, the value from location 11 is shifted right again, then carry (or an upper byte, depending on the CPU used) is loaded and inserted per shift left.
For example on a 8086 this can be done in 3 machine instructions:
MOV AX,loc11 * Load location 11 in AL and 12 in AH
SHL AL * move one bit up to prepare for insertion
SHR AX * Insert bit 7 into AL, now containing the new value of A