| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
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 |
After some further testing of my program, I noticed that having 3 digits does not bring any useful information on a real drive.
Instead having 2 accurate digits is very useful to assess the belt, electronics and even the diskette friction.
I am interested following this discussion, but I see no way to do this without "averaging" more rounds and making the program slower.
One of the best features of my program is not only the accuracy but the short time to achieve it.
Together they are very useful to people testing and repairing drives.
The only program that was near to this was the speed test included in this program: http://blog.worldofjani.com/?p=2180
But, once I tested it in the emulator I found out it was not only slower but very inaccurate on the decimal digit. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Quoting GroepazThe double IRQ technique is not "half variance cascade". He refers to the technique of polling $d012 several times at the end of a line, comparing, and by that cutting the error in half each iteration
OK - then it's a different technique, which would work like - you handle IRQ of the line it was set to be triggered but then you get rid of the jitter by polling RASTER register for change a few (?) more lines, right? I need to check some examples of this out as I never did it this way. But in such case this might in fact be similar to polling V flag in 1541. I was having hard time fitting the "basic raster stabilising technique" the way I remembered it into the 1541 situation at hand. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Yes, only in this case you can do a new test every 26 cycles instead of every 63 :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting GroepazChristopherJam: would be really interesting to see a variant of yours that displays the full (non rounded) value and a value rounded to two decimals, like the programs in the test repo do :) Also some details on how the oscillator calibration works and how accurate it is etc pp
Well, you can kind of do that by hand already with the other two numbers displayed; it's just 60*(the number of c64 cycles per 1 million drive cycles)/(the number of c64 cycles per disk revolution)
As I mentioned earlier, I'm slightly surprised that was giving me a number about 0.01 RPM higher than whatever I was setting VICE to the other day when I did some quick tests.
My c64 cycles per disk revolution accuracy is about 5ppm, and the error in the cycles per million drive cycles has about 7 cycles jitter - so overall I'd expect an error of only about a dozen ppm. Looks like I've got some debugging to do at some point. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
Like i thought - it IS more accurate :=) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriInstead having 2 accurate digits is very useful to assess the belt, electronics and even the diskette friction.
I am interested following this discussion, but I see no way to do this without "averaging" more rounds and making the program slower.
One of the best features of my program is not only the accuracy but the short time to achieve it.
Together they are very useful to people testing and repairing drives.
Valid point.
Wouldn't it be useful to have both kinds of measurements, i.e a running average _and_ a separate single revolution measurement?
The first would be useful to adjust the speed and the second to assess if the belt and/or drive electronics are ok.
It could even be presented as a marker on a horizontal bar with and additional coloured field to see the variance. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting GroepazMore on topic... Taking the oscillator deviation into account (which we really have to do if we are talking about accurracy down to two decimal places) - wouldnt ChristopherJams program actually be *more* accurate than the other discussed methods? Sure they are more accurate in the measurement on the drive itself, in drive-cpu cycles - however, that doesnt mean much if we dont compensate for the deviation of the oscillator frequency (as soci very correctly brought up) - but ChristopherJams program does!
I would assume that the oscillator in the c64 is about the same accuracy as the drives oscillator though so it shouldn't make any difference. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting tlrI would assume that the oscillator in the c64 is about the same accuracy as the drives oscillator though so it shouldn't make any difference. On a PAL C-64, it's about 1.7 MHz faster than the drive's oscillator.
So, given the same tolerance in ppm, i guess you'd end up with ever so slightly more accurate results. :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: Quoting tlrI would assume that the oscillator in the c64 is about the same accuracy as the drives oscillator though so it shouldn't make any difference. On a PAL C-64, it's about 1.7 MHz faster than the drive's oscillator.
So, given the same tolerance in ppm, i guess you'd end up with ever so slightly more accurate results. :)
Perhaps. :)
I tried to find some specifications on early 80's oscillators and crystals a couple of years ago but gave up. There could quite some difference in tolerance between the 16 MHz oscillator module in the drive and the discrete oscillator in the c64. Especially if the module operates in overtone mode. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
Actual datasheets for the parts used would be super interesting indeed.... i looked for this years ago, but couldnt find anything either. bummer. |
| Previous - 1 | ... | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | ... | 28 - Next |
