Half pixel copper delay on A1200 hardware

[ross]

Originally Posted by Toni Wilen

Does hires resolution also have exact same extra delay? (EDIT: I'll try to do some real hardware tests later today)

Attached an hires version.
Video timings changed due to 3 (2pf) hires planes (so similar DMA usage as 6 lowres planes), changed also DDFSTRT/STOP but DIWSTRT/STOP in sync to copper COLOR00 changes.

FSizzle please can you check if half pixel mismatch is visible in your A1200?
(maybe there are different versions that have different behaviors?)

Waiting real test from Master Wilen for a definitive response.

--

I probably explained it in some other thread but here is quick explanation:

This requires large rewrite, currently single Amiga lores/hires/shres pixel is single bit in whole display emulation path. Until finally output pixel color is decided (background, sprite or bitplane pixel) where single pixel becomes 1, 2 or 4 native horizontal pixels using optimized generated code. (every doubling mode has separate routine)

Everything is optimized for this behavior.

Sprites already support it because they are relatively simple and can't have weird side-effects. (like writing to BPLCON1 mid-scanline does)

Thanks Toni, I did not see the thread in which you explained this (sorry)

You write so many interesting things that it would take a secretary to collect everything and make an encyclopedia

Well, when you have time it's an interesting change to increase AGA compatibility.

[Toni Wilen]

Originally Posted by ross

Attached an hires version.
Video timings changed due to 3 (2pf) hires planes (so similar DMA usage as 6 lowres planes), changed also DDFSTRT/STOP but DIWSTRT/STOP in sync to copper COLOR00 changes.

It is too difficult to see, it has too random looking graphics.

EDIT: I did some tests and it happens in hires too, same 1 hires pixel extra delay.

[ross]

Cumulative EDIT:

Ok, thanks!

A solution in a real Amiga, if a game use this feature, can be:

 if (AGA) {
   set a fixed delay, to all playfields, of half lores pixel for every BPLCON1's value
   set DIWHIGH accordingly
 }

[Toni Wilen]

I just edited above post (first test case was not that good). It happens in lores and hires, same 1 hires pixel delay in both modes.

[FSizzle]

FSizzle please can you check if half pixel mismatch is visible in your A1200?

When I boot the halfhres exe there are differences vs WinUAE as follows (for the 5 different states of the test):
- 1 - every second pixel misaligned on left side. Right shows extra non-white pixel column
- 2 - same as 1
- 3 - same as 1
- 4 - right side shows two non-white pixels (left side now matches)
- 5 - same as 4

In hires mode, the mismatches seem to be one hi-res pixel, which is consistent with lowres (half a lowres pixel = one hires pixel after all )

I attached an image showing these 2 states, comparing left and right on real HW vs WinUAE

[ross]

Originally Posted by FSizzle

In hires mode, the mismatches seem to be one hi-res pixel, which is consistent with lowres (half a lowres pixel = one hires pixel after all )

Thanks!

So I know how to patch this 'feature'

[ross]

Originally Posted by FSizzle

When I boot the halfhres exe there are differences vs WinUAE as follows (for the 5 different states of the test):
- 1 - every second pixel misaligned on left side. Right shows extra non-white pixel column
- 2 - same as 1
- 3 - same as 1
- 4 - right side shows two non-white pixels (left side now matches)
- 5 - same as 4

Just a conclusive word: the results are exactly as I expected.
Actually states are 4, one was a mistake in my code due to an erroneous shift initialization

Thanks for your time!

[Toni Wilen]

winuae.7z now adds hires pixel delay to all color register writes if AGA which seems to "fix" this problem. It was very simple change and has nothing to do with BPLCON1 hires/shres missing feature.

But because this causes quite ugly mismatched borders in some games, it most likely looks like new UAE bug..

EDIT: I guess delay may come from BPLCON4 XOR operation. Because when BPLCON4 is modified, it isn't instant but adds another hires pixel delay (was lores previously in emulation but it is actually extra hires = 1 + 1 hires = 1 lores) before colors change after BPLCON4 modification.

EDIT2: HAM and EHB needs testing, some HAM/EHB bits bypass BPLCON4 so in worst case there are 2 possible delays.. (http://eab.abime.net/showthread.php?t=85588)

[ross]

Originally Posted by Toni Wilen

winuae.7z now adds hires pixel delay to all color register writes if AGA which seems to "fix" this problem.

It was very simple change and has nothing to do with BPLCON1 hires/shres missing feature.

Sure, but the only possibility that comes to my mind to patch games that use this feature is by setting PFxH1=1 in every BPLCON1 write and set DIWHIGH(H1,bit12/4)=1

But because this causes quite ugly mismatched borders in some games, it most likely looks like new UAE bug..

Unfortunately most of these games use double playfields and fall into the PF1!=PF2 unsupported shift casuistry, so..
It is not better to leave as before and mask-out H1 in lores screens cases?
At least as long as there is no full AGA shires/hires shift support.

EDIT: I guess delay may come from BPLCON4 XOR operation. Because when BPLCON4 is modified, it isn't instant but adds another hires pixel delay (was lores previously in emulation but it is actually extra hires = 1 + 1 hires = 1 lores) before colors change after BPLCON4 modification.

EDIT2: HAM and EHB needs testing, some HAM/EHB bits bypass BPLCON4 so in worst case there are 2 possible delays.. (http://eab.abime.net/showthread.php?t=85588)

Very interesting.

Thanks as always!

[Toni Wilen]

I started implementing proper subpixel support, more information when/if it starts working... I'll probably enable hires pixel color delay emulation only when subpixel emulation is also enabled.

[ross]

Originally Posted by Toni Wilen

I started implementing proper subpixel support, more information when/if it starts working... I'll probably enable hires pixel color delay emulation only when subpixel emulation is also enabled.

[FSizzle]

I started implementing proper subpixel support, more information when/if it starts working... I'll probably enable hires pixel color delay emulation only when subpixel emulation is also enabled.

@Toni - Very nice. For what it's worth, I think going for accuracy is the right approach - I like the idea of all bugs and hardware quirks being emulated correctly (something WinUAE already does an amazing job of!)

if (AGA) {
set a fixed delay, to all playfields, of half lores pixel for every BPLCON1's value
set DIWHIGH accordingly
}

@ross - I think this is a good option - I need to similarly adjust sprite positioning as well. Alternatively, I also realized that I might be able to solve the problem on AGA by using BRDRBLNK in BPLCON3 (i.e. don't bother syncing at the edges precisely (or even at all), but just mask the border to black instead).

[ross]

Originally Posted by FSizzle

@ross - I think this is a good option - I need to similarly adjust sprite positioning as well. Alternatively, I also realized that I might be able to solve the problem on AGA by using BRDRBLNK in BPLCON3.

Yes, this is a viable alternative
Anyway you've to set DIWHIGH appropriately and there're two little drawback:
- forced black at border with loss in that area of any graphic element (sprite or copper effects)
- the lose of one half-pixel at the left edge (but this is really insignificant )

EDIT: thinking about it better, the former can be a not too little problem for AGA productions that use FMODE=3/7 and cover left edge with sprite(s) to compensate the bigger DDFSTRT and large 64bit scroll. Therefore the use of BRDRBLNK should be carefully weighed and the pros and cons evaluated.

(i.e. don't bother syncing at the edges precisely (or even at all), but just mask the border to black instead)

If you need OCS/ECS compatibility you have to sync

[FSizzle]

If you need OCS/ECS compatibility you have to sync

My target is OCS, so I will continue to sync there. I just want to do some extra stuff on AGA to make it look correct (not have the misalignment)

My plan is to check if running on AGA and build the copperlist differently, so that for OCS I continue to change the background color in sync with DIWSTRT/STOP as I do now, but for AGA, I instead change the color only before the start of each display line and use BRDRBLNK to mask off the border. If I do this, I don't need to tweak DIWHIGH either.

In my case I want the border black in all cases, as I think it looks nicer, so the effect of BRDRBLNK masking is desirable. I would use it for OCS if it was available instead of the explicit timing which burns a lot of copper cycles

I believe BRDRBLNK is avilable on ECS as well, but it's simpler for me to keep it the same as OCS so I don't complicate the copper list construction code with a 3rd set of timings to handle (it's already complex enough with all the sprite multiplexing interleaved with palette changes and other display trickery

[ross]

Yep, for your needs it's the best way to do

Unlucky my 'patch' habit for old demos/games require a different approach.

Back to Lionheart's example: it has a hell of copper list (dynamic, synced, even a little illegal, full of tricks).
To satisfy my need for perfection I did a complete (insane..) re-sourcing of the code.
And from here i've fixed all BPLCON1 (OCS) illegal usage (distibuted in variuos code, tables, copper snippet..) that make all sort of glitches on AGA machines.. not even visible to an untrained eye.
[Well, actually i've optimized MANY other thinghs (this is only a little fraction), but I do not even know if I will eventually get something finished out of it, as I often do..]

Using BRDRBLNK would have solved only the 'edges' part of the video.
And the 2nd possible (monster) AGA copper-list would've required a complete rewrite of the video routine.
So changing H1 (on BPLCON1/DIWHIGH) it's to be considered only a side effect and with small impact on the whole process (and seem to work, I need a beta tester..)

Always a pleasure that there is still someone who enjoys playing with these chipsets.
Good job and fun!

[Toni Wilen]

http://www.winuae.net/files/b/winuae.7z updated with experimental subpixel display emulation support.

- option in chipset panel
- display panel resolution selects internally emulated resolution.
- most speed optimization tricks are not implemented.
- option also works in ocs/ecs modes (but does nothing visible, only slows down emulation, easier test case for me to confirm non-corrupted display)
- 1 hires pixel AGA color delay is only emulated if subpixel emulation is enabled.

Originally Posted by FSizzle

I believe BRDRBLNK is avilable on ECS as well

Border blank feature was introduced in ECS Denise. (Which was part of new genlock features that probably no one used..)

[ReadOnlyCat]

Originally Posted by ross

Back to Lionheart's example: it has a hell of copper list (dynamic, synced, even a little illegal, full of tricks).
To satisfy my need for perfection I did a complete (insane..) re-sourcing of the code.
And from here i've fixed all BPLCON1 (OCS) illegal usage (distibuted in variuos code, tables, copper snippet..) that make all sort of glitches on AGA machines.. not even visible to an untrained eye.

[Well, actually i've optimized MANY other thinghs (this is only a little fraction), but I do not even know if I will eventually get something finished out of it, as I often do..]

You should consider creating a new thread about your changes!

I have been harping for quite a while about how there is likely room for optimization in most commercial Amiga games because: they were built under time pressure, profiling and debugging tools were usually very primitive (especially compared with modern ones like VTune) and oftentimes teams included coders which were not necessarily super experienced.

So I would be super interested in which kinds of avenues for optimization and rework you found in LionHeart.

[ross]

Originally Posted by Toni Wilen

..updated with experimental subpixel display emulation support.

Great, I'll try it!

Originally Posted by ReadOnlyCat

You should consider creating a new thread

Well, I've to make it working first, in this period I have very low rhythms
Some unfinished changes:
- optimized various generic code (too much to list), more pc-relative or base-relative code
- changed memory manager (doesnt require anymore a patch that mess memory)
- native support for whdload (yes, in main code!)
- optimized some blitter routine (with faster blitter wait) and faster objects mirror routine
- all the fix of the whdload version (and more..)
- glitches free and full AGA support (see this thread)

But do not expect significative performace change, this game is really a jewel in Amiga history (maybe less slowdown, which are indeed rare).

Bye!

[FSizzle]

I have discovered another interesting thing related to all this. On AGA the BRDRBLNK is applied a half pixel early on the left hand side on real hardware! Interestingly it is applied at the expected place on the right hand side.

I've attached an updated HalfPixelTest.exe. If you press and hold the right mouse button, the BRDRBLNK will be applied and you can see the third line is correctly cropped on the right, but is cropped a half pixel early on the left.

[FSizzle]

You should consider creating a new thread about your changes!

@ross +1 I would also find this very interesting.