| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
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 Adam People tried to help but you insult them and reply in a disrespectful way that has got you absolutely nowhere. Well done. Ciao. :)
Tried to help how?
By saying my program is bad because it writes a reference track?
Or because it does not have boring pop-ups warning idiots they should have read the instructions in the first place?
Then they even wrote that my program was accurate "because" of the reference track.
I even created a version as accurate as the main one but without writing anything.
Then they compare horrible looking and slow programs to mine.
All this is constructive? How?
Tell me how to improve it if you have ideas.
Or just shut up.
I even have a version with 3 decimal digits but it's totally useless and slower.
They even asked me to "prove" my program is better which is stupid because the program speaks by itself.
The results can be checked with accurate instruments and they match.
Test the code in emulators or real drives, drives without belt or with the rubber belt.
It just works flawlessly.
And I really have enough of oll this stupid passive aggressive hate just because I did something nice that works.
I never insulted people I value like Krill (the JEDI master in these kind of things) and Copyleft (another very valuable individual), but to read lamers like Groepaz bickering on my program and comparing to his unwatchable and unusable "thing" really makes me sad and not angry.
I may sound "angry" but I am not. I just was not expecting this.
Ciao :D |
| |
Adam
Registered: Jul 2009
Posts: 321 |
Quoting Zibri
Tried to help how?
warning idiots ... Tell me how to improve it if you have ideas.
Or just shut up.
you wonder why this thread didn't end up doing so well for you? surprising.
Quote:I may sound "angry" but I am not. I just was not expecting this.
It's abundantly clear to anyone reading this that you're mad :) |
| |
Smasher
Registered: Feb 2003
Posts: 512 |
Whole thread was interesting, it escalated a bit at some points but it was pleasant to read.
A pity last posts are about someone who shows another one how it is correct to behave. yawn.
I hope it gets back on the right (technical) track... or I'll beg Moloch to do his job :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
More on topic... Taking the oscillator deviation into account (which we really have to do if we are talking about accurracy down to two decimal places) - wouldnt ChristopherJams program actually be *more* accurate than the other discussed methods? Sure they are more accurate in the measurement on the drive itself, in drive-cpu cycles - however, that doesnt mean much if we dont compensate for the deviation of the oscillator frequency (as soci very correctly brought up) - but ChristopherJams program does!
ChristopherJam: would be really interesting to see a variant of yours that displays the full (non rounded) value and a value rounded to two decimals, like the programs in the test repo do :) Also some details on how the oscillator calibration works and how accurate it is etc pp |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting AdamIt's abundantly clear to anyone reading this that you're mad :)
I am not at all, believe me. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quoting KrillThis is also one of the basic techniques as used for stabilising raster routines.
Things might have changed since I was doing those decades ago but I recall the basic method was to make sure that the (second) IRQ comes while CPU is doing something, which gives a fixed IRQ latency. Like walking over the NOPs.. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Silver Dream !Quoting KrillThis is also one of the basic techniques as used for stabilising raster routines.
Things might have changed since I was doing those decades ago but I recall the basic method was to make sure that the (second) IRQ comes while CPU is doing something, which gives a fixed IRQ latency. Like walking over the NOPs..
I still really don't know how to apply that method to this situation.
My routine works with "I" flag set. No interrupts occur.
V (SOE) is set by hardware shift register every 8 shifts from the last reset. Using clock "00" that happens every 32 cycles when you write, but not when you read.
When you read the "clock" is the data itself.
So even some "wobbling" could cause a byte to be read in 31 or 33 cycles. (for example) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
The double IRQ technique is not "half variance cascade". He refers to the technique of polling $d012 several times at the end of a line, comparing, and by that cutting the error in half each iteration (when using double IRQ you'd typically do this only once, to eliminate the last jitter cycle). |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
After some further testing of my program, I noticed that having 3 digits does not bring any useful information on a real drive.
Instead having 2 accurate digits is very useful to assess the belt, electronics and even the diskette friction.
I am interested following this discussion, but I see no way to do this without "averaging" more rounds and making the program slower.
One of the best features of my program is not only the accuracy but the short time to achieve it.
Together they are very useful to people testing and repairing drives.
The only program that was near to this was the speed test included in this program: http://blog.worldofjani.com/?p=2180
But, once I tested it in the emulator I found out it was not only slower but very inaccurate on the decimal digit. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quoting GroepazThe double IRQ technique is not "half variance cascade". He refers to the technique of polling $d012 several times at the end of a line, comparing, and by that cutting the error in half each iteration
OK - then it's a different technique, which would work like - you handle IRQ of the line it was set to be triggered but then you get rid of the jitter by polling RASTER register for change a few (?) more lines, right? I need to check some examples of this out as I never did it this way. But in such case this might in fact be similar to polling V flag in 1541. I was having hard time fitting the "basic raster stabilising technique" the way I remembered it into the 1541 situation at hand. |
| Previous - 1 | ... | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | ... | 28 | 29 - Next |
