| |
Zaz
Account closed
Registered: Mar 2004
Posts: 33 |
loading times & drive compatibility
Hi all,
I'm working on my first multi-load demo for the C64.
I'd like to have good synchronization between the music and the effects, so I have to take into account loading times.
So the question is, what's a good strategy to do this? Given that loading times will vary between different drive models, and maybe between different drives of the same model.
Is a simple safety margin good enough, and if so, how can I determine how long it should be? Any other issues to consider?
I would like to use Krill's loader, btw.
Thanks in advance.
|
|
... 39 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Yes, my loader also implements head acceleration for trackseek. These are the parameters:
.define MINSTPSP $18 ; min. r/w head stepping speed on 1541/41-C/41-II/70/71
.define MAXSTPSP $10 ; max. r/w head stepping speed on 1541/41-C/41-II/70/71
.define STEPRACC $1c ; r/w head stepping acceleration on 1541/41-C/41-II/70/71
Note that the initial speed is $18, this seems to be the maximum safe speed without acceleration.
Raven: I'll write up a detailed account on the workings of the non-sync optimization up there and put it here soonish. :) |
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
Thanx Krill :)
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
what & how can go wrong when the speed is too high? how does acceleration fix this ? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: what & how can go wrong when the speed is too high? how does acceleration fix this ?
You can end up on the wrong track/half track.
Acceleration allows faster operation because it takes advantage of the mechanical intertia of the drive head mechanism.
When it is already moving it takes less force to keep moving and more force to stop it. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
so it's a matter of timing to end up on the right track? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: so it's a matter of timing to end up on the right track?
It's not, but if you try to go too fast some steps might not happen correctly.
If you go very slow it will always work.
EDIT: some useful info here: http://en.wikipedia.org/wiki/Stepper_motor |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Following is an explanation of why my optimization as described above works. Refer to the timing table for clarity.
The actual low-level read/write circuitry is clocked at 16 MHz. According to which of the four track zones is selected, 13 to 16 ticks of that clock or less are counted until a clock pulse for the decoder is generated. If no flux reversal (magnetization sign flipping) within the duration of this time has happened while reading, the read value is considered a 0. If there has been a transition of magnetization sense, the value is a 1, and that counter is reset to count 13-16 ticks according to the track zone, syncing the circuit by cutting off the current time slice and starting the next one. (*)
Now, a raw bit is made up by four such periods (where the value of the first period decides on the bit value). This allows a rough general speed estimate of 4 cycles per bit cell.
Also, that yields a somewhat more accurate upper bound of the time needed to read a raw byte on a given track zone (note that this is independent from each drive's individual rotation speed and flutter): On an outermost track (1-17, zone 11), a maximum bit time of 13 cycles at 16 MHz equals 1 cycle at approximately 16 / 13 = 1.23 MHz, which makes 4 * 8 (bits) / 1.23 (MHz) = 26.02 cycles to read a complete byte. This means waiting at least 26 cycles after the last BYTESYNC signal (v-flag set) until reading from the VIA port at $1c01, to safely fetch the next byte in $1c01 without syncing to its corresponding BYTESYNC event. On an innermost track (31+, zone 00), this upper bound is 4 * 8 / 1.00 = 32.00 cycles. (**)
This means that waiting 32 or a few more cycles is safe regardless of the selected track zone. How many more cycles to wait are safe is determined by the next minimum amount of safe wait cycles on the outermost tracks. This is simply 2 * 26.02 = 54.02 cycles, and in reality a bit less than that. (***)
Reading the $1c01 values as soon as possible according to this theory, but of course not too early, is advised.
I hope this explanation is sufficient and explains it well enough. :)
(*) The duration of a time slice is shorter (13 ticks) on the outer tracks (1 and up-/inwards) and longer on the inner tracks, giving the outer tracks more blocks than the the inner tracks. As the same angular distance on the rotating disk equals a shorter arc passed on the inner tracks compared to the outer tracks in the same amount of time, more bits can be safely stored on outer tracks because the bit density is constant on the whole surface, but a longer distance is covered.
(**) Note that the actual maximum amount of time needed is somewhat smaller, as no raw byte is made up entirely of 0's, and 1's are slightly "shorter" on a track due to the nature of the encoding scheme as described here. There can be only two 0's in a row because more than two will make the read circuitry go out of sync, since the counter is not reset at the definite start of a time slice denoted by a transition, i.e., a 1. The "lengthiest" GCR nibbles are those which have three 0's, and two 1's.
(***) Again, less than that also because the existence of 80% 1's (4:1) in a "shortest" (again, in the time domain) GCR stream. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Krill, your explanation and time table is very helpful. There's one thing that I feel needs clarification, though.
You mention that the loop must fit into 130 cycles (actually you say 129, but I assume that's an off-by-one error), because that's how fast a complete 40-bit word swooshes past the read head in the outer tracks. This is of course 5x26 corresponding to the five bytes. In fact your loop executes in 124 cycles if every bvc falls through, giving a slack of 6 cycles.
But if the disk was written with a slow motor and is read back with a fast motor, then the image of each sector on the disk will appear shrunk by a factor corresponding to the difference in motor speeds. (This will cause the 1 bits to arrive earlier than expected, resetting the bit timer.) So if a nominally 130 cycles long part of the sector is allowed to shrink to 124 cycles, that allows for a motor speed factor of 130/124 between writer and reader, which is about 1.05, that is 5%. If we center this interval around the nominal 300 rpm, we get a span of 293-307 which is safe.
Here's a handy table of loop tightness versus motor speed margin:
130 cycles: No margin; exactly same motor speed required of writer and reader.
129 cycles: 299-301 rpm
128 cycles: 298-302 rpm
127 cycles: 296-303 rpm
126 cycles: 295-304 rpm
125 cycles: 294-305 rpm
124 cycles: 293-307 rpm
But this is nowhere near the reported speed difference of 320/280 mentioned in another thread. Either those rumours were exaggerated, or nobody has tried to move floppies between such drives and calibrated ones.
Or do I miscalculate?
For comparison, the 1541 ROM routines use 95 cycles, which allows a speed range of 253-346 rpm. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
5% is already quite much.... from my experience with floppy drives considering ~ +/- 2% is safe. .... the huge margins supported by the 1541 probably comes from the oldish PET drives, where you can be lucky if its in the 5% margin =) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
lft: You were right, i was off by one and have actually maxed out the loop to 130 cycles a few loader versions ago.
No problems have been reported so far (and i believe aging drives tend to spin the disk slower, which is alright as it makes the loop less tight). But we'll see... :) |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
