|
| |
Website :
https://github.com/Zibri/C64-1541-Speed-Test
Credits :
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by chatGPZ on 3 August 2020
User Comment
Submitted by Zibri on 3 August 2020
Yep.. writes a long sync track and writes 5 "5a" bytes then reads 6 bytes and time it. The original front-end was in basic indeed. This is just nicer. If you like I can send you the source directly but I should clean it up before publishing it. It compiles with the very nice win2c64 compiler.
Also, notice the track change routine, until now I found no program do it "properly" :D But for me is just studying. An exercise. |
User Comment
Submitted by chatGPZ on 3 August 2020
| LOL, i am sorry, it reads 6 bytes - and that means its indeed a full revolution and it relies on the timer wraparound. sure, why not. now how much more accurate this actually is... i dont know. its more stable, thats for sure :) |
User Comment
Submitted by chatGPZ on 3 August 2020
so, what this program effectively does is... write a long sync on a track, plus 5 readable bytes. it then measures how many cycles it takes to read those 5 bytes. the "frontend" is basically this
10 open1,8,15,"u30"+chr$(36)
20 print#1,"u31"
30 get#1,x$:get#1,l$:get#1,h$
40 l=asc(l$+chr$(0))
50 h=asc(h$+chr$(0))
60 t=l+(h*256):rem timer value
70 r=(6e+09 / (262139 - t)) + 0.5:rem rpm
80 print t; r
90 goto 20
you surely get more stable values with this - but i have my serious doubts this is any way more accurate than measuring the distances between all sector headers and adding that up to the total time of a revolution. |
User Comment
Submitted by Zibri on 2 August 2020
@Copyfault the program does what is writte in the menu. The first option measures the disk RPM using a new technique. It writes a special track on track 36 and then by using that and some good and precise programming, calculates the time it takes to do a full revolution. Also the other feature use some new techniques for moving the head. For me this was just an excuse to stretch my muscles, learn some new things and code something in a way that was never done before.
About the usefulness of this program, it is useful to some people repairing drives or for the average user just curisous about the state of the elastic belt or the diskette (both of which cause different changes in speed). Keep checking the github page because more documents will come and the source code too. |
User Comment
Submitted by Copyfault on 2 August 2020
I like to see this kind of scene activity - we reached the point of competition to make even better (=more precise) tools :)
Though I have to admit that I do not fully understand what this tools does *exactly* - especially in comparison to the one pointed to by Groepaz. What technique makes it 0.005rpm-precise?
Also, I'm with Groepaz that literally everything that a program does should be printed on screen. Assuming that a certain track is not used is dangerous - maybe a combined format&speedtest would be a good idea;)? |
User Comment
Submitted by chatGPZ on 2 August 2020
"only a fool would use this program on a disk where is "valuable" data on track 36 if any exist."
ehrm. no, just no. writing to a disk without telling the user is just wrong. tools tend to get copied to tooldisks - and you dont know if someone uses a DOS that supports the upper tracks. |
User Comment
Submitted by Zibri on 2 August 2020
| Also, on the D64 release on github there is a configuration program meant for advanced users which also let you decide on which track to operate the speed test. |
User Comment
Submitted by Zibri on 2 August 2020
| Instructions have been updated on github. Track 36 is not used in any standard 1541 disk and only a fool would use this program on a disk where is "valuable" data on track 36 if any exist. |
User Comment
Submitted by chatGPZ on 1 August 2020
| it's still missing that info - and that makes it potentially destroying data |
User Comment
Submitted by Zibri on 1 August 2020
| True, but it trashes track 36 and if you want you can change that with the "configure" program on the d64 release. |
User Comment
Submitted by chatGPZ on 1 August 2020
| The Documentation is missing an important bit of info: The RPM test writes to the disk and trashes the track used for testing :) |
User Comment
Submitted by chatGPZ on 1 August 2020
| I don't see how it is "crazily wrong". The method described is 100% valid. Perhaps the implementation is missing something, and its not really 100% cycle exact (which is pointless anyway). Curious to see how yours works :) |
User Comment
Submitted by Zibri on 1 August 2020
| Ooops... yep. Then sorry Groepaz! I really misread the commenter nickname. (but he linked is code with "mmmm" anyways and that's really a joke. Test both programs then you judge. |
User Comment
Submitted by Frantic on 1 August 2020
| Thanks for the reply. It does seem like you read my comment as if Groepaz had written it though. Just wanted to point it out, to avoid misunderstandings. |
User Comment
Submitted by Zibri on 1 August 2020
First basis: your code does not give stable results even in VICE. The decimals (all of them) fluctuate.
There are really a lot of reasons for this and would be too long to explain here. I will be more than happy to explain it to you, I studied deeply the 1541 and even found a lot of "mistakes" even in commented roms and even in original documents. They are not big mistakes sometimes but they confuse cause and effect very often. (Like the "density" settings which is absolutely not a density setting but a clock setting which results in a density setting... seems the same but it's not).
Anyway, before writing "mmmm" please run my code, first in an emulator then on a real drive and you will see the difference with "yours". |
User Comment
Submitted by Frantic on 1 August 2020
Quote:Groepaz, your rpm tester is crazily wrong. Good as a random generator :D No offense.
Haha. Now that's a funny comment. On a more serious note, it makes me curious to know more about the details. What is the basis for the claim that this is much better than other tools, e.g. what is the difference in the underlying approach compared to other tools? |
User Comment
Submitted by Zibri on 1 August 2020
| Groepaz, your rpm tester is crazily wrong. Good as a random generator :D No offense. This one is 100 times more accurate than the one published there and uses a totally different method. The only one that is both accurate both fast. Tryit before linking to random decimal generators :D |
User Comment
Submitted by chatGPZ on 1 August 2020
| "the most accurate RPM test ever seen" mmmh |
User Comment
Submitted by Zibri on 1 August 2020
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
9.3/10 (9 votes) 