Hi guys,
The Star Commander was my third-year diploma work at the university. :-)
Here's a translated extract from the originally Hungarian documentation:
---
The Commander's high speed transfer system is based on "Star Turbo", a
fast loader written for the Commodore 64, which I engineered in about
two years, after having studied several already existing fast loaders.
A fast loader can bypass several bottlenecks so that data is transferred
from the disk to the computer memory or vice versa as fast as possible.
1. Speed up head movement: the disk controller moves the head towards
the desired track only by a halftrack per interrupt. Setting the startup
value of the disk controller interrupt timer to a lower value makes the
execution of the interrupt occur more often, thus the head arrives at
the desired track within a shorter period of time.
2. Custom sector read/write routine: [...] because of its general purpose,
the disk controller system executes several redundant checks. On the
other hand, the fast loader knows exactly what it wants to do, therefore,
it can read and write sectors more purposefully, starting with skipping
the verification after having written a sector. Furthermore, while it
reads or writes the same track, it does not leave the interrupt. Doing
so would cause a waste of time until the routine is executed again in
the next interrupt. [Note: Actual sector read and write is done inside
the disk controller interrupt. The original 1541 DOS also does so.]
3. Speeding up data transfer: the most important part of the fast loader;
with proper programming, a 6-8 times higher speed can be achieved. The
high speed transfer is based on the two facts that 1) significantly less
synchronization than the original is still sufficient for reliable data
transfer and 2) with proper synchronization, instead of a bit via the
DATA line, two bits can be transferred at a time via the DATA and CLK
lines.
4. Reading sectors without interleave: during the time of decoding the
sector and transferring it to the computer, the disk continues to
revolve. When the transfer ends, not the physically next sector arrives
under the head but cca. the eighth-tenth next sector. If a file was
stored continuously on the disk (the next sector of the file was the
sector with a sector number higher by one) then there would be a waste
of time because of having to wait for the next sector of the file to
arrive under the head. On PC floppy disks, this is solved by the
physical sectors being laid out in a non-continuous order: the first
physical sector is followed by e.g. the fourth, then the seventh; this
is a hard interleave. VC1541 disks, however, use a soft interleave, where
the subsequent logical sectors of the file do not follow each other on
subsequent physical sectors of the disk; e.g. the first logical sector
of the file is on the zeroth physical sector of the disk, the second on
the tenth, the third on the twentieth.
If the fast loader speeds up the data transfer, it is possible, that
the transfer ends then the fifth sector, following the sector having
been transferred, arrives under the head and there's again a waste of
time until the next logical sector [the eighth-tenth physical sector
following] arrives. To circumvent this, there are two methods: either
the fast loader transfers data from the complete track, sends it to the
computer and lets the computer collect the sectors belonging to the
file; or the fast loader itself identifies which sectors on the current
track belong to the file. The latter is accomplished by reading in the
first two bytes of each sector (the link bytes for the sector chaining),
transferring only the sectors belonging to the file, independently of
their logical order, rather by the the order they arrive under the head,
and letting the computer put them back in order. The first method is to
be used when presumably files are not very fragmented on the disk; the
second method is generally useful, as it is not a problem if only one
sector per track belongs to the file: reading into sectors [to get the
link bytes] costs only a single revolution of the disk. Both methods
assume the existence of a track-sized buffer in the computer.
5. Custom GCR-encoding and -decoding program: there are solutions that
are faster than the one embedded into the DOS. Some fast loaders solve
this task themselves, however, this results in a significantly larger
loader.
6. Custom disk format: only for prepared [not all-purpose blank] disks,
e.g. games that already include a fast loader. The reason for the speed
increase is that data is not encoded with the GCR algorithm, when
written onto the disk, but some other method whose decoding costs a
significantly less amount of time. Of course, such disks can be copied
only be special disk copiers, ones that don't attempt to GCR-decode data
read from the source disk, rather copy data unchanged to the destination
disk.
Some Commodore 64 extension cards include fast loaders that speed up
loading to 25 times the original speed, using all of the methods above.
This is very significant as, at such a speed, the complete 64 kbytes of
memory in the Commodore 64 can be filled with data within 8 seconds. Of
course, this requires very special programs that rely on microsecond
timing; this is, unfortunately, impossible when connecting the drive to
a PC.
---
Latter parts talk about Star Turbo and The Star Commander so they're not
as general as that above. Bye,
Joe
--
KOVÁCS Balázs alias Joe Forster/STA ***@c64.org; http://sta.c64.org
Orsolya u. 5. IV/12., 1204 Budapest, Hungary; +36-1-285-3881, 6-10PM CET
(SpamAssassin protection! No HTML E-mails! No uncompressed attachments!)