Look at this :
http://kagutech.com/Resume-CV.htm

and search for "Sprite"

cool

He´s THE GOD! (along six others)

...except that he could have allowed for 8 sprites on a scan line...

Quote:

...except that he could have allowed for 8 sprites on a scan line...

and nice x-y scroll registers .... with scan line ints

... and a programmable palette ...

and more colors per blocks of 8 pixels....

Actually, a blocks of 8 pixels can have a given configuration of colors
in at least two different ways by switching background and foreground
and inverting the pattern shape.
This means that there is at least one bit (more that one bit actually) per
block of 8 pixels that is totally wasted.

In other words:
a block of 8 pixels is coded by two bytes (one for color, one for shape)
but can assume only 105*256 = 26880 different values:
as two bytes give 65536 different values, the encoding of tms9918 is inefficient.

You can get 26880 different values in 14,7 bits, of better,
spend 16 bits to give 65536 different values to the 8 pixel block

OK, Now i think it's time to stop otherwise we reach soon at the v9990.

Well, my point is that, without adding vram, the very same 16K of the tms9918 could have been used better.

Two bytes per 8 pixels gives exactly 4 independent colors per pixel (bitmap mode).

I can imagine one thousand ways to get better color attributes and have 256x192 screens in 16KVRAM

But then the TI99/4a would not have existed: It used the VRAM to store programdata. And if it would not have existed, I would not have gotten an MSX2 computer eventually. And that would have been a shame.

Quote:

Two bytes per 8 pixels gives exactly 4 independent colors per pixel (bitmap mode).

But that leads to a "Amstrad mode 1" like gfx, with only 4 colors it could look really ugly. Having a palette, like in the Amstrad, you can at least choose the appropiate colors; but even given that, I prefer less resolution and more colors.
Maybe using "Hold And Modify" Amiga tricks?, the first pixel uses n pixels to define a color and the following pixels use only a few (only one? ) bits to codify the color difference with the previous one.
Oh, well, just some basic palettized colors could have made me happy...

Quote:

Well, my point is that, without adding vram, the very same 16K of the tms9918 could have been used better. Two bytes per 8 pixels gives exactly 4 independent colors per pixel (bitmap mode). I can imagine one thousand ways to get better color attributes and have 256x192 screens in 16KVRAM

I must agree with you ARTRAG, and unfortunately this is not the unique point where things could have been done better with some or no effort.
The vdp is inefficient in a lot of situations:
For example take into consideration sprites and compare with c64 sprite subsystem. To see 4 of 32 sprites the VDP must at least do:

1 byte read x 32 sprites, to know the sprites the vdp can display (read y )
3 x 4 bytes read to read additional sat data for the 4 sprites is capable of display
2 x 4 bytes to read sprites pattern data

total of 32+12+8=52 bytes/scanline at least


on the c64 the sat is entirely in static register data, 1 and 2 could be avoided only pattern data need ram reads, so
for the 8 sprites is capable of display the vic-ii must read 3 bytes (sprite are 24 pixels wide)
giving 8 x 3 = 24 ram reads/scanline


With less than the vram reads you get larger and more sprites on scanline....

With 2 bit per pixels you need HAM like tricks for coding color images
but the result is usually better than we we have now.

two bits are a number that ranges in -1,0,1,2

Assume a palettes of 32 colors (programmable)
The index of the color of the current pixel is the sum of the index of the adjacent pixel + the value of the index of the current one

You can have any sequence of colors in any 32 pixels sequence,
the limit is that you could need to duplicate the same color in the programmable palette
when you need to vary the sequences of colors at variable distances in the image

Here's a transcript from a TI conference with Karl Guttag.

groups.google.com/group/comp.sys.ti/msg/73e2451bcae4d91a