Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user EviL ! (Registered 2018-07-21) You are not logged in 
CSDb User Forums

Forums > CSDb Entries > Release id #160665 : Stepper Test 1.0
2017-11-30 14:02

Registered: Aug 2004
Posts: 809
Release id #160665 : Stepper Test 1.0

Copying the production notes below, but I'd really like to see some results from other people's drives for this one.
2017-11-30 14:04

Registered: Aug 2004
Posts: 809
"This tool was developed to assist fastload authors in determining the optimal stepper motor timing for moving the head a single track increment.

It reads the block header for 18,0, then steps 1.5 tracks away and 0.5 tracks back (latter to ensure it's coming from the right direction for a multiple track load). Then it waits until T1+T2 bycles before the block header is due to return, tells the stepper motor to move half a track, waits T1 bycles, steps again, then starts searching for the block header. If any of the next 10 syncs is accompanied by the desired block header, it marks success.

The load and save commands just save a screenshot to/from @:STEPPERTESTDATA (screen memory only, not d800)

(one bycle = 256 CPU cycles; term coined by Krill on IRC earlier this month. Each square on the grid is 4 bycles wide, or around a millisecond)."

FWIW, on the step out I spend a fairly conservative 25 bycles on each step, then wait 256 bycles at the most distant radius to allow it to settle before stepping back half a track. Source available on request.
2017-11-30 14:06

Registered: Aug 2004
Posts: 809
Interesting that between 30 and 40 bycles after setting the stepper motor to the half track phase it only takes another couple of bycles on the desired track to be able to read the header, but for the longer T1 values it doesn't stay aligned to the correct track for long. Perhaps overshooting the correct track? Or just returning to the half track after an initial overshoot of the half track?

I'm pondering writing another test just to see when the half track is readable, but I want to see how other's drives fare with this one first.
2017-11-30 16:03
The Human Code Machine

Registered: Sep 2005
Posts: 104
First run on my cold SX-64 using it's internal Bitfire "reference" floppy drive;)

and 2nd run with warm floppy drive

2017-11-30 17:25

Registered: Aug 2004
Posts: 809
Oh wow, the head really doesn't want to move on if it's spent 40-45 bycles trying to settle on the half track. I might have to adjust the scale if there are many more similar results.

Thanks for that!
2017-11-30 18:11

Registered: Apr 2002
Posts: 957
Nice tool, will run it over my stack o'drives on the weekend or so.

Interesting results so far. But i have no explanation for the holesÂ… anyone? :)
2017-11-30 18:18

Registered: Oct 2005
Posts: 118
2017-11-30 19:24

Registered: Apr 2002
Posts: 957
Alpha particles, more likely. But i was thinking about some possible bugs, actually. :)
2017-11-30 19:46

Registered: Dec 2001
Posts: 8600
i am seeing this (1541-II) - guess the ranges that are displayed must be tweaked :) (screenshot taken with chameleon, i made sure it shows exactly the same without chameleon though ;))

2017-11-30 19:53

Registered: Jul 2007
Posts: 355
THCM was kind enough to let me test Spindle on his "problem drive", and one thing I learned was that just after a track change, the head seems to oscillate a bit before coming to rest. During this time, some sectors are garbled. Perhaps the header is read correctly from one track, and then it goes back to reading from the other track halfway through the sector contents.

Disconcertingly, sometimes the sector checksum would come out right even though the contents were wrong. I didn't dig any deeper into what happens here, and I fixed it (on Bitbreaker's suggestion) by throwing away the first few sectors after a track change, until a given number of consecutive sectors with correct checksum have been read.

To research the phenomenon, I would suggest a track with some constant nibble-pattern (55 55 55...) next to a track with a different pattern (cc cc cc...), and then switch back and forth between them, reading sectors, and looking for one that has the correct checksum but some variation in the contents. This sector (and the checksum) could then be sent to the host and displayed on the screen for further analysis. Though it might not work for all nibble-patterns, so some experimentation is called for.
2017-11-30 20:19

Registered: Dec 2001
Posts: 8600
that "oscillating" is the "settle time" - you should be able to find this in the datasheet of the mech :)
... 25 posts hidden. Click here to view all posts....
Previous - 1 | 2 | 3 | 4 - Next
RefreshSubscribe to this thread:

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

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Users Online
Guests online: 33
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 Comaland 100%  (9.6)
5 The Shores of Reflec..  (9.6)
6 Wonderland XII  (9.6)
7 Lunatico  (9.6)
8 We Come in Peace  (9.5)
9 Incoherent Nightmare  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 FMX Music Demo  (9.6)
2 Daah, Those Acid Pil..  (9.5)
3 Pandemoniac Part 2 o..  (9.5)
4 Treu Love [reu]  (9.5)
5 Merry Xmas 2017  (9.4)
6 Arok 20 Invitation  (9.4)
7 Dawnfall V1.1  (9.4)
8 In Memoriam BHF  (9.4)
9 Dawnfall  (9.4)
10 Synthesis  (9.4)
Top Groups
1 Oxyron  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.4)
4 Finnish Gold  (9.4)
5 Crest  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 Snacky  (9.6)
3 Antitrack  (9.6)
4 Sailor  (9.6)
5 S!R  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2018
Page generated in: 0.068 sec.