blitter question

[FedePede04]

hi
i have never use the ST blitter before, so i really don't know anything about the ST Blitter.

my question is,
could you use the blitter to show / put together a not interleave (Amiga format) bitmap/picture
or do you have to convert, the picture first into an atari interleave picture using a software routine?

if it can be done, is there an asm6800 example showing the about.

[dml]

If you mean: can it read direct from non-interleaved Amiga-formatted plane data, then yes. You can specify the skip size for horizontal and vertical intervals at both source and destination, so you can interleave/deinterleave during blits. You may find though that some jobs which could otherwise be done in a single blit may end up needing 4 / one-per-plane (which isn't such a big deal unless the thing being drawn is tiny and numerous - and some common things need 4 anyway).

[FedePede04]

If you mean: can it read direct from non-interleaved Amiga-formatted plane data, then yes. You can specify the skip size for horizontal and vertical intervals at both source and destination, so you can interleave/deinterleave during blits. You may find though that some jobs which could otherwise be done in a single blit may end up needing 4 / one-per-plane (which isn't such a big deal unless the thing being drawn is tiny and numerous - and some common things need 4 anyway).

Hi Doug and many thx.

Yes This is exactly what I mean
all my picture is non interleve rle compressed, so if i shall have a chance to play them in 25HZ, when i think that i need the blitter for that .

Btw is there any chance, that you may have a pieces of blitter code that is doing the about, that you would like to share?

[dml]

Hi,

I have a migraine today so can't spend long on this - but you'll find plenty of reference. Here's a rapidly cobbled snippet. The src/dst x increments are configured to 're interleave' planar data to ST screen, but one plane at a time.

Code: Select all

         move.w   #$ffff,$ffff8a28.w   ; endmask 1 (left, or 1st word in line)
         move.w   #$ffff,$ffff8a2a.w   ; endmask 2 (middle words)
         move.w   #$ffff,$ffff8a2c.w   ; endmask 3 (right, or last word in line)

         move.w   #2,$ffff8a20.w      ; source x incement in bytes for 1 plane (Amiga)
         move.w   #srcskip+2,$ffff8a22.w   ; source y increment in bytes (plus any x increment)
         
         move.w   #8,$ffff8a2e.w      ; dest x increment in bytes for 1 plane (ST)
         move.w   #dstskip+8,$ffff8a30.w   ; dest y increment in bytes (plus any x increment)
         
         move.b   #0,$ffff8a3d.w      ; skew/scroll
         move.b   #2,$ffff8a3a.w      ; halftone logic op (2: [S]rc)
         move.b   #3,$ffff8a3b.w      ; logic op (3: [D]st=[S]rc)
      
         move.w   #4,$ffff8a36.w      ; words to transfer per image line

         move.l   sourcebuf,$ffff8a24.w   ; data source address
         move.l   destbuf,$ffff8a32.w   ; data dest address
         move.w   #16,$ffff8a38.w      ; image lines to transfer

         move.b   #$80,$ffff8a3c.w   ; go! (bus-sharing mode)
.cont:         bset.b   #7,$ffff8a3c.w      ; force-restart until complete
         bne.s   .cont

Beware a few things...

This uses bus-sharing mode which is relatively friendly with interrupts, mouse keyboard etc. You can use HOG mode instead which is not too friendly - but only for tiny blits or you'll have trouble. If you have no interrupts or user-input happening during a blit it may not matter (e.g. demos!)

Also - the source-y-increment and dest-y-increment (skip values) must include any x increment needed, as the x increment value is not added automatically on the last word of a line. This easily causes confusion.

Apart from those things its more or less easy. Gets a bit more complicated if you're scrolling the data, but not a lot.

[FedePede04]

Hi.
sorry to hear about your migraine, I was also plagued by severe headache for a period of my life, so unfortunately I know the feeling.

Many thanks for the code snipe, and also for that you still taking you time to help me
and i hope you soon will get better.

[dml]

Hey no problem.

BTW if it helps later, the formula for calculating src_yinc (or 'srcskip') is fairly standard in most situations.

If your data has nothing to skip (e.g. all source words on every line are going to the destination) then src_yinc = src_xinc. i.e. just advance to the next word at the end of the line, as if its continuing the same line.

If your data has something to skip - e.g. copying a small rectangle from a screen then it looks like this:

src_yinc = (src_linewords-(blit_linewords-1))*src_xinc

e.g. for 64 pixels (4 words) of 1-planar data from a 320 pixel (20 word) per line bitplane image...

src_xinc = 2
src_yinc = (20-(4-1))*2

...and for same, but with ST screen layout as the source...

src_xinc = 8
src_yinc = (20-(4-1))*8

...and for all 4 planes of ST screen data per blit line...

src_xinc = 2
src_yinc = ((20*4)-((4*4)-1))*2

...the -1 is there as compensation because the blitter won't add src_xinc itself when its time to add src_yinc. It only applies one or the other at a time, depending on whether its stepping the 'x loop' or the 'y loop' in its little state machine. You can imagine some 68k which illustrates this:

Code: Select all

 move.w lines,d7
 subq 1,d7

.yloop:

 move.w blit_linewords,d6
 subq 1,d6
 bra.s .xstart

.xloop:
 add.w src_xinc,src
 add.w dst_xinc,dst
.xstart:
 move.w (src),(dst)
 dbra d6,.xloop

 add.w src_yinc,src ; oops! src_xinc wasn't applied!
 add.w dst_yinc,dst
 
 dbra d7,.yloop


I honestly don't remember offhand if the yloop omits the final yinc in the same way - probably does - but in most cases it doesn't matter.


The 3rd example with 4 planes per blit line is the one that confuses people the most I think - since the 'xinc OR yinc' rule applies to the final plane only, not all planes, since 4 planes are being blit as if a single planar block.

Hopefully I got that right. Not in a position to test anything. But hopefully you get the idea

[FedePede04]

Hi
i never got around to try it out before today, you are right the basic is not so complicated,
when one have try it out, but i ran into a problem

i have add it to Enduro Racer, printing the clouds and mountains, but i get some weird pixel.

Enduroracer.png

i don't know if it is because of the mask, have you seen something like this before, and do you have an idea to fixed it?
here is the clouds and mountains print routine

Code: Select all

MounXPositionNotGreaterThen320      
;      new print
         move.w   d0,d6
         and.w   #$f,d6
         eor.w   #$f,d6
         
         And.w   #$fff0,D0

         lsr.w   #1,d0
         
         add.w   6(a6),d0
         Add.l   #MountainGraphicAddr,D0
      
         Moveq   #0,D2
         move.w   (a6),d2

         Lea      YMulList(PC),a0       ; Ypos For Printing Clouds and Mountain
         Add.w   D2,D2
         Move.w   (A0,D2.W),D2
         add.l   log_scr(PC),d2

         move.w   #$ffff,$ffff8a28.w   ; endmask 1 (left, or 1st word in line)
         move.w   #$ffff,$ffff8a2a.w   ; endmask 2 (middle words)
         move.w   #$ffff,$ffff8a2c.w   ; endmask 3 (right, or last word in line)
         
         move.l   #$00080008,$ffff8a20.w       ; source x incement in bytes for 1 plane (Amiga)
               move.l   #$00080008,$ffff8a2e.w       ; dest x increment in bytes for 1 plane (ST)
         
         move.b   D6,$ffff8a3d.w           ; skew / scroll
         move.w   #$0203,$ffff8a3a.w       ; halftone logic op (2: [S]rc)
               move.w   #20,$ffff8a36.w           ; words to transfer per image line
         
         move.w   2(a6),d1
         Moveq.w   #3,D4
BlitLoop:
         Movem.l  D0/D2,-(Sp)
         
                move.l   D0,$ffff8a24.w   ; data source address
         move.l   D2,$ffff8a32.w   ; data dest address
         move.w   D1,$ffff8a38.w   ; image lines to transfer

         move.b   #$80,$ffff8a3c.w   ; go! (bus-sharing mode)

.cont:      
         bset.b   #7,$ffff8a3c.w      ; force-restart until complete
         bne.s   .cont      

         Movem.l (Sp)+,D0/D2
         Addq.w   #2,D0
         Addq.w   #2,D2
         Dbra   D4,BlitLoop
         Rts   


all input are more then welcome

[chicane]

I must admit that I'm too lazy to trace through your code to work out if this is the case, but have you enabled the FXSR bit (bit 7 of $FFFF8A3D)?

It looks like the blitter might be writing the first 16 pixels of the mountain without first being initialised with some source content. I think when you set a skew value, you also need in most cases to set FXSR to ensure that the blitter doesn't write garbage for the first 16 pixels.

[FedePede04]

many thank, i put solved it in the prev post instead of the topic
but i did found the error, i had to shift the mask-1 the same numbers as i had shifted the clouds and it work.

I must admit that I'm too lazy to trace through your code to work out if this is the case, but have you enabled the FXSR bit (bit 7 of $FFFF8A3D)?
It looks like the blitter might be writing the first 16 pixels of the mountain without first being initialised with some source content. I think when you set a skew value, you also need in most cases to set FXSR to ensure that the blitter doesn't write garbage for the first 16 pixels.

did not know about that, will try just to see if it also work.


it is my first blitter code, and i always thought that the blitter was more complicated, but it was actually quite simple, but i bet a sprite routine ain't as simple

btw many talks about if the array is to small, then its/as fast to use the cpu instead of the blitter, do you know how big an array shall be before its better to use the blitter?


again many thanks for taking your time to help.

[FedePede04]

my code does not seem to work, and the bit 7 made the whole graphic, look wrong, i will post a picture
it look normal when i don't have bit 7 set

enduro error.png

[FedePede04]

ok i think it's working now,
i had to change from (before setting bit7)

Code: Select all

      move.l   #$00080008,$ffff8a20.w      ; source x incement in bytes
      move.l   #$00080008,$ffff8a2e.w      ; dest x increment in bytes


to now (after setting bit7)

Code: Select all

      move.l   #$00080000,$ffff8a20.w      ; source x incement in bytes
      move.l   #$00080008,$ffff8a2e.w      ; dest x increment in bytes


and it look right many thx for you help

enduro fixed.png

[chicane]

and it look right many thx for you help

Great! But it sounds like you may have got it working before I mentioned FXSR - did you actually need to use FXSR in the end to get the desired effect?

it is my first blitter code, and i always thought that the blitter was more complicated, but it was actually quite simple, but i bet a sprite routine ain't as simple

Yes - I also held off adding STE support to Pole Position because I was intimidated by the prospect of writing Blitter code. But when I started reading the documentation and looking at examples, it all came very easily! Same with DMA sound - the biggest effort was working out how to create binary files that were in the right format!

btw many talks about if the array is to small, then its/as fast to use the cpu instead of the blitter, do you know how big an array shall be before its better to use the blitter?

I used the Blitter in Pole Position to draw the background mountains and the road. The background mountains were rendered in 4 bitplanes, with one call to the Blitter for line (256 pixels) rendered. I used the Blitter in Hog mode. This was faster than using movem, but not to the degree that you might hope for. Perhaps 10-20% faster. I've not done any extensive testing, but I'd imagine that you'd be getting very slim benefits over the use of movem on any span of less than 128 pixels.

Having said this, I seem to remember reading somewhere that the Blitter really shines when working with less than 4 bitplanes. I think it's much, much faster than a CPU routine when dealing with 1 bitplane, with diminishing returns with each additional bitplane used.

The Blitter brought massive benefits to the road drawing in Pole Position. The non-STE routine I'd previously implemented was quite clever (IMHO) but was oriented towards reducing memory consumption rather than being as fast as possible. With the help of the blitter, I was able to use a much simpler algorithm resembling that used by the arcade hardware - just holding each line of the road as a bitmap in memory and plotting it to the road with the use of Skew to position it with single-pixel accuracy. The downside of this, of course, was the increased memory requirement, which (together with the use of DMA sound) resulted in the game needing 1 meg to run in the end.

[FedePede04]

and it look right many thx for you help

Great! But it sounds like you may have got it working before I mentioned FXSR - did you actually need to use FXSR in the end to get the desired effect?

it is my first blitter code, and i always thought that the blitter was more complicated, but it was actually quite simple, but i bet a sprite routine ain't as simple

Yes - I also held off adding STE support to Pole Position because I was intimidated by the prospect of writing Blitter code. But when I started reading the documentation and looking at examples, it all came very easily! Same with DMA sound - the biggest effort was working out how to create binary files that were in the right format!

btw many talks about if the array is to small, then its/as fast to use the cpu instead of the blitter, do you know how big an array shall be before its better to use the blitter?

I used the Blitter in Pole Position to draw the background mountains and the road. The background mountains were rendered in 4 bitplanes, with one call to the Blitter for line (256 pixels) rendered. I used the Blitter in Hog mode. This was faster than using movem, but not to the degree that you might hope for. Perhaps 10-20% faster. I've not done any extensive testing, but I'd imagine that you'd be getting very slim benefits over the use of movem on any span of less than 128 pixels.

Having said this, I seem to remember reading somewhere that the Blitter really shines when working with less than 4 bitplanes. I think it's much, much faster than a CPU routine when dealing with 1 bitplane, with diminishing returns with each additional bitplane used.

The Blitter brought massive benefits to the road drawing in Pole Position. The non-STE routine I'd previously implemented was quite clever (IMHO) but was oriented towards reducing memory consumption rather than being as fast as possible. With the help of the blitter, I was able to use a much simpler algorithm resembling that used by the arcade hardware - just holding each line of the road as a bitmap in memory and plotting it to the road with the use of Skew to position it with single-pixel accuracy. The downside of this, of course, was the increased memory requirement, which (together with the use of DMA sound) resulted in the game needing 1 meg to run in the end.

no it did not work properly before you help me
but you are writing that you past all the mountains bitplanes in one go, I have not managed that, when i did that it look like it scroll bitplane 1 into bitplane 2 and bitplane 2 into bitplane 3 ect.
so i have to make the blitter first copy bitplane 1 then bitplane 2 ect. it work fine and it is still faster.
i have also thought of using the blitter for the road, but was thinking that it maybe was not faster, and also the road color change, so you need to copy all 4 bitplanes.. but i will wait to later on.
I will see if i can make a routine that can replace the graphic and reallocate the color in the graphic data file. and if i can free a color, so i always have the road color in color 2.
if the road colors always was in color 2, is should make the road routine much more simple, and speed up the print process.
one thing that i have been reading about the blitter, is that you get the Shift for free, so all that can be shifted should be printed by the blitter, also you don't have to preshift it, saving some memory. but in this game, it shift all graphic, road, clouds/mountains, and the sprites, so if i can find out the logic of the sprite routine, there should be room for some serious speed optimizations.

again many thx for the help, and the end result of "Pole Position" is just super....
btw what mame did you use, did you use an external disassemble or did you use mame?
i am think of converting an arcade game after this project.

[chicane]

no it did not work properly before you help me
but you are writing that you past all the mountains bitplanes in one go, I have not managed that, when i did that it look like it scroll bitplane 1 into bitplane 2 and bitplane 2 into bitplane 3 ect.
so i have to make the blitter first copy bitplane 1 then bitplane 2 ect. it work fine and it is still faster.

Yep, I spent a fair while working out how to do this!

Here's how I'd set the Blitter registers to write a single line of 256 pixels in 4 bitplanes with Skew working as you'd expect it to (in fact, this is how each line of the road in Pole Position is drawn). In short, you tell the blitter you're writing 4 lines (using the ycount register), but instead of the src and dest registers moving through different physical lines in the bitmap on each cycle of ycount, they're actually moving through different bitplanes of the same line:

Code: Select all

word @ 0xffff8a28 (endmask1) = -1
word @ 0xffff8a2a (endmask2) = -1
word @ 0xffff8a2c (endmask3) = -1
word @ 0xffff8a20 (srcxinc) = 8
word @ 0xffff8a22 (srcyinc) = -126
word @ 0xffff8a2e (dstxinc) = 8
word @ 0xffff8a30 (dstxinc) = -118
word @ 0xffff8a36 (xcount) = 16
word @ 0xffff8a38 (ycount) = 4
word @ 0xffff8a3a (hop/op) = 0x0203
longword @ 0xffff8a24 (source) = your source address
longword @ 0xffff8a32 (destination) = your destination address


Don't forget to enable FXSR and set a Skew value in 0xffff8a3d too. You've probably guessed that when using this approach, you can only write a single line on the screen with each call to the Blitter, because you're using the ycount register to iterate through bitplanes rather than lines.

i have also thought of using the blitter for the road, but was thinking that it maybe was not faster, and also the road color change, so you need to copy all 4 bitplanes.. but i will wait to later on.
I will see if i can make a routine that can replace the graphic and reallocate the color in the graphic data file. and if i can free a color, so i always have the road color in color 2.
if the road colors always was in color 2, is should make the road routine much more simple, and speed up the print process.

I had a similar problem in Pole Position. In the end, I took the memory-heavy approach and stored 8 variations of the road bitmap in memory:

Variation 0: Red rumble strip, yellow line on edges, no centre line
Variation 1: Red rumble strip, yellow line on edges, centre line present
Variation 2: Red rumble strip, white line on edges, no centre line
Variation 3: Red rumble strip, white line on edges, centre line present
Variation 4: White rumble strip, yellow line on edges, no centre line
And so on...

one thing that i have been reading about the blitter, is that you get the Shift for free, so all that can be shifted should be printed by the blitter, also you don't have to preshift it, saving some memory. but in this game, it shift all graphic, road, clouds/mountains, and the sprites, so if i can find out the logic of the sprite routine, there should be room for some serious speed optimizations.

Yep, the free skew is a major benefit of the Blitter - it's great!

again many thx for the help, and the end result of "Pole Position" is just super....
btw what mame did you use, did you use an external disassemble or did you use mame?
i am think of converting an arcade game after this project.

With Pole Position, I used mame to work out which roms contained the game logic code and data. Then, I used the mame debugger trace command to establish which regions of the roms were code addresses. Using a load of simple php scripts and shell scripts, I then slowly built up assembly language files with labels and variable names that could be assembled back into the arcade roms using the GNU Z8000 assembler.

I spent a lot of time observing memory addresses while running the game in mame in order to work out their relevance to the game logic. There was a lot of guesswork required to establish things that the instruction traces couldn't tell me, like how the two Z8000 CPUs communicate with each other.

Once I had a large portion of the game logic disassembled and understood how everything worked at a high level, I started rewriting the Z8000 code into a portable C code library I named 'ppengine'. Once I'd completed this, I then wrote and refined the ST-specific graphics and sound engine to accompany this, and ST Pole Position was born!

Whilst the source of ST Pole Position isn't currently available, you can see the source of the above mentioned 'ppengine' library here (as part of another Pole Position project that's a 3D accelerated remake of the original for modern machines):

https://github.com/jonathanopalise/ppen ... c/ppengine

[FedePede04]

Thx for replying , I will answer when I get home from Holliday, I am on my old table, and its hopeless slow

thanks for the explaining your method i will see if i can replace the road drawing with a blitter routine, maybe it can boost the program a little.

[FedePede04]

ok here is an other question.
people say that it does not pay to use the blitter to clear a screen, that it is nearly as fast to use the cpu.

but if you get a gain, maybe a little one, would it not still be a benefit?
could you do the same trick as on the Amiga, let the blitter filled the top part on the screen (Atari in hog mode)
and at the same time clear the other half of the screen using the cpu?

what is your experience with this situations

[chicane]

ok here is an other question.
people say that it does not pay to use the blitter to clear a screen, that it is nearly as fast to use the cpu.
but if you get a gain, maybe a little one, would it not still be a benefit?

I've not performed any tests to validate this, but I suspect the fastest clear screen on the ST(E) would be accomplished by means of movem. Can anybody else offer any opinions on this?

could you do the same trick as on the Amiga, let the blitter filled the top part on the screen (Atari in hog mode)
and at the same time clear the other half of the screen using the cpu?
what is your experience with this situations

Sadly I don't think this would be possible on the STE. The "hog" mode literally "hogs" the system - it brings the CPU (including interrupts) to a grinding halt while it performs the blit. As far as I know, the only way you can get the CPU and blitter to execute simultaneously is to execute an instruction on the 68000 that takes a large number of cycles (such as DIV) and then start the blit on the Blitter. This causes the DIV instruction to execute at the same time as the blit, effectively giving you the DIV for free. I can't remember exactly how this is done, but I've seen a few examples dotted around.

[FedePede04]

ok thank, then i let it be as it is, and spend my time on some other part of the game, like the road

[RA_pdx]

The fastest screen clearing (32kb) with CPU on ST is something like that:

Code: Select all

movem.l d0-d7/a0-a5,-(a6)
or
movem.l d0-d7/a0-a6,xxx.w (screen address has to be in low memory)

Unrolled it needs between 68k and 69k cycles.

The blitter in HOG mode needs for the same around 64k cycles.

So you will have just a little advantage of 4-5k cycles with the Blitter in this case. However sometimes every cycle counts.

As soon as you don't want to clear all 4 planes then it's time for the Blitter!

[FedePede04]

The fastest screen clearing (32kb) with CPU on ST is something like that:

Code: Select all

movem.l d0-d7/a0-a5,-(a6)
or
movem.l d0-d7/a0-a6,xxx.w (screen address has to be in low memory)

Unrolled it needs between 68k and 69k cycles.

The blitter in HOG mode needs for the same around 64k cycles.

So you will have just a little advantage of 4-5k cycles with the Blitter in this case. However sometimes every cycle counts.

As soon as you don't want to clear all 4 planes then it's time for the Blitter!

many thx,
if you need to unroll it, then i see 2 small advantages for using the blitter, minor speed gain.
but also memory gain, if you don't unroll the loop and use the dbra the the gain must be bigger.

Code: Select all

 
;   Unroll loop   
   move.w   #199,D0    
loop
   movem.l d1-d7/a0-a5,-(a6)
   dbra         d0,loop