| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
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 |
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: 11377 |
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: 11377 |
Actual datasheets for the parts used would be super interesting indeed.... i looked for this years ago, but couldnt find anything either. bummer. |
| |
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: 11377 |
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* |
| Previous - 1 | ... | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | ... | 28 - Next |
