Ruud,

It looks like for certain multiples there will be "close intervals" (eg : 15
to 1). In these cases, I'd recommend back-scattering so that the interleave
works out to be 4,5 or some other combination as it may not be possible to
exactly reach an interleave of 4.



You're using the current

On Mon, Jun 1, 2009 at 3:29 PM, <Ruud@baltissen.org> wrote:

> Hallo allemaal,
>
>
> I have a little problem which probably has a simple solution but I don't
> see it. I already found out that (for the moment) an interleave of four
> works out fine for all tracks. I calculate the next sector by adding 4 and
> if the result is equal or beyond the number of sectors on that track, I
> subtract this number. For tracks 25..30 that doesn't work out because in
> this way I never get to the odd tracks. So here I use interleave 5.
>
> I changed the program by using tables for every density. The tabel for
> tracks 25..30:
>
> CTab1
>                .by 5, 6, 7, 8, 9, 10, 11, 12, 13
>                .by 14, 15, 16, 17, 0, 1, 2, 3, 4
>
> The idea is simple, use the last read sector as index for the next sector.
> So the order will be 0 -> 5 -> 10 -> 15 -> 2 -> 6 etc. In this case I
> started with 0 but the idea is to be able to start with any sector.
>
> Using an interleave of 4 would result in:
>
>                .by 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
>                .by 14, 15, 16, 17, 0, 1, 2, 3
>
> But of course this goes wrong as the odd sectors aren't read. My question:
> what table should I use to benefit at least a bit of interleave 4?
>
> I tried with swapping the 0 and 1. Works out fine if you start reading with
> sector 0. But if you start with another sector on one moment you will go
> from 15 to 0 as the difference is only three sectors, the drive has to wait
> one turn and there goes all you the time you previously gained. I tried
> some other schemes but they didn't work out. Maybe it is simple but maybe
> my mind isn't with it anymore.
>
> Why? I also tried to write data to the floppy but that didn't work out
> either. For the two day in a row already! I used the routine used by the
> 1541 itself, didn't change one byte. But if I try to read the directory:
> 23, read error. Most strange thing: reading the BAM table and the first
> directory sector prooved that the dat was fine, except that I got the data
> only after a lot track shifting, rattling and other funny noises. I hate
> these kind of errors. Writing or reading wrong data is no problem: you
> always cab track it down to bytes. But this is a type of error that goes a
> bit too deep for the moment. But I know, stayers get the loot (or something
> like this) :)
>
>
> --
>    ___
>   / __|__
>  / /  |_/     Groetjes, Ruud Baltissen
>  \ \__|_\
>   \___|       http://Ruud.C64.org
>
>
>
>
>
>
>
>       Message was sent through the cbm-hackers mailing list
>

       Message was sent through the cbm-hackers mailing list