Overscan and scrolling, missing pixel columns?

[Jobbo]

To move a regular 320x256 sized screen around into the overscan area I'm adjusting diwstrt/stop and ddfstrt/stop and also adjusting bplcon1.


However, when moving to the right with certain scroll values I'm seeing missing pixel columns.


Is this a hardware limit? Is it something I can work around? Or should this work fine, so maybe some bug?



For a 320x256 screen I'm seeing the problem with register values as follows:


DIWSTRT = $2c91
DIWSTOP = $2cd1
DDFSTRT = $0040
DDFSTOP = $00d8
BPLCON0 = $4200
BPLCON1 = $0088
BPL1MOD = $0000
BPL2MOD = $0000
FMODE = $0000



In Winuae the right side will show about 3 missing columns. On my real A1200 you can see more of the overscan area and it seems like there are maybe 4 missing columns but then they start up again.


As I type this I am now wondering if I left a sprite over there, but anyway. Never hurts to ask.

[Toni Wilen]

It is a chipset "feature". It is position where Denise horizontal counter is reset. (Technically beginning of new line) Because counter is reset, BPLCON1 becomes "misaligned".

https://eab.abime.net/showpost.php?p...4&postcount=10

You probably have some filter/scaling option enabled if you don't see whole overscan in WinUAE (and latest betas can show even more). After the "glitch", display continues normally until horizontal blanking starts.

[Jobbo]

Thanks, doesn't seem like I'm doing anything wrong then.

Will have to check out the workaround you mention in Seven Seas / Andromeda. Do you have details you could share?

[DanScott]

DIWSTRT = $2c81
DIWSTOP = $2cc1
DDFSTRT = $0038
DDFSTOP = $00d0

Try these ... otherwise the values you gave in the original post are offset too much to the right

[Jobbo]

That's just the standard 320x256 size.

Seems from the old thread Toni linked that you discussed that the right most extent that can scroll without artifacts is fetch:d8 window:c7.

But Toni mentions that Seven Seas / Andromeda has a workaround, which I can't go look at right now.

c7 only adds 6 pixels on the right which is pretty weak. Anything more than c7 seems to open the right border completely but doesn't work with scrolling. In my case I can just draw things 0..15 pixels to the right instead of scrolling but that requires an extra fetch on the left so everything will fit.

Anyway it's an unexpected hardware issue to work around, it's interesting how buggy a lot of this stuff seems now in retrospect

[Jobbo]

Dan

I just realized the original question might not have been clear.

What I'm trying to do is dynamically move a window around into the overlap regions, not just position it in the center.

[a/b]

Seven Seas is using sprites to cover up the problem.

[Toni Wilen]

Originally Posted by a/b

Seven Seas is using sprites to cover up the problem.

Yes and no. It uses sprites to simulate horizontal blanking to workaround always on horizontal DIW but it also uses copper to modify BPLCON1 at exactly correct position to fix the BPLCON1 glitch. Two copper moves per line.

[Jobbo]

Thanks for the details! Now I know what I need to do to use more of the right border (In my case avoid using bplcon1). And I will forever be even more impressed by demos that managed more than 6 pixels.

[Jobbo]

Originally Posted by Toni Wilen

Yes and no. It uses sprites to simulate horizontal blanking to workaround always on horizontal DIW but it also uses copper to modify BPLCON1 at exactly correct position to fix the BPLCON1 glitch. Two copper moves per line.

Do you have more details about how exactly to fix the glitch?


For example if bplcon1 is supposed to be $11 it looks like Seven Sea's will set it per line near the hpos start and then set it to $bb after a wait for hpos $dc.


I'll have to go through all the other positions by hand. But maybe you already know?

[Jobbo]

From what I can tell adding $a to whatever the offset is supposed to be is what's required.

In my 4bitplane test I need to wait for hpos 112 or $00e1 in the wait command.

Seven Sea's is probably timing it slightly differently for their 6bitplanes display.

Anyway more definitive details would be nice.

[ross]

The key here is what Toni wrote in #2.

When the new 'Amiga' line starts (which is on the far right of the video) the comparison of BPLCON1 and hpos gets out of alignment.
This is because Denise's counter goes up to 455/$(1)c7 and then restarts from 2. As you can guess at that point the value of BPLCON1 is 'wrong' with respect to the counter and needs to be readjusted, otherwise you have the same effect as when you perform the hardware 'shrink' (or gap) with BPLCON1.

So, before the 'line wrap' you need a value that do not match the counter (to avoid bpl data 'shrink, but this is usually guarranteed by the old BPLCON1 value) and after a new calculated value that match the counter and create an alignment with old bpl data.

[Jobbo]

I have it working. And the explanation makes sense. I'm just not sure why adjusting the scroll by 10 is my magic number. Doesn't really matter I suppose.

It's only working if I wait for hpos $e0. Since I'm using only this one wait to catch the end of the line for other reasons I wonder if this will be 100% compatible?

[ross]

Originally Posted by Jobbo

It's only working if I wait for hpos $e0. Since I'm using only this one wait to catch the end of the line for other reasons I wonder if this will be 100% compatible?

Sure yes, under the same conditions (number of bitplanes, FMODE, copper wait position..).
Nothing changed between the various chipsets in this regard, so if the copper wakes up at the right time and finds free cycles in the same timeline it will always behave the same way.