Blitting with size 1x255

[JackAsser]

Hi!

When I setup a simply A=D minterm and let A point to bitmap and D point to bitmap+40, using modolus of 38 on both A and D I don't get the expected result of having the first row repeated all the way down (size 1x255).

However, if I change size to 2x255 and set the modolus to 36 accordingly it works fine.

My end goal is ofcourse not to just copy the first row (doing that I could simply use a negative modolu). This is just one step in the process...

I have only tried this on winuae, perhaps it's an emulation bug?

The result I see is not the expected result of having the first row repeated, but instead having the whole word-column shifted one line down (as if it was in descending mode, but it isn't).

What am I missing here?

/JackAsser

[pmc]

@ Jackasser - I just made myself a little test program. You'll see what you expect if you set bltamod to -2 and bltdmod to 38.

This makes the word pointed at by a get blitted to d+40 each line.

By the way, from more testing I did, if you set both modulos to 38 and call the blit each frame, for example inside a copper interrupt, you get the result you want but the line "grows" down the screen rather than appearing all at once as per when modulos set to -2 and 38.

With both modulos set to 38 you're trying to copy with the a channel what was blitted in immediately previously from a to the d channel.

Perhaps the blitter trips over itself when you do this...?

Toni could confirm.

[Toni Wilen]

Blitter reads sources twice before first write.

[pmc]

LOL.

Toni has just confirmed!

[JackAsser]

@pcm: Yes, as I said, simply copy the first row is not what I wanna do in the end.

@toni: Hmms, I see. Are those two reads emitted on the destination as a FILO-queue, or is simply the word read omitted? I guess it's a FILO, that would explain the observed behaviour completly.

[pmc]

@ JackAsser - that's p m c dude not p c m.

I wouldn't normally care but that's twice now (same in previous thread yesterday...) guy!

[Toni Wilen]

Originally Posted by JackAsser

@toni: Hmms, I see. Are those two reads emitted on the destination as a FILO-queue, or is simply the word read omitted? I guess it's a FILO, that would explain the observed behaviour completly.

It is 2 cycle FIFO (D=A: read1,idle,read2,write1,read3,write2,...,read4,write3,idle,write4)

There are diagrams in HRM. RTFHRM!

[JackAsser]

@pmc: Sorry!

@toni: Hahaha. I ignore the small prints! But thanx alot!

[Photon]

Isn't this the normal 'don't scroll by overlapping source and dest and have dest at a higher address', though?

I'm sure if you point both channels to last word in blit and set the reverse blit mode, it will work fine. or set dest to src MINUS 40.

Hej Jackasser förrexten o/

[JackAsser]

@Photon: Well, the setup was completly intentional and gives quite expected results as long as the blit width > 1 and the distance between A and D are > 1. In my case it wasn't, and didn't produce the expected results. However, I missed that the blitter has a FIFO. With that in mind it's quite natural now, why it produces the output I'm seeing. (hej föresten!)

So, nevermind, case closed! Thanx to Toni for providing the satisfactory answer to my question. I'm enlighted now. More over, I dropped that idea completly and Graham helped me find another solution so I don't need a blit width of 1 any more.

[pmc]

You seem to be making really quick progress JackAsser.

Really looking forward to seeing your Seirpinski zoomer.