What if the disk had some custom loader (like krill or the other one with even custom GCR?!).
For the time being and until proven without a doubt or at least until a sound theory is presented, we can regard the discussed drive-side methods as equal. They measure the duration of a revolution with a fixed reference clock counting from a fixed reference point (angle) on the disk to the same point a revolution later. They will produce a 2-cycle jitter (3 cycles variance), due to the bvc *, on top of the 16 MHz oscillator's tolerance (which has the bigger part in that), on top of natural rotational wow/disk wobble/flutter (probably the biggest part in that). Any deviation from that would be caused by implementation flaws (e.g., timer handling bugs), meta-stabilities, emulator side-effects, or implementation differences (such as converting cycle counts to a float RPM value using different conversion/averaging algorithms). Now, although somewhat pointless, getting rid of the 2-cycle jitter might be achievable by a half-variance technique operating on 2 additional byte-sync points, quite similar to syncing drive and host CPU in a fastloader with a synchronous transfer protocol. Quoting ZibriWhat if the disk had some custom loader (like krill or the other one with even custom GCR?!).Not sure which loader you're referring to, but running on plain standard format, both low-level and file system, is what i deal in with the public IRQ loader.
we can regard the discussed drive-side methods as equal
Any deviation from that would be caused by implementation flaws (e.g., timer handling bugs), meta-stabilities, emulator side-effects, or implementation differences (such as converting cycle counts to a float RPM value using different conversion/averaging algorithms).
This is also one of the basic techniques as used for stabilising raster routines. Depending on density (track zone), there are a nominal 26/28/30/32 cycles between two GCR bytes rolling in from disk. After having synced to the first byte using a plain "bvc *", delay according to density such that a "bvc * + 2" would take 2 cycles if byte-sync (branch not taken) or 3 cycles if no byte-sync (branch taken). We're now down to a one-cycle jitter. Repeat to get down to 0 cycles. Of course, the disk will keep on wobbling, so there is some error left.
My program writes at the lowest density using "00" clocks in 1c00 which is synchronous with the cpu clock.
I was expecting curiosity about this program and I even prepared a document which explains everything I learnt so far on the 1541 and some techniques rarely (or never) used before. Nothing fancy. Just the result of a few weeks of study, from the schematics up to ROM disassembly (most of online ROM disassemblies have a lot of logical errors inside). But after all this "drama" I really lost interest.
