Menu
▾
▴
#470 C1541 interleave command
C1541 could use an "interleave" command to override the drive's default interleave when writing files.
I've done some tests, in x64sc, by timing a disk fast load (my two-bit transfer) with several file and found an interleave of 1 is much faster at 27302316 cycles instead of 37983312 cycles with the default interleave of 10. This rather assumes the drive disk rotation timing in x64sc is accurate, but it seems to match my Oceanic II drive performance wise.
The specific code changes public in this repo: https://github.com/martinpiper/C1541-Tweaks/commit/dd630cd0147f9944f2ee60c25f476f42374b08cc
For comparison reference:
test.d64 uses interleave 10
test2.d64 uses interleave 1
Visually, using interleave 1 means the screen shows multi-coloured bars a lot more often indicating it is doing data transfer and displays a black screen, indicating sector seek/decode, a lot less.
Last edit: Martin Piper 2023-10-14
IMHO this kind of control is out of scope for c1541... c1541 is basically a frontend to the virtual drive emulation, and that tries to operate as close as possible to the real hardware (minus TDE). It'd require quite some ugly hackery to do this sort of thing.
And a modern loader should be able to load out of order anyway :)
C1541 is really meant to be a "complete stand-alone disk image maintenance utility", from its own docs. The code change is very small, no large hacks needed either. It also handles tape files, that's "in scope"... Anyway, altering the interleave, which it already does for drive type, is part of drive disk image maintenance.
The loader does load out of order sectors perfectly well, it's just faster to read sectors in with a different interleave.
Last edit: Martin Piper 2023-10-14
I think there is a misunderstanding about "out of order loading" here: The fastest loaders for the C64 usually implement arbitrary-order-loading by spending one disk revolution to scan the link bytes of all sectors on the track to determine which sectors belong to the current file and what order they should be in. After that, the loader reads and transmits whatever sector comes to the head next that hasn't been transmitted yet (and is related to the current file), reordering the data to file order is handled on the C64 by storing it at the correct memory locations.
With a loader like this the interleave does not matter, one common example is the 1541 loader from the Final Cartridge III.
I just skimmed over your changes - why is the interleave option only exposed via c1541 and not via the command channel? Some speeder ROMs offered that feature (e.g. JiffyDOS' G command) and the 1571 even has it as a stock feature (U0>S).
Yes this is known. However for sequential streaming of data then processing blocks out of order isn't desirable, hence the need to alter the interleave.
The underlying code only uses that point to decide the interleave. It's easiest to tweak that with the command rather than the command channel.
It would have to pass that option through many layers down to the virtual drive code. And we are trying to remove complexity from this code, not add more.
And if your out of order loading shows different behaviour depending on interleave... its not working right in the first place :)
Of course the loader is doing it right, it takes advantage of the drive being able to read and process the data quicker coming from the disk.
It's a simple single function call and setting a single override variable, which you can see in the code diff linked above. It's not hard at all...
You are not making any sense. The data is processed always in the same speed, only the order of blocks changes. Its not proper out of order loading if changing the interleave has any effect. Not relying on that is the whole point of out of order loading.
And that link doesn't work either :)
It makes pefect sense. After sending the data to the C64, the drive is asked to get the next block, if the disk, due to it rotating, is in the wrong position then it needs to wait for the disk to rotate around before it can read the correct block. Changing the interleave means the drive is more often in the correct spot so the drive needs to wait less time for block to be processed.
Try the link again, it's public...
Yes, that is the case for a regular loader, that needs to fetch the blocks in a certain order. It's exactly the thing that out of order loading eliminates.
However it's better to optimise the layout.
I'd rather investigate why the worst case option (interleave = 1) gives the best numbers - because that is a clear indication for that something is seriously broken.
Well no, it's working as expected. You just don't understand the use case.
IF there is a use case for the worst possible interleave, then you failed to explain it in the first place.
In any case, what Unseen said.