Blitter cycle times ?

General discussions or ideas about hardware.
Post Reply
User avatar
exxos
Site Admin
Site Admin
Posts: 23497
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Blitter cycle times ?

Post by 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 ?
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
czietz
Posts: 548
Joined: Sun Jan 14, 2018 1:02 pm

Re: Blitter cycle times ?

Post by czietz »

Blitter can't read from or write to ST-RAM faster than the CPU. All ST-RAM access is orchestrated by the MCU.
User avatar
exxos
Site Admin
Site Admin
Posts: 23497
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Blitter cycle times ?

Post by 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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: Blitter cycle times ?

Post by 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
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
czietz
Posts: 548
Joined: Sun Jan 14, 2018 1:02 pm

Re: Blitter cycle times ?

Post by 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.
User avatar
exxos
Site Admin
Site Admin
Posts: 23497
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Blitter cycle times ?

Post by 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 ?
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: Blitter cycle times ?

Post by Badwolf »

exxos wrote: Fri Oct 29, 2021 12:38 pm 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
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
czietz
Posts: 548
Joined: Sun Jan 14, 2018 1:02 pm

Re: Blitter cycle times ?

Post by 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."
Post Reply

Return to “HARDWARE DISCUSSIONS”