blitter question Solved

All 680x0 related coding posts in this section please.

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

FedePede04
Atari Super Hero
Atari Super Hero
Posts: 935
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

blitter question Solved

Postby FedePede04 » Thu Mar 31, 2016 8:45 am

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.
Last edited by FedePede04 on Sun Oct 15, 2017 9:29 pm, edited 1 time in total.
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: blitter question

Postby dml » Thu Mar 31, 2016 9:45 am

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
Atari Super Hero
Atari Super Hero
Posts: 935
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: blitter question

Postby FedePede04 » Thu Mar 31, 2016 11:26 am

dml wrote: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 :P
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? :angel: :cheers:
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: blitter question

Postby dml » Thu Mar 31, 2016 11:50 am

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
Atari Super Hero
Atari Super Hero
Posts: 935
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: blitter question

Postby FedePede04 » Thu Mar 31, 2016 12:09 pm

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 :cheers:
and i hope you soon will get better.
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: blitter question

Postby dml » Thu Mar 31, 2016 1:59 pm

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

FedePede04
Atari Super Hero
Atari Super Hero
Posts: 935
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: blitter question (solv it)

Postby FedePede04 » Tue Oct 10, 2017 11:02 pm

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 :cheers:
You do not have the required permissions to view the files attached to this post.
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

chicane
Atari freak
Atari freak
Posts: 68
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: blitter question

Postby chicane » Sun Oct 15, 2017 8:01 pm

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
Atari Super Hero
Atari Super Hero
Posts: 935
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: blitter question

Postby FedePede04 » Sun Oct 15, 2017 8:33 pm

many thank, i put solved it in the prev post instead of the topic :oops:
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.

chicane wrote: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 :lol:

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.
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

FedePede04
Atari Super Hero
Atari Super Hero
Posts: 935
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: blitter question

Postby FedePede04 » Sun Oct 15, 2017 8:58 pm

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
You do not have the required permissions to view the files attached to this post.
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

FedePede04
Atari Super Hero
Atari Super Hero
Posts: 935
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: blitter question

Postby FedePede04 » Sun Oct 15, 2017 9:25 pm

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
You do not have the required permissions to view the files attached to this post.
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

chicane
Atari freak
Atari freak
Posts: 68
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: blitter question

Postby chicane » Mon Oct 16, 2017 7:06 pm

FedePede04 wrote: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?

FedePede04 wrote: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 :lol:


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!

FedePede04 wrote: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
Atari Super Hero
Atari Super Hero
Posts: 935
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: blitter question

Postby FedePede04 » Mon Oct 16, 2017 8:43 pm

chicane wrote:
FedePede04 wrote: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?

FedePede04 wrote: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 :lol:


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!

FedePede04 wrote: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 :D
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.
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

chicane
Atari freak
Atari freak
Posts: 68
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: blitter question Solved

Postby chicane » Wed Oct 18, 2017 9:23 pm

FedePede04 wrote:no it did not work properly before you help me :D
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.

FedePede04 wrote: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...

FedePede04 wrote: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!

FedePede04 wrote: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
Atari Super Hero
Atari Super Hero
Posts: 935
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: blitter question Solved

Postby FedePede04 » Thu Oct 19, 2017 7:54 pm

Thx for replying , I will answer when I get home from Holliday, I am on my old table, and its hopeless slow
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 1 guest