Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!versatc!ubvax!ardent!rap!rap
From: rap@rap.ardent.com (Rob Peck)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Blitter Operation
Message-ID: <6633@ardent.UUCP>
Date: 23 May 89 18:17:45 GMT
References: <8905132203.AA27784@postgres.Berkeley.EDU> <17209@usc.edu> <6542@ardent.UUCP> <3854@sugar.hackercorp.com>
Sender: news@ardent.UUCP
Reply-To: rap@rap.ardent.com (Rob Peck)
Organization: Ardent Computer Corp., Sunnyvale, CA
Lines: 25

In article <3854@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes:
>In article <6542@ardent.UUCP>, rap@rap.ardent.com (Rob Peck) writes:

>> though the blitter "stutter-stops" to give the 68000 occasional access,
>> then immediately grabs the bus again after single cycles are granted.
>
>Could this explain why my SMUS player "stutter-plays" anytime floppy
>activity is going on, but not during hard disk activity?  That the
>blitter is used to decode the data read off the floppy and the blitter
>locks the CPU out for a relatively long time (a few ms would be enough)?

I would believe that this IS the case.  Yes, the blitter IS used to decode
the floppy data.  And if there is display DMA going on, that begins to
erode the 68000 access to the bus, and the blitter finishes the job.
A solution that might be tried is to try anything possible to run from
fast memory, attempting to stay out of the blitter's way.  This way both
the custom chips and the 68000 both get to run full-tilt.  That is, make
sure that the data structures that you are manipulating, such as perhaps
an audio I/O control block, are in MEMF_FAST, and only the audio data
to which the block points are in MEMF_CHIP.  You'll still run into
contention when copying from fast to chip to add new audio data, but
perhaps have less stutter along the way.  But then you probably thought
of this already.  :-)

Rob Peck