SCSI Accelerator
SCSI Accelerator
Game Manuals · PDF
| Filename | SCSI_Accelerator_7.pdf |
|---|---|
| Size | 0.01 MB |
| Subsection | SCSI Accelerator |
| Downloads | 0 |
Enjoying MacTrove?
Anonymous downloads are free and unlimited.
Create a free account to track favorites,
contribute metadata corrections, and join the
community chat.
Reader
Loading…
OCR / Text contents
WHAT SCSI-ACCELERATOR IS ALL ABOUT.
The accelerator works only on a MacPlus! It enhances the throughput of I/O
operations for so called blind read and write operations. Nothing else is
affected.
The reason that the performance of these operations can be enhanced is
that Apple's code to do these operations is (and must be) suited to handle a
variety of disk types. Some of these are slower than others. In the following
discussion we will talk about read operations only, but the discussion applies
just as well to write operations.
When transfering data to or from a SCSI device, there is no support for
hardware handshake on the MacPlus (there is some on the other
Macintoshes). Because of this, the only really safe way to do the I/O is to poll
the SCSI chip for the arrival of a new byte each time you need one. Of course
this is slow. Therefore Apple introduced the "blind" operations. For blind
operations, the system only waits for the arrival of the first byte, the rest
of them are read in a small loop which looks like this:
@1 move.b (a1),(a2)+
dbra d6,@1
This means that after every transfer of a single byte, the Macintosh waits
at least the time to execute the DBRA (about 10 cycles) before fetching the
next byte. This is long enough for even the slowest hard disk that Apple
anticipated to have the next byte ready. In fact, most hard disk can deal with
a lot less! Reduction of this "dead" time can be achieved by unfolding the
loop, i.e. reducing the loop trip count and putting more than a single move.b
instruction in the loop body. Of course, if we put two moves right next to
each other, we get the fastest transfer that is possible (knowing that we do
not have a DMA controller). This might be too fast for some hard disks, so it
may well be that we have to put one or more NOP instructions between each
two move.b instructions. The execution time of a NOP is only 4 cycles
however, much less than for the DBRA and thus, throughput can be
increased even if we need 2 NOPs per move.b. By increasing the number of
move.b instructions in the loop body, we further decrease the looping
overhead, leading to increased performance, but of course, also to more use
of memory for the code.
Since the loop illustrated is 6 code bytes long, there is just enough place to
replace the loop with a JSR instruction to a patched version of the loop that
applies these techniques. This is exactly what the SCSI-Accelerator does.
The reason that this does not improve performance on the Mac SE or II/IIx is
that those machines support a sort of pseudo DMA transfer mode that
already takes care of getting in the bytes as soon as they arrive. For this
reason, the accelerator init refuses to install itself on anything other than a
Mac Plus.
HOW TO USE IT.
As said before, if you do not operate a Mac Plus, forget it, it will not install!
If you are using a MacPlus, the thing to do is to find out what kind of unfolded
loop will still work for your con…
Showing first 3,000 characters of 6,529 total. Open the full document →