Blitter cycle times ?

[exxos]

Just a random thought which popped in my head. When the CPU reads and writes to RAM it will take 4 clock cycles to read then likely a shifter access which adds delays, then another 4 cycles to write to ram. Standard stuff.BUT, how does the blitter manage to copy RAM twice as fast when AFAIK you cannot do more than 1 RAM access per CPU bus cycle.

It gives me the impression that the blitter can do read and write operations in a single clock cycle? Not taking the usual 4 clock cycles that the CPU does. It makes sense I think, but then how does the blitter gain this faster RAM access ? More to the point, why can't a faster running CPU ultimately do the same ?

[czietz]

Blitter can't read from or write to ST-RAM faster than the CPU. All ST-RAM access is orchestrated by the MCU.

[exxos]

So what exactly does the blitter do faster than the CPU then ?

I don't know anything about the blitter or how it works unfortunately.

[Badwolf]

In a recent Computerphile video, Steve Bagley did a bit of an explainer.

In effect, fewer instruction reads and fewer data manipulation cycles means the effective memory throughput of the blitter (ie. memory accesses actually serving our purpose) is closer to the theoretical memory bandwidth than that of the CPU.

At least that's my takeaway.




If you have instructions that fit in caches (or really fast AltRAM for instructions whilst the data is in STRAM) and a sufficiently quick CPU, you'll tend towards the same speeds as blitter.

BW

[czietz]

Actually, when doing a simple memcopy, the Blitter is only slightly faster - and not twice as fast. With the 68000, copying 32 bits with the CPU with "MOVE.L (Ax)+,(Ay)+" takes 20 cycles, i.e., 5 cycles per byte. Whereas copying 16 bits with the Blitter (neglecting the time to setup the Blitter) takes 8 cycles, i.e., 4 cycles/byte. The difference is caused by the fact that the CPU also needs to read instructions from RAM (=further bus cycles), while the Blitter once it has been set up only reads and writes data.

The Blitter excels when additional operations (bit shifts, logical operations) are needed on the data.

[exxos]

How does the blitter manage like 7x faster copying data than the CPU then ? In GB6 I copy the square from the top left and move it left to right, that is just a copy operation using the blitter. So just assumed it would copying data faster than the CPU.

EDIT:

I guess the overhead in the OS of "blitter emulation" is to blame ?

[Badwolf]

I guess the overhead in the OS of "blitter emulation" is to blame ?

You'd need to work out the percentage of 'useful' memory accesses versus 'overhead' memory accesses. I'd expect to see a significant difference between instruction cache on and off.

BW

[czietz]

Moving a rectangle on-screen is so much more than a memory copy! It involves masking and bit shifting. Imagine moving the rectangle by one pixel. Then bit0 needs to be shifted into bit1, bit1 into bit2, etc. Shifts are terribly slow on the 68000. That is precisely what I was saying: "The Blitter excels when additional operations (bit shifts, logical operations) are needed on the data."