| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
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. |
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
"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. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
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. |
| |
The Human Code Machine
Registered: Sep 2005
Posts: 110 |
First run on my cold SX-64 using it's internal Bitfire "reference" floppy drive;)
and 2nd run with warm floppy drive
 |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
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! |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
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? :) |
| |
celticdesign
Registered: Oct 2005
Posts: 148 |
Neutrinos?! |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Alpha particles, more likely. But i was thinking about some possible bugs, actually. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
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 ;))
 |
| |
lft
Registered: Jul 2007
Posts: 369 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
that "oscillating" is the "settle time" - you should be able to find this in the datasheet of the mech :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Krill, do you mean just the scattered individual black pixels? Head probably hasn't quite finished settling yet.
Groepaz: that drive is *fast*! Did you install a turbo?? Code would have to have a bit of a redesign to zoom any more tightly on that top edge. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
hedning kindly sent me some test images for a few of his drives last night.
1541-II (cold):
1541-II (warm):
Fairly similar to my 1541, albeit with a bit more of a wave to the right. Vestigial traces of a stall spike before it's warmed up, but otherwise quite well behaved.
The dark pixels in the bottom third of the graph is probably just the stepper test jumping a track just after the last successful test, then never recovering. I should probably fix that..
Oceanic:
A very narrow "oops I've stalled" spike here.
Dwelling on the half track for 20-24 bycles on this one is a terrible plan.
1571:
Rattletastic :) So much noise right of the spike! Interesting how much more quickly the head settles if T1 was short. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
what is t1/t2/bycles ? :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
A bycle is 256 cycles. It's a portmanteau of byte and cycle. This is the usual granularity with which you use timers on a VIA, especially for head stepping.
To seek to the next track, you have to skip a half-track in between. So the head is stepped two times, with T1 and T2 denoting the wait times between issueing half-track-steps or starting to read the next track.
The goal of this tool is to find a safe optimum across all drives, that is a minimal sum of T1+T2, and also to determine where to best stuff in transfer of the previous track's last block during trackstep, for overall optimisation of loading times. |
| |
soci
Registered: Sep 2003
Posts: 473 |
Possibly I've misunderstood the last sentence but I'd like to note that tracks are not aligned on real disks.
Even if it's assumed that the track skew is sort of consistent for the stock ROM format it'll be different for JiffyDOS, with a 1571 and with fast and custom formatters.
For worst case timing a track change must be assumed to be longer than a revolution (>200ms). |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
This is about the track itself, not individual blocks. You can assume out-of-order block loading. It's really just about determining when any block on the destination track can be read safely.
As for track skew and alignment, i have something on my list to fix that. :) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Perfect explanation, thanks. :-) |
| |
soci
Registered: Sep 2003
Posts: 473 |
This sounds like I'll need to change my mailbox soon as swapping will pick up again ;)
More seriously the sectors could be realigned with a small program on the demo disk once it was written out.
Unfortunately this will likely trip on a "gapped" disk fault on a custom formatted disk unless the headers are kept in the same place which is difficult.
Is it really worth it over out of order loading (with prefetch)? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting sociMore seriously the sectors could be realigned with a small program on the demo disk once it was written out. I'm thinking of a custom format routine that would align the tracks and have the same size for all block gaps (so no big tailgap) and then simply disk-copying or transferring stuff onto that disk.
Quoting sociUnfortunately this will likely trip on a "gapped" disk fault on a custom formatted disk unless the headers are kept in the same place which is difficult. Not sure what you mean, but if you were reformatting disks on the fly, you should read a track, format it, then write back its contents.
Quoting sociIs it really worth it over out of order loading (with prefetch)? This isn't mutually exclusive. You can have out-of-order loading on top of a perfectly-formatted disk, or plain sequential loading on a perfectly-formatted disk with meticulously hand-crafted file layout. :) But the point is also getting rid of the big tailgap (which is bad for KERNAL format and worse for fast formatters), such that you get the same, maximum time between reading arbitrary blocks, thus missing fewer blocks after transferring a previous block. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
But let's not hijack this thread and move the UniFormAt (R)(TM) discussion somewhere else. :) |
| |
Tom-Cat
Registered: Apr 2003
Posts: 20 |
Here is my 1541-II that I currently have attached to my c64c:
Looks ok ? :) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
you win the graph niceness compo so far :) |
| |
icon
Registered: Apr 2002
Posts: 89 |
Here is two of my drives (more to come):
1541 (grey and cold)
1570 (white and cold)
 |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
Quote:that drive is *fast*! Did you install a turbo?? Code would have to have a bit of a redesign to zoom any more tightly on that top edge.
random old drive, i only ever cleaned the head and rails and made sure its 300rpm :) (it would be nice of your program had a few maintenance features... like rpm check, motor on/off switch, step to track 1/18/35) |
| |
Impetigo
Registered: Jun 2004
Posts: 30 |
My Oceanic:
Stock JiffyDos kernel, high current power supply.
Doesn't work properly with the original power supply.
 |
| |
Dr.Science
Registered: Oct 2011
Posts: 39 |
1541-II (cold)
 |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Thanks everyone, those are all really useful.
Spending too long on the half track is looking pretty costly on a lot of drives, especially if you catch that spike somewhere around 20-24 bycles. Entertaining given that 25 bycles is the default stepping time before acceleration kicks in..
I suspect what's happening there is the head is oscillating a bit, and that far in it's swung almost back to its starting point. I've tried running a simple physics sim with acceleration proportional to sin((phase-desiredphase)), and friction proportional to velocity. My friction model clearly needs work, as it keeps ringing for far too long, but even with the model as it stands I can already see shapes that loosely approximate some of the readings.
Some sets of parameters indeed result in a spike if the head has almost returned to the starting track at the end of T1, supporting my hypothesis above:
def iter(x0,x1):
a=np.sin((target-x1)*np.pi)
v0=(x1-x0)/dt
dv=v0*dt/Td
v0=v0+a*dt*Ta**-2
v0=v0-dv
return x1+v0*dt
(iter calculates the new head position as a function of the previous two, assuming a constant timestep of dt. Head position in tracks.) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
and some more measurements, these from j0x (thanks again!)
Two from an old 1541 push-down mech drive:
and two from an (almost as) old 1541-II:
 |
| |
soci
Registered: Sep 2003
Posts: 473 |
A bit late, but anyway.
1541-II with refurbished mechanic:
1571:
Another 1571:
Old 1541:
1571CR:
Unfortunately I couldn't do my oceanic this time as it's not here. That'll be interesting as it has an unusual stepper motor and mechanic. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Thanks Soci.
Those 1571s are particularly slow; well worth knowing about. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
The drive in my SX64
I haven't really read this thread very carefully, so a brief comment on what this graph tells about my SX64 drive would be much appreciated. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Frantic, the large black area at upper left means the optimal stepping time for your drive is a little higher than some of the others (you're looking at around 40 bycles/10ms), but it's well within the margins that current loaders rely on (12ms per track). More importantly the lack of a large black spike in the middle says your drive is much less likely than many other to stall for a bit when the normal stepping routine is being used.
So your drive's a little more consistently behaved than many, and is probably saving you a full disk rotation about one seek in twenty.
These results are mostly useful in the aggregate; they'll help tune the timing for improved stepper motor control in the next generation of loaders. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Excellent commentary there, sir! :D |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting ChristopherJamThese results are mostly useful in the aggregate; they'll help tune the timing for improved stepper motor control in the next generation of loaders. "Next generation of loaders" \:D/
I've just added Shrydar Stepping® to the massively overhauled next version of my loader, which is now seriously scratching on the 7 KB/s mark for uncompressed files.
I'm now looking at all these graphs, trying to find the optimal T1 value with a given T2 ≥ 72 bycles (the block transfer takes 72 cycles per byte plus random IRQ/DMA delays).
What would be a good value that's also guaranteed to work across all drives? Want to avoid that Chasm of Death many of them exhibit. :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Quoting KrillI've just added Shrydar Stepping® to the massively overhauled next version of my loader, which is now seriously scratching on the 7 KB/s mark for uncompressed files.
\O/
Quote:What would be a good (T1) value that's also guaranteed to work across all drives? Want to avoid that Chasm of Death many of them exhibit. :)
Given the significant spike at 20-24 bycles exhibited by hedning's Oceanic, and the even heaver one further to the right on THCM's SX-64, I'd probably lean towards going as low as 12-16. For almost all of the drives, that's going to intersect the upper left diagonal edge (minimal total step time) too; most of them will be good to go another dozen bycles later, ages before the block transmission time is over :) |
