Half pixel copper delay on A1200 hardware

[FSizzle]

updated with experimental subpixel display emulation support.

Thanks Toni! - I confirm that with this version, the delay in WinUAE matches my real A1200. You are a machine!

I'd love hear your thoughts on the "early BRDRBLNK" issue if you have chance to think about it. Very odd.

[Toni Wilen]

"Broken" border blank confirmed, single (looks like it is hires) pixel of border color is visible just before horizontal bitplane start.

AGA only, does not happen when using ECS Denise.

Odd that no one has noticed it (or at least mentioned it) previously because this is IMHO actual bug because borderblank is (was) documented as blanking the border color.. Other horizontal hires pixel issues are more like implementation details and not fully documented.

[meynaf]

I remember having seen that border line at the left of the screen on my A1200 many years ago. Thought it was "known fact", but apparently it isn't.

[Toni Wilen]

- AGA borderblank behavior is now emulated (again, only in subpixel mode)
- Not all internal variables were updated when subpixel mode/resolution was changed on the fly causing missing bitplane data in right side of display.

Originally Posted by meynaf

I remember having seen that border line at the left of the screen on my A1200 many years ago. Thought it was "known fact", but apparently it isn't.

Many probably saw it but I am not sure if anyone actually examined it and only wanted to hide it any way possible

[Steve]

Is it really necessary to implement these hardware 'bugs'? I'm sure the original Amiga hardware guys would much rather the machine emulated as it was designed to 'be' without all the little gremlins that sneaked their way in. Maybe bug emulation should be an option?

[StingRay]

Originally Posted by Steve

Is it really necessary to implement these hardware 'bugs'?

Yes. It is very useful to have these hardware bugs emulated!

Originally Posted by Steve

Maybe bug emulation should be an option?

Emulation should be as close as possible to the "real deal" including all bugs and "hidden features".

[ross]

I'm for a name change for the thread, something like:

"AGA chipset: half low-res pixel delay and related oddities"

[Toni Wilen]

Originally Posted by Steve

Is it really necessary to implement these hardware 'bugs'? I'm sure the original Amiga hardware guys would much rather the machine emulated as it was designed to 'be' without all the little gremlins that sneaked their way in. Maybe bug emulation should be an option?

Yes. Absolutely. Accuracy is main goal.

Nothing would work (not even KS 1.x boot screen would look correct, it assumes undocumented blitter behavior) if emulation was based on documented behavior, not actual chipset behavior!

Program written under emulation should create identical output on matching real hardware configuration and vice versa. It is really annoying to code something and later notice it looks wrong on emulation/real hardware. Which is not acceptable. (I don't talk about CPU/bus speed differences, it also varies in real world. Chipset speed and behavior does not depend on CPU speed or bus speed or whatever. It is always the same.)

[meynaf]

I'm not for emulating this kind of bug. No program will ever crash because of this.
If it's about emulation accuracy then it should be under some "more compatible" setting, not by default.

Anyway it's still not accurate this way. I remember my A1200 missing one hires (maybe shres) column at the right of the display under normal 640x256 setting (which an emulated mirror copy of the system does not do).

[Toni Wilen]

I already have mentioned it is not enabled by default (because it requires much more CPU power and it is rarely needed).

I remember my A1200 missing one hires (maybe shres) column at the right of the display under normal 640x256 setting (which an emulated mirror copy of the system does not do).

Any hires/shres "trick" wasn't even possible until now so maybe later..

[meynaf]

Ok then.

Does A4000 also show the behavior or is it only A1200 ?

[Toni Wilen]

Originally Posted by meynaf

Does A4000 also show the behavior or is it only A1200 ?

Yes (just tested). Possibly there are other Lisa (this behavior is 100% Lisa internal) revision that could work differently? Or it works as designed..

My A1200 and A4000s have have same Lisa: 391227-01 (1204 R0) HP manufactured. Another A1200 has non-HP Lisa, same PN but (1207 R0).

btw, AGA borderblank extra border pixel is lores wide when I checked it on A4000 with Indivision AGA (which reads Lisa digital RGB outputs directly without any processing so it should be 100% accurate). A1200 is connected to crappy LCD via Scart with not that sharp image. (I have Indivision for A1200 too but it is currently somewhere unknown..)

So I'll change it to lores pixel unless someone else finds something else. Non-borderblank related color change delay was clearly hires wide.

[ross]

Tested and works properly

I need eventually DIWHIGH(STRT/STOP, H1/H0) emulation, this new visible delay hurt my patch
Or this is a WinUAE fix that need also BLPCON1 (H1/H0) (PF1!=PF2) emulation?

[Toni Wilen]

Thanks for reminding, I didn't remember that DIWHIGH H0/H1 bits are still being ignored...

Implementing this may much more complex than previous updates because DIW values are in lores pixels everywhere. But it needs to be done..

Or this is a WinUAE fix that need also BLPCON1 (H1/H0) (PF1!=PF2) emulation?

No, this is already implemented in "subpixel" mode.

[FSizzle]

I have Indivision for A1200 too but it is currently somewhere unknown..

@Toni. For completeness, all the tests I have done on my real A1200 have been via an Indivision Mk2. I actually thought for a while that this might somehow be responsible for some of these issues, so I also tested everything over scart. All issues noted in this thread are present in both cases.

[FSizzle]

So I'll change it to lores pixel unless someone else finds something else. Non-borderblank related color change delay was clearly hires wide.

The early BRDRBLNK is a hires pixel (70ns) before bitplane data (3rd row), same width as the color delay shown on row 2.

[FSizzle]

Upon closer analysis, it looks like the BRDRBLNK also ends 70ns early. i.e. the BRDRBLNK starts and stops 70ns early.

[ross]

Originally Posted by FSizzle

Upon closer analysis, it looks like the BRDRBLNK also ends 70ns early. i.e. the BRDRBLNK starts and stops 70ns early.

This is reassuring, at the end the bug is "consistent".
Well, knowing it, a right DIW setup can solve everything.

[ross]

Originally Posted by meynaf

Anyway it's still not accurate this way. I remember my A1200 missing one hires (maybe shres) column at the right of the display under normal 640x256 setting (which an emulated mirror copy of the system does not do).

After WinUAE latest emulation update can be interesting to test in your "missing pixel" setup to search where the problem lies.
Probably system that wrongly calculate screenshift/DIWHIGH association.

[EDIT, little OT] I just don't understand the "screen opening" on line-1 (near start of vb..) by KS30+. This can generate some undesired side effect.
Maybe a patch for some prototype chipset or an aid to a hardware probe? Who knows..
Just yesterday I was trying out the new AGA emulation code and I did not understand why I've had some "first frame" garbage on screen. Then I remembered.
So system video copper list can be "wrong" or bad applied.

[Toni Wilen]

Originally Posted by FSizzle

Upon closer analysis, it looks like the BRDRBLNK also ends 70ns early. i.e. the BRDRBLNK starts and stops 70ns early.

This is also emulated now.

Originally Posted by ross

[EDIT, little OT] I just don't understand the "screen opening" on line-1 (near start of vb..) by KS30+. This can generate some undesired side effect.
Maybe a patch for some prototype chipset or an aid to a hardware probe? Who knows..

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.