Any ideas why the full_palette demo doesn't look the same on composite/RF as it does with NESRGB + XRGB-mini?
full_palette:
https://wiki.nesdev.com/w/index.php/Full_palette_demoNESRGB:
https://etim.net.au/nesrgb/Has anyone tried this with Analogue Nt, or Nt mini?
Anything to do with how the Framemeister handles the RGB input?
NESRGB (and HDNES) doesn't implement the PPU's "direct color control mode", because its utility is more-or-less exclusively things like the full (and/or flowing) palette demo.
What? That's a pretty serious omission!
I don't get why hardware makers insist on doing things differently from the original hardware based on what existing (and usually commercial) software does or doesn't do... That's a bummer for developers that are experimenting with new techniques that are perfectly valid on the original hardware but can't be safely used anymore as the number of users of incompatible systems grows.
Because to support it you suddenly have a situation in which the color you're supposed to emit no longer corresponds to the value on the EXT pins (nor current pixel location). You basically have to completely reimplement the same logic that's inside the 2C02 in order to emulate it.
It's not really that serious of an omission. There are many more instances of the feature causing a smear of colors during raster effects than people actually being able to use it ... and you're never really going to get something more useful than the flowing palette demo by using it.
lidnariq wrote:
NESRGB (and HDNES) doesn't implement the PPU's "direct color control mode"
I think I remember hearing way back when that Hi-Def NES supports it, do you have a source that states otherwise?
I think the reason it wasn't in NESRGB was lack of space in the logic IC(s) used.
I was wrong:
viewtopic.php?p=194287#p194287 I thought I remembered that being mentioned, but since the HDNES interposes the
entire CPU and PPU buses the emulation of direct color mode is easier.
Thanks everyone, that's interesting. If it was to preserve image quality I can understand, but I would have liked another switch on the board to allow you to toggle between this sharp mode and a compatibility mode that does support direct color mode.
I got the NESRGB because of the claim that it basically used the PPU as-is and didn't sacrifice compatibility.
To be fair it does clearly state "The NESRGB board effectively bypasses parts of the PPU - Palette RAM (Color Generator), Decoder, and DAC. These functions are duplicated in the NESRGB board with a focus on video quality."
Anyway I am very interested to know if it does work on HiDef NES, Analogue Nt, and Nt mini...
I mean, to be fair, it does use the PPU as is, and it doesn't really sacrifice compatibility because it's basically impossible to use the full/flowing palette mode while doing anything else at all. It's worse than Atari 2600 or ZX80 or the Galaksija. (Not only is the CPU unable to do anything else, but the PPU can't help, and it's not an integer number of CPU cycles per scanline so you can't get clean vertical lines)
Failing to correctly display these demos that explicitly try to use it is basically going to be the only problem, and in exchange you don't get glitchy-looking color rainbows in Wizards and Warriors 3 (and some other games that do do mid-screen palette changes)
Not everything that uses direct color mode works under absolute CPU x PPU synchronization hogging the CPU 99.99% of the time. I once used it in an experimental FMV player to letterbox video that didn't necessarily use black anywhere in the palettes, so one of the normally unused background colors was used to hold the border color instead. I don't remember much from that project, but that solution worked better than changing/restoring color 0, in that specific situation.
Getting rid of rainbows in a few games sounds nice at first, just like increasing the sprites per scanline limit does, until something that relies on the original behavior shows up and ends up looking weird. As far as we know, direct color was never used in actual games, so it really is tempting to leave it out, but it's a cool feature of the original system, with the potential to create really interesting effects, as seen in the flowing palette demo. But omitting that feature in new hardware discourages programmers from ever using it, because they don't want customers complaining that their games are glitchy. So yeah, even though it looks like something minor, I consider this omission crippling and think that it sets a bad precedent for other obscure features that are rarely/never used.
I'm probably getting old and grumpy.
That is basically my thoughts on it, and maintain that a toggle switch would have been nice.
I'm still very happy with my NESRGB at any rate and would not ask my money back just over this.
I would love to see that FMV experiment, or basically anything that tries to break the color barrier! I love things that push hardware past conceived limits.