| |
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....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
OK. That means may program deviates by 3 RPM and the timer wasnt initialized by the ROM at all. again what learned!
Meanwhile someone with a clue provided a nice diagram - he measured the oscillator clock over time (deviation from 16Mhz on Y, seconds on X): https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/dri.. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: OK. That means may program deviates by 3 RPM and the timer wasnt initialized by the ROM at all. again what learned!
Meanwhile someone with a clue provided a nice diagram - he measured the oscillator clock over time (deviation from 16Mhz on Y, seconds on X): https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/dri..
No wonder your program was wrong if this the only thing you learned. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
Yes its wrong. You can see it clearly by how it has the exact same deviation as yours. Can you say it once more? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Yes its wrong. You can see it clearly by how it has the exact same deviation as yours. Can you say it once more?
I just see you copied my program concept and method.
Inspired my a$$.
both rpm2 and rpm3 were "inspired" by my program.
And again your program is total rubbish.
Run VICE: set the speed to 292.71 and run your "rpm.d64" program.
Total bogus values.
I told you and I repeat:
check all speeds btween 275.00 and 325.00 in increments of 0.01 and then see.
Not only you get wrong the last digit but you sometimes get wrong all of them and even the unit.
At 292.71 it even shows: 293.08 ! hahaha
My program does not that.
Why?
BECAUSE IT IS WELL WRITTEN. PERIOD. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
huahuahua
Your masterpiece:
https://pasteboard.co/JkYYmrT.png
my humble program:
https://pasteboard.co/JkYYOzE.png
:P
Really,
please, stop. If you don't understand why my program is correct, that's fine.
But as I told you there is no way to be accurate using different methods.
There will always be situations and values where any other program will fail.
And not mine.
The reason is how it is made.
Search the term "cognitive dissonance" to understand what you are going through. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
It's sad to see that this thread derailed. I'm really curious to read an explanation on what makes this new method superior with regards to accuracy/repeatability. I think ignoring counting the overflows because you know how many will occur within the useful range is kind of clever.
Also most speed tests I saw before used the approach to measure on c64-side which obviously has its limitations. Measuring on the drive-side is much better. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: It's sad to see that this thread derailed. I'm really curious to read an explanation on what makes this new method superior with regards to accuracy/repeatability. I think ignoring counting the overflows because you know how many will occur within the useful range is kind of clever.
Also most speed tests I saw before used the approach to measure on c64-side which obviously has its limitations. Measuring on the drive-side is much better.
Well, I never analyzed deeply other methods but the few I tried were using some drive side code.
The 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.
No other methods (unless derived by this one) will be as accurate.
And no other program writte in 40 years was.
That was my personal challenge.
And I find the rpm display beautiful and perfect for laboratory use since it can be read from far.
Also for how I wrote the program, front ends can be done even in basic and run on any computer from the VIC20 or PET to any other using these drives.
Obviously it even worked in VICE using a real drive connected to a laptop.
Note:
In all my tests, commenting the "skip data" does not alter the results nor give any jitter though |
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
Quote:I'm really curious to read an explanation on what makes this new method superior with regards to accuracy/repeatability.
same :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Yes its wrong. You can see it clearly by how it has the exact same deviation as yours. Can you say it once more?
Even your "inspired" rpm2.prg fails miserably my tests.
Set the speed of VICE to: 313.71 (with 0.00 wobbling)
And your second "inspired" plagiarism will anyway JITTER the second decimal digit.
I didn't test all possible values, but I had similar results with the early versions of my program until I understood the only good method is the one I used after that experience.
Your second "inspired" masterpiece:
https://pasteboard.co/JkZE3PK.png
My humble program:
https://pasteboard.co/JkZEMWF.png
:D |
| |
Jammer
Registered: Nov 2002
Posts: 1335 |
I won't be very constructive here but:
I had no fuckin' idea that thread about measuring drive RPMs might be THAT exciting :D |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 28 - Next |
