| |
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....
|
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Back to a serious discussion:
In all this mess I forgot to mention a major flaw of all
other rpm programs:
if the disk is formatted by a real drive which speed is set to let's say 290RPM, ALL tests will fail.
This behaviour can't be tested on an emulator because VICE always writes at 300RPM and fixed density.
Also, on real hardware is very difficult to test if a fluctuation or program error is real or is the drive speed fluctuating.
That's why I opted for writing a test track in a way that it is independent from the writing speed (i.e. it is dependent but in a way that is irrelevant to the result).
Same goes for all programs written before mine and that's why real test program used pre-mastered disks.
The "beauty" of my program is that it does not need a master disk (a disk mastered by a "perfect" drive) in order to give perfect results.
A faster drive will have a very different track geometry where SYNCS will be nearer to each other and data will be narrower.
By opposite, a slower one will have SYNCs further away from each other (and wider data in the middle).
Also: a slower drive creates "longer" tracks and a faster one creates shorter ones.
Even SYNCs will be shorter or longer depending on the writing speed.
P.S.
There "might" be another way (which I am studying) to achieve the same accuracy my program actually has and without writing a test track (even if I find nothing wrong in doing that).
Unfortunately emulators, including VICE will give false positives to my theory (it will work in emulators but maybe not on real drives).
We will see if my new theory is right (I strongly doubt that) then I will release a new version. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Update:
I compiled a "wrong" version of RPM which I called "rpm2wrong.prg"
This version does not write a test track.
This version still is accurate as the previous one.
BUT
It is wrong as all "other" programs.
Even if in VICE it will give you perfect results.
A further proof:
It is true that vice writes at a fixed speed and density.
But it is also true that that speed is the speed of the drive who wrote (or extracted) the disk.
So, if you take the original version of ARCHON (for example) and convert it from NIB to G64, then you run the "wrong" program, you won't have 300 RPM but (in this case) 298 RPM.
Why? Because the drive used to extract ARCHON was slower!
Instead, if you run my RPM program, even on the same G64, it will continue to work and give you the actual speed of the reading drive.
I know these concepts are not immediately easy to understand. And the emulator complicates things.
I could easily say that my rpm2wrong.prg is working perfectly since it has no glitches, no jitter and it's still precise to the cent like the real version.
But... IT IS WRONG.
If anyone is interested I can give you a link to the wrong version and you can verify it works "flawlessly" in VICE.
Wher will it fail in the real world then?
It will fail if used on a disk which was not formatted by a perfect drive with no wobble and a steady speed of 300 RPM.
All clear?
Good night.
Zibri |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriIt is true that vice writes at a fixed speed and density.
But it is also true that that speed is the speed of the drive who wrote (or extracted) the disk.
So, if you take the original version of ARCHON (for example) and convert it from NIB to G64, then you run the "wrong" program, you won't have 300 RPM but (in this case) 298 RPM.
Why? Because the drive used to extract ARCHON was slower!
Instead, if you run my RPM program, even on the same G64, it will continue to work and give you the actual speed of the reading drive. I'm assuming here that you are still measuring time (as opposed to capacity) with your new implementation. In that case, the actual _time_ cannot physically change if the (emulated) rotational speed is 300 rpm. The actual _amount of data_ per track can change however depending on the speed of the drive used to write it.
It looks to me that what you are seeing is the effect of a limitation (bug) in vice. If the emulated rotational speed is 300 and the actual _time_ before the data loops is longer than one revolution then this is obviously impossible. This could never happen on hardware.
You could try to run it in different emulators (e.g hoxs64) and see if it works differently. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
I dont see why using a disk written on a drive with different speed causes a different type of error with the "wait for sector 0" method than with using a test track. because basically both do the same thing (see post above). unless perhaps you write the test track again and again? please elaborate. As i understand, when you start and read the timer at the same point on the disk after one revolution, it doesnt matter at all if the sync before that is longer or "stretched" or whatever - you are still starting and reading the timer at the exact same spot.
PS: it might also be worth trying P64 images for these experiments, in theory they do not have the mentioned limitations of G64 files. (Now that i wrote it... P64 rotation code always uses 300rpm no matter what. meh) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
They are not the same thing.
The test track I used in my program is a long sync followed by five bytes that start and end with a 0, a different byte would cause another 3 or even 6 cycle error.
Measuring data, you are subject to reading and writing speeds "deltas".
Now, this difference is insignificant mathematically in the case of the 5 bytes but the more BVC loops you use to read bytes the more significant it will be.
To be even more accurate I could use 2 or 3 bytes but after some testing there seems to be no problem using 5 because even a totally out of speed drive will always read and write about 5 bytes and something leading anyway to a full revolution.
My program is still accurate on totally out of speed (real) drives.
And I repeat: I see nothing wrong in writing track 36 which is out of the standard tracks of a normal disk which you are supposed to use for testing the drive anyways.
In the D64 archive on github there is also a small configure program which creates a customized version allowing to change the test track, the hardness of the track42 align and afew other parameters.
But that is useful only if who fixes the drives has special needs. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlrI'm assuming here that you are still measuring time (as opposed to capacity)
Indeed.
It is also possible to write a long bit pattern and then count "how many bits did I write?".
This could also work but it is more difficult to implement with absolutely no advantage.
Counting bytes instead of bits is also possible but it will lead to less accuracy too.
Before chosing the implementation, I considered all possibilities and I chose the more effective, easier to code, fastest to check and best overall.
The result speaks for itself.
I could add the number of bytes written (5 now) as a parameter in the configure program, but I doublt it would be really useful. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11378 |
i dont see how reading more or less bytes makes a difference, you are in sync with the disk after each byte (with 2 cycles jitter). if that wasnt the case and errors added up like you say, you'd never be able to read a sector. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Groepazunless perhaps you write the test track again and again? please elaborate.
No. I write the test track at the start of the test.
I could avoid it and write it just once and check if it's there otherwise write it again, but why?
Again: I see no problem at all in writing a test track.
Doing so I am sure the test results are independent of any external factors induced by who wrote the disk, how it was formatted, etc. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Quoting Zibri
And I repeat: I see nothing wrong in writing track 36 which is out of the standard tracks of a normal disk which you are supposed to use for testing the drive anyways.
Being Dolphin user, virtually all of my disks are 40 tracks formatted. While you can of course say "read the docs, they say you must not use disks containing data on track 36 (or whichever)", it is still a very good and common practice to at least warn the user before destructive operations. So yes - I see nothing wrong with destroying data even on the whole disk as long as the user is forewarned and can safely confirm his intentions or cancel the operation. Just that. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Groepazi dont see how reading more or less bytes makes a difference, you are in sync with the disk after each byte (with 2 cycles jitter). if that wasnt the case and errors added up like you say, you'd never be able to read a sector.
I know you don't see it.
The reading is not in sync with a clock, but with the written bits.
Reading let's say 100 bytes written by a slow drive will take way less time than reading 100 bytes written by a fast drive.
And this happens even if it is the same drive writing and reading.
As I said, I studied the drive down to the schematics.
I suggest you to do the same and do not rely too much on "commented roms" because 50% of the important routines are commented or understood/explained wrong.
An example:
check BIT 5 and BIT 6 of $1C00 in most commented roms I found their function is written badly.
If you check the schematics of 1541 their function becomes immediately clear. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | ... | 28 - Next |
