[CSDb] - User Forums - Accurately Measuring Drive RPM

Welcome to our latest new user IcePic ! (Registered 2024-12-03)

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

2020-08-04 13:41

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: Communication seems to be in a deadlock. I have a feeling that it might get unlocked if Gpz explains, and perhaps gives an example (even if only based on conjecture) of, the reasons why "a stable value alone does not tell its accurate". I haven't seen any signs of understanding that part from the other party, and it is obviously the key matter here.

My program is BOTH stable and both accurate.
Unlike ANY other program ever done until now. (including gpz tool)
Sorry to sound rude, but really gpz showed to understand very little of 1541. He even asked me how does my program reset the lower byte of the VIA timer.
If he knew the 1541 or VIA and CIA chips he should know that writing to the higher nibble also resets the lower one.
And it shows also he tried to disassemble and reverse engineer my program instead of asking.
There is nothing wrong in asking and learning, but I really didn't like his attitude.
Sincerely, I have a nice life, I live since 4 years in one of the most wonderful places in the world, I have the best coral reef literally 50 meters from my door.
I was expecting curiosity about this program and I even prepared a document which explains everything I learnt so far on the 1541 and some techniques rarely (or never) used before. Nothing fancy. Just the result of a few weeks of study, from the schematics up to ROM disassembly (most of online ROM disassemblies have a lot of logical errors inside).
But after all this "drama" I really lost interest.
Don't get me wrong, I am not angry or anything, just a little disappointed.

Peace out.
Zibri

2020-08-04 14:11

chatGPZ

Registered: Dec 2001
Posts: 11378

I'm not much into drive code, thats no secret. So what? And of course, i looked into your code with a disassembler so i can read it and see what it does. Why wouldnt i? None of this matters to the questions asked though. No idea why you get so winded up over it.

And yes, what Frantic said. Observing a program in VICE doesnt prove anything - because we have to assume VICE is wrong and we can not trust it. Likewise, the fact that the value is stable is unrelated to how accurate it is - it could still be totally wrong. What matters is the maximum deviation in the worst case. Repeating over and over how great your code is doesn't help - we already know its slightly more stable than my code. That doesnt mean we can assume or even trust on it being more accurate though.

Instead, the entire behaviour - and accurracy - of the program should be explained using nothing but the program itself, without having to run it. Then we can calculate the maximum deviation for the worst cases, ie when the reference track was written on a significantly too fast or too slow drive. The same kind of calculations should then be done for my tool as well, and only then we can tell how accurate either really is. That (and only that) is what the thread is about.

PS: both CIA and VIA copy the timer lowbyte from the timer latch on write to the high byte. That means your code relies on whatever the ROM initialized the timer latch with. Its not magically "reset".

2020-08-04 18:08

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: I'm not much into drive code, thats no secret. So what? And of course, i looked into your code with a disassembler so i can read it and see what it does. Why wouldnt i? None of this matters to the questions asked though. No idea why you get so winded up over it.

And yes, what Frantic said. Observing a program in VICE doesnt prove anything - because we have to assume VICE is wrong and we can not trust it. Likewise, the fact that the value is stable is unrelated to how accurate it is - it could still be totally wrong. What matters is the maximum deviation in the worst case. Repeating over and over how great your code is doesn't help - we already know its slightly more stable than my code. That doesnt mean we can assume or even trust on it being more accurate though.

Instead, the entire behaviour - and accurracy - of the program should be explained using nothing but the program itself, without having to run it. Then we can calculate the maximum deviation for the worst cases, ie when the reference track was written on a significantly too fast or too slow drive. The same kind of calculations should then be done for my tool as well, and only then we can tell how accurate either really is. That (and only that) is what the thread is about.

PS: both CIA and VIA copy the timer lowbyte from the timer latch on write to the high byte. That means your code relies on whatever the ROM initialized the timer latch with. Its not magically "reset".

1) As I said 3 times, I repeat: my program is both accurate both stable on REAL drives and HW.

2) The "whatever the ROM initialized the timer latch with" is again ignorance: timer is initialized in ROM and it has the right value.

3) is not slightly more stable. Is totally accurate while your program is not and will never be unless you use a similar, "dervied" as you called it, code. Until then it will always be inaccurate and unreliable and that is easily proven.

4) "the program should be explained using nothing but the program itself" I don't agree with this. Prove my program is inaccurate or just shut up and stop showing off your "admitted" ignorance in drive code.

I don't get "winded up". I just don't like that the author of a horrible looking and totally inaccurate program states that mine "is yet to be seen" or that his is just "slightly off".
If you just want to setup up the drive speed you don't even need any program, there is a reference stroboscopic disc on every drive motor for that and tollerances are well over iven 5%... a 1541 works even at 295 or 305 without problems.

With my program you can write the track with a slow or fast drive and my program will still be accurate, by the way, because of how it is made.

I published my prigram and everyone is free to try it and compare it to any other program.

As far as I know (I might be wrong) there is no other program using this method even if a lot of program write a reference track. They just do it wrongly... not by much but not as accurately and precisely as this one.

My program is not "stable" because of tricks. It's stable because of how it works. Infact in a "fairly" good emulator any speed you set the drive to is reflected by my program to the CENT... and not by any other program I tested.

Now a silly note:
I was expecting a different reaction... like:

"thank you for sharing this nice program, after testing it on all supported drives and in emulators, I am impressed by it's accuracy! Would you be so kind to tell us how you did it?"

And expecting THAT reaction I was already preparing a document explaining it.

P.S.
I am not saying I am the best at this, since I think that paople like Krill are way better than me, but still nobody thought about this way and nobody implemented it.
That just wanted to be my small contribution to the ocean of software available for the C64.

2020-08-04 18:56

Copyfault

Registered: Dec 2001
Posts: 476

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: 11378

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: 11378

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: 476

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: 11378

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: 479

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.