| |
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....
|
| |
Comos
Registered: May 2004
Posts: 73 |
Quote: tlr: CF also suggested to look for prior art the other day ... indeed, there were a bunch of other tools. would certainly be interesting. perhaps start look at the usual suspects (basement boys?)
Howabout the drive aligment from FreeSprit Software,which can also measure the drive speed.However that one is PAL/NTSC dependant. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: Howabout the drive aligment from FreeSprit Software,which can also measure the drive speed.However that one is PAL/NTSC dependant.
Free Spirit report 310/320 rpm on pal machines and need his reference disk. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: Free Spirit report 310/320 rpm on pal machines and need his reference disk.
Vorpal has a test as well but I think that also requires a reference disk. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
for reference, this is the one I had: Kwik Load (NTSC only) |
| |
Copyfault
Registered: Dec 2001
Posts: 476 |
Quoting tlrIt would be interesting to see which different approaches various speed tests used. I could have sworn I saw one measuring drive-side before but couldn't find it. [...] As Groepaz already mentioned I was thinking of a thread here on csdb which was about people doing measurements of their real drives and posted certain schemes of the measurement.
After digging through the complete csdb (ok, not;)), I found it: Release id #160665 : Stepper Test 1.0
So *if* enough people are willing to do this once more, we could start a measurement session with all the speed test programs currently available. This would further clarify what is meant with metastability and hopefully lead the discussion into a more constructive direction. |
| |
Comos
Registered: May 2004
Posts: 73 |
Quote: Vorpal has a test as well but I think that also requires a reference disk.
yep,this is mentioned on a inlay paper.
The reference disk is on the other side, if someone owns the orie.But as a reference disk a original CBM demo disk could be used aswell. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
For most of those the "reference disk" probably just contains a standard duplicator written track... because thats really good enough :) (For alignment purposes its a different matter) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Copyfault
So *if* enough people are willing to do this once more, we could start a measurement session with all the speed test programs currently available. This would further clarify what is meant with metastability and hopefully lead the discussion into a more constructive direction.
I tested a few programs before deciding to write my own.
None seem to have accurate results and some failed because they needed a real (original) reference disk.
I guess the reference disk was a disk written with a "direct drive" diskdrive, with no wobbling and electronically controlled motor speed.
Those reference disks were good to check head alignment (but this must change in the future) but overkill for speed asessment.
Also, as Krill pointed out, most inacuracies were introduced by bad programming and at the time it was not as easy as today to see such mistakes.
Today, with emulators you can "freeze time" and check everything both on c64 side both inside the drive.
Freezing time was partly possible with cartridges but it was not possible to freeze a drive in time.
That led to all kinds of quirks and errors. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting Comosyep,this is mentioned on a inlay paper.
The reference disk is on the other side, if someone owns the orie.But as a reference disk a original CBM demo disk could be used aswell.
Ok, good to know. Didn't seem to work in emulation, but maybe I missed something. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlrQuoting Comosyep,this is mentioned on a inlay paper.
The reference disk is on the other side, if someone owns the orie.But as a reference disk a original CBM demo disk could be used aswell.
Ok, good to know. Didn't seem to work in emulation, but maybe I missed something.
I get 299.78 in the emulator with wobbling set to 0.
Meh. |
| Previous - 1 | ... | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | ... | 28 - Next |
