Usual disclaimer: I know the open source nature of MiSTer and that anyone can code the required features, but we are here in order to exchange ideas and to understand better.
Sorgelig wrote:From all available for MiSTer cores, only one can be affected by this option - Minimig. All other cores have less than 8-bits per color component. It means both 235 and 255 usually represent the same brightness for most cores. Same for black level.
I don't get how having less than 8 bits translates to correct full and/or limited RGB gamma. I mean I understand it means that the original platform can represent less color levels than limited RGB, but we should get no correct correspondence both with limited and full RGB (i.e. total black and total white don't match). Let me explain what I think (I might be wrong) should be a correct match: let's say we are emulating/simulating an old computer with RGB555 color space. Its DAC should output volt levels (computer monitors levels or TV/broadcasts levels) corresponding to total black for RGB 0-0-0 and to total white for RGB 31-31-31, and these should correspond to 0-0-0/255-255-255 for HDMI full RGB and 16-16-16 /235-235-235 for limited RGB. So if oR
is original red, oRB
is original red bitdepth and hR
is HDMI red we should have hR=oR/(2^oRB-1)*255
for HDMI RGB full and hR=oR/(2^oRB-1)*(235-16)+16
for HDMI RGB limited. This may be an oversimplification, we could apply correction curves, I'm no video expert, but this is how it should work to the best of my understanding.
Sorgelig wrote:Even with Minimig i didn't get enough info how limited color range is affecting the picture.
Usually if source provides limited color range on full range monitor/TV you notice only grayish black.
Yep, we should get grayish (too bright) blacks and grayish (too dark) whites; generally, we should have compressed and shifted levels through the whole gamma (not only at the extremes).
Sorgelig wrote:With opposite case you may notice some detail loss near white and black
Again, we should have expanded and shifted levels through the whole gamma with clipping (detail loss) at the extremes.
Sorgelig wrote:and usually it's hard to notice unless you compare it side by side.
Perception is personal and depends on, among other things, sensibility, training and OCD levels
Sorgelig wrote:Anyway, video generation is done on FPGA and is up to core implementation.
Currently cores output colors as-is, i.e. in full range.
So, if I understand correctly, if HDMI output is 1:1 to emulated/simulated color buffer, we have full RGB HDMI only when the original color buffer is RGB888.
Anyway, I'm no FPGA expert, but it's my understanding that you can program groups of internal elements of the FPGA chip to act as specific configuration of logic gates and connections. Each specific group can act as an emulated/simulated original chip, with peripheral connections of this group acting as pins of the chip. So, we can interconnect different groups as the interconnections of the chips on the original hardware. Then, again, the peripheral connections of this set of groups (the whole original emulated/simulated hardware) go to the pins of the FPGA chip in order to talk to other components of the FPGA board (HDMI chip, SDRAM, GPIO, etc.). Now, if I'm not wrong, does it make any sense to imagine part of a FPGA chip configured as a "virtual universal DAC" for MiSTer cores? I mean something with standardized peripheral connections for cores to be used as a modular audio and video DAC, as some sort of FPGA utility/API that would take care of all conversions from old audio/video formats to correct modern HDMI levels and timings. I'm trying to imagine MiSTer as a sort of Libretro/RetroArch of the FPGA world, where it could offer standard input/output interfaces for cores that should "only" re-implement original hardware without bothering about user interface and real-world input/output. In emulation world this approach has great success. Take as an example Higan SNES; the native Higan offers two synchronization methods (excluding variable refresh rate monitors) of the emulated SNES (60.1Hz video) to the computer output (60Hz): sync to video, with audio crackling, and sync to audio, with video stuttering; then we have Libretro Higan SNES that automatically inherits Libretro Dynamic Audio Rate Control where video is synchronized to monitor vsync and audio is dynamically stretched to match video rate without crackling; to me, the best possible Higan SNES came when it was ported to a platform like Libretro. Again I'm imagining MiSTer as FPGA's Libretro (I know, I know… good idea, I'm free to implement it).