[CSDb] - User Forums - Accurately Measuring Drive RPM

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

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-05 13:18

tlr

Registered: Sep 2003
Posts: 1737

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.

2020-08-05 13:39

chatGPZ

Registered: Dec 2001
Posts: 11170

So an order of magnitude more than the accuracy of the program? soci has even more leading with calling the discussion BS =D

But, how much does it typically drift in practise though? I *have* seen drives that stopped working because the clock was totally off, but that probably happens rarely?

<strike>edit: wait, what frequency does the Oscillator have? 10Mhz?</strike>

So with 16MHz Crystal and assuming 100ppm, we get a deviation of 6,25 cycles on top. Assuming 300ppm its even 18,75 cycles, which is ~6 times as much as the anticipated 3 cycles deviation of the program....

2020-08-05 14:30

Zibri
Account closed

Registered: May 2020
Posts: 304

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

did you ever take the time to read the instructions on github?

The program works on any original drive with original ROMS.
It even works (by pure luck) with Ocean 118 drive which has rdos.. only difference there is that the track change happens slowly (probably because they hijack the normal IRQ routines.

Quote:

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

Yes it is and it is clearly state in the instructions:
https://github.com/Zibri/C64-1541-Speed-Test

The program was not mean to work with any drive or any non standard configuration/rom.
This has been done on purpose.
Clearly the program was not meant for you.

2020-08-05 14:32

Zibri
Account closed

Registered: May 2020
Posts: 304

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

EXACTLY!

That is the right way to do it.
This program it's just for different purpose than setting the right speed (but for sure it's more comfortable for some that using the strobe).

2020-08-05 14:40

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: 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 :)

hmm.. try starting *your* test on a real drive running at a very low or very high speed. then start your reading and try to set it to 300.00
then recheck the speed with strobe or with my program.
Come on dude.
As I stated, my program is the most accurate SO FAR in 40 years.
Now if anyone wants to learn from it, you are all welcome.
Nice of you explaining to others what I explained you in a private message.

The last phrase in the above message makes me laugh so much.

Is it so difficult to accept I wrote a program that does something new and right?
And that no other program including yours as it was before mine, could?
Really?
How sad is this?

2020-08-05 14:50

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: 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)?

No.. but they got that all I did was to post a program more accurate that any other BEFORE it.
And that *you* made a case out of this.
Even this useless thread was started by you.
If you don't realize this, I can't help it.

And still: my program is the most accurate ever published until the release date.

Deal with it.
And quit all this childish, passive aggressive "discussion".

As I even wrote in my instructions: accuracy is not even needed to have a drive working. The tollerances are very high.
This program helps a bunch of friends of mine who repair drives.
That's all.
And just incidentally it is the most accurate.
Which clearly is all you can see about it.

Personally I also like the big rpm petscii font and even the "dot-in-a-dot" flashing at every update (2 per second in this version).

The program also sports a new way to move the head using DOS but in an agnostic way (no disk needed).

The program has also other functions, but they are only available to who takes the time to read the instructions.
And they are there just for testing/fun/programming.

All this and the only thing you can see is that I shamed your ugly program? gneeeeeee sorry dude...

2020-08-05 14:54

chatGPZ

Registered: Dec 2001
Posts: 11170

Quote:

Nice of you explaining to others what I explained you in a private message.

Like that your program is "100 times" more accurate than mine, and that VIA timer lowbyte is "resetted" when the highbyte is loaded? OK.

I'd rather stick to facts :)

2020-08-05 15:46

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: Quote:
Nice of you explaining to others what I explained you in a private message.

Like that your program is "100 times" more accurate than mine, and that VIA timer lowbyte is "resetted" when the highbyte is loaded? OK.

I'd rather stick to facts :)

And those are both facts.
1) My program is 100 times more accurate than yours (or anyone else) is/was.
2) to reset the VIA timer you just need to read the lower byte or to write the upper one.

2020-08-05 16:26

chatGPZ

Registered: Dec 2001
Posts: 11170

OK. That means may program deviates by 3 RPM and the timer wasnt initialized by the ROM at all. again what learned!

Meanwhile someone with a clue provided a nice diagram - he measured the oscillator clock over time (deviation from 16Mhz on Y, seconds on X): https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/dri..

2020-08-05 16:39

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: OK. That means may program deviates by 3 RPM and the timer wasnt initialized by the ROM at all. again what learned!

Meanwhile someone with a clue provided a nice diagram - he measured the oscillator clock over time (deviation from 16Mhz on Y, seconds on X): https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/dri..

No wonder your program was wrong if this the only thing you learned.

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 28 | 29 - 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

Scrap/Genesis Project
Airwolf/F4CG
Barfly/Extend
eryngi
Freeze/Blazon
Codetapper
Guests online: 94

Top Demos

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

Top onefile Demos

1 Layers  (9.6)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 Rainbow Connection  (9.5)
6 It's More Fun to Com..  (9.5)
7 Dawnfall V1.1  (9.5)
8 Birth of a Flower  (9.5)
9 Morph  (9.5)
10 Quadrants  (9.5)

Top Groups

1 Nostalgia  (9.4)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Offence  (9.3)

Top Original Suppliers

1 Black Beard  (9.7)
2 Derbyshire Ram  (9.5)
3 Fungus  (9.3)
4 hedning  (9.2)
5 Baracuda  (9.1)

Page generated in: 0.059 sec.