| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
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 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
Quote:And I will always be able to produce a disk that will make it fail.
that's totally out of scope of the discussion. of course we are assuming a standard DOS formatted disk. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Groepaz
it's all in post #30. please explain why not if.
I will try again to explain it but you seem not to be willing to listen to a simple fact:
If you don't write the track yourself, you are assuming it's fine, which it can be wrong.
In any laboratory test, the conditions of the test must be known and verifiable.
To do so usually a "master disk" written by very precise drives, is used.
My program creates such a measuring track so to have a reference that is SURE is as it is intended to be.
Anyway, until now I still haven't seen a program able to determine RPMs in a reliable way (and not just in emulators).
Not useful, perhaps. But I liked the challenge. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriSame 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.
Exactly. The timer should be started after reading the header as you write, so that would be after a bvc *. This is how the tests I examined worked, and also how I chose to implement mine in the past. Most of them (including mine) measured timing c64-side though so the accuracy would obviously be much less because of that.
The obvious advantage of this appoach is that it works without writing to the disk. The downside is, like you point out, that it won't work with a very out of range rotational speed or malformed diskette formatting. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quote:And I will always be able to produce a disk that will make it fail.
that's totally out of scope of the discussion. of course we are assuming a standard DOS formatted disk.
Never assume. There are fast format program who format a "working" disk which is far from standard anyways.
It's not out of scope at all.
To be precise:
your "approach" would work if your program will also format a disk in a very standard way.
In the end it will be slower and trash an entire disk.
I opted for writing a simple test track. I could even reformat a standard track but it would have been the same.
A waste of time and resources when a simpler approach solves all problems without any downside. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
It will work fine whenever there is exactly one sector 0 header on the tested track. doesnt matter how it was written at all, because the last bvc * is the reference point. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlrThe downside is, like you point out, that it won't work with a very out of range rotational speed or malformed diskette formatting.
And that's why all professional tools use a master disk.
Mine creates such a track without the need of a pre-mastered disk.
Also, it creates the track in a "smart" way that is very easy to manage and that leaves no space to errors. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriI can format a disk in a way that it works for DOS but will make such a program fail.
This is kind of interesting, how? Multiple sector 0 headers on the track? That would be kind of evil but assuming nothing on the disk references sector 0 of that particular track it could work fine in DOS i guess. :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazIt will work fine whenever there is exactly one sector 0 header on the tested track. doesnt matter how it was written at all, because the last bvc * is the reference point.
Again: you seem not to care about the implications. I did.
What if the track is not even formatted? What if the disk had some custom loader (like krill or the other one with even custom GCR?!).
Please, stop this discussion.
You assume a lot of things. My program is agnostic.
As I am. |
| Previous - 1 | ... | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | ... | 28 - Next |
