And Neogeo has NO background layer, it just supports so many huge sprites, they made background with them, so basically it can have many layers, or just one.

Weird huh?

I always knew I was color deficient in some regard, but it's nice knowing what my actual problems are.

The protanopia example's numbers look like nothing to me, it's just the background. Can't see any numbers in that picture at all...

I honestly didn't notice but now you've told me I can see it more. God, this is annoying.

Earlier I said,
"One of the most obvious problems with that is the screen resolution. It has a resolution of 320x240 square pixels."

Here is a fun fact about having NTSC standard square pixels, and the NES color palette. The NES samples it's output video signal at 42.95Mhz, and the chroma signal is a square wave that is 12 subpixels longs, and 1 NES pixel is 8 subpixels long. NTSC standard square pixels require a 6.136Mhz pixel clock, which is exactly one 7th of the NES's video signal sample rate. So all that would had to be changed was changing the number of subpixels from 8 down to 7.

Of course, this will cause relatively more dot crawl per pixel, without filtering the chroma signal.

I think I know how a system like this would exist. Use a 6.136 Mhz VDP with a 32-bit data bus. There will be 390 VDP cycles per line. The first 336 cycles in a line will be used to render 4 bg layers of 4bpp tiles. The following 48 will be used to render 48 sprites that fall on the line, and the last 6 cycles will be unused. While rendering the background, every 4 cycles are used to render 2 8x8 bg tiles for one layer. 1 cycle to fetch the bg map, 2 cycles to fetch patterns, and 1 free cycle for DMA. Then rotation/scaling would be implemented into the DMA, with the DMA fetching a 4 bit pixel every cycle during "bg layer rendering time" and writing it to vram during the free DMA access cycles.