new GFX card

I think it will be fun to design a heavily beefed up VDP that would work for an MSX.

That will be fun indeed

But:

Only 512x 8x8 pixel 256 color map patterns?
Only 64x 16x16 256 color sprite patterns?

And what about transparency, scaling, rotating and screensplits?

MSX has a pretty slow CPU, so the VDP has to do a lot itself. It would be fun if it was also possible to implement some math instructions like multiply and such in fpga.

Anyway, I’ll discuss with ghostguy what we are missing in the gfx9000 and see if we can come up with a nice wish list

Yes, "Only". Transparancy keys ofcourse supported (color 0). The reason for this is simplicity. After all, it is an MSX computer with a 3.54MHz Z80 CPU. The CPU <> VDP interface therefore has to be simple and manageable. If you want a 3D accelerated 1920x1200 display adapter, go buy a PC if you know what I mean. The VDP-to-be-designed has to be in spirit of MSX.

Splitscreen is not needed any more due to use of layers which implement independancy. Example, score bar drawon on Layer 0, doesn't scroll. Map drawn on layer 1, scrolls. Z order set to have layer 0 be on top. Sprites hiding behind walls, buildings etc (clipped) simply done in hardware by setting appropriate Zorder for each pattern in the name table. Each element is 16 bits, 9 bits for the pattern (512 combinations) 4 bits Z order, 3 unused which could be used to increase the number of patterns.

What is it that you really want in the world of MSX? Full color sprites. Softscroll. Multilayer screens. (Take SD snatcher, the frame around the playfield. That would be one layer. The map a layer below it)

Resolutions at most 512x384, that's plenty. Since I would make use of the Xilinx 2-port block RAM system, such VDP could be made very fast as blocks can be organized in a parallel fashion for simultanious sprite, pattern and map processing. The memory would present to the CPU as a 16KB page mapped lineair 128KB or 256KB of memory for direct access (simplicity). Add in a bitblitter to scroll the pattern name table, although as I described the virtual map system, this is not even needed anymore as the map will be circular in both H and V directions. You only need to write new tile rows and columns in the direction(s) you're scrolling to.

The programming model would be pretty much similar to MSX1's VDP Graphic 3 mode, only this time with 256 color capability. Ofcourse the pattern table could be made even 1024 unique patterns or 2048. But again, how often do you make a pattern based screen where every element in the nametable is unique (32x24 = 768) 768 unique tiles? The point of a pattern table is compression and speed. Repeatable patterns just defined with an index. Similarly, 512 8x8 patterns equals 32KB. If you define multiple tilesets, the amount of memory racks up quickly.

Basically, simplicity (familiar programming model, direct VRAM access), appeal (256 color pattern / sprites, 16M palette), speed (pattern based, sprites) are the keypoints. If you know what I'm sayin

Trebmint's crossplatform suggestion is actually the thing to do.

In addition: The number of map and sprite patterns could 'easily' be increased up to 1024 map patterns (64KB) and 256 16x16 sprite patterns (another 64KB). But as you can see, the memory usage increases a lot. And the question is there.. how many unique sprite patterns you'll use anyways?

wolf_: AGREED.

In addition: The number of map and sprite patterns could 'easily' be increased up to 1024 map patterns (64KB) and 256 16x16 sprite patterns (another 64KB). But as you can see, the memory usage increases a lot. And the question is there.. how many unique sprite patterns you'll use anyways?
Would it be possible to have let's say 256KB pattern RAM and have all the layers share those patterns? If that is impossible: I do not care that much about memory usage anyway. I care more about the time it takes to update the patterns in-game.