| |
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....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
I figured out how to do it before, see my comment in the release :) I'd still prefer a simple self contained test program for the testbench :)
PS: this thread is about the accuracy of the mentioned methods and how to determine/proove it |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: I figured out how to do it before, see my comment in the release :) I'd still prefer a simple self contained test program for the testbench :)
PS: this thread is about the accuracy of the mentioned methods and how to determine/proove it
proof: set VICE to 275.00 then increment to .01 .02 .03 up until 325.00.
My program: accurate.
Every other program: not accurate.
Period.
I told you how my program works, that should be enough to prove the accuracy. 2/200000 is it's accuracy.
At speeds lower than 300 obviously the accuracy will be always 2/LONGERTIME but at speeds higher it will be lower accuracy.
In both cases even at the extreme edges the accuracy is more than anough to always get 2 decimal digits.
It's also interesting when you test "direct drive" drives with my program (the ones without the elastic belt).
There you will see a 0.01 wobbling or even none at all. Depending on how "stiff" is the diskette you tested it on.
About self contained program, just tell me what you need and I can code it easily. Basic program with single output? Multiple?
The real "program" I coded is the one inside the drive which allows:
1) The most accurate reading of rotation speed.
2) A new (customizable) routine do align to track 42.
3) A way to change track using DOS but in an agnostic way (not even needing a disk inside) which nobody did so far.
About (3), everyone until now coded a routine to physically address $1c00 lower bits to move the step motor. That's fine if done correctly, but I liked more "the commodore way", so I studied it and implemented it.
As I already said, for me this was just a mental gymnastic exercise, I learned a lot and implemented what I learned. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
In a nutshell:
30 open 15,8,15,"u30"+chr$(36)
40 get #15,a$,a$,b$
50 tt=asc(a$+chr$(0))+256*asc(b$+chr$(0))
60 if tt > 32767 then tt = tt-65536
70 t=3*65536-tt-5
80 rpm=int(0.5+6000000000/t)/100
90 print "rpm="rpm
100 close15
for a single reading.
for multiple (and fast) ones:
just do a print#15,"U31" and then the same code from line 40 to line 90 in a loop. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
i knew all that. its not what i am looking for, as said before. |
| |
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. |
| |
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. |
| |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
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 :) |
| |
Frantic
Registered: Mar 2003
Posts: 1647 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 28 - Next |
