rap@rap.ardent.com (Rob Peck) (05/19/89)
> In article <4182@tekig5.PEN.TEK.COM> wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) writes: > 2. Blitter only accesses 1 out 2 memory cycles at best and it > isn't real time anyway. As I remember it, the blitter is quite capable of using EVERY cycle. It only takes a back seat if it senses that some other DMA is pending. The 68000 gets locked out of most cycles when the blitter is running, though the blitter "stutter-stops" to give the 68000 occasional access, then immediately grabs the bus again after single cycles are granted. Display DMA takes precedence over the blitter automatically to assure that a stable display is shown. Tom Rokiki (BlitLab author and known blitter expert could confirm this.) Rob Peck
karl@sugar.hackercorp.com (Karl Lehenbauer) (05/23/89)
In article <6542@ardent.UUCP>, rap@rap.ardent.com (Rob Peck) writes: > As I remember it, the blitter is quite capable of using EVERY cycle. > It only takes a back seat if it senses that some other DMA is pending. > The 68000 gets locked out of most cycles when the blitter is running, > 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)? -- -- uunet!sugar!karl | "Nobody hipped me to that, dude." -- Pee Wee -- Usenet BBS (713) 438-5018
rap@rap.ardent.com (Rob Peck) (05/24/89)
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
doug@xdos.UUCP (Doug Merritt) (05/24/89)
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: >> As I remember it, the blitter is quite capable of using EVERY cycle. >> It only takes a back seat if it senses that some other DMA is pending. The mode where the blitter takes *all* of the 68K cycles is the one called BLITTER_NASTY (I guess the first time around, all of us were waiting for someone else to say so). It is not the blitter's usual mode, simply because it *is* unfriendly. >Could this explain why my SMUS player "stutter-plays" anytime floppy >activity is going on, but not during hard disk activity? That the I know that some hard disk controllers/drivers use BLITTER_NASTY and others don't, depending on the manufacturer. I don't recall whether the floppy does (I can't seem to find my Hardware Reference manual), but I wouldn't think so because it seems like it would be slow enough not to need it. But I could be wrong. I suggest you try upping the SMUS task priority; that's pretty likely to fix the problem. Weren't you going to post this player? Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary "Welcome to Mars; now go home!" (Seen on a bumper sticker off Phobos)
dale@boing.UUCP (Dale Luck) (05/28/89)
In article <328@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: >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: >>> As I remember it, the blitter is quite capable of using EVERY cycle. >>> It only takes a back seat if it senses that some other DMA is pending. > >The mode where the blitter takes *all* of the 68K cycles is the one called >BLITTER_NASTY (I guess the first time around, all of us were waiting for >someone else to say so). > >It is not the blitter's usual mode, simply because it *is* unfriendly. > The blitter has 4 dma channels (3 read and 1 write). It is incapable of using a single channel every cycle however it can use alternate channels every cycle. Because of this interleaving, startup and stopping the blitter with multiple channels can leave available cycles for the processor. If you are using only one channel the blitter will use every other cycle. The rest are left for the processor. Note: Most other dma devices have priority over the blitter: display dma, sprites, floppy, copper, etc. So blitter cycles are fit in between these requests as well. The standard 2 bitplane 640x200 wb display requires every other memory cycle during display refresh to keep DENISE busy. So the blitter can only get every other cycle here. The blitter will let the 68000 get cycles when it needs them but when both are running full tilt the blitter will take most of the cycles. Blitter_Nasty mode controls whether the blitter should yield to the processor if they both need cycles. If there are cycles available because the blitter does not need them they will be given to the processor even if blitter_nasty is set. Blitter Nasty does not control how many times it uses the memory cycles, the frequency of access to memory is just the same as Blitter_nasty off. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale