| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Interleave question(s).
Using a d64 with modified interleave in vice, the difference in speed access is noticeable or all work always at the maximum possible speed because "nothing rotate really"?
And again: there is a way to know exactly which sector is "under" drive head during an access?
In other words: when a sector access is done, how can i know for sure where head is after X amount of time?
(Also theoretical calculation based on a perfect 300rpm rotating disk are wellcome... +) ) |
|
... 1 post hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
or you can always use D64 Shredder V0.1 :o) |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
I need to learn something.
This is a loader "read sector" subroutine into drivecode:
readsect: ldy #RETRIES ;Retry counter
retry: cli ;Enable interrupts so that command can be
jsr success ;executed, turn on led
lda #$80
sta acsbf ;Command:read sector
poll1: lda acsbf ;Wait until ready
bmi poll1
sei
cmp #1
beq success ;Also sets carry flag to 1
lda id ;Check for disk ID change
sta iddrv0
lda id+1
sta iddrv0+1
dey ;Decrease retry counter
bne retry
failure: clc
success: lda $1c00
eor #$08
sta $1c00
rts
If i understand correctly, the code labeled as "poll1" is where "read sector" command is started and code wait until drive is ready (correct sector is found).
Is this the point where i need to "count how far" drive is from correct sector? |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
That is the Covert Bitops loader drivecode, right? When you work in the "high level" like it does, using the drive OS and jobcodes you don't get to know what's happening in the meanwhile, and what sectors actually pass under the drive head. Instead you just block until the right sector has been read, like you observed.
When you work in the low level by reading the raw bit data yourself you are able to see which sector is about to start, by first decoding the sector header only, and can then decide what to do with it. For inspiration you can look at Krill's loader, but it's much more complex overall that way.
For practical purposes using a simple high-level loader such as the CovertBitops loader I second Doynax; just experiment with interleaves and find out which works best. Lots of factors affect this: the transfer protocol, any on-the-fly decompression, how much rastertime is being taken away by interrupts. |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Quoting cadaverjust experiment with interleaves and find out which works best. Lots of factors affect this: the transfer protocol, any on-the-fly decompression, how much rastertime is being taken away by interrupts.
Once assembled loader with the rest of code, i'm looking for a method to determine best interleave value, obviously taking care of the fair degree of variance between drives, emulated or not, avoid simply proceed by trial and error. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting FlaviowebOnce assembled loader with the rest of code, i'm looking for a method to determine best interleave value, obviously taking care of the fair degree of variance between drives, emulated or not, avoid simply proceed by trial and error. I empathize with your aversion to magic numbers but in this case there are so few plausible values to try that there is little to be gained from automating the process.
For traditional blanked-screen loading of uncompressed data the only variable is the speed-zone and rate of rotation and so you may calculate the ideal setting. Even so you will still want to verify your calculations so you might as well take manual approach.
In the modern world of background IRQ loading and streaming decompression there is no such thing as a single ideal interleave for a track. Instead it all varies from sector to sector.
Granted for any perfectly deterministic demo there is some optimum sector layout. Therefore you might attempt a bit of profile-guided optimization by letting the low-level drivecode log the first encountered actual sector at each seek attempt and feed the result back into your floppy imaging process (there are wrinkles but you get the general idea.)
A saner, not to mention far less brittle, approach would be to try for an interleave-insensitive loading scheme instead. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Out of order loading solves the interleave problems to a certain degree (you need to differ between needed and unneeded sectors only at the starting and ending track) |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
What is the "speed tolerance" in which a 1541 still working?
300rpm +/- ?% |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
There is some discussion about it here: Drive coding: safe maximum time between $1c01 reads?
Worst case is certainly less than 300 rpm +/-10%.
+/-5% should be safe in most cases. |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Just another thing that sounds a little ambiguous to me.
Doynax says "At 300 RPM the distance between each pair of sectors is about PAL 9400 cycles."
This mean that if head is at the start of sector 1, after 9400 cycles (+/-) is at the start of sector 2, or on sector 3? |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
300 rpm = 200 ms/rev.
200 ms / 21 sectors = 9523 cycles nominal @ 1 MHz.
19 sectors = 10526.
18 sectors = 11111.
17 sectors = 11764.
Because of speed tolerances + the sectors are not evenly spread (larger gap at the end of the track) the values can be lower (or higher) in practice. |
| Previous - 1 | 2 - Next |
