how do you figure 2) ?
You'd have the normal tile and then another byte for the overlay pattern and another nibble for the color. That whole lot would take 4 bytes per line then. Sc5 is 4 bytes per line..
So you could as well have a color per pixel at the same cost ^_^
Umh, even a 128x192x4bit pixels take 12KB as the ungly screen 2
how about having 2 bitplanes - 2x screen 2 in overlay ? With the option of having sprites in front of or in between the two planes? (Like a poor man's V9990 P1 mode)
wolf, think this:
due to the fact that that the same line of 8 pixels in screen 2 has two possible
representations, there is at least 1 bit each 8 pixels that is wasted.
How use it ?
If you just assume that the first color nibble has to be lower than the second
Any violation can be used as a flag
If not, you can, e.g., take the colors of the line from a different palette
Very nice in theory, but I highly doubt the TMS could cope with that with its current performance power, and there *are* situations in which foreground and background colors really could have a meaning to a game, tho this is prolly rare.
I would like to have 4 colors per character. Instead of using 6KB for 1bpp characters and 6KB for color assignment as in screen 2, simply use all 12KB for 2bpp characters. Splitting the screen up into three character sets could be optional as well, so really just 4KB for 256 characters. Then it needs a palette, with at least 4*4 colors for the background (like the NES) and the first 64 characters in the set could use the first 4 colors, characters 64-127 would use colors 4-7, etc. And with more than 15 available colors the sprites wouldn't have to use the same colors as the background (see those unused bits in the color byte in the sprite attributes table)
scrolling would be nice too...
wolf, I do not think this would be so difficult to be done,
anyway
another really important feature missing in screen 2 is the
possibility to use the s.c. hybrid modes having the possibility of
relocating the tilest freely in the vram.
Actually the VRAM can hold up to 4 complete tilesets
let's say 3 tileset plus sprites and the rest
Having only one active tileset, why we cannot swap freely among
the available tilesets already in vram?
Why we cannot point the tilesets freely in vram?
This would help a lot games, for scrolling and animations.
if i am not wrong tms9918/29 has surimpose line out(Y*) it is then possible to have to vdps whose video are surimposed are even aded/mixed for more color tones
This means also twice the number of sprites...
In the msx io table the second vdp in already specified at 0x90 and 0x80 base address.
yes, this is also how VDU works
Having only one active tileset, why we cannot swap freely among
the available tilesets already in vram?
Why we cannot point the tilesets freely in vram?
This would help a lot games, for scrolling and animations.
I agree with you artrag: little things in vdp that could made a big difference.
For example also the pattern/color table: why must be fixed to 0 or 8KB the start address? Let the programmer move freely in memory to achieve tricks. If a programmer is so stupid to overlap patterns with color data is another story.
Even take into consideration that on screen 1 pattern tables are more fine grained.
