about the blitter ^^

All 680x0 related coding posts in this section please.

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Orion_
Captain Atari
Captain Atari
Posts: 333
Joined: Sat Jan 10, 2004 12:20 pm
Location: France
Contact:

about the blitter ^^

Postby 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 :D)

User avatar
GT Turbo
Captain Atari
Captain Atari
Posts: 335
Joined: Tue Feb 17, 2004 9:41 am
Location: Alsace, France
Contact:

Argh

Postby 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 :!: )
Never forget : Power is in your minds !!!

http://Cerebral-Vortex.net

http://Jagware.org

User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Postby 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 :wink: ! (but there's a lot)

Bye :wink: !

Here is the 'bible' i use :
You do not have the required permissions to view the files attached to this post.
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4774
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Postby 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....
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Postby 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 :wink: !
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.

User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Postby 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 :wink: !

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.
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.

User avatar
SoLo2
Captain Atari
Captain Atari
Posts: 207
Joined: Wed Feb 04, 2004 4:09 am
Location: Spain
Contact:

Postby 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
~~~~~~~~~~~~~~~~~~~~~~~~~~*~~~
The BITS Club http://bits.atari.org

User avatar
Cyprian
Atari God
Atari God
Posts: 1398
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Postby 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

User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Postby 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...
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby 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.
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

User avatar
Cyprian
Atari God
Atari God
Posts: 1398
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Postby 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.

User avatar
ggn
Atari God
Atari God
Posts: 1131
Joined: Sat Dec 28, 2002 4:49 pm

Postby 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.
is 73 Falcon patched atari games enough ? ^^

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2233
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Postby 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 :coffe:
:D

User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Postby 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).
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.

User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Postby 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 :coffe:
:D

Very nice doc indeed :)
If you plan to shift data with a negative source x increment, then you'll have to read it *carefully* ;)
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby 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 :)
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4774
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Postby 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....
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2759
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re:

Postby 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.
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:

User avatar
Cyprian
Atari God
Atari God
Posts: 1398
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Re:

Postby 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.
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
leonard
Moderator
Moderator
Posts: 640
Joined: Thu May 23, 2002 10:48 pm
Contact:

Re: about the blitter ^^

Postby 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 :)
Leonard/OXYGENE.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2759
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Re:

Postby 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.
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:

User avatar
Cyprian
Atari God
Atari God
Posts: 1398
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: about the blitter ^^

Postby 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"
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
alexh
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2553
Joined: Wed Oct 20, 2004 1:52 pm
Location: UK - Oxford
Contact:

Re: Re:

Postby 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

User avatar
leonard
Moderator
Moderator
Posts: 640
Joined: Thu May 23, 2002 10:48 pm
Contact:

Re: Re:

Postby 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.
Leonard/OXYGENE.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2759
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: about the blitter ^^

Postby 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.
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 3 guests