Display brightness in ST emulators

[sandord]

Something that kept drawing my attention was that the overall brightness of the picture in STeem wasn't actually very bright. The whites look a tad dimmed, never becoming as bright as the browser window next to it on the same monitor for example.

So I took a screenshot and ran it through a histogram:

Untitled3.png

Untitled2.png

The largest spike represents the whites (the screenshot has a lot of white in it, hence the length of the spike). As you can see, the spike isn't at the top so ST-white doesn't reach full brightness in the output picture.

Apparently, ST colours are converted to PC colours by simply shifting the primary colour bits 5 positions to the left:

Code: Select all

(ST)  #777 = 0111 0111 0111

Which then becomes on STeem:

#E0E0E0 (PC) = 11100000 11100000 11100000

As a side node, by configuring STeem to emulate an STE, the desktop white becomes #F0F0F0 so the STE gives a bit brighter display in STeem.

I checked with Hatari as well and it also doesn't reach full brightness. But it gets quite a bit brighter:

Code: Select all

(ST) #777 = 0111 0111 0111

Which then becomes on Hatari:

#EEEEEE (PC) = 11101110 11101110 11101110

The latter looks like a simple but quite effective way (copying the 4 MSB on top of the 4 LSB) to (almost) correct the problem without using much additional processing power.

So if you ask me, I'd like STeem to have an option that corrects the brightness. Obviously, I should take this to the STeem support forum on SourceForge (https://sourceforge.net/p/steemsse/forum/rest).

But first I wanted to see if any of you had noticed the same and perhaps I'm missing a perspective here... Maybe the ST doesn't output video levels at full brightness (say less than 5V on the RGB pins)?

Here's a quick wrap-up of the story in a picture:

Untitled.png

[czietz]

I checked with Hatari as well and it also doesn't reach full brightness. But it gets quite a bit brighter:

Code: Select all

(ST) #777 = 0111 0111 0111

Which then becomes on Hatari:

#EEEEEE (PC) = 11101110 11101110 11101110

Note that STE white (#FFF) becomes "true" white #FFFFFF with Hatari. Imho, it is a sensible choice to have the same mapping for ST and STE, even though that means that ST white will only go up to #EEEEEE. If you changed that, software that only uses ST (3 bits per color) palette values would look differently on a Hatari-emulated ST than on a Hatari-emulated STE.

[Smonson]

Exellent work investigating and diagnosing this!

Having gone through similar thoughts for the HDMI mod (since it outputs 8 bits per colour), in my opinion the ideal solution is to repeat the palette bits without gaps, i.e. for each colour, a 3-bit brightness represented by bits 123 (for STFM) should be repeated 12312312 for 8 bits or 12341234 for the STE palette. It doesn't matter if the last bit is missed out in the 3rd repetition. The full gamut will then be spread across the 8 (or 16) brightness positions as evenly as possible that way.

Doing both STFM and STE as 12341234 is a decent compromise, but leaves the STFM able to reach only 93% brightness instead of the 100%. But it's still better than nothing.

[sandord]

Note that STE white (#FFF) becomes "true" white #FFFFFF with Hatari. Imho, it is a sensible choice to have the same mapping for ST and STE, even though that means that ST white will only go up to #EEEEEE. If you changed that, software that only uses ST (3 bits per color) palette values would look differently on a Hatari-emulated ST than on a Hatari-emulated STE.

It sounds sensible, yes. But the best solution would be one that reflects real hardware behaviour. Running ST software on an STE should in most cases leave the LSB of each primary color at 0 (unless the software writes 1's to those bits, even though that didn't do anything on an ST). This means that on an STE, the effective 4-bit value becomes 1110, which can't be anything else than a tad less bright than the 1111 that would result from STE software setting the brightest value. Unless the STE uses an overdrive on the video out of course, where ST #777 could have the same brightness on both the ST and the STE. But I doubt they'd do something like that.

[sandord]

Exellent work investigating and diagnosing this!

Having gone through similar thoughts for the HDMI mod (since it outputs 8 bits per colour), in my opinion the ideal solution is to repeat the palette bits without gaps, i.e. for each colour, a 3-bit brightness represented by bits 123 (for STFM) should be repeated 12312312 for 8 bits or 12341234 for the STE palette. It doesn't matter if the last bit is missed out in the 3rd repetition. The full gamut will then be spread across the 8 (or 16) brightness positions as evenly as possible that way.

Doing both STFM and STE as 12341234 is a decent compromise, but leaves the STFM able to reach only 93% brightness instead of the 100%. But it's still better than nothing.

Hey, that's actually a very smart (and both simple and performant) way to spread the brightness. I didn't realise that when I saw the repetition in Hatari's colour values.

[EvilFranky]

Sorry if I'm not understanding this correctly.

As far as I remember from owning an STFM a long time ago, but it's normal for the 9-bit palette to look a bit 'duller'?

The Megadrive whites are the same?

[Smonson]

As far as I remember from owning an STFM a long time ago, but it's normal for the 9-bit palette to look a bit 'duller'?

It's relative. It may be duller than another device plugged into the same monitor, because it is down to an absolute voltage that is applied to the video signal - but that brightness level is still the brightest white that it's possible to get as far as the ST is concerned.