about the blitter ^^

Orion_ · Post by **Orion_** » Fri Apr 09, 2004 7:17 pm

hehe, after playing a little with raster I was wondering If I could speed up my routine with the blitter

I saw that it can do a lot of thing like shift, and/or operation and all at 16MHz !
I tried to use it but nothing apears on screen

here is what I do:

32 bits address of the image in $FF8A24 - $FF8A26
32 bits address of the screen in $FF8A32 - $FF8A34
1 in $FF8A20 (increment of 1 word each time (?) )
1 in $FF8A2E (--)
0 in $FF8A22 (increment of 0 each Y time, (the source is a 1D sprite) )
120 in $FF8A30 (120 bytes each Y time to go to next screen line)
10 in $FF8A36 (10 word to copy for each line)
81 in $FF8A38 (81 lines)
3 in $FF8A3B (copy source (?) )

did I forget something ? (I think yes

)

GT Turbo · Post by **GT Turbo** » Sat Apr 10, 2004 8:41 am

Hi Orion,

There is some errors in the blitter source, if i have enough time i will
send you an example of blitter's code. Coz i haven't a blitter doc or example around me.

Just one word, the blitter run at 16 Mhz only on a Falcon

Perhaps Tobe, can help you too. Hi Tobe the blitter maniac, can you help him

GT Turbo(Blitter killer

)

tobe · Post by **tobe** » Sat Apr 10, 2004 12:37 pm

Hello,

FF8A20 = incr in bytes, must be even, can be negative

FF8A22 = page width - src width + (FF8A20), (because the blitter didn't incr after the last word of a line) must be even, can be negative.

same things for dst incr

FF8A36 = words per line
FF8138 = lines count

then FF8A3C = C0 to start blitter

The blitter will allow to copy a word with an op and a shift very quicly, it's a good way to scroll and put sprites, for other weird uses, i can't tell more

! (but there's a lot)

Bye

!

Here is the 'bible' i use :

Post by **simonsunnyboy** » Mon Apr 12, 2004 3:39 pm

While discussing the Blitter..I'm interested in some documented routine to do sprites with it. I've found some at Programmer's Heaven but those are a bit weird....

tobe · Post by **tobe** » Mon Apr 12, 2004 5:39 pm

Did you tried to draw them using skew and mask registers, one bitplan a time ?

I'm going to post an example here, but i must write a readable one

!

tobe · Post by **tobe** » Mon Apr 12, 2004 6:36 pm

I didn't test it, but i should works !

There's 2 extra bits in the skew register, for use of 32x28 instead of 48x28, but you will have to found them by yourself

!

Code: Select all

' DST = screen 320x200 4bp
' SRC = 32x28 inside 48x28 (3 words * 28)
' { mask bp1, sprite bp1, sprite bp2, sprite bp3, sprite bp4 }
'
PROCEDURE blitter_sprite ( dst%, src%, x& )
  ' set skew
  dec&            = AND(x&,&HF)
  BYTE{&HFF8A3D}  = dec&
  '
  ' set left mask
  CARD{&HFF8A28}  = SHR(&HFFFF,dec&)
  ' we don't need right mask because we use 48x28 storage
  '
  ' set incrs
  LONG{&HFF8A20}  = &H20002    ! flat storage
  LONG{&HFF8A2E}  = &H80090    ! screen
  '
  ' masking
  BYTE{&HFF8A3B}  = 4
  ' mask bitplan 1
  LONG{&HFF8A24}  = src%
  LONG{&HFF8A32}  = dst%
  LONG{&HFF8A36}  = &H3001C
  BYTE{&HFF8A3C}  = &HC0
  ' mask bitplan 2
  LONG{&HFF8A24}  = src%
  LONG{&HFF8A32}  = ADD(dst%,2)
  LONG{&HFF8A36}  = &H3001C
  BYTE{&HFF8A3C}  = &HC0
  ' mask bitplan 3
  LONG{&HFF8A24}  = src%
  LONG{&HFF8A32}  = ADD(dst%,4)
  LONG{&HFF8A36}  = &H3001C
  BYTE{&HFF8A3C}  = &HC0
  ' mask bitplan 4
  LONG{&HFF8A24}  = src%
  LONG{&HFF8A32}  = ADD(dst%,6)
  LONG{&HFF8A36}  = &H3001C
  BYTE{&HFF8A3C}  = &HC0
  '
  ' drawing
  BYTE{&HFF8A3B}  = 7
  ' draw bitplan 1
  LONG{&HFF8A24}  = ADD(src%,168)
  LONG{&HFF8A32}  = dst%
  LONG{&HFF8A36}  = &H3001C
  BYTE{&HFF8A3C}  = &HC0
  ' draw bitplan 2
  LONG{&HFF8A24}  = ADD(src%,336)
  LONG{&HFF8A32}  = ADD(dst%,2)
  LONG{&HFF8A36}  = &H3001C
  BYTE{&HFF8A3C}  = &HC0
  ' draw bitplan 3
  LONG{&HFF8A24}  = ADD(src%,504)
  LONG{&HFF8A32}  = ADD(dst%,4)
  LONG{&HFF8A36}  = &H3001C
  BYTE{&HFF8A3C}  = &HC0
  ' draw bitplan 4
  LONG{&HFF8A24}  = ADD(src%,672)
  LONG{&HFF8A32}  = ADD(dst%,6)
  LONG{&HFF8A36}  = &H3001C
  BYTE{&HFF8A3C}  = &HC0
RETURN

Forget preshifting, now you have 16 times more memory for your sprites !

Tobe.

SoLo2 · Post by **SoLo2** » Mon Jul 30, 2007 3:02 am

Hello!

Thanks for all this Blitter information.

I had read that blitter could be slower
than copying with 68000, BUT didn't
take shifting or AND/OR operations
into account?

I would be interested in _real_
benchmark results with/without blitter
and comparisions to Amiga blitter and
old Mega ST blitter. For routines like
ORing a sprite, ANDing a mask, line
drawing or line filling (rectangle,
circles, triangles, ...).
If there are none then maybe I try
somethin in STEem.

Greetings,
SoLo2

Cyprian · Post by **Cyprian** » Mon Jul 30, 2007 6:01 am

SoLo2 wrote:I had read that blitter could be slower
than copying with 68000, BUT didn't
take shifting or AND/OR operations
into account?

Actually, in Amiga1200 and Falcon030 blitter in many cases is slower than cpu.

But in Atari ST, blitter is about twice faster than 68000 in raw copy and much faster when you do shifting, masking and logical operation. In blitter those operations are zero costs.

Orion_ those registers consist counts of bytes - $FF8A20,$FF8A22 and $FF8A2e, $FF8A30, but significant bit is ignored (because of word alignment)

$FF8A26, $FF8A34 - significant bit is ignored, because of word alignment.

$FF8A36 - counts of words

straight copy:

Code: Select all

lea	$FFFF8A20.W,A0		; blitter
move.l	#$40000,(A0)+		; source X & Y increment
move.l	#source,(A0)+		; source address
move.l	#$FFFFFFFF,(A0)+	; mask 1 & 2
move.w	#$FFFF,(A0)+		; mask 3
move.l	#$40000,(A0)+		; destination X & y increment
move.l	#destination,(A0)+	; destination address
move.w	#4096,(A0)+	; count X surface
move.w	#$0001,(A0)+		; count Y surface
move.w	#$0207,(A0)+		; mode HOP & OP
move.b	#$cc,1(A0)		; FXSR & NFSR & SKEW 12bit
move.b	#$C0,(A0)		; start
nop

copy with shifting

Code: Select all

lea	$FFFF8A20.W,A0		; blitter
move.l	#$00000,(A0)+		; source X & Y increment
move.l	#source,(A0)+		; source address
move.l	#$FFFFFFFF,(A0)+	; mask 1 & 2
move.w	#$FFFF,(A0)+		; mask 3
move.l	#$40000,(A0)+		; destination X & y increment
move.l	#destination,(A0)+	; destination address
move.w	#4096,(A0)+	; count X surface
move.w	#$0001,(A0)+		; count Y surface
move.w	#$0200,(A0)+		; mode HOP & OP
move.b	#$00,1(A0)
move.b	#$C0,(A0)		; start
nop

tobe · Post by **tobe** » Mon Jul 30, 2007 7:29 am

Blitter can be slower with small copies because you need to load its registers. So don't forget some registers doesn't need to be reloaded each time. For example, the word count ($FFFF8A36) is reset to the original value after each line, so at the end of the copy operation its value is the same than before the op. You can store your source bitplans splitted, and use the source/destination increments so you don't need to reload the source and destination registers for each bitplan, etc...

unseenmenace · Post by **unseenmenace** » Mon Jul 30, 2007 7:59 am

tobe wrote:You can store your source bitplans splitted, and use the source/destination increments so you don't need to reload the source and destination registers for each bitplan, etc...

Sorry if I'm being a bit dumb but could you (or anyone) explain that last bit a bit more as I'm not sure I understand.

Cyprian · Post by **Cyprian** » Mon Jul 30, 2007 8:18 am

tobe wrote:Blitter can be slower with small copies because you need to load its registers. So don't forget some registers doesn't need to be reloaded each time. For example, the word count ($FFFF8A36) is reset to the original value after each line, so at the end of the copy operation its value is the same than before the op. You can store your source bitplans splitted, and use the source/destination increments so you don't need to reload the source and destination registers for each bitplan, etc...

you right

Actually, to do blitting you need to reload only two registers "Y COUNT" and $FFFF8A3D, e.g.:

prefill blitters registers:

Code: Select all

	lea		halftone,a0
	lea		$ffff8a00.w,a1
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	clr.l	(a1)+
	move.l	#kolory,(a1)+
	move.l	#$ffffffff,(a1)+
	move.w	#$ffff,(a1)+
	clr.l	(a1)+
	move.l	#$ffff8240,(a1)+
	move.w	#$1,(a1)+
	move.w	#$1,(a1)+
	move.b	#$1,(a1)+
	move.b	#$3,(a1)+
	move.b	#$0,(a1)+
	move.w	#128*50,d0
	move.w	#$c0,d1
	lea	$ffff8a38.w,a0
	lea	$ffff8a3c.w,a1

halftone
	dc.w	$0f00, $00f0, $000f, $0ff0, $0f0f, $00ff, $0c00, $00c0
	dc.w	$000c, $0cc0, $0c0c, $00cc, $0fff, $0555, $0aaa, $0000

kolory
	dc.w	$000f, $0007, $000e, $0006, $000d, $0005, $000d, $0004
	dc.w	$000c, $0003, $000b, $0002, $000a, $0001, $0008, $0000

do blitting:

Code: Select all

	move.w d0,(a0)
	move.b d1,(a1)

do blitting again:

Code: Select all

	move.w d0,(a0)
	move.b d1,(a1)

and again:

Code: Select all

	move.w d0,(a0)
	move.b d1,(a1)

As we can see, biggest part is prefilling register, but you do not need touch all of it., e.g. you can leave halftone. And do blitting (many times as you need) takes two instuctions.
Then you need only 16 cycles per start blitting.

Post by **ggn** » Mon Jul 30, 2007 10:43 am

About the preloading, I found that you can preload all blitter registers in one go like this:

Code: Select all

movem.l blit_vars(pc),d0-7
movem.l d0-7,$8a20.w

blit_vars: dc.w 20
               .....

(Assuming that you have changed some stuff in the struct blit_vars beforehand)

I haven't tested if it's faster than lots of move.w/ls but at least the code is smaller this way.

lp · Post by lp » Mon Jul 30, 2007 3:19 pm

If you are interested in the official docs from Atari:
http://dev-docs.atariforge.org/files/BL ... 5-1990.pdf

tobe · Post by **tobe** » Mon Jul 30, 2007 8:11 pm

unseenmenace wrote:
tobe wrote:You can store your source bitplans splitted, and use the source/destination increments so you don't need to reload the source and destination registers for each bitplan, etc...
Sorry if I'm being a bit dumb but could you (or anyone) explain that last bit a bit more as I'm not sure I understand.

Well, instead of storing your sprites like this: (16*4)

BPL1 BPL2 BPL3 BPL4
BPL1 BPL2 BPL3 BPL4
BPL1 BPL2 BPL3 BPL4
BPL1 BPL2 BPL3 BPL4

Store it like this:

BPL1 BPL1 BPL1 BPL1
BPL2 BPL2 BPL2 BPL2
BPL3 BPL3 BPL3 BPL3
BPL4 BPL4 BPL4 BPL4

So if you use #$2 as source x and y increments, you'll be able to blit the whole sprite without reloading the source adress. You'll have to reload the destination (i did a mistake in my previous post).

tobe · Post by **tobe** » Mon Jul 30, 2007 8:12 pm

lp wrote:If you are interested in the official docs from Atari:
http://dev-docs.atariforge.org/files/BL ... 5-1990.pdf

Very nice doc indeed

If you plan to shift data with a negative source x increment, then you'll have to read it *carefully*

unseenmenace · Post by **unseenmenace** » Mon Jul 30, 2007 9:56 pm

tobe wrote:Well, instead of storing your sprites like this: (16*4)

BPL1 BPL2 BPL3 BPL4
BPL1 BPL2 BPL3 BPL4
BPL1 BPL2 BPL3 BPL4
BPL1 BPL2 BPL3 BPL4

Store it like this:

BPL1 BPL1 BPL1 BPL1
BPL2 BPL2 BPL2 BPL2
BPL3 BPL3 BPL3 BPL3
BPL4 BPL4 BPL4 BPL4

So if you use #$2 as source x and y increments, you'll be able to blit the whole sprite without reloading the source adress. You'll have to reload the destination (i did a mistake in my previous post).

Cheers for the explanation mate, that does indeed make sense. Hopefully I can put that to good use

Post by **simonsunnyboy** » Mon Jul 30, 2007 10:02 pm

It doe not only make sense, it shows an important idea how to speed up Blitter operation if you don't have to reload the registers....

AtariZoll · Post by **AtariZoll** » Sun Mar 26, 2017 10:10 am

Cyprian wrote:...
Actually, in Amiga1200 and Falcon030 blitter in many cases is slower than cpu.
...
But in Atari ST, blitter is about twice faster than 68000 in raw copy and much faster when you do shifting, masking and logical operation. In blitter those operations are zero costs.
...

Old thread, but I spent some time with blitter coding last years, and especially last weeks, so some experiences:
In case of RAW copy blitter may be faster, but not 2x than good CPU code. The real limit is of course speed of RAM.
Even using simple move.l (a0)+,(a1)+ is not 2x slower, but we can use movem.l with lot of registers - then CPU is some 10-15% slower.

The real benefit is when shifting is needed - where 68000 is slow, while blitter does it without extra time penalty - if using properly.
Additional gain is when combine shifting with 4 bitplane draw - using 8 as X increment. That is good for sprite draw, but would be even better if there would be special mask register too, which shifts same bits as content. As it is, sprite draw on background is 2 step process, while all it could be single step - where blitter would do NOT MASK and BGR and SPRITE OR BGR in one step. And some faster clipping support would be nice too. But Atari was not designed as gaming machine. Ahh, and same thing missing what in 68000 CPU: byte-swap - that can be done, but not so fast as when it would be OP.
Would not say that shifting and masking are 0 cost, because above mentioned, and because that in case of shifting we need some extra RAM accesses, but cost is little, indeed.

Cyprian · Post by **Cyprian** » Sun Mar 26, 2017 4:50 pm

AtariZoll wrote:but we can use movem.l with lot of registers - then CPU is some 10-15% slower.

yep, but in this case all the CPU registers are blocked and as you mentioned CPU blitting is 10-15% slower.
Therefore, the BLiTTER ensures you faster blitting and free CPU for other tasks.

AtariZoll wrote:But Atari was not designed as gaming machine

yep.
In opposite to amiga, ST was designed as the real computer, therefore there were no need to install a game console blitter chip in it.
Regarding amiga, it was designed as a game console but in term of performance and capabilities e.g. SNES (which was released only one year after A500) was a twice or more better.

leonard · Post by **leonard** » Sun Mar 26, 2017 5:16 pm

For plain 4 bitplan copy, the blitter is not much faster, true.

But for one bitplan things, it's often twice as fast! for instance to display a 1 bitplan background, you will do :
move.w (a0)+,offset(a1)
this is 4 nops per write on CPU, only 2 with blitter!

it's even better to clear one bitplan: 3 times faster!
move.w d0,offset(a1) ( CPU: 3nops, blitter using Halftone-RAM: 1 nop!)

That's why there is so much one bitplan stuff in "We Were @" demo

AtariZoll · Post by **AtariZoll** » Sun Mar 26, 2017 5:30 pm

Cyprian wrote:
AtariZoll wrote:but we can use movem.l with lot of registers - then CPU is some 10-15% slower.
yep, but in this case all the CPU registers are blocked and as you mentioned CPU blitting is 10-15% slower.
Therefore, the BLiTTER ensures you faster blitting and free CPU for other tasks.

Actually, blitter is faster only in HOG mode. So, that claim about being free for other tasks is not exactly correct. Blocking of CPU registers is not problem, because coders go on max speed only when some larger RAM area is handled. And some efficient blitter code needs all registers often.

Cyprian · Post by **Cyprian** » Sun Mar 26, 2017 9:27 pm

lets say we have a block of code where we can distinguish two parts:
A) copy a block of memory
B) some CPU calculation (e.g. depacking)

It is interesting which variant will be faster:
1) A done by the CPU and then B done by the CPU
or
2) A done by the BLiTTER and B done by the CPU - both points in parallel thanks to "BLIT mode"

alexh · Post by **alexh** » Mon Mar 27, 2017 8:48 am

Sorry for going off topic

Cyprian wrote:SNES (which was released only one year after A500) was a twice or more better.

Not true. SNES = 1990, A500=1987 (but A500 chipset dates to 1985) so 5 years

leonard · Post by **leonard** » Mon Mar 27, 2017 6:13 pm

Cyprian wrote:SNES (which was released only one year after A500) was a twice or more better.

it's extremly hard to compare the two systems, and even harder with numbers! ( twice or more ). What feature are you speaking? If you speak about CPU power, SNES is more than twice slower than AMIGA

Of course SNES is a lot better regarding hardware sprites.

AtariZoll · Post by **AtariZoll** » Mon Mar 27, 2017 6:43 pm

Cyprian wrote:lets say we have a block of code where we can distinguish two parts:
A) copy a block of memory
B) some CPU calculation (e.g. depacking)

It is interesting which variant will be faster:
1) A done by the CPU and then B done by the CPU
or
2) A done by the BLiTTER and B done by the CPU - both points in parallel thanks to "BLIT mode"

I don't think that depacking is good example. It reads source byte by byte, maybe word by word, then perfoms some operations, and writes only few to destination. Don't see use of fast blitter RAM copy. Could help rather if there is lot of shifting - only on 68000, of course.

Atari-Forum

about the blitter ^^

about the blitter ^^

Argh

Re:

Re: Re:

Re: about the blitter ^^

Re: Re:

Re: about the blitter ^^

Re: Re:

Re: Re:

Re: about the blitter ^^