[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-03 22:39

chatGPZ

Registered: Dec 2001
Posts: 11290

i knew all that. its not what i am looking for, as said before.

2020-08-03 23:20

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: i knew all that. its not what i am looking for, as said before.

Then I really don't understand what you are looking for.

2020-08-04 01:25

JackAsser

Registered: Jun 2002
Posts: 2014

Quote: Then I really don't understand what you are looking for.

You coding a self contained prg-file that is 100% compatible with the VICE test suite ofc. Not saying I agree, I'm merely pointing out what Groepaz meant, if that was unclear.

2020-08-04 06:08

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: You coding a self contained prg-file that is 100% compatible with the VICE test suite ofc. Not saying I agree, I'm merely pointing out what Groepaz meant, if that was unclear.

My program *is* self contained.
I don't understand what he means by "compliant".
Vice has so many limitations that I had to modify my program so it worked also with vice.

An example:
VICE always writes at 300RPM (or at the speed the g64 you are writing to was extracted... crazy... but I understand why).
VICE also writes at the density it decides. If you tell 1541 to write at density 3 in track 1, it will write at density 0 anyways.
VICE does not support any of the mechanics of the 1541 like SPIN up / SPIN down of the drive motor (it goes to 0 or maximum speed, nothing in between)

And so on...
I sincerely prefer to study REAL hardware and not to make programs "compliant" to (reasonably) incomplete emulators.

2020-08-04 08:37

Krill

Registered: Apr 2002
Posts: 2940

I believe he's not looking for just another test program measuring RPM, but a way to make the measurement more accurate, and a few explanations as to why existing approaches have certain accuracy properties.

2020-08-04 11:12

chatGPZ

Registered: Dec 2001
Posts: 11290

what krill said. it's written in the first post, in the last paragraph.

and as for the test program, it should be compliant to the *testbench* of course, not VICE. and it should be a simple small program not containing anything but that one test. preferably the code is as simple as possible and without unnecessary optimizations that make it hard(er) to read. and there should be sourcecode for all of it (which is part of being compliant for the testbench). and - as said before - none of that really matters because i can easily write such program myself. this thread isnt about the test program :)

2020-08-04 11:50

Frantic

Registered: Mar 2003
Posts: 1641

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.

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

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.