| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
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 ChristopherJamHah! You're not telling me anything that I didn't already write in my comment :P
I did mention that I'm reading 0.01 RPM higher than actual, and I praised you for the speed of your tool. Please read what people write before you respond.
Besides, to one decimal place, 280.0 is correct.
For you it is. For my own personal challenge which was to code the most accurate and fast program to help some friends of mine in repairs and assessment, that is unacceptable.
To everyone else:
since you are so strongly against the writing of a track,
I coded also a second version which I called "rpm2wrong.prg" which does not write anything and assumes
the disk in the drive was formatted by the same drive doing the tests.
It is as accurate as the previous one.
But it is totally "wrong". |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1390 |
Once again, Zibri reads a single line of a multi line comment, this time even though it was only three lines long...
and this time skips over the first half of the sentence.
Zibri, go back again, and read the part that says "to one decimal place." |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ChristopherJamOnce again, Zibri reads a single line of a multi line comment, this time even though it was only three lines long...
and this time skips over the first half of the sentence.
Zibri, go back again, and read the part that says "to one decimal place."
Go back and check your "one" decimal place in the screenshot. It is WRONG, the decimal and the whole read.
And it is obvious why.
In my opinion your program is mostly useless.
Not only because it's not precise.
But because it gives absolutely no useful information.
With your program you can't tune the drive speed.
You can't assess the status of the belt.
You can't check the raising speed found in drives that need to be recapped. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1390 |
I'm wondering if there is a language issue here?
If you were to round 279.99 to one decimal place, the closest result is 280.0
If my utility had reported 279.9 then it would have been out by 0.09RPM. 280.0 is only out by 0.01, hence is a more accurate answer to give (again, assuming only reporting to the nearest tenth of an RPM)
Perhaps more pertinently though, 60*985256/211124 is 280.003 - so there is indeed something screwy going on. Perhaps it is for the best that I was only reporting to a single decimal place after all :D |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Here is a version for the whining people:
https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm3wr..
This "wrong" version does not write a reference track.
It's again 100% accurate. 100% stable.
I just preferred writing my own reference track so to make the program totally agnostic.
If you prefer this "wrong" version, be my guest.
Happy, now? Any other problems? You don't like the graphics? Whuld that be ugly as the others just to be accepted?
I really don't understand you guys.
My bad.
Note:
This versions works only on a normal, standard formatted
empty disk. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ChristopherJam
If you were to round 279.99 to one decimal place, the closest result is 280.0
That is called "approximation".
And approximation is what you do when you don't have an accurate result.
If you had, I bet you would have wrote another digit.
Also my program "approximates" but the result is, as I said many times, the most accurate and stable as of today in 40 yers.
That's it. That is what I wanted to do. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1390 |
Well, yes - your utility accurately reports to two significant figures, mine does to one significant figure.
They're both "wrong" if they measure a disk rotating at 279.995, but neither would be inaccurate to be stating 280.0 or 279.99 to the nearest tenth or hundredth of an RPM respectively. They are both as accurate as they claim to be.
I only take offense at your claim that mine is somehow "wrong" more often than yours is - they both do what they say on the tin, and yours provides more precision (again, not something I've ever disputed), but there are no drives in the real world that rotate at an exact multiple of 0.01 RPM! |
| |
SLC
Registered: Jan 2002
Posts: 52 |
@Zibri:
You don't respond well to any form of criticism it appears. Your routine may be accurate, but a lot of what you write comes out wrong. And your attitude sucks. Even flaws that actually is of concerns is brushed off as an attack on your precious code.
Also, making fuzz out of 0.01RPM... are you even aware how ridiculous that is? CJam's result is not an "approximation", it shows a real value which is rounded to the closest decimal. One decimal is more than enough accuracy to begin with. If someone made a solution that showed three decimals, yours would by your logic also become an approximation. Just stop it.
And regarding the things that others pointed out:
1. You mix up the terms alignment and track 0/stop-calibration. It gets pointed out, you defend it by people being "elite" enough to understand it rather than accept the correction.
2. Writing data to a disk without informing or asking the user is a bad idea. Even if you believe that most doesn't use track 36. You refer to the docs which have the warning, but you said you already assumed people being "elite" here. Why wouuld you then expect them to need to read the docs for a drive speed test!? Also keep in mind that many games may have protection data on track 36, and some actually load prg-files directly through ethernet or other means. Your program would then willingly just wipe protection data without telling the users. That's destructive behavior. You should really change that if you insist on this method. But again, you respond by becoming overly defensive rather than accept that it is a bad decision. |
| |
iAN CooG
Registered: May 2002
Posts: 3142 |
> many games may have protection data on track 36
well if someone uses an original disk to make some tests, he deserves to trash it, who with a sane mind would do that? =)
We can all agree that a warning before it starts testing should a better solution. |
| |
SLC
Registered: Jan 2002
Posts: 52 |
Sometimes you may want to use the actual disks you want to read for reference for whatever reason. Having no alignment disks I've several times used originals as reference for example (Though, I always write protect) |
| Previous - 1 | ... | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | ... | 28 | 29 - Next |
