Blitter fighting the CPU

[h0ffman]

So, I'm trying to get my latest thingy-me-bob to run in a frame. It consists of 4 scopes plotted full width accross the screen which are vertically blitter filled.

If i switch off the blitter calls the whole CPU plotting time take around 2/3 or 3/4 of the raster time. If i switch the blitter calls on, its taking longer than a frame.

Am I right in thinking when the blitter is running, it steals cycles from the CPU? So the CPU would take longer to run the code?

If this is the case, I think I might have to drastically re-think how this thingy-me-bob is working..

[pmc]

h0ffman - it's probably chip RAM access where the conflicts are I would've thought cos that's where your graphics data is.

Obviously the blitter and CPU can't access the bus to the chip RAM at the same time so yes, there are conflicts.

You could maybe try setting blitter nasty to allow the blitter to steal cycles from the CPU, might make your blitter operations complete quicker...?

Whether this will help you squeeze it into a frame or not I'm not sure...

Obviously, narrowing the scopes and optimising the rest of the code or, at worst case, cutting something out might be required though...

[h0ffman]

I have a plan B, half the scope size and double each line up. Thus halfing the blitter time required.

[Lord Riton]

Here is some explanation of this: http://amigadev.elowar.com/read/ADCD.../node012B.html

[h0ffman]

Dam it! My own fault for now writing it with Cycle Exact on in the first place!

At least with the changes the general look of the thingy-me-bob should remain.

[pmc]

Originally Posted by h0ffman

Dam it! My own fault for now writing it with Cycle Exact on in the first place!

It's always worth running the emulator in cycle exact if you're developing your code in the emulator and you want to be reasonably sure that it'll then run OK on a real machine too.

Obviously this holds more true for emulated OCS/ECS 68000 systems as that's where the emu is most accurate.