| |
chatGPZ
Registered: Dec 2001
Posts: 11165 |
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 GroepazQuote:The reading is not in sync with a clock, but with the written bits.
exactly. and every time 8 bits arrived in the shift register, V flag is being set to signal just that. in turn that means after every byte (BVC *) we are in sync (with 2 cycles jitter) to the bits on the disk. it doesnt matter how often we do this, every single time we are again in sync. if that wouldnt be the case, you wouldnt be able to read more than a couple bytes without an extra sync marker.
Yes, that is obvious, but I don't understand what you are trying to say.
Since we count the time, yes we are in sync, but it will take more or less time depending on drive speed.
But in that way you are anyway counting bytes.
That's unacceptable inaccuracy in my book.
I thought of counting bits, and it was ok, but the program was overly complex.
My final approach resulted to be the best.
I see no reason to change it. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11165 |
What i am trying to say is that there is no difference between how many bytes we are reading before starting and reading the timer, as long as we are doing it at the same angular position on the disk. How fast those bytes were written doesnt matter either, because our reference point to start and stop is still the same angular position on the disk. |
| |
tlr
Registered: Sep 2003
Posts: 1737 |
Quote: What i am trying to say is that there is no difference between how many bytes we are reading before starting and reading the timer, as long as we are doing it at the same angular position on the disk. How fast those bytes were written doesnt matter either, because our reference point to start and stop is still the same angular position on the disk.
I am puzzled by why this would make a difference too. A sector header is normally 40 bits of sync followed by a $52 byte, then 9 more bytes so the pattern isn't really that different. Would stopping reading the header after 5 bytes yield better accuracy? I'd love a better explanation! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11165 |
Quote:How fast those bytes were written doesnt matter either, because our reference point to start and stop is still the same angular position on the disk.
apropos, if that wasnt the case - then the exact same problem would exist with using a special reference track (unless you rewrite it all the time). |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quote:How fast those bytes were written doesnt matter either, because our reference point to start and stop is still the same angular position on the disk.
apropos, if that wasnt the case - then the exact same problem would exist with using a special reference track (unless you rewrite it all the time).
Wrong. Just wrong. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: I am puzzled by why this would make a difference too. A sector header is normally 40 bits of sync followed by a $52 byte, then 9 more bytes so the pattern isn't really that different. Would stopping reading the header after 5 bytes yield better accuracy? I'd love a better explanation!
Sorry but I don't follow.
Please write all program logic from start to end and I will tell you if it is sound or not.
From when you start the timer to when you stop it, I mean. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: What i am trying to say is that there is no difference between how many bytes we are reading before starting and reading the timer, as long as we are doing it at the same angular position on the disk. How fast those bytes were written doesnt matter either, because our reference point to start and stop is still the same angular position on the disk.
Same here. Show me the program logical flow, because I am getting lost in all this theoretical talking.
Anyway, what you read before starting the timer, depending how you do it could influence the ooutcome by starting the timer too early or too late (for example when reading SYNCs).
If you are talking about:
1) read sync.
2) check if sector 0
3) start timer
4) read sync
5) is it sector 0? no, goto 4
6) stop the timer.
That could work it just induces more problems than advantages and I can think of a few situations where this approach is unreliable: first of them all is that you don't know who formatted the disk and using what.
I can format a disk in a way that it works for DOS but will make such a program fail.
My program can't fail.
And that's why I coded it in that way. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11165 |
Quote:Wrong. Just wrong.
please explain why
Quote:Please write all program logic from start to end and I will tell you if it is sound or not.
it's all in post #30. please explain why not if. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Oh and I remind you,
my purpose when I wrote it was to write the most accurate program ever made and without needing a "master" pre-recorded diskette.
Then it became a tool also for aligning and help a few friends who fix drives to move the head around, align it and check the status of the rubber belt and capacitors.
When I will have my 1541 I will add a few more features which I can't test on the emulator.
Or maybe just do a different utility.. I don't know. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quote:Wrong. Just wrong.
please explain why
Quote:Please write all program logic from start to end and I will tell you if it is sound or not.
it's all in post #30. please explain why not if.
And ruin all the fun?
Do a program that does not write a test track.
A program without "value fixes" or special situation IFs.
And I will always be able to produce a disk that will make it fail.
Write a test track and that would never happen.
My program just can't fail and that was the purpose.
And I accomplished my own challenge.
And again:
My program is the most accurate ever made in 40 years at the time of release. It has no jittering, no errors and works flawlessly in all situations (if the drive is able to write and the disk is in average shape).
How can I make it clear to you that I am not interested in theorizing other alternatives since I found the best one in 40 years I am more than satisfied.
Now, I value comments like the one of Silver Dream (I didn't even know what Dolphin DOS was before he mentioned it).
And if there are any suggestion to further improve my program I am listening.
But I won't make my program bigger just to include warnings or idiot proofing when all people need to do is to RTFM (on github).
Have a nice day. |
| Previous - 1 | ... | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | ... | 28 | 29 - Next |
