new GFX card

That's possible as well. Layers would already share the same patterns. It's just that sprites got their own pattern memory. The reason for that is to parallelize processing of maps and sprites by giving each their own memory block. The sprite engine can then both read the attribute table and set up the pattern memory address while the map engine does the same. Basically allowing them two to work in parallel. The 'mixer' engine then produces the pixel output.

However, increasing the RAM size exponentially increases cost/resource of the FPGA. 256KB = 2048mbit blockram, that's gonna be a hefty FPGA. I doubt you will need 4096 8x8 patterns (256KB) simulataniously. Nothing stops you from loading a new tileset for the next level into the VDP. Not needed to have so many patterns sitting in VRAM.

As for updating patterns in-game I assume you refer to setting/modifying the nametable. Since the VRAM in my design-to-be is directly mapped into CPU address space, you can move 1.5KB using LDIR etc to update the screen for one layer in one go. 768x2 = 1536 bytes. Nametable updates will be as fast as the Z80 can update it. There will not be any access delay for this VDP.

...alpha blending... rotatating sprites... rotating layers... at least enough tiles for one screen per layer...
scaling... window masking... various sprite sizes... mirror... priority... scroll list (horizontal and vertical)...
lots of vram... (very fast) transfer commands...

If you go and design a chip then make it count. No hi-res crap, no insane amount of colors, just the things you need too make kick ass action game even on the poor z80 .

Different people different needs... anyway, I think the gfx9000 is fun enough for now.

Though a few additional things would have been nice, like:

- mirror bits in sprites (2 unused bits?)
- mirror bits or pallette select in tiles (I haven't decided yet wich one I prefer more)
- priority in tiles
(8159 tiles seems a bit overkill to me so lets make that 2048 so we can fit the prio and mir bits)

But I guess we are entering an age we design a video chip for a game istead of a game for a video chip.

Question is.. is the MSX community wanting to embrace an upgraded video system whose halmarks are simple, fast, yet powerful? Assuming it would be available for a < $50 price.

Question is.. is the MSX community wanting to embrace an upgraded video system whose halmarks are simple, fast, yet powerful? Assuming it would be available for a < $50 price.
For me even with features like the V5Z80P project it's a perfect choice, i would add only X-Y sprite flipping

Having checked a quick reference of V9990's pattern mode screens, it's safe to say that my proposed specs by far exceed that of V9990, provided I increase the pattern buffer.

Gotta keep in mind though that on V9990 both pattern and sprite patterns are shared. In my design these would be separate memories.

                  V9990(P1)     VDPX
Res:	         256x212       256x212
Map Patterns:     8160          2048 (8x8)
Sprite Patterns:  ^shared       256 (16x16)
Sprites:	         125/16scan    128
Map Layers:       2(ScA/B)      4 (or even 8)
Map Size:         64x64         User defined
Pattern Colors:   16/32         256
Sprite Colors:    16/48         256
Palette:          4x32K         16.7M

That's as far as pattern mode goes though. VRAM commands and additional modes are to be defined. My first goal would be to implement this screenmode, using a total of 256KB video memory. If we were to double VRAM to 512KB, we'd end up with 4096 256-color patterns and 512 256-color sprites.
No excotic trickery with palette bits in registers to somewhat create more than 16 colors on-screen, but straight forward 256-color patterns/sprites and one master palette.

I think this could have merit