Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
  You are not logged in 
1541 Speed Test   [2020]

1541 Speed Test Released by :
Zibri

Release Date :
31 July 2020

Type :
C64 Tool

User rating:**********  10/10 (6 votes)   See votestatistics

Credits :
Code .... Zibri of Ram Jam
Graphics .... Zibri of Ram Jam
Design .... Zibri of Ram Jam
Idea .... Zibri of Ram Jam
Test .... Flavioweb of Asura, Digital Monastery, Hokuto Force
  Zibri of Ram Jam
Help .... Flavioweb of Asura, Digital Monastery, Hokuto Force

Download :
http://csdb.dk/getinternalfile.php/201989/speedtest.d64 (downloads: 121)
http://csdb.dk/getinternalfile.php/201988/rpm_instructions.txt (downloads: 96)
https://github.com/Zibri/C64-1541-Speed-Test/blob/master/RPM.d64 (downloads: 7)
https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm_instructions.txt (downloads: 5)
https://github.com/Zibri/C64-1541-Speed-Test (downloads: 4)
https://github.com/Zibri/C64-1541-Speed-Test/blob/master/RPM.tap (downloads: 3)
https://github.com/Zibri/C64-1541-Speed-Test/blob/master/RPM.wav (downloads: 3)

Look for downloads on external sites:
 Pokefinder.org


User Comment
Submitted by Groepaz on 3 August 2020
lets discuss in Accurately Measuring Drive RPM :)
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 Groepaz 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 Groepaz 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 Groepaz 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 Groepaz 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 Groepaz 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 Groepaz 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 Groepaz on 1 August 2020
"the most accurate RPM test ever seen" mmmh
User Comment
Submitted by Zibri on 1 August 2020
Github repository: https://github.com/Zibri/C64-1541-Speed-Test

Soon also source code will be released!
Search CSDb
Advanced
Navigate
Prev - Random - Next
Detailed Info
· Summaries
· User Comments (20)
· Production Notes (1)
Fun Stuff
· Goofs
· Hidden Parts
· Trivia
Forum
· Discuss this release (14)
Sponsored links
Support CSDb
Help keep CSDb running:



Funding status:




About this site:
CSDb (Commodore 64 Scene Database) is a website which goal is to gather as much information and material about the scene around the commodore 64 computer - the worlds most popular home computer throughout time. Here you can find almost anything which was ever made for the commodore 64, and more is being added every day. As this website is scene related, you can mostly find demos, music and graphics made by the people who made the scene (the sceners), but you can also find a lot of the old classic games here. Try out the search box in the top right corner, or check out the CSDb main page for the latest additions.
Home - Disclaimer
Copyright © No Name 2001-2020
Page generated in: 0.316 sec.