| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
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....
|
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Groepaz
it's all in post #30. please explain why not if.
I will try again to explain it but you seem not to be willing to listen to a simple fact:
If you don't write the track yourself, you are assuming it's fine, which it can be wrong.
In any laboratory test, the conditions of the test must be known and verifiable.
To do so usually a "master disk" written by very precise drives, is used.
My program creates such a measuring track so to have a reference that is SURE is as it is intended to be.
Anyway, until now I still haven't seen a program able to determine RPMs in a reliable way (and not just in emulators).
Not useful, perhaps. But I liked the challenge. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriSame here. Show me the program logical flow, because I am getting lost in all this theoretical talking.
Anyway, what you read before starting the timer, depending how you do it could influence the ooutcome by starting the timer too early or too late (for example when reading SYNCs).
If you are talking about:
1) read sync.
2) check if sector 0
3) start timer
4) read sync
5) is it sector 0? no, goto 4
6) stop the timer.
Exactly. The timer should be started after reading the header as you write, so that would be after a bvc *. This is how the tests I examined worked, and also how I chose to implement mine in the past. Most of them (including mine) measured timing c64-side though so the accuracy would obviously be much less because of that.
The obvious advantage of this appoach is that it works without writing to the disk. The downside is, like you point out, that it won't work with a very out of range rotational speed or malformed diskette formatting. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quote:And I will always be able to produce a disk that will make it fail.
that's totally out of scope of the discussion. of course we are assuming a standard DOS formatted disk.
Never assume. There are fast format program who format a "working" disk which is far from standard anyways.
It's not out of scope at all.
To be precise:
your "approach" would work if your program will also format a disk in a very standard way.
In the end it will be slower and trash an entire disk.
I opted for writing a simple test track. I could even reformat a standard track but it would have been the same.
A waste of time and resources when a simpler approach solves all problems without any downside. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
It will work fine whenever there is exactly one sector 0 header on the tested track. doesnt matter how it was written at all, because the last bvc * is the reference point. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlrThe downside is, like you point out, that it won't work with a very out of range rotational speed or malformed diskette formatting.
And that's why all professional tools use a master disk.
Mine creates such a track without the need of a pre-mastered disk.
Also, it creates the track in a "smart" way that is very easy to manage and that leaves no space to errors. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriI can format a disk in a way that it works for DOS but will make such a program fail.
This is kind of interesting, how? Multiple sector 0 headers on the track? That would be kind of evil but assuming nothing on the disk references sector 0 of that particular track it could work fine in DOS i guess. :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazIt will work fine whenever there is exactly one sector 0 header on the tested track. doesnt matter how it was written at all, because the last bvc * is the reference point.
Again: you seem not to care about the implications. I did.
What if the track is not even formatted? What if the disk had some custom loader (like krill or the other one with even custom GCR?!).
Please, stop this discussion.
You assume a lot of things. My program is agnostic.
As I am. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
Quote:that's totally out of scope of the discussion. of course we are assuming a standard DOS formatted disk.
the thread is about comparing how accurate the two methods are, not how you can make them fail using non standard disks. please stick to the topic. you still havent explained some of your claims regarding accuracy.
tlr: eg you could put two sector 0 headers after each other, and only one of them is followed by a data block - that will work fine (for reading at least). copy protections used this, as a simple copier will not recreate this. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Groepaz
the thread is about comparing how accurate the two methods are, not how you can make them fail using non standard disks. please stick to the topic. you still havent explained some of your claims regarding accuracy
Mine are not "claims".
The proof is my program itself and no progranm before that could accomplish the same results including yours.
Even after the modifications.
I even tested your programs since you clearly didn't even take the time to test them before committing them.
The screenshots are more than eloquent.
I repeat: I have nothing to prove nor to explain to you nor anybody else. If you wanted to learn something you use the worst attitude to do so.
Sorry, but I really am not in the mood to be teaching anything to you. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
So i take it that you can not explain why one method is supposed to be more accurate than the other, nor explain why the explanation in post #30 is false. Repeating the same claims over and over does not help, nor prove anything. Forget my program, my program (or anyone elses) is irrelevant for explaining how accurate yours is. |
| Previous - 1 | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | ... | 28 - Next |
