Note that if you're working under the assumption that 3 reads is sufficient, and at least 2 are equal, then you really only need to do

*one* bytewise compare.

1. Presume that A = B or A = C or B = C:

2. If A = B then just take A or take B.

3. If A != B, then either A = C or B = C. Take C for either case (there is no need to actually compare).

The bytewise version is something like:

**Code:**

lda A

cmp B

beq end ; A=B, keep A

lda C ; A!=B implies A=C or B=C, keep C

end:

Also note that if A=B you don't even have to poll for C, which is a lot bigger savings than the comparision logic itself. (Also, if you're polling as you go, you don't need to store B or C either.)

Now, the presumption that at least two are equal could in theory be a false presumption, but given what tepples pointed out (i.e. a bit deletion invalidates the whole byte), I think it's as strong a presumption as you're starting with for the A/B/C bit-majority approach.

With the presumption that no more than 1 in 3 consecutive reads will fail, then they seem equivalently correct. Speed differences I think would be down to how often a deleted bit comes up. If you account for that, I think the bitwise majority approach is unfortunately the worst of these three:

1. Poll until 2-in-a-row: min 2 polls (common), max 4 polls (rare).

2. Poll A=B or C: min 2 polls (common), max 3 polls (rare).

3. Poll A,B,C bitwise majority: min/max 3 polls (always).

Though worth noting that there are some extremely rare edge cases where 1 could poll more (or many more) than 4 times, whereas the 2/3 will always terminate within 3 (whether "right" or "wrong"). Not really an issue unless you need to make severe restrictions about timing.

*Edit: after further consideration, the bitwise method definitely seems superior in the rare worst case. See below.*