Half pixel copper delay on A1200 hardware

[ross]

Originally Posted by Toni Wilen

You meant that unexplained tiny DIWSTRT/DIWSTOP DDFSTRT/DDFSTOP region set at the beginning of copper list? Yes, I agree that it must be some buggy chipset workaround.

Yes, that.
Another oddity is the $00E0,$0000 at copper list start (no reason for this..).

[FSizzle]

So finally, thanks to all the help in this thread (which is really appreciated - thank you Toni and ross!), I have everything lining up nicely on AGA.

For anyone following the thread who might find it useful, the end result of all this, to have OCS and AGA match, I added the following (after the normal diwstart/stop stuff):

if ( System_IsAGA() )
{
    CopperList_Move( c, BPLCON0, bplCon0 | 0x1 ); // ECSENA active for BRDRBLNK
    CopperList_Move( c, BPLCON3, 0x20 );  // Enable BRDRBLNK (fix right side)
    CopperList_Move( c, DIWHIGH, 0x2010 );// Start half pixel later (fix left side)
}
else
{
    CopperList_Move( c, BPLCON0, bplCon0 ); // Normal BPLCON0 on OCS/ECS
}

This means on AGA only:

• the window starts one half lores pixel later (70ns). This makes the left edge of bitplane and sprite data line up with the COLOR00 change from the copper which is delayed by 70ns
• the window is clipped on the right side by BRDRBLNK. This clips half a lowres pixel (70ns) off bitplane/sprite data due to BRDRBLNK being applied 70ns too early, but it clips COLOR00 at the same place so it lines up
• I lose a pixel of display data in total, but it's a nice symmetrical half pixel from either side and looks good. You can barely tell the half pixels are missing, as opposed to the misalignment which was immediately visible)

I have not tested this on ECS, but based on Toni's comment about the delay being AGA specific, this hopefully works correctly on ECS as well (by using the normal OCS settings). I will test it next time I can access an A600.

Since this fix is quite non-intrusive, it could probably be retroactively applied to titles like Shadow of the Beast if desired.

[ross]

Originally Posted by FSizzle

So finally, thanks to all the help in this thread (which is really appreciated - thank you Toni and ross!), I have everything lining up nicely on AGA.

For anyone following the thread who might find it useful, the end result of all this, to have OCS and AGA match, I added the following (after the normal diwstart/stop stuff):

if ( System_IsAGA() )
{
    CopperList_Move( c, BPLCON0, bplCon0 | 0x1 ); // ECSENA active for BRDRBLNK
    CopperList_Move( c, BPLCON3, 0x20 );  // Enable BRDRBLNK (fix right side)
    CopperList_Move( c, DIWHIGH, 0x2010 );// Start half pixel later (fix left side)
}
else
{
    CopperList_Move( c, BPLCON0, bplCon0 ); // Normal BPLCON0 on OCS/ECS
}

This means on AGA only:

• the window starts one half lores pixel later (70ns). This makes the left edge of bitplane and sprite data line up with the COLOR00 change from the copper which is delayed by 70ns
• the window is clipped on the right side by BRDRBLNK. This clips half a lowres pixel (70ns) off bitplane/sprite data due to BRDRBLNK being applied 70ns too early, but it clips COLOR00 at the same place so it lines up
• I lose a pixel of display data in total, but it's a nice symmetrical half pixel from either side and looks good. You can barely tell the half pixels are missing, as opposed to the misalignment which was immediately visible)

I have not tested this on ECS, but based on Toni's comment about the delay being AGA specific, this hopefully works correctly on ECS as well (by using the normal OCS settings). I will test it next time I can access an A600.

Since this fix is quite non-intrusive, it could probably be retroactively applied to titles like Shadow of the Beast if desired.

Well done

Only two little details:

BRDRBLNK
    CopperList_Move( c, BPLCON3, 0x0C20 );  // Enable BRDRBLNK (fix right side)

because you need default color table to be compatible with OCS/ECS
and

 CopperList_Move( c, DIWHIGH, 0x2110 );// Start half pixel later (fix left side)

for a DIW compatible with PAL screen (but logically depends on screen/game).

[FSizzle]

you need default color table to be compatible with OCS/ECS

This only seems to relate to dual playfield setup, but I think it makes sense to drive these to defaults, so I've done that.

for a DIW compatible with PAL screen (but logically depends on screen/game).

In my case i'm driving an NTSC display, but I added a comment to my code because if I need PAL in the future, I'm sure to forget about this

Thanks!

[Toni Wilen]

I started adding DIWHIGH H0/H1 start/end bit support. But I need some test programs to validate it, my own tests (when using my own test programs) are rarely not that good

[ross]

Originally Posted by Toni Wilen

I started adding DIWHIGH H0/H1 start/end bit support. But I need some test programs to validate it, my own tests (when using my own test programs) are rarely not that good

Ok, I'm writing a test program.

But found another strangeness..
I'm using SHRES bit of BPLCON0 with FMODE=0 for an AGA/ECS testbed and i've the right part [and left if DIWSTRT is covering some pixels] of video not showing.
After some found that DIWSTOP=xxC8 is accepted! (yes, i'm not using DIWHIGH, BEAMCON0 or other advanced registers).
Changing to HIRES or LORES and leaving xxC8 let the horizontal borders (left and right) is opened like usual.

Is this an AGA feature? (that I didn't know absolutely..)

[Toni Wilen]

How much you can increase it until full overscan opens? C9?

Superhires does have some odd side-effects, like disabling DDFSTRT/STOP limits but I haven't noticed this previously.

winuae.7z possibly handles DIWHIGH H0/H1 now but not really tested and there still may be some parts that assume lores pixels.

[ross]

Sorry Toni if I do not specify it all the times, but all my tests are in WinUAE (i've not a real machine).

Originally Posted by Toni Wilen

How much you can increase it until full overscan opens? C9?

Full overscan open at C8.

Superhires does have some odd side-effects, like disabling DDFSTRT/STOP limits but I haven't noticed this previously.

Ok

winuae.7z possibly handles DIWHIGH H0/H1 now but not really tested and there still may be some parts that assume lores pixels.

Ok, i'll test it.
Not releasing a binary because i've a strange video effect (still in shres): with some shift values there are pixels visible after DIWSTOP position.. but can a bug in my code.

[Toni Wilen]

These kinds of test programs must be done and tested on real hardware first.

EDIT: UAE has specific test for "HARD_DDF_LIMITS_DISABLED" state (=BEAMCON bit 7 or bit 14 set or BPLCON0 SuperHires bit) which changes how display window end detection is done. Unfortunately I am not sure if it is correct or not

EDIT2: Change log entry: "Reset horizontal display window if it is still active at the end of scanline (even if it is
larger than last hpos value) if programmed mode or superhires. Perhaps this is wrong, perhaps not,
not bothered to test yet.. (Background "leak" in right edge in some wide programmed mode screens)"

Probably never confirmed..

I guess test code that does not try any tricks is good, even if it is not real hardware tested. Maybe.

[ross]

Ok, made a little test for the shres open border WinUAE behaviour.
SHRES=1, 1024 pixels wide screen from DDFSTRT=4e

In a real machine you could see it like this, maybe..:


In WinUAE you see:


DIWSTRT is set to xxff, DIWSTOP to xxca

With right mouse you decrease DIWSTOP value.
After some click in a real machine (when value reached c7) you should see the same as Winuae..

---

EDIT: executable removed, Toni fixed the problem in new WinUAE version, thanks

[ross]

Originally Posted by ross

with some shift values there are pixels visible after DIWSTOP position.. but can a bug in my code.

Yes, my bug. High shift bits are masked out in (s)hires video modes and there is a early roll of LUT values

Originally Posted by Toni Wilen

I guess test code that does not try any tricks is good, even if it is not real hardware tested. Maybe.

I disagree Trying some tricks is one of Amiga's funniest things.

[Toni Wilen]

I didn't ask for superhires border test programs. I asked for DIWHIGH H0/H1 bit test programs (because pixel counting is annoying and easy to make mistakes). Testing it this way is pointless speculation because real hardware test is extremely simple (Which I do in next few days) and quick and results must not be assumed when it is about undocumented features.

And as usual, "does not work" is not acceptable, works for me.

I disagree. Trying some tricks is one of Amiga's funniest things.

I said I am not going to accept any test programs (using tricks) made for testing emulation without real hardware test. It would be pointless.

[ross]

Originally Posted by Toni Wilen

And as usual, "does not work" is not acceptable, works for me.

Sorry, for some reason i've downloaded a wrong version (the 22/07 version report the same 21/07 date).
In this version BPLCON1(H1/H0) work properly.
Please wait a test binary.

I said I am not going to accept any test programs (using tricks) made for testing emulation without real hardware test. It would be pointless.

Like i've said was an involuntary trick, that made me loss even some time.

[ross]

I'm sorry but it does not work well for me (version dated 22/07 16:35).
EDIT: because i'm dumb, wrong bits selected..

I've checked the code several times but this certainly does not rule out that it may be a bug on my part.
EDIT: yes, looked several times and always looked wrong..
Not being able to try on my own real machine is frustrating.

The binary values: DIWSTRT=30a1, DIWSTOP=00a1, DIWHIGH=2100, DDFSTRT=004e, DDFSTOP=00c6, BPLCON0=1240
Some copper color0 synced with DIWSTRT -> works properly (you can notice that this time color0 is before bplanes because the DDFSTRT value)
Right mouse click increment shift value by quarter pixel -> work properly
Left mouse click increment DIWSTRT/STOP by quarter pixel -> do not works properly
EDIT: yes works if you use the right bits...
Exit with both mouse buttons pressed.
EDIT: updated executable on message #79

I've also a visible "ghost" problem on workbench at max overscan (not present in previous versions).
And unfortunately I continue to have several problems with the integrated debugger.
Ok, today is not a good day with the Amiga.
EDIT: it would have been better to go for a walk

[Toni Wilen]

DIWHIGH H0/H1 bits seem to work as expected in my quick test code (of course with subpixel checkbox ticked). I also can't find anything wrong with BPLCON1.

("max overscan" is mostly meaningless because copper list contents depends on resolution, number of colors, WB version and more.. Reason I usually require program that takes over the system)

[ross]

Originally Posted by Toni Wilen

DIWHIGH H0/H1 bits seem to work as expected in my quick test code (of course with subpixel checkbox ticked). I also can't find anything wrong with BPLCON1.

DIWHIGH H0/H1 doesn't work as expected in my exe from message #74 (can be my fault).
In same message I confirm that BPLCON1 is working properly (shift value by quarter pixel is working properly).
Of course with subpixel checkbox ticked, Host/Display/Resolution as SuperHires, Host/Filter Null,No scaling,H/V=1x.

("max overscan" is mostly meaningless because copper list contents depends on resolution, number of colors, WB version and more.. Reason I usually require program that takes over the system)

This is easily reproducible.
Quickstart A1200 setup (020, no fastmem, but doesn't matter), default KS31/WB31 setup (like a first installation), no extra fancies, PAL Hires screen at max ovescan (724x) with standard Prefs prog, numbers of colours do not matter, subpixel and SuperHires active, no scaling.
The ghost effect is visible like message #74. If you disable subpixel or superhires, glitch is no more.

[Toni Wilen]

I don't think your test program is setting DIWHIGH correctly, originally it is $2100 (default), one click and it becomes $2504 which does not make any sense. (V8 and V10 start bits set, V10 stop bit set).

[ross]

Originally Posted by Toni Wilen

I don't think your test program is setting DIWHIGH correctly, originally it is $2100 (default), one click and it becomes $2504 which does not make any sense. (V8 and V10 start bits set, V10 stop bit set).

aaargh, i've used the wrong bits!
I reassemble immediately a proper version.
Sorry

[ross]

Attached a working version.
My apologies Toni.


EDIT: I can also confirm that works like a charm in my patched Lionheart version.
That have a really delirantic copper list, BPLICON1 abuse and code that race the video beam.
No glitch anywhere.

[ross]

More info about the "ghost" glitch.

It's related to ddfstrt/ddfstop values: the max wide fetch ($18/$d8) generate the problem.
Any lower set (like $28/$d8 or $18/$c8, wb use these) do not create glitch.
And ghosted image seems containg only data from bitplanes 2,4,6,8.