AGA scrolling

[jotd]

I've lost the evening on this


Fetch mode = 3 (64 bit bitplane fetch, ECS sprites)

    move.w    #0x30,d5
    
    move.w    d5,d6
    and.w    #0xF,d6        | 16 original bits
    and.w    #0x30,d5    | 2 remaining bits
    lsl.w    #6,d5        | position in 10-11

    or.w    d5,d6   | this is the bplcon value

I can't seem to apply 48 of scroll shift. 47 seems to work ok (2F) but 48 fails. Any idea?

[ross]

Quick look at my crystal ball: DDFSTRT is 'misaligned'.
But it's very late, we'll think about it tomorrow

[jotd]

probably but I have tried several values since and no luck

    move.w #0x0020,ddfstrt(a5)   <- read that on demoscene, was using 30 earlier, no luck either just different results
    move.w #0x00B8,ddfstop(a5)
    move.w	#-8,d0

    move.w #0,bplcon1(a5)
    move.w #-8+(64-40),bpl1mod(a5)

there must be a combination of modulo & ddf but that's beyond me.

There are virtually no examples for AGA. I had done ECS scrolling before without issues, and also AGA scrolling but vertical

[ross]

Yep, the DDFSTRT is 'wrong' (neither $20 nor $30 can work as you intend), try $18.

But more info please.
What is the framebuffer you have in memory? (those values you used requires 384 pixels on the x)
Do you want to use sprites? if yes, how many?
What video window are you going to use (values for DIW)?

Unfortunately, even my crystal ball has limits..

[a/b]

Not an AGA expert, but just in case...
I see 64, that's total width 512px. I see 40, that's diplayed width 320px. -8 is compensation for 64px scrolling (4+2 bits, bottom 2 bits are zeroes). Am I right?
Normal (no scrolling) fmode=3 dma is $38-$a0. To extend that with extra 64x pix on the left for scrolling, start should be moved to $18:
($a0-$38+8+48)*2=320
($a0-$18+8+48)*2=320+64
(end-start+8)*2 is the OCS/ECS math for dma (fmode=0), fmode=3 fetches extra 48 bits (64 vs. 16). Is this correct (never did AGA scrolling :P)?

[jotd]

that looks correct indeed. All those calculations are beyond me though. thanks a lot both of you, will try tonight.

[a/b]

Let me try to clarify with a simplified example...

Say you have an 8bpl display. With fmode=0 the fetch looks like:
8 8 8 8... 8
Now when you enable fmode=3 you get 4x speed, you know that, and you might think it works like this:
2(*4) 2(*4) 2(*4) 2(*4)... 2(*4)
But this is *not* how it works, it's actually like this:
8(*4) 0 0 0 8(*4) 0 0 0... 8(*4) 0 0 0
As you see, it's 25% active/burst and 75% inactive, on *average* that's 4x faster.

This is critical e.g. if you are planning on having max speed copper (8 cycles per move) at all times with 5+ bpls by using fmode > 0. It won't work due to bursty nature of fmode, copper will still get slowed down during bursts (7bpl ocs trick ).

So if you want to extend your display to compensate for scrolling, you cannot only include the 25% active part (-$8), you also have to include the 75% inactive part (-$18), giving you a total of -$20 -> $18.
$18 8*4 (will be scrolled iin), $20 0, $28 0, $30 0, $38 8*4, ...

Something like that :P.

[ross]

Interesting point of view, you eventually come to the correct conclusion, even if in fact the hadware doesn't 'think' that way

It all boils down to when BPL1DAT is 'written' and when BPLCON1 value match Lisa's counter.

In fact the writing of BPL1DAT is 'early' due to the FMODE burst and the match bits are 6 (8 if we consider the sub-pixels) and therefore the 'comparison window' widens and remains 'valid' for the values from 0 to $3F for the low bits of Lisa's counter (this require a proper DDFSTRT to write to BPL1DAT 'before' the 0 point).

[jotd]

that $18 value fixed it! now I have a lot to do with DIWSTART/STOP on both playfields to make sure they match, but that I can manage

thanks again!

[jotd]

so it works but there's a strange phenomenon on the bottom of the screen

If I set DDFSTRT at $18 as instructed, the ground strip (with moonbase) seems to have shifted bitplanes, but the upper panel uses the exact same drawing routine (if I draw the panel in the bottom the same phenomenon appears too)



With DDFSTRT as $30 (old crap value that made scroll glitchy because unaligned), the bottom tiles are perfect and the moonbase displays properly



Thing is: I'm setting bitplane pointers for the blue mountains different from panel (as mountains scroll horizontally but also vertically), then I re-set the bitplanes for the ground strip (green mountains are on another playfield with the jeep, no hardware scroll, just blits, like ECS version)

So the copperlist sets panel bitplanes (and they display OK), then sets mountains bitplanes (seem strange vs real pic but it can be something else) then sets ground strip bitplanes. I've tried to sub/add 8 but it doesn't work. I suspect that doing that bitplane set, I'm breaking the fetch. I'm sure it can be done but the values seem wrong with that ddfstrt... This is really obscure.

In theory this is really awesome, as there are very few blits involved, blue mountains & ground strip share the same playfield, but with different scroll values, and the separation is made with the green mountain which has priority (and I'll use color 0 as green to finish the job, but just not now...). Since blue mountains never get lower than the ground strip, it works.

I understand that games like Jim Power use dual playfield and even change playfield/sprite priority so they can have objects in the foreground too (bottom part) where the upper parts are the background mountains. Clever.

[ross]

Probably at this point a test version is required, the causes could be various
Is it downloadable somewhere?

Are you 100% sure that all AGA fetches in memory are 8-byte aligned?

Then I have doubts about the sprites... if you want to use some of them you have to 'move' forward with DDF and at that point manage the video shift differently (even if I see that the view is 'narrow' so it shouldn't be a problem).

[jotd]

Originally Posted by ross

Probably at this point a test version is required, the causes could be various
Is it downloadable somewhere?

source of AGA driver is here:

https://github.com/jotd666/mpatrol/b.../aga/amiga.68k

There are a lot of constants that assembler computes, maybe it's not going to be helpful for you.

Are you 100% sure that all AGA fetches in memory are 8-byte aligned?

When I reposition the bitplanes, I always add a multiple of 64 so it should work.

Then I have doubts about the sprites... if you want to use some of them you have to 'move' forward with DDF and at that point manage the video shift differently (even if I see that the view is 'narrow' so it shouldn't be a problem).

I'm using sprites, but if I have to drop them I think it will be possible given the saved bandwidth not blitting 2 big layers. I'll check that later.


Zoned a test version. Useless for anyone that doesn't want to debug it

insert coin & start game to see shifted moonbase. In the intro screen it's not as blatant (the blue mountains have the same issue, probably, as if I blit them on the top, overwriting panel, they're okay, else they're really strange but since it's repetitive and only 2 colors it's more difficult to tell)

One thing is sure: changing bitplane pointers using the copperlist caused the problem. But I have to do that to add the 0,8,16,24 byte offset required to scroll my 512 pixel wide image on the 512 pixel wide display

[a/b]

It looks like the problem is that there isn't enough time to load all the bitplane pointers before dma becomes active ($18 is rather early). I changed the wait from $dc01 to $dbd1 and the problem was gone.

[jotd]

Yes @a/b that's probably the problem. But ross suggested a radical approach: drop FMODE=3 and go for FMODE=1 to be able to use sprites. Seems to work pretty well. Thank you both.

[Galahad/FLT]

Not withstanding a/b's help, but I often wonder what life was like before Ross joined EAB.

Yikes, they were dark times!

[ross]

Originally Posted by Galahad/FLT

.. I often wonder what life was like before Ross joined EAB.

Definitely better because we were younger

Seriously, I blushed a bit
Thanks Sir Galahad.

[jotd]

ross was definitely a big help. This "new" hardware is hard to master

[TCD]

Originally Posted by Galahad/FLT

Not withstanding a/b's help, but I often wonder what life was like before Ross joined EAB.

Yikes, they were dark times!

Well put One day I must find out where ross was hiding all those years

[ross]

Originally Posted by TCD

One day I must find out where ross was hiding all those years

I was just doing other things.

Then you get kicked out of the house by your woman, you have a mid-life crisis, you start to feel old and sick, and eventually you start using the Amiga again
A very normal common story..

[TCD]

Originally Posted by ross

Then you get kicked out of the house by your woman, you have a mid-life crisis, you start to feel old and sick, and eventually you start using the Amiga again
A very normal common story..

Yep