| |
chatGPZ
Registered: Dec 2001
Posts: 11290 |
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....
|
| |
iAN CooG
Registered: May 2002
Posts: 3170 |
Jammer: I was about to post this gif myself in the release comment as soon as gpz wrote his reply but I said "nah, better refrain in pouring more gas in the fire" :D |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: I won't be very constructive here but:
I had no fuckin' idea that thread about measuring drive RPMs might be THAT exciting :D
LOL! Me neither :D |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Jammer: I was about to post this gif myself in the release comment as soon as gpz wrote his reply but I said "nah, better refrain in pouring more gas in the fire" :D
What fire? Oh.. you mean the one under gpz butt... hmmm maybe he eat something too hot...dunno :P |
| |
chatGPZ
Registered: Dec 2001
Posts: 11290 |
Quote:I didn't test all possible values, but I had similar results with the early versions of my program until I accidently reached metastability.
fixed |
| |
Jammer
Registered: Nov 2002
Posts: 1333 |
Quoting ZibriLOL! Me neither :D
I refer mainly to your purely narcissistic reactions which are really, really cringy :D With all respect to your knowledge on the field ;) |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
Quoting ZibriThe method has been already discussed but I can summurize it for you:
Test track creation:
1) create a test track made of all "1".
2) write 5 bytes (starting and ending with a 0) to the track.
Measurement:
1) skip "data" (not really needed but in a rare situation it can make the program fail)
2) read one byte and start (reset to FFFF) the timer.
3) read 5 bytes (the fifth will be the first we skipped)
4) stop the timer and send the value back to the front-end.
On the fron-t end side my program just subtracts 5 to the rotation time (because my program stops the time 5 cycles after the last read) then divide 6000000000 by the calculated time and get the integer part that will be 100 times the real value.
This is the method used and this is the only method that will give you this accuracy.
I understand the method, but I'd love an explanation on why it is more accurate.
When I've done speed tests in the past I've used the seek sector 0 appoach. Although it's obvious that your method of not actually checking the sync is different, it's not obvious to me as to why that makes a difference in result.
Quoting ZibriAnd I find the rpm display beautiful and perfect for laboratory use since it can be read from far.
I agree, the presentation is nice. |
| |
hedning
Registered: Mar 2009
Posts: 4696 |
I don't know shit about this, and should shut up, but I get strangly aroused by it, so keep on talking. :D
 |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quote:I didn't test all possible values, but I had similar results with the early versions of my program until I accidently reached metastability.
fixed
1) I never wrote such a thing.
2) I am not your beta (alpha) tester.
3) I don't agree with anything you said about this subject.
Sure you can use trick, fixes and patches. That happens when code is wrong.
My code has no fixes. No value corrections. It just counts right.
End of story.
I won't fuel anymore this useless debate.
I was hoping to find a different environment from which even learn something.
I just found some curious persons (and that's fine) and someone bragging without bringing a shred of code or evidente to his claims.
And filling the gaps with "I don't know why your program is stable or accurate" or other useless childish phrases.
I have to prove nothing to you or anyone else.
Prove my program is wrong or that there was a BETTER program before I released mine.
Or just shut up or continue this "debate" alone.
Bye bye |
| |
chatGPZ
Registered: Dec 2001
Posts: 11290 |
_I_ was bragging? =D
Quote:I understand the method, but I'd love an explanation on why it is more accurate.
When I've done speed tests in the past I've used the seek sector 0 appoach. Although it's obvious that your method of not actually checking the sync is different, it's not obvious to me as to why that makes a difference in result.
this. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Quoting JammerI had no fuckin' idea that thread about measuring drive RPMs might be THAT exciting :D
I thought of suggesting the continuation of this mesmerising thread inside new demos' scrolltexts :-) Wow - nostalgia... |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | ... | 28 - Next |
