I’m used to emulation where the colors are generated from the voltages themselves. Also, before switching to patchy-ntsc, I generated a palette from gamutthingy and used that in addition to my LUT. That seemed to work acceptably. I don’t know if that palette is able to avoid the clamping or not. All that I am looking for is a way to apply the luma and hue skews on top since not all NES emulators have palette support because they already handle the color correctly with voltages.
Are you open to the idea of moving this conversation over to NesDev if I start a thread there? I have a good rapport with lidnariq, and I think a lot of the hardware pieces to the “shader equation” can be cleared up from the group over there who are well versed in baseband signals and video output from consoles.
Not your fault, but I’m not sure what you mean by this. Rereading question 3 from your last post, I’m confused now as to what exactly you were asking about or what you meant. The idea of incorporating the hue and luma skews without using the raw palette doesn’t make sense to me since that step is already completed and baked into the NES palettes, like the one you had output by gamutthingy, and it’s part of my video signal emulation process with the raw palette too.
I must’ve been very tired or distracted when I answered you last, too, because that tangent I went off on doesn’t really directly answer the question you asked. The raw palette is required to emulate the signal, and using measured voltages is a required part of that process too. Since the process of making an NES palette as RGB values is only based on decoding the signal in non-invertible ways, it’s not possible to take an NES palette (other than the raw palette) and construct a video signal based on it. That’s even if the emulator outputs the palette “correctly using voltages” which isn’t invertible and still has multiple different “correct” ways based on the same voltages.
My shaders are using lidnariq’s measured voltage levels to generate the NES video signal as a perfect square wave as outlined in the nesdev wiki. I did the row hue skew in a hacky way temporarily (which makes de-emphasized colors get skewed wrongly). (The slight luma increase on the de-emph columns is missing, however.) All we can do is try to make a new NES palette from this output. There’s a prependable “test pattern” shader with an option to show the whole NES raw palette as a grid of differently colored rectangles, so that might be useful for this. All I have left to do is make my shaders compatible with the gamutthingy LUT. (I believe this should be doable, unless I’m not thinking things through. Negative values clamping shouldn’t be a real problem if I make my shaders compatible with the postgammaunlimited mode properly.)
On the subject of the NES, I just realized there’s a small fix I need to do with the black pedestal crush too (though I believe that isn’t in the October version that you have.). So much cleaning up that I need to do with this shader code now that I’m coming back to it.
I’m fine with that. This might hopefully help me get some direction on how to go about implementing the Genesis signal properly.
So, both higan and ares generate their own palette based on hardware voltages (I’m pretty sure they are from lidnariq’s numbers). Anyway, I think what I’m looking at is finding out first if the emulator is not incorporating the hue and luma skews into its calculations. I think there is good reason for the emulator (and others with similar approach) to handle this. Then, I can make presets according to who uses the raw palette and who does not. So, basically, I’m trying to cover all of the scenarios that I can. I don’t want to neglect Nestopia or Mesen users when my daily driver is ares. I want to be fair to most of the commonly used active emulators.
I know postgammaunlimited mode (applied through grade) is a bit unusual for RetroArch shaders, but it works really well with koko-aio. I can reach a point of physiological nostalgia with how well the LUT and koko-aio work together. Adding the proper NTSC effects just further solidifies that feeling.
I opened up a topic under “Other Retro Dev”. It should appear once it has been approved. I’m hoping it will be beneficial to everyone in getting the puzzle completed.
Lastly, I’m hanging onto the “color initial offset” for Genesis. I want to get my preset pack out, and I can worry about corrections later. With the color initial offset in place, the lowpassWindowStdBaseSize came out to 0.525, and the lowpassSincStdBase Rate was 0.800. That’s where my unorthodox, nostalgia-guiding approach took me. I believe chroma bandwidth is normally 1.5 MHz. So, I’m not sure if those variable values align well with the bandwidth or not.
@kev4cards The problem I have found with Mega Drive is that if you ask five different people what it should look like you will get five different answers. Going by the schematic was the only reasonable choice I could make for it. I generally follow schematics for all the presets to the best I can find them. Most other consoles are more consistent.
The Famicom voltage outputs are fundamentally different from later consoles that output RGB and then convert to composite in the analog domain. The Famicom outputs direct composite voltages digitally. If the emulator wants to hold to the ‘output voltage directly’ ideal than it would have to output the dot clock pattern directly, not just the 256x240 framebuffer they do now.
Scanline Classic reconstructs the analog composite signal by first reconstructing the dot clock signal and then applying the appropriate cosine functions to chroma part of the signal. For Famicom/NES I would do the same thing but map chroma to a digital pulse pattern instead of multiplying chroma by a cosine. This is why there are no NES/Famicom presets yet (in fact there’s nothing earlier than the PC Engine yet).
I understand that the Mega Drive does fluctuate quite a bit due to wiring problems with the luma notch and the series of encoder changes from revision to revision, model to model. With that said, as I stated in Looking to combine an NTSC shader with koko-aio and a LUT, there does seem to be something else on for the shader to not be able to recreate the output seen in the YouTube video. I’m not sure if that is a bug in the shader or the schematic is incorrect or what. The only thing that appeared off to me was the pixel clock parameter within the gen.slangp preset is actually the master clock for the Genesis. I assume that’s intentional as the other preset files appear to follow that pattern, but I don’t know how you then adjust for the actual changing pixel clock based upon when H32 or H40 mode is used.
For Famicom, I realize I was thinking about it incorrectly. However, higan and its successor ares render at the pixel-level with cycle accuracy. So, with their lack of support for .pal files, I was seeking a way to apply the NTSC effects on top of the palettes those two emulators already produce natively. I like to accommodate emulators that lack .pal support as well as have presets for those that do.
Lastly, there is a topic over at NesDev to garner some more details from the folks over there who are well practiced in the space of signals: https://forums.nesdev.org/viewtopic.php?t=26521 . I hope that can become useful for technical information surrounding NTSC signals (and possibly PAL if discussion heads that way).
Fuzzy math is used. The Mega Drive uses a variable pixel clock, but thankfully the visible area portion of the screen (including borders) uses a fixed pixel clock, so the variable aspects can be ignored. The shader uses a function that goes through a number of steps to derive precise timing values, including the number of effective pixels per active line. This comes out to 420 for H40 mode. I forget what the number is for H32 but it’s exactly the same as the hardware.
You can find all the code for this in modulation.inc.
