[CSDb] - User Forums - Accurately Measuring Drive RPM

Welcome to our latest new user IcePic ! (Registered 2024-12-03)

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

2020-08-07 16:05

Zibri
Account closed

Registered: May 2020
Posts: 304

Quoting Copyfault

So *if* enough people are willing to do this once more, we could start a measurement session with all the speed test programs currently available. This would further clarify what is meant with metastability and hopefully lead the discussion into a more constructive direction.

I tested a few programs before deciding to write my own.
None seem to have accurate results and some failed because they needed a real (original) reference disk.
I guess the reference disk was a disk written with a "direct drive" diskdrive, with no wobbling and electronically controlled motor speed.
Those reference disks were good to check head alignment (but this must change in the future) but overkill for speed asessment.
Also, as Krill pointed out, most inacuracies were introduced by bad programming and at the time it was not as easy as today to see such mistakes.
Today, with emulators you can "freeze time" and check everything both on c64 side both inside the drive.
Freezing time was partly possible with cartridges but it was not possible to freeze a drive in time.
That led to all kinds of quirks and errors.

2020-08-07 16:26

tlr

Registered: Sep 2003
Posts: 1787

Quoting Comos

yep,this is mentioned on a inlay paper.
The reference disk is on the other side, if someone owns the orie.But as a reference disk a original CBM demo disk could be used aswell.

Ok, good to know. Didn't seem to work in emulation, but maybe I missed something.

2020-08-07 17:00

Zibri
Account closed

Registered: May 2020
Posts: 304

Quoting tlr

Quoting Comos
yep,this is mentioned on a inlay paper.
The reference disk is on the other side, if someone owns the orie.But as a reference disk a original CBM demo disk could be used aswell.

Ok, good to know. Didn't seem to work in emulation, but maybe I missed something.

I get 299.78 in the emulator with wobbling set to 0.
Meh.

2020-08-08 11:28

ChristopherJam

Registered: Aug 2004
Posts: 1409

Hi all.

Belatedly throwing my two cents into the ring.

I did release RPM Test 1.0 back in 2016. It only directly reports RPM to one decimal place, but it also gives the number of c64 cycles per disk revolution, and the number of c64 cycles per 1 million drive cycles. 60*(the latter)/(the former) should theoretically give one the same accuracy as Zibri's, assuming a 1MHz drive crystal.

The first measurement is one sixteenth of the total time of four runs each of which measures four revolutions to 7 cycle accuracy - so the total jitter should be a shade under two cycles per rotation, and expected error less than one cycle per rotation.

The second measurement is only accurate to the nearest 7 cycles, but that's only 7ppm of error which is more than accurate enough for present purposes.

Somewhat surprisingly, if I calculate the RPM to two decimal places, this afternoon I'm consistently getting about 0.01 RPM higher than what I request from VICE 3.1 Cocoa. This may warrant further investigation…)

So, Zibri's is faster, and will directly display an extra decimal place of accuracy. Nice work, on both those counts!

I just released first, don't overwrite any data, and do very little stepping (my tool repeatedly seeks to the first block from a track near the directory). Go me \o/

As for methodology, my drive code just signals the c64 whenever it reads the block mentioned above, leaving the c64 to do all the timing. It also sends a one million cycle long pulse for crystal calibration; no PAL/NTSC setting required.

On master disks:

A master disk is worse than a disk that has been formatted by the drive being tested, as a drive is more likely to be able to read a disk it has written than a disk written by another drive.

On writing test tracks:

As various people have already pointed out on this page, there's no need to write a test track, as you can just read the same header each revolution instead without losing any accuracy at all.

Writing a test track is undesirable, as it destroys information on the disk.

Writing a test track without warning the user who is running the program is even worse.

Relying on people reading documentation to find out that your code will damage the disk in the drive really isn't reasonable; it should be safe to just "try something out" without trawling through the documentation.

On Stepper Test 1.0:

Copyfault: thanks for the props, but for current purposes I'd be more interested in seeing results from RPM test, as that also reports relative crystal speeds.

(just as an aside, I'm still cursing myself for not including a crystal speed measurement in Stepper Test, given how much more uptake I got for the latter! Thanks again for the tests, all :) )

On praise

It's always appreciated, but never owed - and being grumpy about not receiving enough is never a good look. Perhaps I'm being hypocritical on this count? Meh.

2020-08-08 12:03

chatGPZ

Registered: Dec 2001
Posts: 11379

Quote:

A master disk is worse than a disk that has been formatted by the drive being tested, as a drive is more likely to be able to read a disk it has written than a disk written by another drive.

In that case you should probably first align the drive though, instead of being worried about super exact RPM =D

2020-08-08 12:29

Compyx

Registered: Jan 2005
Posts: 631

Quoting ChristopherJam

On praise

It's always appreciated, but never owed - and being grumpy about not receiving enough is never a good look. Perhaps I'm being hypocritical on this count? Meh.

Nah, I agree. Don't expect praise or try to force it, earn it.
I still consider myself one of the, if not the greatest, logo and font artist. Reality shows otherwise :)

A little arrogance seems inherent to being a scener, and that's fine, motivates you when someone does something better than you. Gotta show you're more awesome =P

2020-08-08 12:34

Copyfault

Registered: Dec 2001
Posts: 476

Quoting ChristopherJam

Hi all.

Belatedly throwing my two cents into the ring.
[...]

I was wondering why you did not already contribute to this discussion - and at the same time hoping that it will happen at some point:)

Feel my relief!

Quoting ChristopherJam

On Stepper Test 1.0:

Copyfault: thanks for the props, but for current purposes I'd be more interested in seeing results from RPM test, as that also reports relative crystal speeds.

(just as an aside, I'm still cursing myself for not including a crystal speed measurement in Stepper Test, given how much more uptake I got for the latter! Thanks again for the tests, all :) )[...]

I was even thinking of tests done in parallel with different tools, like your RPM-Test, the rpm1/2/3.prg-tools Groepaz recently added to Sourceforge and ofcourse Zibri's 1541 Speed Test-tool. But such tests would've to be done on different *real* drives, so it's a matter of motivating people, especially those with "corner case drives", to do all these tests and present a table with the resulting values. I have a feeling that it will show equal *real* accuracy between some(if not most) of the beforementioned tools.

2020-08-08 12:45

ChristopherJam

Registered: Aug 2004
Posts: 1409

Haha, fair point about drive alignment, Groepaz

Compyx - But you *are* one of the greatest logo and font artists of all time :D

Copyfault - I must admit, I've been itching to reply for a few days now, but I started a new job recently and I've been a tad low on time and sleep Monday to Friday while I acclimatise! Happy to oblige with a contribution.

Nice idea about comparing results from the various tools out there, on multiple realdrives. It would indeed be interesting to see how well they correlate.

2020-08-08 12:47

Oswald

Registered: Apr 2002
Posts: 5086

"I still consider myself one of the, if not the greatest, logo and font artist. "

u r one of the greats if you ask me .)

2020-08-08 13:11

Compyx

Registered: Jan 2005
Posts: 631

Thanks! Probably should have used a different example.

Previous - 1 | ... | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | ... | 28 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

HBH.ZTH/Abnormal
Guests online: 72

Top Demos

1 Next Level  (9.7)
2 What Is The Matrix 2  (9.7)
3 13:37  (9.7)
4 Coma Light 13  (9.7)
5 Edge of Disgrace  (9.7)
6 Mojo  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Wonderland XIV  (9.6)
10 Comaland 100%  (9.6)

Top onefile Demos

1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Libertongo  (9.5)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 It's More Fun to Com..  (9.5)

Top Groups

1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Nostalgia  (9.3)
5 Triad  (9.3)

Top Fullscreen Graphicians

1 Joe  (9.7)
2 Veto  (9.6)
3 Facet  (9.6)
4 The Sarge  (9.6)
5 Carrion  (9.5)

Page generated in: 0.059 sec.