The logic behind NTSC distortion and graphic limits

Hello.

I'm working on a project I have for the SegaCD videogame console, named "Alphaomega". It's about the character Miles "Tails" Prower being caught inside a graphical, artificial dimension and what has to do in order to go back to real world. The gameplay and level map style is meant to be similar as the old 16-bit Sonic the hedgehog games, but it has a bunch of ideas and concepts that doesn't fit to a Sonic the Hedgehog game, so Sonic isn't present for this game

I'm doing some drafts for a new level I'll get started with really soon, which for now I named as "Bitfield Zone". The goal here is to keep it, somehow, with a NES vibe to it.
Of course the Sega Genesis' video chip couldn't apply any post-processing effects to the final image (other than scanline-specific tweaks), but the least I can do is to implement this new art in such a way that looks visually accurate on screen, not only taking the color limts into account (which I need to be aware of yet!), but I'd also like to represent stuff such as a fake sprite limit, the color distortion (i.e. when some shading seem to appear like diagonal bar), etc.

What do I need to know?
Thank you!
EDIT: Grammar/Redaction

I think that NTSC artifacts would be difficult to simulate accurately, considering that the Genesis VDP has its own set of peculiarities that affect the video it generates.

But you could certainly make the video more similar to that of the NES by using the 256-pixel video mode, instead of the 320-pixel one. Use only 1 background layer, and try to approximate the colors that are available in the NES palette. You can even have real sprite flickering, if you place dummy high-priority sprites across the whole height of the screen to reduce the number of sprites you can actually use on each scanline.

The Genesis VDP can show 16 sprites and 32 slivers per line in 256 pixel mode or 20 sprites and 40 slivers per line in 320 pixel mode. The NES can show only 8 sprites and 8 slivers. So I'd guess the sprite limits can be simulated by putting six high-priority 32x32 pixel transparent sprites on each line with more than 8 sprites in order to eat up 24 of the 32 slivers, though that would also eat up most of your OAM. (The sprite display list in Genesis 256px mode has only 64 entries, as on the Master System and NES.)

But you probably won't be able to pull off a convincing diagonal bar distortion on a Genesis VDP. Its color burst lines up vertically, not diagonally, like the Master System screenshot at ccovell's page. Both a Genesis VDP in 256px mode and the NES/SNES PPU use the TMS9918 pixel rate of three pixels per two color burst periods. But the Genesis VDP keeps the 342 pixels per line of the TMS9918, compared to 341 for the Nintendo parts.

SG-1000, CreatiVision, ColecoVision, Master System, Genesis:
342 pixels per line * 2/3 color burst periods per pixel = 228 color burst periods per line
Because this is an integer, color artifacts line up directly below each other.

NES, Super NES:
341 pixels per line * 2/3 color burst periods per pixel = 227.33 color burst periods per line
Because this is not an integer, color artifacts line up diagonally.

Standard TV, by contrast, has 227.5 color burst periods per line, which produces an even checkerboard. If the NES or Super NES PPU added an extra master clock (1/4 pixel) to each line's horizontal blanking, it would produce a standard scanline period and thus artifacts closer to those of standard TV.

Great. Also just checked, and from FCEUX' PPU viewer it seems like each of "tiles/cells" could use any of the 8 palettes out there, worth 4 colors each.
I THINK I can "purposely" make the sprites to blink here through software (in case a virtual sprite limit is reached), and I THINK I can achieve NTSC distortion by animating the necessary tiles according to the plane/sprite's vertical position and to each pair/unpair "frame number".
Is there any available NES color chart out there?
And finally, what's the maximum sprite size? (leaving alone the obvious possibility of mapping them)

Same as the Master System: sprites are either 8x8 or 8x16, globally (it's not a per-sprite setting).

The background uses only the first four palettes, and the sprites use only the last four. Background palettes are assigned not to 8x8 pixel areas but to 16x16 pixel areas (2 cells by 2 cells).



Why you won't see Fifty Shades of Grey on the NES


All single sprites in a scene are 8x8 or 8x16.

Thank you so much!
I'll update this post once I get a part of this level added and working within game.


XD. This made my day.

Sprite list has always 128 entries, just that only first 64 (or 80) sprites are parsed before cycles run out on that line (order only determined by the 7bit link value in sprite definition).

So there are more entries than the VDP can parse per scanline, and you choose which ones will be parsed by creating a linked list? Interesting... I can't see much benefit in having sprite entries that won't be used though...

I guess it allows static allocation of display list entries to particular actor slots even if different frames of animation take more or fewer sprites. This frees the CPU from having to rerun the allocation every frame the way it is done on the NES.

Er no, only 80 entries, the VDP explicitly cuts the list the moment you try to use entries 80~127 (don't forget that those entries don't have room in the sprite cache). Also apparently it cuts sprites after 63 in H32 mode (though 64~79 are still usable if they were cached before... albeit it wasn't stable if I recall correctly).

I don't recall link values higher than 79 or 63 cutting out the rendering...

EDIT: Just did a quick test. Sprite at 0 and one at 127, and both display... buuuuut there's a peculiarity. The second sprite doesn't seem to have the Y coord I supplied on the hardware (it is positioned correctly in the emulator), rest is correct though.
EDIT2: Sprites from 80 to 127 seem to fix the Y coord at my first sprites one.
EDIT3: I added a second sprite, aaaaand the sprites in 80 to 127 are totally messed up in vertical direction. I can make out the GFX as it flickers line by line between the two normal sprites. How fun.
EDIT4: Any sprites coming back from 80...127 to the 0...79 range will not be rendered it seems.
So I will have to eat my words. Stay away from 80...127 and stick some GFX into those bytes instead !

http://www.tmeeco.eu/BitShit/SpriteFunTest.jpg

OK so in other words the VDP just sees high impedance from the sprite cache and whether something works or not (and how) depends entirely on whatever noise it happened to read. ¯\(º_o)/¯

Well, the warning stands, I guess.

Rather there is something weird going on in the sprite evaluation circuit, the line buffer does store stuff properly, but where exactly the GFX ends up is all barfed.