| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
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? |
|
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting GroepazVIA timers are only 16bit and can not be cascaded
[...]
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? From loader sources: ; timers/watchdog initialisation
; for the long timeout between block-ready and block-send, use two arithmetically cascaded timers:
; their periods differ, so their counters drift further apart every time either timer resets.
; the effective timeout is reached as soon as the difference between the counters is >= 128, which for
; the used periods' difference of 7 cycles with the counter periods of $ef00 and $ef07 is at least
; floor(128 / 7) * $ef07 = 18 * $ef07 = 1,101,438 cycles at 1 MHz, i.e., roughly 1 second.
; a few cycles are added to or subtracted from the effective timeout: added because as a counter reset
; apparently takes 2 cycles, so the effective periods are $ef02 and $ef09, subtracted because the counters'
; difference does not increase by 7 on counter $ef07 reset, but increases by 7 and then decreases by 2.I have a hunch that you could use something like this to have rather precise measurements using two VIA timers with adjustable periods. |
| |
Quiss
Registered: Nov 2016
Posts: 43 |
Quote:
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?
You don't need to go full Chinese remainder.
Set both timers to free running, and their latches to N and N-1, respectively.
Now, whenever you read out both timers, the difference between them will tell you how often they underflowed, thus giving you another ~16 most significant bits.
(Also see Krill's post: Extending MOS 6522 VIA timers to more than 16 bits without interrupts) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: 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?
"somehow this produces a stable value without any jitter"
because to check for a sync you have to use two
LDA/BMI wait loops.
These induce an error of 6-7 cycles each!
Instead to read "X" bytes you use a single
loop BVC loop
which has only a 2/3 cycle jitter.
2 / 200000 is more accuracy that I wanted to achieve.
Note, don't put in vice repository a "derived" test (i.e. copied). Just put my program. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Another note:
it's totally useless to use both VIA timers.
Considering the speed range of VICE, the difference between 275 RPM and 325 is 33566.4 cycles which is fine because it's smaller than the 65536 cycles the timer can give us.
Obviously the timer will underflow 3 times.. but we don't care because we already know the range.
Believe me there is no better way to determine the rpm than my program does.
For sure you could have a "sort of" accurate result in other ways but you will need more rounds and mathematical averaging. This is the fastest direct way to get it. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting ZibriNote, don't put in vice repository a "derived" test (i.e. copied). Just put my program. Pretty sure they'll add an unmodified version if you make it VICE test suite compliant (so it can be run in batch mode, without manual intervention).
They did with skew1.prg provided by me (https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/dri..) which also measures RPM, but only as a bonus. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting ZibriAnother note:
it's totally useless to use both VIA timers.
Considering the speed range of VICE, the difference between 275 RPM and 325 is 33566.4 cycles which is fine because it's smaller than the 65536 cycles the timer can give us. The point is that 2 timers can give accurate measurements of at least 30 bits, even without hardware cascading.
A revolution takes 200,000 cycles plus/minus tolerance, so you could measure that time pretty much directly. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
The question still is: by doing that, do we gain accurracy over the free running timer? Like Zibri said, we know already we will measure something close to 200000 cycles, and we dont have to be able to measure arbitrary times.
And yes, i'd prefer a simple small non interactive test program, similar to the existing ones :) |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting GroepazThe question still is: by doing that, do we gain accurracy over the free running timer? Like Zibri said, we know already we will measure something close to 200000 cycles, and we dont have to be able to measure arbitrary times. Granted, possibly no gain by extending the range. But there may be something with, e.g., using an additional timer with a period co-prime to the main free-running timer (maybe also pretty small, like 3 cycles). Could maybe be used to increase accuracy and counter the polling loop's jitter.
Or a second timer with exactly the polling loop's period... mh. :) |
| |
Copyfault
Registered: Dec 2001
Posts: 476 |
Never thought this would become *that* mathmatical ;)
Well, reading the word "Chinese remainder theorem" triggered me, so if we set the two VIAs to different (and coprime) timer values and trigger different irqs, we could implement the chinese remainder theorem 1:1.
But the approach with the differences is even better. While the Chin.remainder theorem states a certain "equality" between different modulo-class-rings, one can proof in a more or less direct way that, given M<N
Z_M X Z_N -> Z_N; (m, n) |-> n-m
is surjective with kernel isomorphic* to Z_M (the "smaller one").
Putting this straight (and less algebraic;)) this means that the difference (in Z_N, mind!) gives a measure of the relative positions of the numbers in Z_N and Z_M. Aplplying this to continously running timers, it exactly gives the no. of underflows modulo M.
At certain points the difference can result in a negative value; but since we're in modulo-class-rings, there's always a non-negative representative: in Z_N, this means n-m = N+n-m in case of n-m<0.
So the widest range should be achieved by setting one VIA timer to $ffff (as far as I understand timers, this effectively means 65536=$10000 cycles since it underflows after reaching 0) and the other to $fffe. Since the larger value is $ffff, we have N=65536 in the algebraic sense and the modulo is given automagically by the way the binary system works ;)
Really nice! Never thought that such "algebraic nonsense" *does* occur in practice. Makes me happy :)
*) "isomorphic" is usually used in mathmatics when certain abstract construction and maps between them are considered. It extends the idea of "being equal" to these concepts. Here we "only" take a closer look at modulo-class-rings, so it's ok to think of "numbers are equal modulo a certain number" here. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
As already stated in my program instructions, all you have to do is:
"U30"+chr$(tracknumber) (I suggest track 36 but any can be chosen) crates the test track.
"U31" times the "actual track" (so run in a loop after U30 can give you a result every revolution).
The result is on channel #15 and it's a "0" followed by 2 bytes which are the ramainder timer in little endian.
Then to get rpm all you have to do is:
RPM = 6000000000/(196603-Timer)
P.S.
The drive code is the last block of my program.
By doing
LOAD"rpm",8
even without running it the code is already loaded and ready in the drive :D
and you can, for example create the test track by just issuing:
open,15,8,15,"U30"+chr$(36)
get #15, a$,a$,b$
close15
The timer will be: TT=chr$(a$+chr$(0))+chr$(b$+chr$(0))*256
RPM will be as the formula above.
Remember to add 0.5 before doing INT in basic or you'll get a wrong result.
Later today I will post an example in basic that just gives a one shot result if you want. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
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: 11377 |
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: 11377 |
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. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: 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.
My program is BOTH stable and both accurate.
Unlike ANY other program ever done until now. (including gpz tool)
Sorry to sound rude, but really gpz showed to understand very little of 1541. He even asked me how does my program reset the lower byte of the VIA timer.
If he knew the 1541 or VIA and CIA chips he should know that writing to the higher nibble also resets the lower one.
And it shows also he tried to disassemble and reverse engineer my program instead of asking.
There is nothing wrong in asking and learning, but I really didn't like his attitude.
Sincerely, I have a nice life, I live since 4 years in one of the most wonderful places in the world, I have the best coral reef literally 50 meters from my door.
I was expecting curiosity about this program and I even prepared a document which explains everything I learnt so far on the 1541 and some techniques rarely (or never) used before. Nothing fancy. Just the result of a few weeks of study, from the schematics up to ROM disassembly (most of online ROM disassemblies have a lot of logical errors inside).
But after all this "drama" I really lost interest.
Don't get me wrong, I am not angry or anything, just a little disappointed.
Peace out.
Zibri |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
I'm not much into drive code, thats no secret. So what? And of course, i looked into your code with a disassembler so i can read it and see what it does. Why wouldnt i? None of this matters to the questions asked though. No idea why you get so winded up over it.
And yes, what Frantic said. Observing a program in VICE doesnt prove anything - because we have to assume VICE is wrong and we can not trust it. Likewise, the fact that the value is stable is unrelated to how accurate it is - it could still be totally wrong. What matters is the maximum deviation in the worst case. Repeating over and over how great your code is doesn't help - we already know its slightly more stable than my code. That doesnt mean we can assume or even trust on it being more accurate though.
Instead, the entire behaviour - and accurracy - of the program should be explained using nothing but the program itself, without having to run it. Then we can calculate the maximum deviation for the worst cases, ie when the reference track was written on a significantly too fast or too slow drive. The same kind of calculations should then be done for my tool as well, and only then we can tell how accurate either really is. That (and only that) is what the thread is about.
PS: both CIA and VIA copy the timer lowbyte from the timer latch on write to the high byte. That means your code relies on whatever the ROM initialized the timer latch with. Its not magically "reset". |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: I'm not much into drive code, thats no secret. So what? And of course, i looked into your code with a disassembler so i can read it and see what it does. Why wouldnt i? None of this matters to the questions asked though. No idea why you get so winded up over it.
And yes, what Frantic said. Observing a program in VICE doesnt prove anything - because we have to assume VICE is wrong and we can not trust it. Likewise, the fact that the value is stable is unrelated to how accurate it is - it could still be totally wrong. What matters is the maximum deviation in the worst case. Repeating over and over how great your code is doesn't help - we already know its slightly more stable than my code. That doesnt mean we can assume or even trust on it being more accurate though.
Instead, the entire behaviour - and accurracy - of the program should be explained using nothing but the program itself, without having to run it. Then we can calculate the maximum deviation for the worst cases, ie when the reference track was written on a significantly too fast or too slow drive. The same kind of calculations should then be done for my tool as well, and only then we can tell how accurate either really is. That (and only that) is what the thread is about.
PS: both CIA and VIA copy the timer lowbyte from the timer latch on write to the high byte. That means your code relies on whatever the ROM initialized the timer latch with. Its not magically "reset".
1) As I said 3 times, I repeat: my program is both accurate both stable on REAL drives and HW.
2) The "whatever the ROM initialized the timer latch with" is again ignorance: timer is initialized in ROM and it has the right value.
3) is not slightly more stable. Is totally accurate while your program is not and will never be unless you use a similar, "dervied" as you called it, code. Until then it will always be inaccurate and unreliable and that is easily proven.
4) "the program should be explained using nothing but the program itself" I don't agree with this. Prove my program is inaccurate or just shut up and stop showing off your "admitted" ignorance in drive code.
I don't get "winded up". I just don't like that the author of a horrible looking and totally inaccurate program states that mine "is yet to be seen" or that his is just "slightly off".
If you just want to setup up the drive speed you don't even need any program, there is a reference stroboscopic disc on every drive motor for that and tollerances are well over iven 5%... a 1541 works even at 295 or 305 without problems.
With my program you can write the track with a slow or fast drive and my program will still be accurate, by the way, because of how it is made.
I published my prigram and everyone is free to try it and compare it to any other program.
As far as I know (I might be wrong) there is no other program using this method even if a lot of program write a reference track. They just do it wrongly... not by much but not as accurately and precisely as this one.
My program is not "stable" because of tricks. It's stable because of how it works. Infact in a "fairly" good emulator any speed you set the drive to is reflected by my program to the CENT... and not by any other program I tested.
Now a silly note:
I was expecting a different reaction... like:
"thank you for sharing this nice program, after testing it on all supported drives and in emulators, I am impressed by it's accuracy! Would you be so kind to tell us how you did it?"
And expecting THAT reaction I was already preparing a document explaining it.
P.S.
I am not saying I am the best at this, since I think that paople like Krill are way better than me, but still nobody thought about this way and nobody implemented it.
That just wanted to be my small contribution to the ocean of software available for the C64. |
| |
Copyfault
Registered: Dec 2001
Posts: 476 |
Oh, oh, this disucssion went astray :(
@Zibri: don't get mad about this. My guess is that this thread was opened for the exact same reason you already started to write your document for. The questions put up by Groepaz were just born out of the curiosity on how to properly "compare" tools, in this case tools for testing the speed of floppy drives AND on the principles that are applied and their properties.
As I put it in the comments on your speed test tool: it's nice to have "competition" on the tools' side also these days. Maybe the word competition sparked wrong feelings; if so, I apologize for it! The c64 scene tends to get an understanding for literally everything in utmost detail (imagine the opposite, would we still be watching only standard scrollers as demos;)?).
So my suggestion is to take it as an honour that this thread was started - your work was the ignition for it and it shines even more that it's not only a nice piece of sw but also a starting point to understand even more! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
wow, just wow. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Oh, oh, this disucssion went astray :(
@Zibri: don't get mad about this. My guess is that this thread was opened for the exact same reason you already started to write your document for. The questions put up by Groepaz were just born out of the curiosity on how to properly "compare" tools, in this case tools for testing the speed of floppy drives AND on the principles that are applied and their properties.
As I put it in the comments on your speed test tool: it's nice to have "competition" on the tools' side also these days. Maybe the word competition sparked wrong feelings; if so, I apologize for it! The c64 scene tends to get an understanding for literally everything in utmost detail (imagine the opposite, would we still be watching only standard scrollers as demos;)?).
So my suggestion is to take it as an honour that this thread was started - your work was the ignition for it and it shines even more that it's not only a nice piece of sw but also a starting point to understand even more!
@Copyfault: Apologize? You did absolutely nothing wrong!
I know how the "scene" works.. I have always been "behind the scenes" in the past. believe me, I am not mad at all. A few people know me personally and they know I almost never get mad at someone and for sure not for a so little "skirmish".
I tried just to suggest (repeatedly) to gpz (by the way my initials are pgz hahahah) to take things a little more maturely because a "sane" competition is very healthy but saying "my program has only a minor jitter" or that my program (which he admittedly didn't understand) has something wrong. If I wrote it is, as I said, as an exercise and because after searching I didn't find any program that did the same in an accurate way.
About the how I did it, for non technical people the explaination is sort of long, but for you people I thought it was enough to say that I write a full long sync track and then I write 5 "5A" bytes on it and then I time the read of 6 bytes.
And no matter how slow or fast a drive is. It will always time a full revolution.
As most good things, in the end was a very simple solution, it just took 3 weeks of studying from the chematics to the ROM to learn as much as I could about it.
Ok let's play a different game: without disassembling my program, how would position the head on a track using DOS and not a custom $1c00 routine?
In my study I found two different ways, but one is "blind" and allows half track movement (but is not "dos" compliant) the other one is fully dos compliant and it was meant that way by commodore but I could not find it anywhere.
In stead there aother things I found by studying it.
Things that could lead to some proof of concept demos and maybe a better way to copy disks (but this is yet to be seen.. I am waiting to receive a 1541 to do further testing which I can't do in emulators) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
So will you contribute anything to finding the answer to the question of how big the standard deviation of either program is, or will you keep repeating how good your code is and how mine sucks (all 3 cycles jitter make it totally useless, everyone got this now)? |
| |
Copyfault
Registered: Dec 2001
Posts: 476 |
Quoting Zibri@Copyfault: Apologize? You did absolutely nothing wrong!
I know how the "scene" works.. I have always been "behind the scenes" in the past. believe me, I am not mad at all. A few people know me personally and they know I almost never get mad at someone and for sure not for a so little "skirmish". Good to read;) So I take it you are not too shocked about all the discussion.
Quoting ZibriI tried just to suggest (repeatedly) to gpz (by the way my initials are pgz hahahah) to take things a little more maturely because a "sane" competition is very healthy but saying "my program has only a minor jitter" or that my program (which he admittedly didn't understand) has something wrong. If I wrote it is, as I said, as an exercise and because after searching I didn't find any program that did the same in an accurate way. Hmmm, I think not every detail on how the differences between your and gpz code influence that jitter (and thereby the accuracy) has been fully understood. Pointing out how good a routine is or blaming the other one does not help in that. Or to put it in other words: your test prog seems hyper accurate, but the core reason for this is unclear to some (most?) people;)
Quoting ZibriAbout the how I did it, for non technical people the explaination is sort of long, but for you people I thought it was enough to say that I write a full long sync track and then I write 5 "5A" bytes on it and then I time the read of 6 bytes.
And no matter how slow or fast a drive is. It will always time a full revolution. This is another thing that at least I do not fully understand: is it really independant of the drive's speed? Or even more precise: if the test track gets written by a drive that is considerably slower (or faster resp.) than the one that is used for reading, does this have influence on the value the routine computes?
Quoting Zibri[...]Ok let's play a different game: without disassembling my program, how would position the head on a track using DOS and not a custom $1c00 routine?
In my study I found two different ways, but one is "blind" and allows half track movement (but is not "dos" compliant) the other one is fully dos compliant and it was meant that way by commodore but I could not find it anywhere. Just as Groepaz I have to admit I'm not really into drive code, but I'm nontheless interested in understanding underlying methods;) I bet it's just the very same for gpz!
Quoting ZibriIn stead there aother things I found by studying it.
Things that could lead to some proof of concept demos and maybe a better way to copy disks (but this is yet to be seen.. I am waiting to receive a 1541 to do further testing which I can't do in emulators) I'm really looking forward to these proof-of-concept-demos!!! Let's see what it will lead us to... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
After some more discussing with someone who really knows this stuff much better than i do (and who may or may not speak up here) we came to the conclusion that actually, there isnt much of a difference between the two methods/programs.
First, i have made a testprogram using the method with writing a test track and reading 6 bytes (see in the above linked repository). I did not copy Zibris code 1:1 but made some more or less trivial changes to make it more readable and to not rely on the ROM initializing the timer. However, none of those changes affect the timing/accuracy (only a few more or less cycles to compensate, but that doesnt matter). However, the result was that now the program also shows 3 cycles jitter in VICE (as i expected from the start, and wondered why it is not there). The reason is very likely that before it was metastable in VICE (since the drive CPU clock and the rotation are in perfect sync in the emulation, there can be cases where code is in perfect sync with the disk and shows no jittering at all - but this will never happen on real hardware).
Now, what causes the jittering in the code is the waiting for "byte ready", typically done by a BVC * - after that the code is in sync with the disk data, jittering 2 cycles.
What Zibris code does is basically this:
- wait for sync
- read a byte (now we are jittering 2 cycles)
- reset the timer
- read 5 more bytes (after that we are again jittering 2 cycles)
- read the timer
What my code (rpm2, lets ignore the first version for a while) does is
- wait for sync
- read a byte (now we are jittering 2 cycles)
- check if this is a sector header, if not repeat
- if yes read the header, check if it is sector 0, if not repeat.
- at this point the jittering is still 2 cycles
- reset the timer
- wait for sync
- read a byte (now we are jittering 2 cycles)
- check if this is a sector header, if not repeat
- if yes read the header, check if it is sector 0, if not repeat.
- at this point the jittering is still 2 cycles
- read the timer
so ultimatively, BVC * syncs to the disk (with two cycles jitter) two times in both cases. what happens in between doesnt actually matter, since the timer is free running. both measure the time for one revolution, both jitter pretty much the same way.
now the last case is the first version of the program, which reads all sector headers on a track and adds up the deltas. provided we dont miss a sector header for some reason, this does infact provide the same jitter, since again at sector 0 the timer will get resetted, and only checked after each header. its only overengineered unnecessary bolloks that can be omitted - but doesnt affect the jitter either.
as for "will the disk speed matter" - no, it doesnt. the answer is simple: the angular position of the referenced "markers" does not change, and their relative distance stays the same, and thats all that matters to the code.
so, the standard deviation is 15ppm or 0,0015%, ie 0,0045RPM for the observed 3 cycles jitter total - for all those programs.
we could, in theory, increase the accuracy/remove the jitter further by reading more bytes and adding a BVS *+2 half-variance kaskade. i'll leave that as an exercise to anyone who is crazy enough to think 15ppm isnt accurate enough already =P
case closed :) |
| |
soci
Registered: Sep 2003
Posts: 479 |
The drive code is incompatible with my fastloader of choice and the result is a "70, NO CHANNEL". There's no error handling of course to display if anything went wrong it just returns to the menu immediately.
I seem to get different readings for the original ROM vs. JiffyDOS.
It destroys data on track 36 and there's no warning that it does so. Is this really necessary for such a measurement?
There's no field to enter the base frequency from a frequency counter and therefore the displayed value can't be the "true" speed. Not that it matters much as there's no chance to set up 300.00 through that miniature pot on the board anyway. Different disks are different of course.
So in short please initialize everything properly in the drive and don't just assume it's state. Do a bit of error handling. The accuracy and jitter discussion is BS without any practical value (apart from the timer chaining method). If you want to create something truly useful and outstanding from the crowd please add a histogram display as the shape of the graph tells more from the condition of the drive than a single speed number. |
| |
Fungus
Registered: Sep 2002
Posts: 681 |
*pulls lid off drive, gets florescent light, adjusts pot, closes lid* |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
soci has leading! (try rpm3.prg from the vice repo, it does init things)
so indeed, we'll have to consider deviations of the clock itself too to really calculate the actual standard deviation :) i have no idea how much that typically is (before the drive stops working alltogether). anyone? :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: soci has leading! (try rpm3.prg from the vice repo, it does init things)
so indeed, we'll have to consider deviations of the clock itself too to really calculate the actual standard deviation :) i have no idea how much that typically is (before the drive stops working alltogether). anyone? :)
I'd say that an oscillator of that era would have something like +/- a 100-300 ppm unless very expensive. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
So an order of magnitude more than the accuracy of the program? soci has even more leading with calling the discussion BS =D
But, how much does it typically drift in practise though? I *have* seen drives that stopped working because the clock was totally off, but that probably happens rarely?
<strike>edit: wait, what frequency does the Oscillator have? 10Mhz?</strike>
So with 16MHz Crystal and assuming 100ppm, we get a deviation of 6,25 cycles on top. Assuming 300ppm its even 18,75 cycles, which is ~6 times as much as the anticipated 3 cycles deviation of the program.... |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: The drive code is incompatible with my fastloader of choice and the result is a "70, NO CHANNEL". There's no error handling of course to display if anything went wrong it just returns to the menu immediately.
I seem to get different readings for the original ROM vs. JiffyDOS.
It destroys data on track 36 and there's no warning that it does so. Is this really necessary for such a measurement?
There's no field to enter the base frequency from a frequency counter and therefore the displayed value can't be the "true" speed. Not that it matters much as there's no chance to set up 300.00 through that miniature pot on the board anyway. Different disks are different of course.
So in short please initialize everything properly in the drive and don't just assume it's state. Do a bit of error handling. The accuracy and jitter discussion is BS without any practical value (apart from the timer chaining method). If you want to create something truly useful and outstanding from the crowd please add a histogram display as the shape of the graph tells more from the condition of the drive than a single speed number.
did you ever take the time to read the instructions on github?
The program works on any original drive with original ROMS.
It even works (by pure luck) with Ocean 118 drive which has rdos.. only difference there is that the track change happens slowly (probably because they hijack the normal IRQ routines.
Quote:
It destroys data on track 36 and there's no warning that it does so. Is this really necessary for such a measurement?
Yes it is and it is clearly state in the instructions:
https://github.com/Zibri/C64-1541-Speed-Test
The program was not mean to work with any drive or any non standard configuration/rom.
This has been done on purpose.
Clearly the program was not meant for you. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: *pulls lid off drive, gets florescent light, adjusts pot, closes lid*
EXACTLY!
That is the right way to do it.
This program it's just for different purpose than setting the right speed (but for sure it's more comfortable for some that using the strobe). |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: After some more discussing with someone who really knows this stuff much better than i do (and who may or may not speak up here) we came to the conclusion that actually, there isnt much of a difference between the two methods/programs.
First, i have made a testprogram using the method with writing a test track and reading 6 bytes (see in the above linked repository). I did not copy Zibris code 1:1 but made some more or less trivial changes to make it more readable and to not rely on the ROM initializing the timer. However, none of those changes affect the timing/accuracy (only a few more or less cycles to compensate, but that doesnt matter). However, the result was that now the program also shows 3 cycles jitter in VICE (as i expected from the start, and wondered why it is not there). The reason is very likely that before it was metastable in VICE (since the drive CPU clock and the rotation are in perfect sync in the emulation, there can be cases where code is in perfect sync with the disk and shows no jittering at all - but this will never happen on real hardware).
Now, what causes the jittering in the code is the waiting for "byte ready", typically done by a BVC * - after that the code is in sync with the disk data, jittering 2 cycles.
What Zibris code does is basically this:
- wait for sync
- read a byte (now we are jittering 2 cycles)
- reset the timer
- read 5 more bytes (after that we are again jittering 2 cycles)
- read the timer
What my code (rpm2, lets ignore the first version for a while) does is
- wait for sync
- read a byte (now we are jittering 2 cycles)
- check if this is a sector header, if not repeat
- if yes read the header, check if it is sector 0, if not repeat.
- at this point the jittering is still 2 cycles
- reset the timer
- wait for sync
- read a byte (now we are jittering 2 cycles)
- check if this is a sector header, if not repeat
- if yes read the header, check if it is sector 0, if not repeat.
- at this point the jittering is still 2 cycles
- read the timer
so ultimatively, BVC * syncs to the disk (with two cycles jitter) two times in both cases. what happens in between doesnt actually matter, since the timer is free running. both measure the time for one revolution, both jitter pretty much the same way.
now the last case is the first version of the program, which reads all sector headers on a track and adds up the deltas. provided we dont miss a sector header for some reason, this does infact provide the same jitter, since again at sector 0 the timer will get resetted, and only checked after each header. its only overengineered unnecessary bolloks that can be omitted - but doesnt affect the jitter either.
as for "will the disk speed matter" - no, it doesnt. the answer is simple: the angular position of the referenced "markers" does not change, and their relative distance stays the same, and thats all that matters to the code.
so, the standard deviation is 15ppm or 0,0015%, ie 0,0045RPM for the observed 3 cycles jitter total - for all those programs.
we could, in theory, increase the accuracy/remove the jitter further by reading more bytes and adding a BVS *+2 half-variance kaskade. i'll leave that as an exercise to anyone who is crazy enough to think 15ppm isnt accurate enough already =P
case closed :)
hmm.. try starting *your* test on a real drive running at a very low or very high speed. then start your reading and try to set it to 300.00
then recheck the speed with strobe or with my program.
Come on dude.
As I stated, my program is the most accurate SO FAR in 40 years.
Now if anyone wants to learn from it, you are all welcome.
Nice of you explaining to others what I explained you in a private message.
The last phrase in the above message makes me laugh so much.
Is it so difficult to accept I wrote a program that does something new and right?
And that no other program including yours as it was before mine, could?
Really?
How sad is this? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: So will you contribute anything to finding the answer to the question of how big the standard deviation of either program is, or will you keep repeating how good your code is and how mine sucks (all 3 cycles jitter make it totally useless, everyone got this now)?
No.. but they got that all I did was to post a program more accurate that any other BEFORE it.
And that *you* made a case out of this.
Even this useless thread was started by you.
If you don't realize this, I can't help it.
And still: my program is the most accurate ever published until the release date.
Deal with it.
And quit all this childish, passive aggressive "discussion".
As I even wrote in my instructions: accuracy is not even needed to have a drive working. The tollerances are very high.
This program helps a bunch of friends of mine who repair drives.
That's all.
And just incidentally it is the most accurate.
Which clearly is all you can see about it.
Personally I also like the big rpm petscii font and even the "dot-in-a-dot" flashing at every update (2 per second in this version).
The program also sports a new way to move the head using DOS but in an agnostic way (no disk needed).
The program has also other functions, but they are only available to who takes the time to read the instructions.
And they are there just for testing/fun/programming.
All this and the only thing you can see is that I shamed your ugly program? gneeeeeee sorry dude... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:Nice of you explaining to others what I explained you in a private message.
Like that your program is "100 times" more accurate than mine, and that VIA timer lowbyte is "resetted" when the highbyte is loaded? OK.
I'd rather stick to facts :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quote:Nice of you explaining to others what I explained you in a private message.
Like that your program is "100 times" more accurate than mine, and that VIA timer lowbyte is "resetted" when the highbyte is loaded? OK.
I'd rather stick to facts :)
And those are both facts.
1) My program is 100 times more accurate than yours (or anyone else) is/was.
2) to reset the VIA timer you just need to read the lower byte or to write the upper one. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
OK. That means may program deviates by 3 RPM and the timer wasnt initialized by the ROM at all. again what learned!
Meanwhile someone with a clue provided a nice diagram - he measured the oscillator clock over time (deviation from 16Mhz on Y, seconds on X): https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/dri.. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: OK. That means may program deviates by 3 RPM and the timer wasnt initialized by the ROM at all. again what learned!
Meanwhile someone with a clue provided a nice diagram - he measured the oscillator clock over time (deviation from 16Mhz on Y, seconds on X): https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/dri..
No wonder your program was wrong if this the only thing you learned. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Yes its wrong. You can see it clearly by how it has the exact same deviation as yours. Can you say it once more? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Yes its wrong. You can see it clearly by how it has the exact same deviation as yours. Can you say it once more?
I just see you copied my program concept and method.
Inspired my a$$.
both rpm2 and rpm3 were "inspired" by my program.
And again your program is total rubbish.
Run VICE: set the speed to 292.71 and run your "rpm.d64" program.
Total bogus values.
I told you and I repeat:
check all speeds btween 275.00 and 325.00 in increments of 0.01 and then see.
Not only you get wrong the last digit but you sometimes get wrong all of them and even the unit.
At 292.71 it even shows: 293.08 ! hahaha
My program does not that.
Why?
BECAUSE IT IS WELL WRITTEN. PERIOD. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
huahuahua
Your masterpiece:
https://pasteboard.co/JkYYmrT.png
my humble program:
https://pasteboard.co/JkYYOzE.png
:P
Really,
please, stop. If you don't understand why my program is correct, that's fine.
But as I told you there is no way to be accurate using different methods.
There will always be situations and values where any other program will fail.
And not mine.
The reason is how it is made.
Search the term "cognitive dissonance" to understand what you are going through. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
It's sad to see that this thread derailed. I'm really curious to read an explanation on what makes this new method superior with regards to accuracy/repeatability. I think ignoring counting the overflows because you know how many will occur within the useful range is kind of clever.
Also most speed tests I saw before used the approach to measure on c64-side which obviously has its limitations. Measuring on the drive-side is much better. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: It's sad to see that this thread derailed. I'm really curious to read an explanation on what makes this new method superior with regards to accuracy/repeatability. I think ignoring counting the overflows because you know how many will occur within the useful range is kind of clever.
Also most speed tests I saw before used the approach to measure on c64-side which obviously has its limitations. Measuring on the drive-side is much better.
Well, I never analyzed deeply other methods but the few I tried were using some drive side code.
The method has been already discussed but I can summurize it for you:
Test track creation:
1) create a test track made of all "1".
2) write 5 bytes (starting and ending with a 0) to the track.
Measurement:
1) skip "data" (not really needed but in a rare situation it can make the program fail)
2) read one byte and start (reset to FFFF) the timer.
3) read 5 bytes (the fifth will be the first we skipped)
4) stop the timer and send the value back to the front-end.
On the fron-t end side my program just subtracts 5 to the rotation time (because my program stops the time 5 cycles after the last read) then divide 6000000000 by the calculated time and get the integer part that will be 100 times the real value.
This is the method used and this is the only method that will give you this accuracy.
No other methods (unless derived by this one) will be as accurate.
And no other program writte in 40 years was.
That was my personal challenge.
And I find the rpm display beautiful and perfect for laboratory use since it can be read from far.
Also for how I wrote the program, front ends can be done even in basic and run on any computer from the VIC20 or PET to any other using these drives.
Obviously it even worked in VICE using a real drive connected to a laptop.
Note:
In all my tests, commenting the "skip data" does not alter the results nor give any jitter though |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:I'm really curious to read an explanation on what makes this new method superior with regards to accuracy/repeatability.
same :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Yes its wrong. You can see it clearly by how it has the exact same deviation as yours. Can you say it once more?
Even your "inspired" rpm2.prg fails miserably my tests.
Set the speed of VICE to: 313.71 (with 0.00 wobbling)
And your second "inspired" plagiarism will anyway JITTER the second decimal digit.
I didn't test all possible values, but I had similar results with the early versions of my program until I understood the only good method is the one I used after that experience.
Your second "inspired" masterpiece:
https://pasteboard.co/JkZE3PK.png
My humble program:
https://pasteboard.co/JkZEMWF.png
:D |
| |
Jammer
Registered: Nov 2002
Posts: 1335 |
I won't be very constructive here but:
I had no fuckin' idea that thread about measuring drive RPMs might be THAT exciting :D |
| |
iAN CooG
Registered: May 2002
Posts: 3187 |
Jammer: I was about to post this gif myself in the release comment as soon as gpz wrote his reply but I said "nah, better refrain in pouring more gas in the fire" :D |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: I won't be very constructive here but:
I had no fuckin' idea that thread about measuring drive RPMs might be THAT exciting :D
LOL! Me neither :D |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Jammer: I was about to post this gif myself in the release comment as soon as gpz wrote his reply but I said "nah, better refrain in pouring more gas in the fire" :D
What fire? Oh.. you mean the one under gpz butt... hmmm maybe he eat something too hot...dunno :P |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:I didn't test all possible values, but I had similar results with the early versions of my program until I accidently reached metastability.
fixed |
| |
Jammer
Registered: Nov 2002
Posts: 1335 |
Quoting ZibriLOL! Me neither :D
I refer mainly to your purely narcissistic reactions which are really, really cringy :D With all respect to your knowledge on the field ;) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriThe method has been already discussed but I can summurize it for you:
Test track creation:
1) create a test track made of all "1".
2) write 5 bytes (starting and ending with a 0) to the track.
Measurement:
1) skip "data" (not really needed but in a rare situation it can make the program fail)
2) read one byte and start (reset to FFFF) the timer.
3) read 5 bytes (the fifth will be the first we skipped)
4) stop the timer and send the value back to the front-end.
On the fron-t end side my program just subtracts 5 to the rotation time (because my program stops the time 5 cycles after the last read) then divide 6000000000 by the calculated time and get the integer part that will be 100 times the real value.
This is the method used and this is the only method that will give you this accuracy.
I understand the method, but I'd love an explanation on why it is more accurate.
When I've done speed tests in the past I've used the seek sector 0 appoach. Although it's obvious that your method of not actually checking the sync is different, it's not obvious to me as to why that makes a difference in result.
Quoting ZibriAnd I find the rpm display beautiful and perfect for laboratory use since it can be read from far.
I agree, the presentation is nice. |
| |
hedning
Registered: Mar 2009
Posts: 4724 |
I don't know shit about this, and should shut up, but I get strangly aroused by it, so keep on talking. :D
 |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quote:I didn't test all possible values, but I had similar results with the early versions of my program until I accidently reached metastability.
fixed
1) I never wrote such a thing.
2) I am not your beta (alpha) tester.
3) I don't agree with anything you said about this subject.
Sure you can use trick, fixes and patches. That happens when code is wrong.
My code has no fixes. No value corrections. It just counts right.
End of story.
I won't fuel anymore this useless debate.
I was hoping to find a different environment from which even learn something.
I just found some curious persons (and that's fine) and someone bragging without bringing a shred of code or evidente to his claims.
And filling the gaps with "I don't know why your program is stable or accurate" or other useless childish phrases.
I have to prove nothing to you or anyone else.
Prove my program is wrong or that there was a BETTER program before I released mine.
Or just shut up or continue this "debate" alone.
Bye bye |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
_I_ was bragging? =D
Quote:I understand the method, but I'd love an explanation on why it is more accurate.
When I've done speed tests in the past I've used the seek sector 0 appoach. Although it's obvious that your method of not actually checking the sync is different, it's not obvious to me as to why that makes a difference in result.
this. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Quoting JammerI had no fuckin' idea that thread about measuring drive RPMs might be THAT exciting :D
I thought of suggesting the continuation of this mesmerising thread inside new demos' scrolltexts :-) Wow - nostalgia... |
| |
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: 11377 |
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: 11377 |
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. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Silver Dream !
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.
And that's where the configure program comes into play:
just set 41 as your test track and you are good to go.
Instructions were incomplete at the time a friend of mine uploaded the program to csdb, but it is written clearly in the instructions on github. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:The reading is not in sync with a clock, but with the written bits.
exactly. and every time 8 bits arrived in the shift register, V flag is being set to signal just that. in turn that means after every byte (BVC *) we are in sync (with 2 cycles jitter) to the bits on the disk. it doesnt matter how often we do this, every single time we are again in sync. if that wouldnt be the case, you wouldnt be able to read more than a couple bytes without an extra sync marker. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazQuote:The reading is not in sync with a clock, but with the written bits.
exactly. and every time 8 bits arrived in the shift register, V flag is being set to signal just that. in turn that means after every byte (BVC *) we are in sync (with 2 cycles jitter) to the bits on the disk. it doesnt matter how often we do this, every single time we are again in sync. if that wouldnt be the case, you wouldnt be able to read more than a couple bytes without an extra sync marker.
Yes, that is obvious, but I don't understand what you are trying to say.
Since we count the time, yes we are in sync, but it will take more or less time depending on drive speed.
But in that way you are anyway counting bytes.
That's unacceptable inaccuracy in my book.
I thought of counting bits, and it was ok, but the program was overly complex.
My final approach resulted to be the best.
I see no reason to change it. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
What i am trying to say is that there is no difference between how many bytes we are reading before starting and reading the timer, as long as we are doing it at the same angular position on the disk. How fast those bytes were written doesnt matter either, because our reference point to start and stop is still the same angular position on the disk. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: What i am trying to say is that there is no difference between how many bytes we are reading before starting and reading the timer, as long as we are doing it at the same angular position on the disk. How fast those bytes were written doesnt matter either, because our reference point to start and stop is still the same angular position on the disk.
I am puzzled by why this would make a difference too. A sector header is normally 40 bits of sync followed by a $52 byte, then 9 more bytes so the pattern isn't really that different. Would stopping reading the header after 5 bytes yield better accuracy? I'd love a better explanation! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:How fast those bytes were written doesnt matter either, because our reference point to start and stop is still the same angular position on the disk.
apropos, if that wasnt the case - then the exact same problem would exist with using a special reference track (unless you rewrite it all the time). |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quote:How fast those bytes were written doesnt matter either, because our reference point to start and stop is still the same angular position on the disk.
apropos, if that wasnt the case - then the exact same problem would exist with using a special reference track (unless you rewrite it all the time).
Wrong. Just wrong. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: I am puzzled by why this would make a difference too. A sector header is normally 40 bits of sync followed by a $52 byte, then 9 more bytes so the pattern isn't really that different. Would stopping reading the header after 5 bytes yield better accuracy? I'd love a better explanation!
Sorry but I don't follow.
Please write all program logic from start to end and I will tell you if it is sound or not.
From when you start the timer to when you stop it, I mean. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: What i am trying to say is that there is no difference between how many bytes we are reading before starting and reading the timer, as long as we are doing it at the same angular position on the disk. How fast those bytes were written doesnt matter either, because our reference point to start and stop is still the same angular position on the disk.
Same here. Show me the program logical flow, because I am getting lost in all this theoretical talking.
Anyway, what you read before starting the timer, depending how you do it could influence the ooutcome by starting the timer too early or too late (for example when reading SYNCs).
If you are talking about:
1) read sync.
2) check if sector 0
3) start timer
4) read sync
5) is it sector 0? no, goto 4
6) stop the timer.
That could work it just induces more problems than advantages and I can think of a few situations where this approach is unreliable: first of them all is that you don't know who formatted the disk and using what.
I can format a disk in a way that it works for DOS but will make such a program fail.
My program can't fail.
And that's why I coded it in that way. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:Wrong. Just wrong.
please explain why
Quote:Please write all program logic from start to end and I will tell you if it is sound or not.
it's all in post #30. please explain why not if. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Oh and I remind you,
my purpose when I wrote it was to write the most accurate program ever made and without needing a "master" pre-recorded diskette.
Then it became a tool also for aligning and help a few friends who fix drives to move the head around, align it and check the status of the rubber belt and capacitors.
When I will have my 1541 I will add a few more features which I can't test on the emulator.
Or maybe just do a different utility.. I don't know. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quote:Wrong. Just wrong.
please explain why
Quote:Please write all program logic from start to end and I will tell you if it is sound or not.
it's all in post #30. please explain why not if.
And ruin all the fun?
Do a program that does not write a test track.
A program without "value fixes" or special situation IFs.
And I will always be able to produce a disk that will make it fail.
Write a test track and that would never happen.
My program just can't fail and that was the purpose.
And I accomplished my own challenge.
And again:
My program is the most accurate ever made in 40 years at the time of release. It has no jittering, no errors and works flawlessly in all situations (if the drive is able to write and the disk is in average shape).
How can I make it clear to you that I am not interested in theorizing other alternatives since I found the best one in 40 years I am more than satisfied.
Now, I value comments like the one of Silver Dream (I didn't even know what Dolphin DOS was before he mentioned it).
And if there are any suggestion to further improve my program I am listening.
But I won't make my program bigger just to include warnings or idiot proofing when all people need to do is to RTFM (on github).
Have a nice day. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:And I will always be able to produce a disk that will make it fail.
that's totally out of scope of the discussion. of course we are assuming a standard DOS formatted disk. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Groepaz
it's all in post #30. please explain why not if.
I will try again to explain it but you seem not to be willing to listen to a simple fact:
If you don't write the track yourself, you are assuming it's fine, which it can be wrong.
In any laboratory test, the conditions of the test must be known and verifiable.
To do so usually a "master disk" written by very precise drives, is used.
My program creates such a measuring track so to have a reference that is SURE is as it is intended to be.
Anyway, until now I still haven't seen a program able to determine RPMs in a reliable way (and not just in emulators).
Not useful, perhaps. But I liked the challenge. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriSame here. Show me the program logical flow, because I am getting lost in all this theoretical talking.
Anyway, what you read before starting the timer, depending how you do it could influence the ooutcome by starting the timer too early or too late (for example when reading SYNCs).
If you are talking about:
1) read sync.
2) check if sector 0
3) start timer
4) read sync
5) is it sector 0? no, goto 4
6) stop the timer.
Exactly. The timer should be started after reading the header as you write, so that would be after a bvc *. This is how the tests I examined worked, and also how I chose to implement mine in the past. Most of them (including mine) measured timing c64-side though so the accuracy would obviously be much less because of that.
The obvious advantage of this appoach is that it works without writing to the disk. The downside is, like you point out, that it won't work with a very out of range rotational speed or malformed diskette formatting. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quote:And I will always be able to produce a disk that will make it fail.
that's totally out of scope of the discussion. of course we are assuming a standard DOS formatted disk.
Never assume. There are fast format program who format a "working" disk which is far from standard anyways.
It's not out of scope at all.
To be precise:
your "approach" would work if your program will also format a disk in a very standard way.
In the end it will be slower and trash an entire disk.
I opted for writing a simple test track. I could even reformat a standard track but it would have been the same.
A waste of time and resources when a simpler approach solves all problems without any downside. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
It will work fine whenever there is exactly one sector 0 header on the tested track. doesnt matter how it was written at all, because the last bvc * is the reference point. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlrThe downside is, like you point out, that it won't work with a very out of range rotational speed or malformed diskette formatting.
And that's why all professional tools use a master disk.
Mine creates such a track without the need of a pre-mastered disk.
Also, it creates the track in a "smart" way that is very easy to manage and that leaves no space to errors. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriI can format a disk in a way that it works for DOS but will make such a program fail.
This is kind of interesting, how? Multiple sector 0 headers on the track? That would be kind of evil but assuming nothing on the disk references sector 0 of that particular track it could work fine in DOS i guess. :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazIt will work fine whenever there is exactly one sector 0 header on the tested track. doesnt matter how it was written at all, because the last bvc * is the reference point.
Again: you seem not to care about the implications. I did.
What if the track is not even formatted? What if the disk had some custom loader (like krill or the other one with even custom GCR?!).
Please, stop this discussion.
You assume a lot of things. My program is agnostic.
As I am. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:that's totally out of scope of the discussion. of course we are assuming a standard DOS formatted disk.
the thread is about comparing how accurate the two methods are, not how you can make them fail using non standard disks. please stick to the topic. you still havent explained some of your claims regarding accuracy.
tlr: eg you could put two sector 0 headers after each other, and only one of them is followed by a data block - that will work fine (for reading at least). copy protections used this, as a simple copier will not recreate this. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Groepaz
the thread is about comparing how accurate the two methods are, not how you can make them fail using non standard disks. please stick to the topic. you still havent explained some of your claims regarding accuracy
Mine are not "claims".
The proof is my program itself and no progranm before that could accomplish the same results including yours.
Even after the modifications.
I even tested your programs since you clearly didn't even take the time to test them before committing them.
The screenshots are more than eloquent.
I repeat: I have nothing to prove nor to explain to you nor anybody else. If you wanted to learn something you use the worst attitude to do so.
Sorry, but I really am not in the mood to be teaching anything to you. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
So i take it that you can not explain why one method is supposed to be more accurate than the other, nor explain why the explanation in post #30 is false. Repeating the same claims over and over does not help, nor prove anything. Forget my program, my program (or anyone elses) is irrelevant for explaining how accurate yours is. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: So i take it that you can not explain why one method is supposed to be more accurate than the other, nor explain why the explanation in post #30 is false. Repeating the same claims over and over does not help, nor prove anything. Forget my program, my program (or anyone elses) is irrelevant for explaining how accurate yours is.
Bite me.
Live with it. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
If anyone is interested some made even a video tutorial (in italian, but automatic sbutitles seem to work about fine).
https://www.youtube.com/watch?v=p87sw33byYY |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
"Some" |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Pretty cool, he even let you work on his drive! |
| |
Rebok
Registered: Apr 2017
Posts: 10 |
Zibri, what about the station 1541-II. Is there a similar way to adjust? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Take off the top cover, the pot is on the small motor control board |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
I know how to double the accuracy.... |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting HoogoI know how to double the accuracy....
Multiple laps at once, no? Don't forget the 16 MHz timebase though, you might need a rubidium clock fed from a GPS to reach that level. :)
Though it would make sense to do a running average over a few laps though to make for a less twitchy measurement. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting HoogoI know how to double the accuracy....
You mean by averaging or by making 2 laps instead of one? If it's some other way it's interesting but more accurate than this is somehwt useless.. yet it's interesting :D |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlrQuoting HoogoI know how to double the accuracy....
Multiple laps at once, no? Don't forget the 16 MHz timebase though, you might need a rubidium clock fed from a GPS to reach that level. :)
Though it would make sense to do a running average over a few laps though to make for a less twitchy measurement.
Hmm I find the "wobbling" a very interesting data. It tells you the state of the rubber belt and the capacitors (in that case speed will increase gradually while it's running). |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
For the time being and until proven without a doubt or at least until a sound theory is presented, we can regard the discussed drive-side methods as equal.
They measure the duration of a revolution with a fixed reference clock counting from a fixed reference point (angle) on the disk to the same point a revolution later.
They will produce a 2-cycle jitter (3 cycles variance), due to the bvc *, on top of the 16 MHz oscillator's tolerance (which has the bigger part in that), on top of natural rotational wow/disk wobble/flutter (probably the biggest part in that).
Any deviation from that would be caused by implementation flaws (e.g., timer handling bugs), meta-stabilities, emulator side-effects, or implementation differences (such as converting cycle counts to a float RPM value using different conversion/averaging algorithms).
Now, although somewhat pointless, getting rid of the 2-cycle jitter might be achievable by a half-variance technique operating on 2 additional byte-sync points, quite similar to syncing drive and host CPU in a fastloader with a synchronous transfer protocol.
Quoting ZibriWhat if the disk had some custom loader (like krill or the other one with even custom GCR?!). Not sure which loader you're referring to, but running on plain standard format, both low-level and file system, is what i deal in with the public IRQ loader. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting KrillFor the time being and until proven without a doubt or at least until a sound theory is presented, we can regard the discussed drive-side methods as equal.
They measure the duration of a revolution with a fixed reference clock counting from a fixed reference point (angle) on the disk to the same point a revolution later.
They will produce a 2-cycle jitter (3 cycles variance), due to the bvc *, on top of the 16 MHz oscillator's tolerance (which has the bigger part in that), on top of natural rotational wow/disk wobble/flutter (probably the biggest part in that).
Any deviation from that would be caused by implementation flaws (e.g., timer handling bugs), meta-stabilities, emulator side-effects, or implementation differences (such as converting cycle counts to a float RPM value using different conversion/averaging algorithms).
Now, although somewhat pointless, getting rid of the 2-cycle jitter might be achievable by a half-variance technique operating on 2 additional byte-sync points, quite similar to syncing drive and host CPU in a fastloader with a synchronous transfer protocol.
Quoting ZibriWhat if the disk had some custom loader (like krill or the other one with even custom GCR?!). Not sure which loader you're referring to, but running on plain standard format, both low-level and file system, is what i deal in with the public IRQ loader.
Now, this is a real honor since I consider you a JEDI in these kind of things. I am a humble padawan :D
Hmm I sincerely have no idea hot to get rid of the 2 cycle jitter without significantly hinder the speed.
If you care to elaborate I would be glad to implement it. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
This is also one of the basic techniques as used for stabilising raster routines.
Depending on density (track zone), there are a nominal 26/28/30/32 cycles between two GCR bytes rolling in from disk.
After having synced to the first byte using a plain "bvc *", delay according to density such that a "bvc * + 2" would take 2 cycles if byte-sync (branch not taken) or 3 cycles if no byte-sync (branch taken). We're now down to a one-cycle jitter. Repeat to get down to 0 cycles.
Of course, the disk will keep on wobbling, so there is some error left. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:we can regard the discussed drive-side methods as equal
say it isn't so :o) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: Quote:we can regard the discussed drive-side methods as equal
say it isn't so :o)
You, baby, clearly didn't read the phrase:
Quote:Any deviation from that would be caused by implementation flaws (e.g., timer handling bugs), meta-stabilities, emulator side-effects, or implementation differences (such as converting cycle counts to a float RPM value using different conversion/averaging algorithms). Which is one of the reason your program was a random generator before you saw mine.
Also. And I repeat it: you program assumes a normal disk and you can't be sure of that unless you format it yourself like my program does.
End of discussion with you.
You failed multiple times in front of everyone.
Aren't you tired?
Peace out. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
oh boy =D |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting KrillThis is also one of the basic techniques as used for stabilising raster routines.
Depending on density (track zone), there are a nominal 26/28/30/32 cycles between two GCR bytes rolling in from disk.
After having synced to the first byte using a plain "bvc *", delay according to density such that a "bvc * + 2" would take 2 cycles if byte-sync (branch not taken) or 3 cycles if no byte-sync (branch taken). We're now down to a one-cycle jitter. Repeat to get down to 0 cycles.
Of course, the disk will keep on wobbling, so there is some error left.
I partly understand this.
Really, I am just a padawan, there's a lot I still have to learn.
My program writes at the lowest density using "00" clocks in 1c00 which is synchronous with the cpu clock. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
That explains the metastability =D |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting ZibriMy program writes at the lowest density using "00" clocks in 1c00 which is synchronous with the cpu clock. Yes, you're operating on track 36, which is in the lowest density zone of tracks 31 and up.
I have a hunch that operating on the highest density instead would somewhat improve accuracy, but this of course on top of inaccuracies that are orders of magnitude bigger than 1 MHz clock cycles. :) |
| |
Smasher
Registered: Feb 2003
Posts: 519 |
Ciao Zibri. just a little request from me, then I'll follow this interesting thread in silence again...
Quote:I was expecting curiosity about this program and I even prepared a document which explains everything I learnt so far on the 1541 and some techniques rarely (or never) used before. Nothing fancy. Just the result of a few weeks of study, from the schematics up to ROM disassembly (most of online ROM disassemblies have a lot of logical errors inside).
But after all this "drama" I really lost interest.
please don't! I'd really appreciate if you'll publish that txt one day. I'm not saying I'll understand much of what you discovered, but others will. sharing is caring. grazie! :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ZeSmasherCiao Zibri. just a little request from me, then I'll follow this interesting thread in silence again...
Quote:I was expecting curiosity about this program and I even prepared a document which explains everything I learnt so far on the 1541 and some techniques rarely (or never) used before. Nothing fancy. Just the result of a few weeks of study, from the schematics up to ROM disassembly (most of online ROM disassemblies have a lot of logical errors inside).
But after all this "drama" I really lost interest.
please don't! I'd really appreciate if you'll publish that txt one day. I'm not saying I'll understand much of what you discovered, but others will. sharing is caring. grazie! :)
Don't worry.. I will release that too.
Sometimes I just get itchy when some ignorant with an inferior program launches accusations and asks for proof when CODE is all the proof you need.
He spoke about theory but in practice, before mine there was no accurate program.
Anyway, don't worry, if anyone is interested I am happy to discuss it, but don't overestimate me.. I am no Krill :D
Prego. :D |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting KrillQuoting ZibriMy program writes at the lowest density using "00" clocks in 1c00 which is synchronous with the cpu clock. Yes, you're operating on track 36, which is in the lowest density zone of tracks 31 and up.
I have a hunch that operating on the highest density instead would somewhat improve accuracy, but this of course on top of inaccuracies that are orders of magnitude bigger than 1 MHz clock cycles. :)
Well.. density as you know is not bound to tracks... I coould use density 00 even for track #1.
I saw no praticular improvement by using track 1 instead of 36 or 42 even. But I also feel that maybe I am missing something.
The important thing for now is that my program works, it's stable and has accurate results (as useful/useless they can be).
I really don't know if my program is more accurate because is better coded or has a better method.
In theory the waitforsec0 should work but I have see no implementation of that method giving accurate results in any program I tested. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
The problem is that you are mistaking metastability for accurracy. your code shows the same 3 cycles jumping numbers as the sector0 waiting if you change it slightly (constant time, which does not affect accurracy at all). Likewhise if someone is really bored, he can probably shuffly cycles around in the sector0 waiting code and make it metastable too.
And yes, the whole thread is about theory and methods, not bickering about someone elses code. |
| |
Copyfault
Registered: Dec 2001
Posts: 476 |
Quoting KrillThis is also one of the basic techniques as used for stabilising raster routines.
Depending on density (track zone), there are a nominal 26/28/30/32 cycles between two GCR bytes rolling in from disk.
After having synced to the first byte using a plain "bvc *", delay according to density such that a "bvc * + 2" would take 2 cycles if byte-sync (branch not taken) or 3 cycles if no byte-sync (branch taken). We're now down to a one-cycle jitter. Repeat to get down to 0 cycles.[...] Just a thought: couldn't it be done by using an auxiliary timer that "measures" the potential variance?
Something like:
1. start a 3-cycle-timer (running continously)
2. wait for sync
3. start main timer (used for speed calculation later) + in the same moment(=directly after main timer start) save the value of the aux timer as a reference value
4. wait for sync
5a. calculate the speed with the main timer
5b. calculate the differnce between the current value of the aux timer and the ref value stored before (this should be the variance)
Maybe I'm on the wrong track... after all, I guess the remaining 2-cycle-jittering is not worth the trouble.
Something that really bugs me in the chosen approach is the non-linearity: the "resolution" of the speed-value is seemingly higher the slower the drive is. Since we do a const/x-type calculation, this is no surprise. Is there really no sane way to precisely determine the position on a test-track after a constant number of cycles? This would enable us to have a linear dependance, i.e. drivespeed = byte / c, with constant c and the byte being given by the position on the track.
I slowly start to understand more and more that there is no good way to do this with the given properties of the 1541. Guess I have to accept the non-linear approach as is. But someone please prove me wrong;) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazAnd yes, the whole thread is about theory and methods, not bickering about someone elses code. Which is exactly what you are doing from the start. So stop. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:Which is exactly what you are doing from the start. So stop.
I have exactly ONCE posted something around those lines, and immediatly corrected myself and apologized. Since then, you are flooding this thread with how great your code is and how much everyone elses sucks. Indeed, please stop. It doesnt contribute anything to this thread at all. Do you realize Krill pretty much acknowledged what i wrote in #30? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Copyfault Guess I have to accept the non-linear approach as is. But someone please prove me wrong;) I can't. I think you are right. I had the same thoughts.
About the 2 cycle jitter I also thought of writing 5 bytes + 1 bit. In that way, reading the last byte should tell us it there was a jitter or not.
But again.. I don't think if that is relevant/useful at all. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazDo you realize Krill pretty much acknowledged what i wrote in #30? Sure he did. And do you realize you (or anyone else) were not able to implement it right? At the time I released my program there was no accurate program released.
Please, really, stop this. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
It doesnt matter who implemented what. The thread is about theories and methods, not someones code.
But now that you acknowledge that what i wrote in #30 is actually correct, you might want to reread some of the thread. It's a step forwared afterall. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting CopyfaultJust a thought: couldn't it be done by using an auxiliary timer that "measures" the potential variance?
Something like:
1. start a 3-cycle-timer (running continously)
2. wait for sync
3. start main timer (used for speed calculation later) + in the same moment(=directly after main timer start) save the value of the aux timer as a reference value
4. wait for sync
5a. calculate the speed with the main timer
5b. calculate the differnce between the current value of the aux timer and the ref value stored before (this should be the variance)
Thought about such an approach as well, but i think it falls flat due to the fact that the bvc polling loop has a given granularity of N = 3 cycles.
You start an aux timer before the loop, run for N * 3 cycles, then read the aux timer. It will have run for N * 3 plus a constant number of cycles and not tell you anything below that granularity.
What might work is controlling a cycle-counting timer in hardware via the byte-sync signal, but afaik there is not such facility in the 1541. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazIt doesnt matter who implemented what. The thread is about theories and methods, not someones code.
But now that you acknowledge that what i wrote in #30 is actually correct, you might want to reread some the thread. It's a step forwared afterall. If all it takes to make you shut up and free this thread from your useless comments is to aknlowledge that your obvious theoretical statements were true: for sure they were.
But what counts for me is code. Code that works. Reliable code. (And a pleasant output too). |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting KrillThought about such an approach as well, but i think it falls flat due to the fact that the bvc polling loop has a given granularity of N = 3 cycles.
You start an aux timer before the loop, run for N * 3 cycles, then read the aux timer. It will have run for N * 3 plus a constant number of cycles and not tell you anything below that granularity.
What might work is controlling a cycle-counting timer in hardware via the byte-sync signal, but afaik there is not such facility in the 1541. Same here. Another approach was to write one bit more. The last byte read will be different if there was a jitter. Doing so I redeuced significantly the jitter in another version but at the time something was not working.. don't remember what. But I think that also could be an interesting approach. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:If all it takes to make you shut up and free this thread from your useless comments
if you wont mention again you were the first to implement something, and wrote the only stable program (which is metastable but ok), perhaps. but i doubt it :)
Quote:But what counts for me is code. Code that works. Reliable code. (And a pleasant output too).
Make a seperate thread for code praising then, please. This thread is about methods and theories and the accurracy of said methods. Thanks. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Groepazgne gne gne gne gne gne
https://www.youtube.com/watch?v=kMsrE-9CLFg |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting ZibriAnother approach was to write one bit more. The last byte read will be different if there was a jitter. Doing so I redeuced significantly the jitter in another version but at the time something was not working.. don't remember what. But I think that also could be an interesting approach. Per-bit update without byte granularity works by disabling the latching in the VIA, and that in turn only works on long-board 1541 (or Oceanic). 1541-II with gate-array instead of discrete glue logic will always only give you byte by byte. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting KrillQuoting ZibriAnother approach was to write one bit more. The last byte read will be different if there was a jitter. Doing so I redeuced significantly the jitter in another version but at the time something was not working.. don't remember what. But I think that also could be an interesting approach. Per-bit update without byte granularity works by disabling the latching in the VIA, and that in turn only works on long-board 1541 (or Oceanic). 1541-II with gate-array instead of discrete glue logic will always only give you byte by byte. Good to know. I didn't know that.
I thought that after a CLV, counting cycles I could get the shifted-in bit (on 1541 works) didn't know about the others. |
| |
sailor
Registered: Jan 2002
Posts: 90 |
Sorry for off topic, but would you elaborate your thoughts on the following: (from the docs)
Quote: F3 align the head to track 42 in a better way than other programs do.
F5 moves the head to track 1
How to correctly align a drive:
1) gently unscrew the screws of the track 1 "stop"
2) press F3
3) press F5
4) gently move the track 1 block so there is 0.25 mm (a hair or little more) between the block and the head the head.
5) screw the screws tight carefully checking the block is still at 0.25mm from the head.
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
It would be interesting to see which different approaches various speed tests used. I could have sworn I saw one measuring drive-side before but couldn't find it. Kwik Load was the first I saw, and that was as pointed out earlier NTSC only so it was plain wrong on my setup. :)
@sailor: very off topic, maybe post in the comments to that release? |
| |
sailor
Registered: Jan 2002
Posts: 90 |
Comments closed in the entry, moved alignment to Release id #194046 : 1541 Speed Test |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
tlr: CF also suggested to look for prior art the other day ... indeed, there were a bunch of other tools. would certainly be interesting. perhaps start look at the usual suspects (basement boys?) |
| |
Comos
Registered: May 2004
Posts: 73 |
Quote: tlr: CF also suggested to look for prior art the other day ... indeed, there were a bunch of other tools. would certainly be interesting. perhaps start look at the usual suspects (basement boys?)
Howabout the drive aligment from FreeSprit Software,which can also measure the drive speed.However that one is PAL/NTSC dependant. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: Howabout the drive aligment from FreeSprit Software,which can also measure the drive speed.However that one is PAL/NTSC dependant.
Free Spirit report 310/320 rpm on pal machines and need his reference disk. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: Free Spirit report 310/320 rpm on pal machines and need his reference disk.
Vorpal has a test as well but I think that also requires a reference disk. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
for reference, this is the one I had: Kwik Load (NTSC only) |
| |
Copyfault
Registered: Dec 2001
Posts: 476 |
Quoting tlrIt would be interesting to see which different approaches various speed tests used. I could have sworn I saw one measuring drive-side before but couldn't find it. [...] As Groepaz already mentioned I was thinking of a thread here on csdb which was about people doing measurements of their real drives and posted certain schemes of the measurement.
After digging through the complete csdb (ok, not;)), I found it: Release id #160665 : Stepper Test 1.0
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. |
| |
Comos
Registered: May 2004
Posts: 73 |
Quote: Vorpal has a test as well but I think that also requires a reference disk.
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
For most of those the "reference disk" probably just contains a standard duplicator written track... because thats really good enough :) (For alignment purposes its a different matter) |
| |
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. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting Comosyep,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. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlrQuoting Comosyep,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. |
| |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
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 |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quoting ChristopherJamOn 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 |
| |
Copyfault
Registered: Dec 2001
Posts: 476 |
Quoting ChristopherJamHi 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 ChristopherJamOn 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. |
| |
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. |
| |
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 .) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Thanks! Probably should have used a different example. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ChristopherJam
On RPM Test 1.0
I checked the release.
Sorry but also yours happens not to be accurate as my program is.
Proof:
RPM Test 1.0
https://pasteboard.co/JlpK1Fg.png
My program:
https://pasteboard.co/JlpKTNn.png
As I said before: of all the programs I tested,
1541 Speed Test
seems to be:
1) the fastest.
2) the most accurate.
3) the nicer (but that just a few people opinion)
Also, your program is not suitable for lab use.
Takes long time to run and then stops. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Hah! You're not telling me anything that I didn't already write in my comment :P
I did mention that I'm reading 0.01 RPM higher than actual, and I praised you for the speed of your tool. Please read what people write before you respond.
Besides, to one decimal place, 280.0 is correct. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ChristopherJamHah! You're not telling me anything that I didn't already write in my comment :P
I did mention that I'm reading 0.01 RPM higher than actual, and I praised you for the speed of your tool. Please read what people write before you respond.
Besides, to one decimal place, 280.0 is correct.
For you it is. For my own personal challenge which was to code the most accurate and fast program to help some friends of mine in repairs and assessment, that is unacceptable.
To everyone else:
since you are so strongly against the writing of a track,
I coded also a second version which I called "rpm2wrong.prg" which does not write anything and assumes
the disk in the drive was formatted by the same drive doing the tests.
It is as accurate as the previous one.
But it is totally "wrong". |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Once again, Zibri reads a single line of a multi line comment, this time even though it was only three lines long...
and this time skips over the first half of the sentence.
Zibri, go back again, and read the part that says "to one decimal place." |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ChristopherJamOnce again, Zibri reads a single line of a multi line comment, this time even though it was only three lines long...
and this time skips over the first half of the sentence.
Zibri, go back again, and read the part that says "to one decimal place."
Go back and check your "one" decimal place in the screenshot. It is WRONG, the decimal and the whole read.
And it is obvious why.
In my opinion your program is mostly useless.
Not only because it's not precise.
But because it gives absolutely no useful information.
With your program you can't tune the drive speed.
You can't assess the status of the belt.
You can't check the raising speed found in drives that need to be recapped. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
I'm wondering if there is a language issue here?
If you were to round 279.99 to one decimal place, the closest result is 280.0
If my utility had reported 279.9 then it would have been out by 0.09RPM. 280.0 is only out by 0.01, hence is a more accurate answer to give (again, assuming only reporting to the nearest tenth of an RPM)
Perhaps more pertinently though, 60*985256/211124 is 280.003 - so there is indeed something screwy going on. Perhaps it is for the best that I was only reporting to a single decimal place after all :D |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Here is a version for the whining people:
https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm3wr..
This "wrong" version does not write a reference track.
It's again 100% accurate. 100% stable.
I just preferred writing my own reference track so to make the program totally agnostic.
If you prefer this "wrong" version, be my guest.
Happy, now? Any other problems? You don't like the graphics? Whuld that be ugly as the others just to be accepted?
I really don't understand you guys.
My bad.
Note:
This versions works only on a normal, standard formatted
empty disk. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ChristopherJam
If you were to round 279.99 to one decimal place, the closest result is 280.0
That is called "approximation".
And approximation is what you do when you don't have an accurate result.
If you had, I bet you would have wrote another digit.
Also my program "approximates" but the result is, as I said many times, the most accurate and stable as of today in 40 yers.
That's it. That is what I wanted to do. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Well, yes - your utility accurately reports to two significant figures, mine does to one significant figure.
They're both "wrong" if they measure a disk rotating at 279.995, but neither would be inaccurate to be stating 280.0 or 279.99 to the nearest tenth or hundredth of an RPM respectively. They are both as accurate as they claim to be.
I only take offense at your claim that mine is somehow "wrong" more often than yours is - they both do what they say on the tin, and yours provides more precision (again, not something I've ever disputed), but there are no drives in the real world that rotate at an exact multiple of 0.01 RPM! |
| |
SLC
Registered: Jan 2002
Posts: 52 |
@Zibri:
You don't respond well to any form of criticism it appears. Your routine may be accurate, but a lot of what you write comes out wrong. And your attitude sucks. Even flaws that actually is of concerns is brushed off as an attack on your precious code.
Also, making fuzz out of 0.01RPM... are you even aware how ridiculous that is? CJam's result is not an "approximation", it shows a real value which is rounded to the closest decimal. One decimal is more than enough accuracy to begin with. If someone made a solution that showed three decimals, yours would by your logic also become an approximation. Just stop it.
And regarding the things that others pointed out:
1. You mix up the terms alignment and track 0/stop-calibration. It gets pointed out, you defend it by people being "elite" enough to understand it rather than accept the correction.
2. Writing data to a disk without informing or asking the user is a bad idea. Even if you believe that most doesn't use track 36. You refer to the docs which have the warning, but you said you already assumed people being "elite" here. Why wouuld you then expect them to need to read the docs for a drive speed test!? Also keep in mind that many games may have protection data on track 36, and some actually load prg-files directly through ethernet or other means. Your program would then willingly just wipe protection data without telling the users. That's destructive behavior. You should really change that if you insist on this method. But again, you respond by becoming overly defensive rather than accept that it is a bad decision. |
| |
iAN CooG
Registered: May 2002
Posts: 3187 |
> many games may have protection data on track 36
well if someone uses an original disk to make some tests, he deserves to trash it, who with a sane mind would do that? =)
We can all agree that a warning before it starts testing should a better solution. |
| |
SLC
Registered: Jan 2002
Posts: 52 |
Sometimes you may want to use the actual disks you want to read for reference for whatever reason. Having no alignment disks I've several times used originals as reference for example (Though, I always write protect) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:well if someone uses an original disk to make some tests, he deserves to trash it, who with a sane mind would do that? =)
We can all agree that a warning before it starts testing should a better solution.
Indeed, it's much more likely someone runs this disk from his tool disk, with the tool disk in the drive, than that he will put an original disk into the drive. That also means that destroying a random track without asking is much more likely a problem than relying on a track being in CBM DOS format :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting SLCSometimes you may want to use the actual disks you want to read for reference for whatever reason. Having no alignment disks I've several times used originals as reference for example (Though, I always write protect) Write protect in 1541 is only software. Even with my program, you can write protect the disk as you want but it writes on it.
Check out the other version "rpm3wrong.prg". That does not write anything. But still I prefer the released version. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting SLC@Zibri:
You don't respond well to any form of criticism it appears. Your routine may be accurate, but a lot of what you write comes out wrong. And your attitude sucks. Even flaws that actually is of concerns is brushed off as an attack on your precious code.
Ilove you too :P
Quoting SLC
bla bla bla gne gne gne
My program stiil does what it promises.
It is the most accurate, fast and "nice" as of the time of publishing.
Sorry for bruising so much your egos with a program that anybody could have written in 40 years.
Clearly nobody cared (I bet Krill was able) or was not able (Groepaz) to do it.
Sorry again. For me was just fun to write and see it working.
So easy that even a kid can use it.
So precise that can show flaws in capacitors or belt or other components.
That's all I wanted to do. I did it. It was fun.
And, by the way, it wasn't even me releasing it here on this troll infested forum/website.
Ciao. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ChristopherJamWell, yes - your utility accurately reports to two significant figures, mine does to one significant figure.
This is called a 10 time jump in precision.
Exactly my point. |
| |
Nerdine
Account closed
Registered: Nov 2012
Posts: 2 |
Quoting ZibriQuoting SLC@Zibri:
You don't respond well to any form of criticism it appears. Your routine may be accurate, but a lot of what you write comes out wrong. And your attitude sucks. Even flaws that actually is of concerns is brushed off as an attack on your precious code.
Ilove you too :P
q.e.d |
| |
Fungus
Registered: Sep 2002
Posts: 681 |
Write protect is hardware, learn to read schematics smooth brain. |
| |
BiGFooT
Registered: Mar 2002
Posts: 33 |
Quoting Zibri
Sorry for bruising so much your egos with a program that anybody could have written in 40 years.
I can't hold it back anymore. The only people in this thread who have problem with "ego" is you. I followed the whole thing from the beginning and what I've learned is this:
- your code is the most accurate and best and everyone else suck
- it's the most accurate and best because you say so, and whoever wants to discuss his thoughs and problems with you is seems like an idiot
I don't know if the problem is your attitude or it's because of the language differences but you talk off really talented guys here, like you pulled 'em out from your ass.
Some people want to learn, but it seems that you're not a (good) teacher. I was interested in the _deep_ technical details and I got more information from the others than you. Trust me, teaching others is a good thing, you should be proud of that, also a good leader shows the way and not talk people down.
Inteligent people starts to think, when more and more people says that something is wrong. I hope that you're also one... |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting BiGFooTQuoting Zibri
Sorry for bruising so much your egos with a program that anybody could have written in 40 years.
I can't hold it back anymore. The only people in this thread who have problem with "ego" is you. I followed the whole thing from the beginning and what I've learned is this:
- your code is the most accurate and best and everyone else suck
- it's the most accurate and best because you say so, and whoever wants to discuss his thoughs and problems with you is seems like an idiot
I don't know if the problem is your attitude or it's because of the language differences but you talk off really talented guys here, like you pulled 'em out from your ass.
Some people want to learn, but it seems that you're not a (good) teacher. I was interested in the _deep_ technical details and I got more information from the others than you. Trust me, teaching others is a good thing, you should be proud of that, also a good leader shows the way and not talk people down.
Inteligent people starts to think, when more and more people says that something is wrong. I hope that you're also one...
People who tanto to learn don't attack me as Groepaz did in a lame passive-aggressive way.
Whoever knows me personally, knows I am a very kind and funny person who jokes almost all the time and does not take anything seriously.
They also know me as a person who loves to learn and tech to others (I have done many things in my life including courses).
Sincerely there is only a couple of people, in this discussion, who I could learn from.
What made me answer less "funnily" and more "rudely" were people just bad mouthing a program they clearly have not even tested and compared it to other programs they probably didn't test or use.
I coded this program for fun and to prove a more accurate, usable and good looking program could be done.
About the people who supposedly want to learn, I told them how my program works.
So I really don't understand why all this fuss.
And strangely, the loudest voice in this discussion comes from the guy who made the most horrible and unusable program. That hurts. The eyes. :P
Now a challenge on getting rid of the 3 cycle jitter and achieve a 3 digit accuracy, that would be interesting!
That would teach me something.
But here clearly nobody really want to learn something otherwise someone would have asked how did I do the "non writing" version in so little time and changing just a few lines of my original code.
Sorry but I see no friendship in this forum, nobody wishing to learn and nobody (excpet the usual 2 people) tying to offer a real advice and some coding examples.
I repeat: I didn't release this program on csdb. They just informed me of this. And I came here more by curiosity than to prove anything.
I am not amused by this mainly toxic environment.
I apologize with the "few good men" reading all this thread. |
| |
Frantic
Registered: Mar 2003
Posts: 1647 |
I wonder if it is the Dunning-Kruger effect in play. At least when it comes to social/communication skills. |
| |
Adam
Registered: Jul 2009
Posts: 323 |
Quoting Zibri
it wasn't even me releasing it here on this troll infested forum/website.
It's always the way: people magically become trolls as soon as a disagreement arises. That's not quite how it works, zibri. You aren't on twitter, facebook or your youtube channel where you can control who says what in your echo chamber circlejerk. If you really feel this way about CSDb, just don't log in ever again. Easy.
Quote:So I really don't understand why all this fuss. I am not amused by this mainly toxic environment.
You've been the #1 cause of toxicity in this entire thread as far as I'm concerned. People tried to help but you insult them and reply in a disrespectful way that has got you absolutely nowhere. Well done. Ciao. :) |
| |
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: 323 |
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: 519 |
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: 11377 |
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: 108 |
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: 11377 |
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: 108 |
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. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Yes, only in this case you can do a new test every 26 cycles instead of every 63 :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting GroepazChristopherJam: 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
Well, you can kind of do that by hand already with the other two numbers displayed; it's just 60*(the number of c64 cycles per 1 million drive cycles)/(the number of c64 cycles per disk revolution)
As I mentioned earlier, I'm slightly surprised that was giving me a number about 0.01 RPM higher than whatever I was setting VICE to the other day when I did some quick tests.
My c64 cycles per disk revolution accuracy is about 5ppm, and the error in the cycles per million drive cycles has about 7 cycles jitter - so overall I'd expect an error of only about a dozen ppm. Looks like I've got some debugging to do at some point. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Like i thought - it IS more accurate :=) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriInstead 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.
Valid point.
Wouldn't it be useful to have both kinds of measurements, i.e a running average _and_ a separate single revolution measurement?
The first would be useful to adjust the speed and the second to assess if the belt and/or drive electronics are ok.
It could even be presented as a marker on a horizontal bar with and additional coloured field to see the variance. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting GroepazMore 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!
I would assume that the oscillator in the c64 is about the same accuracy as the drives oscillator though so it shouldn't make any difference. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting tlrI would assume that the oscillator in the c64 is about the same accuracy as the drives oscillator though so it shouldn't make any difference. On a PAL C-64, it's about 1.7 MHz faster than the drive's oscillator.
So, given the same tolerance in ppm, i guess you'd end up with ever so slightly more accurate results. :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: Quoting tlrI would assume that the oscillator in the c64 is about the same accuracy as the drives oscillator though so it shouldn't make any difference. On a PAL C-64, it's about 1.7 MHz faster than the drive's oscillator.
So, given the same tolerance in ppm, i guess you'd end up with ever so slightly more accurate results. :)
Perhaps. :)
I tried to find some specifications on early 80's oscillators and crystals a couple of years ago but gave up. There could quite some difference in tolerance between the 16 MHz oscillator module in the drive and the discrete oscillator in the c64. Especially if the module operates in overtone mode. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Actual datasheets for the parts used would be super interesting indeed.... i looked for this years ago, but couldnt find anything either. bummer. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
I must admit, I mostly did the measurement that way because I a) wanted to know how consistent the drive:C64 clock speed ratio was from one scener’s setup to the next, and b) couldn’t be arsed digging up or or coding a routine to send numbers from the drive to the c64.
Any miniscule improvements in accuracy were just a bonus :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting KrillThis is also one of the basic techniques as used for stabilising raster routines.
Depending on density (track zone), there are a nominal 26/28/30/32 cycles between two GCR bytes rolling in from disk.
After having synced to the first byte using a plain "bvc *", delay according to density such that a "bvc * + 2" would take 2 cycles if byte-sync (branch not taken) or 3 cycles if no byte-sync (branch taken). We're now down to a one-cycle jitter. Repeat to get down to 0 cycles.
If we accept writing a test track, perhaps this could be done by a carefully crafted sync pattern?
You'd write something like '111111111111 010 111111111111 010 111111111111 010...'. When this is read, whenever there are 10 * '1'-bits in the shift register the sync bit in $1c00 will be set, generating a squarish pattern. This pattern could then be used to stabilise to a single bit using the suggested technique.
The actual duty cycle can be adjusted by increasing the number of sync bits and/or the number of bits in between.
Would this work the same on different generations of the hw?
EDIT: would also make a pretty brutal copy protection scheme. ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Wasnt there some protection doing something similar? MMmmh.
I thought you'd set up a timer that underflows say 50 cycles (much more than a byte takes), then you read a byte and add/sub from the timer value alternating values until you are at perfect zero after reading (maybe more than one) byte. *shrug* |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting GroepazWasnt there some protection doing something similar? MMmmh.
I thought you'd set up a timer that underflows say 50 cycles (much more than a byte takes), then you read a byte and add/sub from the timer value alternating values until you are at perfect zero after reading (maybe more than one) byte. *shrug*
The point wasn't the protection bit. The point is that you can generate a squarish pattern on the msb of $1c00, perhaps allowing a simpler way of cycle exact synchronization. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Yeah it might be easier, of course. I'm still thinking along the lines of just reading an arbitrary track (sector headers). Why go the easier route when you don't have to? :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Fair enough. :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
IMHO:
Whatever could be the error of a quartz is totally irrelevant to the RPM calculations.
Even the worst quarts loose or gain a few seconds per year. Not only we are talking about measuring 200milliseconds but the quarts real frequency is divided by 16 (iirc).
Writing a test track: https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm.prg
Or not writing a test track: https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm3wr..
Give exactly the same result. (the first one is more reliable since he knows the track is written correctly, while the second "wrong" one assumes (hence the "wrong") that track 35 is formatted and never written to.
Any accuracy below the 2 digits is not enough to assess the status of the belt or mechanics and disk.
Any accuracy over the 2 digits does not add any useful information and will just induce more latency.
Just fyi, the "wrong" version was tested even with disks formatted by a drive whose speed was 290RPM at the time of formatting and still showed the right speed before and after the tuning. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:Even the worst quarts looses or gains a few seconds per year.
wat.
you should re-read the thread perhaps. the deviation you can expect from the quarz results in almost 10 times bigger error than your supposed 3 cycles jitter. soci was quite correct with what he said. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting ZibriIMHO:
Whatever could be the error of a quartz is totally irrelevant to the RPM calculations.
Even the worst quarts loose or gain a few seconds per year. Not only we are talking about measuring 200milliseconds but the quarts real frequency is divided by 16 (iirc).
Dividing the frequency by 16 doesn't change the percentage error. If it's 20-30ppm before you divide by 16, it's 20-30ppm after - in either case that's going to be bigger than the 10ppm error you get from 2 cycles jitter on a measurement of a ~200,000 cycle time period
Quote:Just fyi, the "wrong" version was tested even with disks formatted by a drive whose speed was 290RPM at the time of formatting and still showed the right speed before and after the tuning.
Every version of any tool that determines RPM by timing one or more full rotations of the disk (ie any of the releases by you, Groepaz or I under discussion) will be unaffected by the speed of the drive used to write the track being read, regardless of whether it's a special track or just whatever data is already there.
It's still a 360 degree rotation each time a marker or selected sector sails by.
I'd have been a lot more surprised if you'd manage to get a *wrong* answer from a disk that was written at a different speed, that would be quite special :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ChristopherJam
I'd have been a lot more surprised if you'd manage to get a *wrong* answer from a disk that was written at a different speed, that would be quite special :)
Well, I didn't do the math but since I read (past tense) 6 bytes, I thought that if a drive is really slow it could mistake 5 bytes for 6... but I think it should be so slow that this thought was just theoretical.
Anyway, Just to be on the safe side, I wrote a new version:
It uses a slightly different way to measure the speed.
It uses track 36 if writing is enabled and track 35 if writing is disabled.
(But in this case it expects track 35 to be formatted and empty and never written)
It is still as fast as before.
It is still as accurate as before.
It has been tested on at least 20 different drives and the speed reported by my program was compared to the speed read optically by the strobe "disc" printed on the motor spindle.
If anyone has a better way to check (by instruments) the motor speed we can do the final tests but I am pretty confident there will be no difference.
I undesrtand your theoretical thoughts about quartz tolerances but empirically I can tell that so far it has been proven to be very accurate.
If you want to test it, here is the new version.
https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm4.p..
...but I still think the first version is perfect... |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
Ive seen on youtube a device that measures rpm by sound |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting ChristopherJamDividing the frequency by 16 doesn't change the percentage error. If it's 20-30ppm before you divide by 16, it's 20-30ppm after - in either case that's going to be bigger than the 10ppm error you get from 2 cycles jitter on a measurement of a ~200,000 cycle time period. Indeed, but the errors add. So even getting rid of the smaller part is the pointless demoscene thing to do, just because! :D
That said, a simple way to get down from 2 cycles jitter to 1 cycle is using a chain of 18-ish "BVS readtimer" instead of "BVC *". (Or 11-ish NOPs plus 7-ish BVS in the red zone, you get the idea.)
Will give either 0-cycle delay (spot on) or be 1 cycle late. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriIMHO:
Whatever could be the error of a quartz is totally irrelevant to the RPM calculations.
Even the worst quarts loose or gain a few seconds per year. Not only we are talking about measuring 200milliseconds but the quarts real frequency is divided by 16 (iirc).
and
Quoting ZibriAny accuracy below the 2 digits is not enough to assess the status of the belt or mechanics and disk.
Any accuracy over the 2 digits does not add any useful information and will just induce more latency.
I think the confusion may be a language issue?
In the field of measuring stuff (metrology), "accuracy" has a specific meaning. It means how close to the _absolute value_ you can measure. The term "precision" refers to how _repeatable_ a measure is.
See: Accuracy and precision (wikipedia)
For assessing the belt and the drive electronics, the repeatability (and thus the precision) is essential. The precision is indeed going to be very high using the crystal oscillator as reference as the frequency deviation on the short time scale is very low.
For setting the absolute speed the accuracy is essential. To measure an rpm value with .01 accuracy, then a typical crystal with, say +/- 100ppm, isn't sufficient.
For a drive rotating at exactly 300 rpm, given the same +/- 100 ppm assumption:
0.2 s * ( 1 MHz + 100ppm ) = 199980 cycles => 60/0.199980 = 300.03 rpm
0.2 s * ( 1 MHz - 100ppm ) = 200020 cycles => 60/0.200020 = 299.97 rpm
...thus to achieve the desired accuracy a better reference oscillator is required.
(with reservations for eventual miscalculations) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
And don't forget the temperature drift, of which Unseen provided a nice diagram
And yes, language barrier is/was kindof obvious :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting GroepazAnd don't forget the temperature drift, of which Unseen provided a nice diagram
Good point. It affects the accuracy as well. It probably won't affect the ability to assess the belt though as the curve doesn't seem to move very much per typical rotation, at least not after the first minute or so.
BTW I notice I've swapped the +100ppm and -100ppm in my calculation above, but fortunately it only results in the results swapped. My bad! |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting Krill So even getting rid of the smaller part is the pointless demoscene thing to do, just because! :D
True enough. I mostly wanted to point out that the variation in crystal speed is an even bigger factor if "accuracy" is the issue.
As TLR has already come at from the opposite direction, Zibri's target error of <0.01RPM amounts to 30ppm, so stats on actual crystal variation will tell us whether his dream is even possible in practice.
Quote:That said, a simple way to get down from 2 cycles jitter to 1 cycle is using a chain of 18-ish "BVS readtimer" instead of "BVC *". (Or 11-ish NOPs plus 7-ish BVS in the red zone, you get the idea.)
Will give either 0-cycle delay (spot on) or be 1 cycle late.
True! And damn, I'd been meaning to post that ;-) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting ZibriAny accuracy below the 2 digits is not enough to assess the status of the belt or mechanics and disk.
I'm curious about this claim. I've been assuming that loaders need to be tolerant of anything from 295 to 305 RPM, in which case even 1 digit is somewhat overkill.
Have I been wrong all this time, in which case surely it would be safe to relax the GCR restrictions to allow runs of three zeros instead of just two? :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ChristopherJamAs TLR has already come at from the opposite direction, Zibri's target error of <0.01RPM amounts to 30ppm, so stats on actual crystal variation will tell us whether his dream is even possible in practice.
That would be +/- 15ppm in crystal-speak, but yeah.
And measuring that requires non-trivial equipment. Where should we send all our drives... ;) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ChristopherJamQuoting ZibriAny accuracy below the 2 digits is not enough to assess the status of the belt or mechanics and disk.
I'm curious about this claim. I've been assuming that loaders need to be tolerant of anything from 295 to 305 RPM, in which case even 1 digit is somewhat overkill.
I read that claim as, by watching how much the lower digits flicker around something can be said about belt slippage and things like that (this would be "precision"). Loader speed tolerance would normally be accounting for the "accuracy" of the rotational speed.
As for the presentation, I still think some kind of plot would be useful for quick adjustment. Think: Recorder-Justage [german] or HeadAlign 1.1. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
histogram would tell quite nicely how bad the "wobble" is... less than trivial to implement unfortunately :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: histogram would tell quite nicely how bad the "wobble" is... less than trivial to implement unfortunately :)
I think plotting instantaneous vs running average (5 laps maybe) in the same graph would do. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
probably... not quite as nice, but sure... :) also a simple scrolling scatter plot like recorder justage does seems interesting enough. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ChristopherJamQuoting ZibriAny accuracy below the 2 digits is not enough to assess the status of the belt or mechanics and disk.
I'm curious about this claim. I've been assuming that loaders need to be tolerant of anything from 295 to 305 RPM, in which case even 1 digit is somewhat overkill.
Have I been wrong all this time, in which case surely it would be safe to relax the GCR restrictions to allow runs of three zeros instead of just two? :)
You are not wrong at all. I even wrote it in the instructions.
A drive works even when set to 290 RPM! |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting Zibri
You are not wrong at all. I even wrote it in the instructions.
A drive works even when set to 290 RPM!
So... why do you need to know the nearest 0.01RPM if the "safe zone" is 2000 times as wide as that? /puzzled |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlr
...thus to achieve the desired accuracy a better reference oscillator is required.
(with reservations for eventual miscalculations)
Yes, sorry, my bad, for me accuracy and precision were synonyms.
About your calculations, I don't know if they are right or wrong, but empyrically I don't see such deviations when measuring drives with no belt (motor is spinning the disk directly).
In that particular case I see a variation of 0.01 which is probably because of the diskette "stiffness". Different diskettes give different results. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Commodore service manual
TEST OVERVIEW
The Soft Error Test writes a worst case pattern to the diskette and then reads for the specified number
of passes. The number of sectors tested is fixed at 16 per track with all 35 tracks tested.
The program keeps a log on the diskette of the number of passes and errors which occur during program run time.
The drive speed is measured by writing a sync mark on a track which is outside the normal range
of the system and measuring the time (to 100 micro-second accuracy) the period of each revolution.
Belt quality is measured during the speed program by comparing two (2) successive revolutions of
the diskette. This comparison is repeated twenty (20) times and the results are displayed.
• If a failure occurs during this test, the drive belt should be either replaced or reversed.
LOL!
I found this by pure chance.
Apparently commdore used a similar method I used.
They wrote a reference track "outside the normal range" like my program does.
The only difference is that they used a SYNC mark which gave their program less accuracy than mine.
That's all.
Ok now you can also blame commodore along with me. :D
http://www.zimmers.net/anonftp/pub/cbm/schematics/drives/new/15.. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriQuoting Commodore service manual
TEST OVERVIEW
The Soft Error Test writes a worst case pattern to the diskette and then reads for the specified number
of passes. The number of sectors tested is fixed at 16 per track with all 35 tracks tested.
The program keeps a log on the diskette of the number of passes and errors which occur during program run time.
The drive speed is measured by writing a sync mark on a track which is outside the normal range
of the system and measuring the time (to 100 micro-second accuracy) the period of each revolution.
Belt quality is measured during the speed program by comparing two (2) successive revolutions of
the diskette. This comparison is repeated twenty (20) times and the results are displayed.
• If a failure occurs during this test, the drive belt should be either replaced or reversed.
LOL!
I found this by pure chance.
Apparently commdore used a similar method I used.
They wrote a reference track "outside the normal range" like my program does.
The only difference is that they used a SYNC mark which gave their program less accuracy than mine.
That's all.
Ok now you can also blame commodore along with me. :D
Maybe it asks before writing though, but yeah kind of funny. One of the earlier test programs I saw did something similar. I think it was SuperCopy 64. IIRC it gives readings that are really off when run in vice. Same for PAL and NTSC, not sure why. Haven't tested on hardware.
I tried a bit to find a specification on the rotational speed but couldn't find it. The service manual just says 300 rpm, and gives no tolerance. I would have guessed +/- 1 rpm or something like that. Maybe it's specified for the actual drive mechanics? The motor controller is part of that. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
You can find it in some datasheets for (shugart) drive mechanics (and then its usually +/- 1%). For the drives used in CBM drives i have not seen any datasheets, but its probably very similar. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting ZibriQuoting Commodore service manualThe drive speed is measured by writing a sync mark on a track which is outside the normal range
of the system and measuring the time (to 100 micro-second accuracy) the period of each revolution. The only difference is that they used a SYNC mark which gave their program less accuracy than mine. Pretty sure the 100 cycles of accuracy don't come chiefly from using a SYNC mark (7 cycles poll loop) vs BVC * (3 cycles poll loop) but more significantly from the discussed oscillator tolerance. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting GroepazYou can find it in some datasheets for (shugart) drive mechanics (and then its usually +/- 1%). For the drives used in CBM drives i have not seen any datasheets, but its probably very similar.
297-303 rpm sounds a lot, but maybe that's the case. I've only seen the speed of a few drives, but I think they've all been tighter than that. Not that that would mean it's wrong of course. :) If they were calibrated using the strobe pattern it could be tighter. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
About the crystal.
The average 16MHZ crystals in 1541 have 50ppm deviation.
That is 50 clock cycles "jitter" over 16 million which translates to 3.125 cycles over one million.
And that's why it's irrelevant to the measurement.
If what you wrote until now was true (I suspect some calculation error), there would be errors all over the place since a BIT can last 4 (cycles at 1mhz) (at the slowest clock) to as little as 3.25 (cycles at 1mhz).
Probably I am not using the right terminology, but something here is not right.
I see no such deviations anywhere.
The maximum "jitter" I saw in a directly connected motor was of 0.01 and was probably induced by a very stiff new disk. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting KrillQuoting ZibriQuoting Commodore service manualThe drive speed is measured by writing a sync mark on a track which is outside the normal range
of the system and measuring the time (to 100 micro-second accuracy) the period of each revolution. The only difference is that they used a SYNC mark which gave their program less accuracy than mine. Pretty sure the 100 cycles of accuracy don't come chiefly from using a SYNC mark (7 cycles poll loop) vs BVC * (3 cycles poll loop) but more significantly from the discussed oscillator tolerance.
That's a very good point! I didn't realise the significance of that statement.
100 us (+/- 50 us) would be explained by a frequency tolerance of around +/- 250ppm if I'm not miscalculating. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriAbout the crystal.
The average 16MHZ crystals in 1541 have 50ppm deviation.
That is 50 clock cycles "jitter" over 16 million which translates to 3.125 cycles over one million.
Where did you get the 50ppm (+/- 50ppm?) specification? The parts lists all seem to just specify "16 MHz crystal" or "16 MHz crystal oscillator".
Also, +/- 50 ppm would translate to +/- 10 cycles per nominal rotation, no? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote:Where did you get the 50ppm (+/- 50ppm?) specification?
indeed, it sounds very precise for that era. citation needed :)
Quote:That is 50 clock cycles "jitter" over 16 million
https://en.wikipedia.org/wiki/Parts_per_million |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriProbably I am not using the right terminology, but something here is not right.
I see no such deviations anywhere.
The maximum "jitter" I saw in a directly connected motor was of 0.01 and was probably induced by a very stiff new disk.
The terminology isn't the most important, the concepts are. From your last statement I suspect what the misconception is. The accuracy of the crystal (i.e +/- x ppm) is something that is fairly constant to each individual crystal. Some will be +10ppm, some -100ppm, some + 25ppm, and so on... They will _not_ sweep around randomly within that interval, hence the _precision_ is much better.
The important point is that these are two completely different aspects of the crystal's behaviour. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting ZibriIf what you wrote until now was true (I suspect some calculation error), there would be errors all over the place since a BIT can last 4 (cycles at 1mhz) (at the slowest clock) to as little as 3.25 (cycles at 1mhz).
[...]
The maximum "jitter" I saw in a directly connected motor was of 0.01 and was probably induced by a very stiff new disk. Note that the oscillator's frequency changes very slowly over time, and also that it might be quite stable at some frequency close to but not quite at 16 MHz sharp.
It will not produce "jitter" as in something you can see flicker in a short amount of time.
It will still cause an error in measurement of the absolute RPM figure with regard to a clock that is more precise than the oscillator. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Yeah, over time the deviation will only change a little bit, and slowly - see Unseens diagram. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting GroepazYeah, over time the deviation will only change a little bit, and slowly - see Unseens diagram. About that... this is from power-up of a cold device, then idling in room temperature while the oscillator asymptotically approaches zero deviation? Needs a bit more context, i'm afraid. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Its exactly that :) deviation from 16Mhz on Y and seconds after powerup on X (so roughly 2.5h) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting KrillQuoting GroepazYeah, over time the deviation will only change a little bit, and slowly - see Unseens diagram. About that... this is from power-up of a cold device, then idling in room temperature while the oscillator asymptotically approaches zero deviation? Needs a bit more context, i'm afraid.
...and it would be good form to state roughly which setup was used to measure it. I assume Unseen did it right, but if done wrong, some of the curve could easily come from the test equipment itself. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
What he told me is "The Frequency counter had a OCXO and was warmed up an hour before the measurement". I can ask for more details if you tell me what to ask :) (But i also assume no terrible mistakes were made, he knows his stuff) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: What he told me is "The Frequency counter had a OCXO and was warmed up an hour before the measurement". I can ask for more details if you tell me what to ask :) (But i also assume no terrible mistakes were made, he knows his stuff)
That statement, and preferably which actual instrument it was. If you put that in the readme in the repo, then anybody doubting the graph could just look up the specs of the instrument and see for themselves. I would assume a few ppm error is to be expected, which in this case is negligible. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
The deviation can be expected to increase after running a stress test for a while, no? Especially on a 1541 with that built-in PSU. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: The deviation can be expected to increase after running a stress test for a while, no? Especially on a 1541 with that built-in PSU.
Maybe, although it seems to be running quite hot at all times really. If it gets hotter, I guess it would pass the 0-line further down. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Just searching the net, i found this jpg:
http://www.bertinettobartolomeodavide.it/programmazione/commodo..
where we can see that quartz is a "Toyocom TCO-/745A" of which i can found this:
https://www.datasheetarchive.com/pdf/download.php?id=caa472aa5e..
in which is stated that "Frequence stability" is from "-50" to "50" ppm.
I don't know if/how this can be useful, but that is. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting KrillThe deviation can be expected to increase after running a stress test for a while, no? Especially on a 1541 with that built-in PSU.
It has been observed in some drives but I think it's because of the old capacitors. If speed increases after 2-3 minutes running my programs it means is time to recap :D |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting FlaviowebJust searching the net, i found this jpg:
http://www.bertinettobartolomeodavide.it/programmazione/commodo..
where we can see that quartz is a "Toyocom TCO-/745A" of which i can found this:
https://www.datasheetarchive.com/pdf/download.php?id=caa472aa5e..
in which is stated that "Frequence stability" is from "-50" to "50" ppm.
I don't know if/how this can be useful, but that is.
That's a good find, and an interesting data point! So at least some drives have +/- 50ppm (the oscillator was produced in 84 in this case). Tighter tolerance than I would have expected. I wonder if I'm likewise mistaken on the accuracy of crystals used in the c64 and older drives? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlr
Quoting Zibri They will _not_ sweep around randomly within that interval, hence the _precision_ is much better.
The important point is that these are two completely different aspects of the crystal's behaviour.
From what I read, the frequency "sweep" is dependent also from the ambient temperature.
Anyway I think is not as big as the deviation in speed caused by old capacitors.
I saw some drives starting at 298 and slowly go up to 302 rpm as they get hotter.
That's also why I wrote my program as I wrote it:
it's very easy to assess the drive health just but letting it run for a few minutes.
You can see differences even from a disk to another due to friction.
If you have any suggestions for improvement, I would be glad to hear them.
I think my next program will be about checking the head alignment in a new way but I need to wait for DHL to pack the material and send it to me:
A C64, a boxed 1541 21 sealed disks and a C64 SX (just for fun since it will soon be my birthday) :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting Zibri
Quoting tlrQuoting Zibri They will _not_ sweep around randomly within that interval, hence the _precision_ is much better.
The important point is that these are two completely different aspects of the crystal's behaviour.
From what I read, the frequency "sweep" is dependent also from the ambient temperature.
Anyway I think is not as big as the deviation in speed caused by old capacitors.
I saw some drives starting at 298 and slowly go up to 302 rpm as they get hotter.
Yes, frequency will change with temperature. It will also change a little with voltage, though the speed change you see with presumed bad caps is probably caused by an actual change in motor speed (voltage to motor controller fluctuating).
These oscillator cans (as opposed to discrete crystals) can in some cases have temperature compensation in them, although then more expensive.
Quoting ZibriA C64, a boxed 1541 21 sealed disks and a C64 SX (just for fun since it will soon be my birthday) :)
Getting new hardware is always nice! |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting tlrQuoting FlaviowebJust searching the net, i found this jpg:
http://www.bertinettobartolomeodavide.it/programmazione/commodo..
where we can see that quartz is a "Toyocom TCO-/745A" of which i can found this:
https://www.datasheetarchive.com/pdf/download.php?id=caa472aa5e..
in which is stated that "Frequence stability" is from "-50" to "50" ppm.
I don't know if/how this can be useful, but that is.
That's a good find, and an interesting data point! So at least some drives have +/- 50ppm (the oscillator was produced in 84 in this case). Tighter tolerance than I would have expected. I wonder if I'm likewise mistaken on the accuracy of crystals used in the c64 and older drives?
1541 board (hackaday.io)
This oscillator is similar to the one I have on my older (white) 1541 drive. Anyone have a guess on which manufacturer?
EDIT: KSS seems to be a Japanese manufacturer |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
So, assuming 50ppm, the oscillator deviation can be taken as +/- 10 cycles per revolution, or ~ +/- 0.015 RPM, ie ~6 times as much as the supposed 3 cycles jitter of the measurement on the drive. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
https://play.google.com/store/apps/details?id=com.javiery.rpmga.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Quote: https://play.google.com/store/apps/details?id=com.javiery.rpmga..
The comments remind me of this thread :o) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: So, assuming 50ppm, the oscillator deviation can be taken as +/- 10 cycles per revolution, or ~ +/- 0.015 RPM, ie ~6 times as much as the supposed 3 cycles jitter of the measurement on the drive.
yes.
Also, that diagram by Unseen shows quite a lot of dynamic frequency change (90 Hz). That is roughly 40-50 ppm to one direction. Isn't that quite much if the actual accuracy of the oscillator measured is +/- 50 ppm? Could be that most of the +/- 50 ppm is to account for just that though, I'm not sure.
And, those 100us stated for the measurement program in the service manual indicates much less accuracy. It could be that a wider tolerance was allowed (and used in some batches), or it could just be a left over from the late 70's PET drives.
Many questions...
Finding data sheets for a few more oscillators and crystals used would help. I find the crystals trickiest. Often they just say NHK and a frequency. How do you know which type? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: So, assuming 50ppm, the oscillator deviation can be taken as +/- 10 cycles per revolution, or ~ +/- 0.015 RPM, ie ~6 times as much as the supposed 3 cycles jitter of the measurement on the drive.
In the wrost case.
But i guess, in most cases, fully operational, we should be below 0,01 rpm.
Maybe more than three cycles. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
You always have to consider the worst case, thats precisely(!) what defines the accurracy(!) |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: You always have to consider the worst case, thats precisely(!) what defines the accurracy(!)
Technically speaking, you are absolutely right.
I have practically never checked the rpm at 0 or + 70c.
(Just kidding... huh ... =)) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
see Unseens diagram - you can see that devation at normal operation over time
Quote:Also, that diagram by Unseen shows quite a lot of dynamic frequency change (90 Hz). That is roughly 40-50 ppm to one direction. Isn't that quite much if the actual accuracy of the oscillator measured is +/- 50 ppm? Could be that most of the +/- 50 ppm is to account for just that though, I'm not sure.
Well, of course it is, its the max. deviation guaranteed under all conditions (within the limits defined in the datasheet). That includes drift over time and temperature, of course. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: Technically speaking, you are absolutely right.
I have practically never checked the rpm at 0 or + 70c.
(Just kidding... huh ... =))
Bring out your temp chambers! :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
As if the heat wouldnt be bad enough right now >_< |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
So?
Did anyone try the new version?
https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm4.p..
I would like some feedback.
Personally I prefer the "official" one, but this should work as well.
The only drawback of this version is that it may not give results if the speed is too low or too high, but this has still to be tested.
In this version is also possible to disable/enable the reference track writing. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quoting ZibriIn this version is also possible to disable/enable the reference track writing.
Yay! Amazing it only took 251 posts :) |
| |
Joe
Registered: Apr 2002
Posts: 227 |
Lol, this is called trolling perhaps. But out of curiousity, what will you all guys do now when you found out measuring this and that from a drive named this and that on that and that revision of a computer. à quoi ça sert? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting CompyxQuoting ZibriIn this version is also possible to disable/enable the reference track writing.
Yay! Amazing it only took 251 posts :)
Yep.. it takes time to comply to idiotic requests.
And that's just it.
The official version is still the first one. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting JoeLol, this is called trolling perhaps. But out of curiousity, what will you all guys do now when you found out measuring this and that from a drive named this and that on that and that revision of a computer. à quoi ça sert?
For me it was a programming exercise.
For a few people I know it is a good tool to asses the status of a drive when they buy it or when they fix one.
For some idiots was just an excuse for arguing about nothing.
Pick yours :D |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting JoeLol, this is called trolling perhaps. But out of curiousity, what will you all guys do now when you found out measuring this and that from a drive named this and that on that and that revision of a computer. à quoi ça sert?
:)
I guess there are a few interesting technical bits in here, although no major new techniques really materialized.
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.
... oh, and it could be used to subtly improve a few emulation aspects. |
| |
Joe
Registered: Apr 2002
Posts: 227 |
Great enough answer. Great work! I'm not picking one ;D I have the third pill ;D (The Exit without exit). |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting JoeGreat enough answer. Great work! I'm not picking one ;D I have the third pill ;D (The Exit without exit).
LOL :D |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
who would have thought that measuring drive RPM will be one of the best threads ever :D |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting Oswaldwho would have thought that measuring drive RPM will be one of the best threads ever :D
Maybe you should write your own prg? Chicks dig measuring drive RPM! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
They also dig jittering =D |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting tlrAs 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. :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
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. |
| |
Copyfault
Registered: Dec 2001
Posts: 476 |
Quoting ZibriSmall 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. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting KrillQuoting tlrAs 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. |
| |
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. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ChristopherJamQuoting KrillQuoting tlrAs 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? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting CopyfaultQuoting ZibriSmall 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 ChristopherJamthough 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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
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? |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting GroepazQuote: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. |
| |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
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 :) |
| |
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. |
