| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
Accurately Measuring Drive RPM
To bring the discussion from 1541 Speed Test into the forum....
first lets recapitulate:
The general idea is: have a "marker" on a track, then measure the time for one revolution using timers. Generally there are different ways to achieve this:
- wait for the marker and toggle a IEC line. the C64 measures the time using CIA timer. this is what eg the well known "Kwik Load" copy does, the problem is that it is PAL/NTSC specific, and it can never be 100% exact due to the timing drift between drive and C64.
- wait for the marker and measure the time using VIA timers on the drive. the problem with this is that VIA timers are only 16bit and can not be cascaded, so you either have to measure smaller portions at a time, or rely on the wraparound and the value being in certain bounds at the time you read it.
now, to make either way slightly more accurate, a special kind of reference track can be used. typically this track will contain nothing except one marker - which makes the code a bit simpler and straightforward. this is what 1541 Speed Test does. the DOS also does something similar when formatting, to calculate the gaps. This obviosly has the problem that we are overwriting said track.
Now - the question isn't how to do all this, that's a solved problem. The question is, given a specific implementation, how *accurate* is it actually, and why?
The basic math to calculate the RPM is this:
expected ideal:
300 rounds per minute
= 5 rounds per second
= 200 milliseconds per round
at 1MHz (0,001 milliseconds per clock)
= 200000 cycles per round
to calculate RPM from cycles per round:
RPM = (200000 * 300) / cycles
two little test programs are here: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/dri.. ... the first reads timer values between each sector header and then the total time for a revolution is accumulated from the delta times. the second leaves the timer running for one revolution and then indirectly gets the time for a revolution from that. to my own surprise, both appear to be accurate down to 3 cycles (in theory the second one should be more accurate, at least thats what i thought. i also expected some more jitter than just 3 cycles)
1541 Speed Test writes a track that contains one long sync, and then 5 regular bytes which serve as the marker. it then reads 6 bytes and measures the time that takes, which equals one revolution. somehow this produces a stable value without any jitter, which was a bit surprising to me too (i expected at least one cycle jitter, due to the sync waiting loops) (i am waiting for the source release and will put a derived test into the vice repo too)
So, again, the question is... how accurate are those and why? (a stable value alone does not tell its accurate). Some details are not quite clear to me, eg if we are writing a reference track, how much will that affect the accuracy of the following measurement? how will the result change when the reference track was written at a different speed than when doing the measuring? Will using a certain speedzone make it more or less accurate?
Bonus question: can we use https://en.wikipedia.org/wiki/Chinese_remainder_theorem with two VIA timers to make this more accurate? or is it a pointless exercise? |
|
... 263 posts hidden. Click here to view all posts....
|
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazDo you realize Krill pretty much acknowledged what i wrote in #30? Sure he did. And do you realize you (or anyone else) were not able to implement it right? At the time I released my program there was no accurate program released.
Please, really, stop this. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
It doesnt matter who implemented what. The thread is about theories and methods, not someones code.
But now that you acknowledge that what i wrote in #30 is actually correct, you might want to reread some of the thread. It's a step forwared afterall. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting CopyfaultJust a thought: couldn't it be done by using an auxiliary timer that "measures" the potential variance?
Something like:
1. start a 3-cycle-timer (running continously)
2. wait for sync
3. start main timer (used for speed calculation later) + in the same moment(=directly after main timer start) save the value of the aux timer as a reference value
4. wait for sync
5a. calculate the speed with the main timer
5b. calculate the differnce between the current value of the aux timer and the ref value stored before (this should be the variance)
Thought about such an approach as well, but i think it falls flat due to the fact that the bvc polling loop has a given granularity of N = 3 cycles.
You start an aux timer before the loop, run for N * 3 cycles, then read the aux timer. It will have run for N * 3 plus a constant number of cycles and not tell you anything below that granularity.
What might work is controlling a cycle-counting timer in hardware via the byte-sync signal, but afaik there is not such facility in the 1541. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazIt doesnt matter who implemented what. The thread is about theories and methods, not someones code.
But now that you acknowledge that what i wrote in #30 is actually correct, you might want to reread some the thread. It's a step forwared afterall. If all it takes to make you shut up and free this thread from your useless comments is to aknlowledge that your obvious theoretical statements were true: for sure they were.
But what counts for me is code. Code that works. Reliable code. (And a pleasant output too). |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting KrillThought about such an approach as well, but i think it falls flat due to the fact that the bvc polling loop has a given granularity of N = 3 cycles.
You start an aux timer before the loop, run for N * 3 cycles, then read the aux timer. It will have run for N * 3 plus a constant number of cycles and not tell you anything below that granularity.
What might work is controlling a cycle-counting timer in hardware via the byte-sync signal, but afaik there is not such facility in the 1541. Same here. Another approach was to write one bit more. The last byte read will be different if there was a jitter. Doing so I redeuced significantly the jitter in another version but at the time something was not working.. don't remember what. But I think that also could be an interesting approach. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
Quote:If all it takes to make you shut up and free this thread from your useless comments
if you wont mention again you were the first to implement something, and wrote the only stable program (which is metastable but ok), perhaps. but i doubt it :)
Quote:But what counts for me is code. Code that works. Reliable code. (And a pleasant output too).
Make a seperate thread for code praising then, please. This thread is about methods and theories and the accurracy of said methods. Thanks. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Groepazgne gne gne gne gne gne
https://www.youtube.com/watch?v=kMsrE-9CLFg |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting ZibriAnother approach was to write one bit more. The last byte read will be different if there was a jitter. Doing so I redeuced significantly the jitter in another version but at the time something was not working.. don't remember what. But I think that also could be an interesting approach. Per-bit update without byte granularity works by disabling the latching in the VIA, and that in turn only works on long-board 1541 (or Oceanic). 1541-II with gate-array instead of discrete glue logic will always only give you byte by byte. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting KrillQuoting ZibriAnother approach was to write one bit more. The last byte read will be different if there was a jitter. Doing so I redeuced significantly the jitter in another version but at the time something was not working.. don't remember what. But I think that also could be an interesting approach. Per-bit update without byte granularity works by disabling the latching in the VIA, and that in turn only works on long-board 1541 (or Oceanic). 1541-II with gate-array instead of discrete glue logic will always only give you byte by byte. Good to know. I didn't know that.
I thought that after a CLV, counting cycles I could get the shifted-in bit (on 1541 works) didn't know about the others. |
| |
sailor
Registered: Jan 2002
Posts: 90 |
Sorry for off topic, but would you elaborate your thoughts on the following: (from the docs)
Quote: F3 align the head to track 42 in a better way than other programs do.
F5 moves the head to track 1
How to correctly align a drive:
1) gently unscrew the screws of the track 1 "stop"
2) press F3
3) press F5
4) gently move the track 1 block so there is 0.25 mm (a hair or little more) between the block and the head the head.
5) screw the screws tight carefully checking the block is still at 0.25mm from the head.
|
| Previous - 1 | ... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | ... | 28 - Next |
