[CSDb] - User Forums - Accurately Measuring Drive RPM

Welcome to our latest new user Critikill ! (Registered 2024-09-19)

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Accurately Measuring Drive RPM

2020-08-03 16:07

chatGPZ

Registered: Dec 2001
Posts: 11290

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....

2020-08-04 18:56

Copyfault

Registered: Dec 2001
Posts: 468

Oh, oh, this disucssion went astray :(

@Zibri: don't get mad about this. My guess is that this thread was opened for the exact same reason you already started to write your document for. The questions put up by Groepaz were just born out of the curiosity on how to properly "compare" tools, in this case tools for testing the speed of floppy drives AND on the principles that are applied and their properties.

As I put it in the comments on your speed test tool: it's nice to have "competition" on the tools' side also these days. Maybe the word competition sparked wrong feelings; if so, I apologize for it! The c64 scene tends to get an understanding for literally everything in utmost detail (imagine the opposite, would we still be watching only standard scrollers as demos;)?).

So my suggestion is to take it as an honour that this thread was started - your work was the ignition for it and it shines even more that it's not only a nice piece of sw but also a starting point to understand even more!

2020-08-04 19:27

chatGPZ

Registered: Dec 2001
Posts: 11290

wow, just wow.

2020-08-04 21:54

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: Oh, oh, this disucssion went astray :(

@Zibri: don't get mad about this. My guess is that this thread was opened for the exact same reason you already started to write your document for. The questions put up by Groepaz were just born out of the curiosity on how to properly "compare" tools, in this case tools for testing the speed of floppy drives AND on the principles that are applied and their properties.

As I put it in the comments on your speed test tool: it's nice to have "competition" on the tools' side also these days. Maybe the word competition sparked wrong feelings; if so, I apologize for it! The c64 scene tends to get an understanding for literally everything in utmost detail (imagine the opposite, would we still be watching only standard scrollers as demos;)?).

So my suggestion is to take it as an honour that this thread was started - your work was the ignition for it and it shines even more that it's not only a nice piece of sw but also a starting point to understand even more!

@Copyfault: Apologize? You did absolutely nothing wrong!
I know how the "scene" works.. I have always been "behind the scenes" in the past. believe me, I am not mad at all. A few people know me personally and they know I almost never get mad at someone and for sure not for a so little "skirmish".
I tried just to suggest (repeatedly) to gpz (by the way my initials are pgz hahahah) to take things a little more maturely because a "sane" competition is very healthy but saying "my program has only a minor jitter" or that my program (which he admittedly didn't understand) has something wrong. If I wrote it is, as I said, as an exercise and because after searching I didn't find any program that did the same in an accurate way.

About the how I did it, for non technical people the explaination is sort of long, but for you people I thought it was enough to say that I write a full long sync track and then I write 5 "5A" bytes on it and then I time the read of 6 bytes.
And no matter how slow or fast a drive is. It will always time a full revolution.
As most good things, in the end was a very simple solution, it just took 3 weeks of studying from the chematics to the ROM to learn as much as I could about it.

Ok let's play a different game: without disassembling my program, how would position the head on a track using DOS and not a custom $1c00 routine?

In my study I found two different ways, but one is "blind" and allows half track movement (but is not "dos" compliant) the other one is fully dos compliant and it was meant that way by commodore but I could not find it anywhere.

In stead there aother things I found by studying it.
Things that could lead to some proof of concept demos and maybe a better way to copy disks (but this is yet to be seen.. I am waiting to receive a 1541 to do further testing which I can't do in emulators)

2020-08-04 22:05

chatGPZ

Registered: Dec 2001
Posts: 11290

So will you contribute anything to finding the answer to the question of how big the standard deviation of either program is, or will you keep repeating how good your code is and how mine sucks (all 3 cycles jitter make it totally useless, everyone got this now)?

2020-08-05 00:21

Copyfault

Registered: Dec 2001
Posts: 468

Quoting Zibri

@Copyfault: Apologize? You did absolutely nothing wrong!
I know how the "scene" works.. I have always been "behind the scenes" in the past. believe me, I am not mad at all. A few people know me personally and they know I almost never get mad at someone and for sure not for a so little "skirmish".

Good to read;) So I take it you are not too shocked about all the discussion.

Quoting Zibri

I tried just to suggest (repeatedly) to gpz (by the way my initials are pgz hahahah) to take things a little more maturely because a "sane" competition is very healthy but saying "my program has only a minor jitter" or that my program (which he admittedly didn't understand) has something wrong. If I wrote it is, as I said, as an exercise and because after searching I didn't find any program that did the same in an accurate way.

Hmmm, I think not every detail on how the differences between your and gpz code influence that jitter (and thereby the accuracy) has been fully understood. Pointing out how good a routine is or blaming the other one does not help in that. Or to put it in other words: your test prog seems hyper accurate, but the core reason for this is unclear to some (most?) people;)

Quoting Zibri

About the how I did it, for non technical people the explaination is sort of long, but for you people I thought it was enough to say that I write a full long sync track and then I write 5 "5A" bytes on it and then I time the read of 6 bytes.
And no matter how slow or fast a drive is. It will always time a full revolution.

This is another thing that at least I do not fully understand: is it really independant of the drive's speed? Or even more precise: if the test track gets written by a drive that is considerably slower (or faster resp.) than the one that is used for reading, does this have influence on the value the routine computes?

Quoting Zibri

[...]Ok let's play a different game: without disassembling my program, how would position the head on a track using DOS and not a custom $1c00 routine?

In my study I found two different ways, but one is "blind" and allows half track movement (but is not "dos" compliant) the other one is fully dos compliant and it was meant that way by commodore but I could not find it anywhere.

Just as Groepaz I have to admit I'm not really into drive code, but I'm nontheless interested in understanding underlying methods;) I bet it's just the very same for gpz!

Quoting Zibri

In stead there aother things I found by studying it.
Things that could lead to some proof of concept demos and maybe a better way to copy disks (but this is yet to be seen.. I am waiting to receive a 1541 to do further testing which I can't do in emulators)

I'm really looking forward to these proof-of-concept-demos!!! Let's see what it will lead us to...

2020-08-05 00:54

chatGPZ

Registered: Dec 2001
Posts: 11290

After some more discussing with someone who really knows this stuff much better than i do (and who may or may not speak up here) we came to the conclusion that actually, there isnt much of a difference between the two methods/programs.

First, i have made a testprogram using the method with writing a test track and reading 6 bytes (see in the above linked repository). I did not copy Zibris code 1:1 but made some more or less trivial changes to make it more readable and to not rely on the ROM initializing the timer. However, none of those changes affect the timing/accuracy (only a few more or less cycles to compensate, but that doesnt matter). However, the result was that now the program also shows 3 cycles jitter in VICE (as i expected from the start, and wondered why it is not there). The reason is very likely that before it was metastable in VICE (since the drive CPU clock and the rotation are in perfect sync in the emulation, there can be cases where code is in perfect sync with the disk and shows no jittering at all - but this will never happen on real hardware).

Now, what causes the jittering in the code is the waiting for "byte ready", typically done by a BVC * - after that the code is in sync with the disk data, jittering 2 cycles.

What Zibris code does is basically this:

- wait for sync
- read a byte (now we are jittering 2 cycles)
- reset the timer
- read 5 more bytes (after that we are again jittering 2 cycles)
- read the timer

What my code (rpm2, lets ignore the first version for a while) does is

- wait for sync
- read a byte (now we are jittering 2 cycles)
- check if this is a sector header, if not repeat
- if yes read the header, check if it is sector 0, if not repeat.
- at this point the jittering is still 2 cycles
- reset the timer
- wait for sync
- read a byte (now we are jittering 2 cycles)
- check if this is a sector header, if not repeat
- if yes read the header, check if it is sector 0, if not repeat.
- at this point the jittering is still 2 cycles
- read the timer

so ultimatively, BVC * syncs to the disk (with two cycles jitter) two times in both cases. what happens in between doesnt actually matter, since the timer is free running. both measure the time for one revolution, both jitter pretty much the same way.

now the last case is the first version of the program, which reads all sector headers on a track and adds up the deltas. provided we dont miss a sector header for some reason, this does infact provide the same jitter, since again at sector 0 the timer will get resetted, and only checked after each header. its only overengineered unnecessary bolloks that can be omitted - but doesnt affect the jitter either.

as for "will the disk speed matter" - no, it doesnt. the answer is simple: the angular position of the referenced "markers" does not change, and their relative distance stays the same, and thats all that matters to the code.

so, the standard deviation is 15ppm or 0,0015%, ie 0,0045RPM for the observed 3 cycles jitter total - for all those programs.

we could, in theory, increase the accuracy/remove the jitter further by reading more bytes and adding a BVS *+2 half-variance kaskade. i'll leave that as an exercise to anyone who is crazy enough to think 15ppm isnt accurate enough already =P

case closed :)

2020-08-05 08:16

soci

Registered: Sep 2003
Posts: 478

The drive code is incompatible with my fastloader of choice and the result is a "70, NO CHANNEL". There's no error handling of course to display if anything went wrong it just returns to the menu immediately.

I seem to get different readings for the original ROM vs. JiffyDOS.

It destroys data on track 36 and there's no warning that it does so. Is this really necessary for such a measurement?

There's no field to enter the base frequency from a frequency counter and therefore the displayed value can't be the "true" speed. Not that it matters much as there's no chance to set up 300.00 through that miniature pot on the board anyway. Different disks are different of course.

So in short please initialize everything properly in the drive and don't just assume it's state. Do a bit of error handling. The accuracy and jitter discussion is BS without any practical value (apart from the timer chaining method). If you want to create something truly useful and outstanding from the crowd please add a histogram display as the shape of the graph tells more from the condition of the drive than a single speed number.

2020-08-05 11:34

Fungus

Registered: Sep 2002
Posts: 668

*pulls lid off drive, gets florescent light, adjusts pot, closes lid*

2020-08-05 12:31

chatGPZ

Registered: Dec 2001
Posts: 11290

soci has leading! (try rpm3.prg from the vice repo, it does init things)

so indeed, we'll have to consider deviations of the clock itself too to really calculate the actual standard deviation :) i have no idea how much that typically is (before the drive stops working alltogether). anyone? :)

2020-08-05 13:18

tlr

Registered: Sep 2003
Posts: 1762

Quote: soci has leading! (try rpm3.prg from the vice repo, it does init things)

so indeed, we'll have to consider deviations of the clock itself too to really calculate the actual standard deviation :) i have no idea how much that typically is (before the drive stops working alltogether). anyone? :)

I'd say that an oscillator of that era would have something like +/- a 100-300 ppm unless very expensive.

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 28 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

REBEL 1/HF
Spinball/Excess
TFWP
dstar/Fairlight
Sentinel/Excess/TREX
sebalozlepsi
Guests online: 92

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 Uncensored  (9.6)
7 Comaland 100%  (9.6)
8 Wonderland XIV  (9.6)
9 No Bounds  (9.6)
10 Unboxed  (9.6)

Top onefile Demos

1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Rainbow Connection  (9.5)
6 It's More Fun to Com..  (9.5)
7 Morph  (9.5)
8 Dawnfall V1.1  (9.5)
9 Onscreen 5k  (9.5)
10 Daah, Those Acid Pil..  (9.5)

Top Groups

1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Nostalgia  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.2)

Top Organizers

1 Burglar  (9.9)
2 Sixx  (9.8)
3 hedning  (9.7)
4 Irata  (9.7)
5 Tim  (9.7)

Page generated in: 0.072 sec.