*-----------------------------------------------------------------------*
*		   Falcon MC68040 CPU ToolKit v5.00			* 
*-----------------------------------------------------------------------*


DMASNOOP.PRG
------------


Technical description:
----------------------

DMASNOOP.PRG is a small utility which runs from the auto folder and
converts all remaining ST-RAM into non-cacheable memory. This program is
not really needed for most setups, but certain applications will rely
on this for safe SCSI disk access and/or faultless audio record/playback.

If you are not sure how important DMASNOOP is on your system, it may be
safer to simply install it anyway. An understanding of what the program
actually does will help you make your mind up on the matter.


Stale cache entries and DMASNOOP:
---------------------------------

The Falcon/Afterburner has no hardware 'bus-snooping' capabilities. This
means that data transferred via DMA hardware will not be noticed by the
processor itself - resulting in possible conflicts between the actual
contents of system RAM and the contents of the CPU cache - the datacache
in particular.

DMA devices include things like SCSI, Floppy disk, Blitter chip (this is
now off-limits anyway), Audio hardware and certain (rare) DSP operations.

The only way to make these functions 100% safe with some software is to
make sure the ST-RAM used by those applications can *never* be cached by
the CPU - after all, stale cache entries can never arise if the cache
never holds the data in the first place! DMASNOOP simply prevents ST-RAM
from being cached by the CPU and so compatibility with direct-DMA based
software is assured, so long as that software only uses ST-RAM which has
been protected by DMASNOOP. This means programs which have been executed
after DMASNOOP in the auto-folder or on the desktop.

It is important to note that DMASNOOP only converts *REMAINING* ST-RAM
to non-cacheable memory. For this reason, the safety of direct-DMA based
applications installed *before* DMASNOOP cannot be assured!

Any software actually *running* in ST-RAM with DMASNOOP installed will
unfortunately run _very_ slowly because the caches will act like they are
disabled, so it is important to run everything from FastRAM wherever
possible.

Even programs relying on DMA should be able to run from FastRAM so long
as they allocate buffers and resources from ST-RAM. This can be achieved
by setting the TT-Prg flag and clearing the TT-Malloc flag in the program
header. If this doesn't work, and you can't stand the slow speed of
programs relying entirely on ST-RAM, you will have to risk running
without DMASNOOP and just hope that the software does not suffer from
problems caused by stale cache entries.

A good compromise in these cases is running without DMASNOOP, but with
the data cache turned off. It is usually the data cache which causes such
problems, and it has the least impact on program execution times (of the
two caches) so turning it off is a good alternative to using DMASNOOP
when FastRAM is just not an option. This is a very rarely encountered
situation, but it is worth remembering.

Since most software never relies on direct DMA, you can normally run
happily without DMASNOOP, and with both caches enabled. If you don't
have SCSI devices fitted, your need for DMASNOOP is *greatly* reduced.

Note: It goes without saying that since FastRAM cannot be used by DMA
devices, there is no point in worrying about it. Only ST-RAM can cause
problems of this nature. Since ST-RAM is not used for running programs
when you have FastRAM available, non-cacheable ST-RAM is not normally
going to be a problem!

So, to re-iterate (and highly compress) what has been covered above...

DMASNOOP is needed *only* when programs are likely to use ST-RAM for
direct-DMA transfers, which normally means SCSI, Floppy or Audio. Even
then, most of the time it just isn't needed because good software knows
about such problems and prevents them from happening.

Since the harddisk driver and OS are already capable of dealing with
direct DMA, these don't count. It's only when *additional* software is
likely to 'detour' around the OS that things get a little risky.

This 'additional' software includes things like 3rd party disk caches,
low-level disk copiers, sound samplers, disk formatters etc. etc.

Known applications:
-------------------

Some examples of software with known DMA/cache problems include:

* TCACHE63 	Requires DMASNOOP when told to malloc from ST-RAM,
		although it is *not* necessary if told to malloc
		from FastRAM. Some people (14MB users) may want to
		spend large wads of ST-RAM on a disk cache, since
		it's not much needed for anything else. This is a
		good reason for installing DMASNOOP.

(this list is still being updated)