Display off / black not really black

[Muzza]

In my Turrican conversion, When I have multiple displays (one screen on top of another screen), my copper list will wait until the end of the first, then set BPLCON0 to 1 to disable the display (1 is to enable ECS because BPLCON3 has BRDNBLNK set).

Then the copper list sets up the palette for the second screen, waits, and enables the display for it. The screens backgrounds are all black, so in WinUAE you get a consistent display (the screen gap is just under the logo but invisible here):



On a real Amiga with a scart display, you can see the gaps. Whenever the display is active, black is not really black.



My guess is that when the beam is on, it never delivers true blacks, so you can see the differences when the copper is turning the display on/off (although interestingly this is taken from an LCD with a scart input, not a CRT).

Is there a better way I should be handling this kind of thing on the Amiga, to disable the display without getting the solid black bar?

[pandy71]

Originally Posted by Muzza

In my Turrican conversion, When I have multiple displays (one screen on top of another screen), my copper list will wait until the end of the first, then set BPLCON0 to 1 to disable the display (1 is to enable ECS because BPLCON3 has BRDNBLNK set).

My guess is that when the beam is on, it never delivers true blacks, so you can see the differences when the copper is turning the display on/off (although interestingly this is taken from an LCD with a scart input, not a CRT).

Is there a better way I should be handling this kind of thing on the Amiga, to disable the display without getting the solid black bar?

It may be limitation of your display - VBI is usually 'underblack' or 'blacker than black'. With DC coupled signal or with improper black level acquisition black may be not fully black.
I would check some CRT display to verify this issue.
As a workaround you mat try to tweak brightness and contrast settings on your display.
Also display may expect different signal level at input (usually expected video signal is or 700mV or 1000mV) - if you feed 1000mV to 700mV input then it may give similar result.
Gamma setting may be also useful.

[earok]

For the reason that borderblank is "blacker than black" on real displays, I gave up using it in Scorpion Engine (if color 0 is not#000, then I use the copper to set and unset the colors at the edges, this also means visually it's identical on OCS to ECS)

[ross]

This can be emulated with the WinUAE "Blacker than Black" setting in Host/Display.

A simple workaround in Amiga side could be to set BPLCON0/BPU=1 ($1001 instead of $1) and COLOR00=COLOR01=0 during the split gap (f you don't want to touch ECSENA).

[hooverphonique]

How is it even possible hw-wise, that setting all palette registers to 0, and then 0 bitplanes enabled produces another color than with >0 bitplanes enabled?

[ross]

Originally Posted by hooverphonique

How is it even possible hw-wise, that setting all palette registers to 0, and then 0 bitplanes enabled produces another color than with >0 bitplanes enabled?

Because with BRDRBLNK active this 'gap' is not really black but BLANK.
There is a voltage difference between the two and, depending on device calibration and setup, this can be easily spotted.

Some devices, for diagnostics, may also display a different 'color' than pure black when BLANK.
It is very convenient when you have to emulate the programmable blanks correctly, as in ECS and AGA

[Thomas Richter]

Originally Posted by Muzza

Is there a better way I should be handling this kind of thing on the Amiga, to disable the display without getting the solid black bar?

That an effect caused by the analog TV norm, which adds a "pedestal" to the colors and uses signal levels between "black" and "0V" for signalling. Apparently, your monitor does not interpret the TV signal correctly and instead of showing black shows the toe offset (or black pedestal) instead.



I wouldn't turn off the display unless needed as TVs may also react a bit allergic to the missing pedestal, and just keep it black, but as stated, it looks to me as if the monitor is rather trying to interpret the Amiga output as VGA compatible signal (with 0V = black) instead of following the TV norm with its additional head and toe region for the signal levels.

[hooverphonique]

Originally Posted by ross

Because with BRDRBLNK active this 'gap' is not really black but BLANK.

so the gap is considered "border", even though it is inside the display window? I would say that's a bug

[ross]

Originally Posted by hooverphonique

so the gap is considered "border", even though it is inside the display window? I would say that's a bug

Nah, it is border (if there are no active bitplanes technically it is 'border')

[Muzza]

Thanks for the replies. This is proving to be more painful than I'd hoped.

In some cases the number of copper instructions to set up the second screen only just fits in the time available. Disabling the display with one instruction allowed me to set everything up (palette, bitplanes, modulos, etc.) and then enable it all instantly with BPLCON0.

If I keep the display active I have to either set up a dummy bitplane, or use Rosses suggestion. Either way it results in extra instructions and requires moving the screen setup around. COLOR0/1 needs to be deferred (which includes BPLCON3 instructions as it is AGA so that is extra instructions). As do BPL1MOD and BPL1PT.
Every combination I try throws the copper timings off just enough that I'd have to leave an extra scanline between the scrolling display and status bar during the game. :/

I looked at the BYPASS bit in BPLCON0. The documentation is a little low on detail but it makes it sound as though bypassing the palette lookup would result in COLOR1 coming out as 'almost black' which I hoped might let me get away without messing with the palette, but the results I get from trying it in WinUAE are not what I'd expect - I still get colours.

[Muzza]

In the end I've settled on (mostly) removing borderblank as earok suggested.
I had to shuffle around art asset palettes to avoid using colour 0 for copper effects. There is one level where I've kept borderblank enabled as the HW sprite parallax combined with copper gradients make it painful to not use colour 0, and I didn't want to pay the performance price of a lot of additional copper instructions (plus I was struggling to get the colours to change at the exact place I needed with my screen setup).
Anyway, a lot of hassle for a seemingly minor thing...

[Muzza]

...and I've just remembered that some of the bosses rely on the background colour being zero for fast blits. So now I'm undoing it all...

[roondar]

Originally Posted by Muzza

...and I've just remembered that some of the bosses rely on the background colour being zero for fast blits. So now I'm undoing it all...

You could opt to have two screen set ups: one for the title screen and one for the main game. I've seen many Amiga games do that, it might help fix your issue?

[ross]

Originally Posted by Muzza

...and I've just remembered that some of the bosses rely on the background colour being zero for fast blits. So now I'm undoing it all...

mmh, maybe solvable.
But we have to talk about it in PM because there are some technicalities to consider and it depends on how you plan to organize the (Copper) code.

[Muzza]

Originally Posted by roondar

You could opt to have two screen set ups: one for the title screen and one for the main game. I've seen many Amiga games do that, it might help fix your issue?

That's basically where I've ended up. I use borderblank in the game, and turn it off for the menu. Could have saved myself a lot of time if I'd just done that to start with, but it felt inconsistent.

[pandy71]

Originally Posted by Muzza

That's basically where I've ended up. I use borderblank in the game, and turn it off for the menu. Could have saved myself a lot of time if I'd just done that to start with, but it felt inconsistent.

It will be easier if you describe your HW setup - saw something like this before in one case - RGB on SCART added with CVBS - normally CVBS is used by Amiga to pass sync pulses so sync pulse is from 0mV to 300mV then you have video from 300mV (i.e. IRE 0 i.e. BLACK) to 1000mV, RGB lines should from 0mV to 700mV - if somehow electronics in your display combine both signals then this effect may be visible exactly as you provide pictures.
Personally i would put some capacitor like 220..470uF on CVBS line so 300mV pedestal will be removed and as such signal should be restored to normal.
Alternatively if your display support H and V sync pulses you can use cable with separate H and V.
But simple capacitor should help to solve your issue.

[Muzza]

It was a software fix I was looking for, rather than HW, as I'm trying to make it look good on all hardware.

Ross your PMs are full, but I tried EXTBLKEN and got it working, but I would have to do some additional work as there were some problems at the top of the screen with sprites showing through. So for now, I'm going to stick with borderblank on in the game, but off in the menu.

[ross]

Originally Posted by Muzza

.. but I would have to do some additional work as there were some problems at the top of the screen with sprites showing through.

Interesting.
I'm always available if there is any side effect of programmable modes
Although I suspect this sprite issue is due to something completely unrelated to HB.

[pandy71]

Originally Posted by Muzza

It was a software fix I was looking for, rather than HW, as I'm trying to make it look good on all hardware.

Once again - this is more likely corrupted HW issue. Obviously black level is not sampled from RGB but from CVBS where CVBS is only CSYNC.

https://www.eecg.utoronto.ca/~tm4/rgbout.html


https://electronics.stackexchange.co...in-crt-display

Black level in CVBS shall be sampled and restored just after chroma burst and before active video but RGB is not the case as black is always 0mV (no sync pulses) - obviously your display is confused and trying to do something wrong.



EXTBLKEN workaround will work only in ECS and in AGA not on ICS/OCS so it is partial fix.