[roondar]

Originally Posted by idrougge

Sounds to me like the true Amiga solution is a lot of talking and a lot less doing.

Ah, sorry - this thread is about discussions (see title), not actually making stuff. That'd be silly

You're talking about prefetching. It may or may not work depending on how the game assets are used. I'm aware of the parallelism possible with the chipset.

Generally though you only really get parallelism on the last bit plane of a bob. If you're doing a load of blits in sequence you have to serialise access to the blitter.
The rest of the time you're waiting on the blitter. Polling the blitter's status is a chip ram bus access btw. If you want true parallelism you either:

a) use interleaved bitplanes which limits the vertical size of your bob and costs you duplicate mask data (ouch)

Interleaved bitplanes is pretty much the standard for quick blitting on the Amiga. Yeah, the extra mask data kinda sucks - but the vertical size is never really a problem (for a 4 bitplane screen, max blit vertical size is ~250 pixels when using interleaved mode. I'd say that's enough, really).

Blitting seperate bitplanes is not the way to go if you want speed.

b) Use an interrupt restart and suck up the cost of the interrupt handler (ouch)

Indeed, that'll cost some 100 or so CPU cycles per blit. But when compared to the ~3000 CPU cycles your blit is going to take it's not really that much.

c) Limit it to one VBL, use the blitter finished disable bit and do it via the copper.

Blitter controlled by Copper is pretty much the way to go when using fastram and was what I was getting at. The CPU can spend whatever portion of a frame it needs to create an optimised Copper list (copying over just the result or even just the delta if you want to be really clever), which then does all the blitting on the next frame. And because you'd create such a copperlist runtime you can even do blits that cross the VBL.

Moreover, because you are blitting using the copper, the CPU needs only touch chipram to either write the relevant parts of the copperlist to update or to transfer GFX over from fastram. Meaning that the rest of the available DMA* can be used pretty much just for the blitter - instead of using 10-30% of the DMA time to run CPU instructions.

*) Of course, deducting bitplane, sprite, etc DMA.

In essence, such a method would give the 68000 all ~141000 cycles to use per frame for game logic and setting up the copperlists and give the blitter a bunch more cycles than it would normally have.

Again, not exactly easy - but definitely possible and definitely much quicker than running code & blitter from chipmemory/slowmemory. Which is exactly why I lament the lack of fastram expansions for the most common Amiga.

Many slots usable for the blitter typically get consumed by higher priority DMA.
Bitplanes, copper, audio (!) and sprites all steal cycles usable by the Amiga blitter.

This happens regardless of running the CPU in fastram or not. So, running the CPU in fastram does let you use more chip DMA cycles than normal. Plus, you're no longer slowing the CPU - regardless of screenmode.

I'd rather have a true bus master blitter which can access everything. I'd prefer that even if it only uses 68k bus cycles.
That way system fonts can be blitted from ROM, workbench background pictures don't consume any precious chip memory and bitmap fonts can be rendered from fast RAM.

Swings and roundabouts....

WellI agree that a bus master blitter would've been nicer, but the Amiga does not have such a Blitter. The one it does have is pretty nice though