| |
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....
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
I must admit, I mostly did the measurement that way because I a) wanted to know how consistent the drive:C64 clock speed ratio was from one scener’s setup to the next, and b) couldn’t be arsed digging up or or coding a routine to send numbers from the drive to the c64.
Any miniscule improvements in accuracy were just a bonus :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting KrillThis is also one of the basic techniques as used for stabilising raster routines.
Depending on density (track zone), there are a nominal 26/28/30/32 cycles between two GCR bytes rolling in from disk.
After having synced to the first byte using a plain "bvc *", delay according to density such that a "bvc * + 2" would take 2 cycles if byte-sync (branch not taken) or 3 cycles if no byte-sync (branch taken). We're now down to a one-cycle jitter. Repeat to get down to 0 cycles.
If we accept writing a test track, perhaps this could be done by a carefully crafted sync pattern?
You'd write something like '111111111111 010 111111111111 010 111111111111 010...'. When this is read, whenever there are 10 * '1'-bits in the shift register the sync bit in $1c00 will be set, generating a squarish pattern. This pattern could then be used to stabilise to a single bit using the suggested technique.
The actual duty cycle can be adjusted by increasing the number of sync bits and/or the number of bits in between.
Would this work the same on different generations of the hw?
EDIT: would also make a pretty brutal copy protection scheme. ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
Wasnt there some protection doing something similar? MMmmh.
I thought you'd set up a timer that underflows say 50 cycles (much more than a byte takes), then you read a byte and add/sub from the timer value alternating values until you are at perfect zero after reading (maybe more than one) byte. *shrug* |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting GroepazWasnt there some protection doing something similar? MMmmh.
I thought you'd set up a timer that underflows say 50 cycles (much more than a byte takes), then you read a byte and add/sub from the timer value alternating values until you are at perfect zero after reading (maybe more than one) byte. *shrug*
The point wasn't the protection bit. The point is that you can generate a squarish pattern on the msb of $1c00, perhaps allowing a simpler way of cycle exact synchronization. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
Yeah it might be easier, of course. I'm still thinking along the lines of just reading an arbitrary track (sector headers). Why go the easier route when you don't have to? :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Fair enough. :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
IMHO:
Whatever could be the error of a quartz is totally irrelevant to the RPM calculations.
Even the worst quarts loose or gain a few seconds per year. Not only we are talking about measuring 200milliseconds but the quarts real frequency is divided by 16 (iirc).
Writing a test track: https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm.prg
Or not writing a test track: https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm3wr..
Give exactly the same result. (the first one is more reliable since he knows the track is written correctly, while the second "wrong" one assumes (hence the "wrong") that track 35 is formatted and never written to.
Any accuracy below the 2 digits is not enough to assess the status of the belt or mechanics and disk.
Any accuracy over the 2 digits does not add any useful information and will just induce more latency.
Just fyi, the "wrong" version was tested even with disks formatted by a drive whose speed was 290RPM at the time of formatting and still showed the right speed before and after the tuning. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
Quote:Even the worst quarts looses or gains a few seconds per year.
wat.
you should re-read the thread perhaps. the deviation you can expect from the quarz results in almost 10 times bigger error than your supposed 3 cycles jitter. soci was quite correct with what he said. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting ZibriIMHO:
Whatever could be the error of a quartz is totally irrelevant to the RPM calculations.
Even the worst quarts loose or gain a few seconds per year. Not only we are talking about measuring 200milliseconds but the quarts real frequency is divided by 16 (iirc).
Dividing the frequency by 16 doesn't change the percentage error. If it's 20-30ppm before you divide by 16, it's 20-30ppm after - in either case that's going to be bigger than the 10ppm error you get from 2 cycles jitter on a measurement of a ~200,000 cycle time period
Quote:Just fyi, the "wrong" version was tested even with disks formatted by a drive whose speed was 290RPM at the time of formatting and still showed the right speed before and after the tuning.
Every version of any tool that determines RPM by timing one or more full rotations of the disk (ie any of the releases by you, Groepaz or I under discussion) will be unaffected by the speed of the drive used to write the track being read, regardless of whether it's a special track or just whatever data is already there.
It's still a 360 degree rotation each time a marker or selected sector sails by.
I'd have been a lot more surprised if you'd manage to get a *wrong* answer from a disk that was written at a different speed, that would be quite special :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ChristopherJam
I'd have been a lot more surprised if you'd manage to get a *wrong* answer from a disk that was written at a different speed, that would be quite special :)
Well, I didn't do the math but since I read (past tense) 6 bytes, I thought that if a drive is really slow it could mistake 5 bytes for 6... but I think it should be so slow that this thought was just theoretical.
Anyway, Just to be on the safe side, I wrote a new version:
It uses a slightly different way to measure the speed.
It uses track 36 if writing is enabled and track 35 if writing is disabled.
(But in this case it expects track 35 to be formatted and empty and never written)
It is still as fast as before.
It is still as accurate as before.
It has been tested on at least 20 different drives and the speed reported by my program was compared to the speed read optically by the strobe "disc" printed on the motor spindle.
If anyone has a better way to check (by instruments) the motor speed we can do the final tests but I am pretty confident there will be no difference.
I undesrtand your theoretical thoughts about quartz tolerances but empirically I can tell that so far it has been proven to be very accurate.
If you want to test it, here is the new version.
https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm4.p..
...but I still think the first version is perfect... |
| Previous - 1 | ... | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | ... | 28 - Next |
