I essentially piled hacks together until it was capable of loading the broadest range of iffy CSW files.
b-em CSW loader: https://github.com/stardot/b-em/blob/d5 ... csw.c#L148
BeebEm CSW loader: https://github.com/stardot/beebem-windo ... w.cpp#L477
beebjit's original approach was similar to b-em and BeebEm, and very simple: look at each half wave length, sequentially, in the CSW file and decide if it's a "0" bit (1200Hz), "1" bit (2400Hz).
Code: https://github.com/scarybeasts/beebjit/ ... csw.c#L111
beebjit's original approach differed from b-em and BeebEm because it was actually pickier in two regards:
1) It checked all CSW half lengths in any bit, requiring each to be "in range". For a "0" bit there are 2x half waves checked and for a "1" bit there are 4x half waves checked. Both b-em and BeebEm look at one half wave only and then skip either 1 or 3 half waves depending on if it's a "0" bit or a "1" bit.
2) The tolerances for acceptable half wave lengths were tighter:
https://github.com/scarybeasts/beebjit/ ... _csw.c#L11
Both b-em and BeebEm, by contrast, appear to differentiate with the simple "<= 0xD".
So the original beebjit CSW loader was less capable of loading wobbly CSWs than b-em or BeebEm.
The heuristic changes applied over time were:
1) Assess the half wave lengths as a sum, not individually. This smooths out any localized wobbles:
https://github.com/scarybeasts/beebjit/ ... 3c52338cd8
2) Fiddle with the exact threshold for detecting a 2400Hz half wave. This is important to lock on to the correct phase at carrier -> data transition.
As can be seen in this change, I also started being more disciplined about collecting and checking in interesting CSW test cases.
https://github.com/scarybeasts/beebjit/ ... fa6be6fbc2
3) Have two different "0" bit bit detection thresholds based on whether the state is in data or in carrier.
This was necessary to get the phase correct at the carrier -> data transition for borderline cases.
https://github.com/scarybeasts/beebjit/ ... d394c16232