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

2020-08-13 01:15

Copyfault

Registered: Dec 2001
Posts: 476

Quoting Zibri

Small update:
I finally had time to do some testing of "rpm4.prg" and as I thoretically suspected, it works but it "misbehaves" if the speed difference is too big.
Starting the test att 300 gives bad results below 260 and vice versa.
This does not happen with the official version.
The official version does not "wait for a certain byte" to pass (like many of you implied) and it works.
RPM4.prg instead awaits for a certain byte to pass and it fails like many other programs out there.

Hoping to not stir up the heat even more, may I ask for a brief explanation on how the updated version differs from the previous "official" version? I read smth about "wait for a certain byte", so I'd suggest rpm4.prg does the measurement based on receiving a certain trigger-byte whereas the original tool did it solely based on interpreting the timer in a special way. So is it correct to say rpm4.prg uses a variable position on the track while the other always sticks to a full revolution?

It would be good to have the full sourcecodes of your tools; there was some basic code-style before, but full (and documented) sources are ofcourse better (and would've prevented most of (if not all) the dispute in this very thread;)).

But maybe I'm just too impatient and it's all part of the document you are working on, so take it as a well-meant suggestion.

2020-08-13 02:07

ChristopherJam

Registered: Aug 2004
Posts: 1409

Quoting Krill

Quoting tlr
As for the accuracy of the crystals, I think the most interesting thing it could be used for is calibrating a transfer routine for a much faster block transfer, c64 to/from drive.
Please do elaborate. :)

Well, if the ratio of the drive and c64 crystals was sufficiently precise, you could eschew syncing every few bits by using a Bresenham like variable loop length.

Sadly my experiments in that direction have not been promising.

2020-08-13 02:15

ChristopherJam

Registered: Aug 2004
Posts: 1409

Quoting Zibri

RPM4.prg instead awaits for a certain byte to pass and it fails like many other programs out there.

FWIW, I've found "waiting for a certain block" does indeed miss occasionally, which is why RPM Test 1.0 checks that the time it's measured falls below a threshhold so it can reject values that imply that the disk has rotated more than four times, and retry until it gets something useful

With that in place, I've never seen surprising values from real drives, though admittedly I'm reporting a lot less often than 1541 Speed Test.

2020-08-13 08:50

tlr

Registered: Sep 2003
Posts: 1787

Quoting ChristopherJam

Quoting Krill
Quoting tlr
As for the accuracy of the crystals, I think the most interesting thing it could be used for is calibrating a transfer routine for a much faster block transfer, c64 to/from drive.
Please do elaborate. :)

Well, if the ratio of the drive and c64 crystals was sufficiently precise, you could eschew syncing every few bits by using a Bresenham like variable loop length.

Sadly my experiments in that direction have not been promising.

Something like that, yes. We measure the difference between the c64 and drive clock at init and "dead reckon" basically. I would go about it by inserting static timing adjustment after every n bit pairs. Though, that graph Unseen measured of the deviation during running might make it necessary to re-calibrate. Maybe just check how far in cycles we are off after a couple of block transfers and adjust if too different?

2020-08-13 09:31

Zibri
Account closed

Registered: May 2020
Posts: 304

Quoting Copyfault

Quoting Zibri
Small update:
I finally had time to do some testing of "rpm4.prg" and as I thoretically suspected, it works but it "misbehaves" if the speed difference is too big.
Starting the test att 300 gives bad results below 260 and vice versa.
This does not happen with the official version.
The official version does not "wait for a certain byte" to pass (like many of you implied) and it works.
RPM4.prg instead awaits for a certain byte to pass and it fails like many other programs out there.
Hoping to not stir up the heat even more, may I ask for a brief explanation on how the updated version differs from the previous "official" version? I read smth about "wait for a certain byte", so I'd suggest rpm4.prg does the measurement based on receiving a certain trigger-byte whereas the original tool did it solely based on interpreting the timer in a special way. So is it correct to say rpm4.prg uses a variable position on the track while the other always sticks to a full revolution?

It would be good to have the full sourcecodes of your tools; there was some basic code-style before, but full (and documented) sources are ofcourse better (and would've prevented most of (if not all) the dispute in this very thread;)).

But maybe I'm just too impatient and it's all part of the document you are working on, so take it as a well-meant suggestion.

My mistake.
All versions "fail" below 260 but for a different reason.
It's the timer overflowing one more time.
I could correct that, but sincerely I don't care much since if the speed is so low the drive won't be usable for anything. Infact I tested the program with the emulator which goes from 275 to 325.
Strangely enough it doesn't seem to skip the byte in "rpm4".

About the method the "official" version uses:
it writes 5 bytes on track 36 which is previously filled by all "1", thus interrupting the ones at a certain point.
The timing routine waits for one byte then reads 5 more bytes. This guarantees a full revolution, no matter what byte is read.
"rpm4" instead waits for a single "known" byte on track 35 (or on the differently written track 36) and time its passage.
So, in case of a bit error, the official version won't flinch but rpm4 "should".
I quoted "should" because after a few tests with real hardware, this didn't happen.

Quoting ChristopherJam

though admittedly I'm reporting a lot less often than 1541 Speed Test.

I used the same checks and even more cheks in a preliminary version.
But after a code rewrite I didn't see this happening anymore.
Please, do check both RPM.prg and RPM4.prg (from github page) and tell me if you see this happening.
In my tests everything is fine in the range 275 (and down to 261) to 325 rpm.

2020-08-13 14:21

chatGPZ

Registered: Dec 2001
Posts: 11378

Quote:

Maybe just check how far in cycles we are off after a couple of block transfers and adjust if too different?

maybe (getting wild here) put a sync pattern like you suggested before on each track (somewhere in the tail gap perhaps?) and use that to resync?

2020-08-13 16:09

tlr

Registered: Sep 2003
Posts: 1787

Quoting Groepaz

Quote:
Maybe just check how far in cycles we are off after a couple of block transfers and adjust if too different?

maybe (getting wild here) put a sync pattern like you suggested before on each track (somewhere in the tail gap perhaps?) and use that to resync?

Was more thinking of dead reckoning on the IEC bus only. I guess it could be possible to sync to the track data but I think that in practice it would always wobble too much.

2020-08-24 01:46

Zibri
Account closed

Registered: May 2020
Posts: 304

Update:

Thanks to Groepaz who recently modified VICE (r38422) giving a bigger (way too big) speed range to the 1541 emulation,
now my program is not only the most accurate but the only one (or one of the very few) that supports drives at very high or very low speed settings. And still keeping maximum accuracy!

Go download the latest version as usual at: https://github.com/Zibri/C64-1541-Speed-Test

All major formats are available, PRG, D64, TAP and even WAV.

Note: in the D64 is also present a configuration program (CONFIGURE.PRG) that creates a customized version.

Regards,
Zibri

Note:
Big thanks to the downvoter who voted 3 this useful program out of misidrected anger from his life failures.
I know exactly who you are.
And no, it was not Groepaz, we bicker online but I think we respect each other but I might be wrong.

2020-08-30 18:00

chatGPZ

Registered: Dec 2001
Posts: 11378

Quote:

As for the presentation, I still think some kind of plot would be useful for quick adjustment.

I have implemented this now, see the *plot.prg variants of the testprograms: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/dri..

It would be cool if some people could run them on their setups and post the results (screenshots). Please tell exactly what kind of drive it is that you are using :)

Edit: when you run the program, it will take a second or two to calibrate (so it can align the graph to the middle of the screen, more or less). Then you can increase the resolution (decrease the divisor) for the timer value using F7,F5,F3,F1. Use the smallest divisor (widest plot) that still fits on Y. And dont forget to mention what the F-Key was that you pressed :)

Edit++: while you are at it - it might be a good time to calibrate the RPM of your drive to roughly 300RPM :)

2023-03-16 13:57

Mr. Mouse

Registered: Dec 2001
Posts: 235

Mr Tester &D Neil Chriss already released a speed test in 1984 in his Mr Tester. A program of extraordinary magnitude, I must add.

Previous - 1 | ... | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 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

Matt
Da Snake
Magic/Nah-Kolor
Impetigo/Crescent
MWR/Visdom
Guests online: 103

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 Onscreen 5k  (9.5)
8 Morph  (9.5)
9 Dawnfall V1.1  (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 Logo Graphicians

1 t0m3000  (10)
2 Sander  (9.8)
3 Mermaid  (9.5)
4 Facet  (9.4)
5 Shine  (9.4)

Page generated in: 0.059 sec.