Jump to content
IGNORED

TMS9918 rant


Bruce Tomlin

Recommended Posts

I've been tinkering around with doing some CV code lately, and it's really amazing how the TMS9918 managed to miss getting things right.

 

The main problem is one word: COLOR

 

Okay, you've got four graphics modes. Mode 1 is 40-column text, and is pretty useless unless you want to write It's Only Rock And Roll II.

 

Mode 2 is equivalent to Apple II low-res graphics. Great if you want to look like a pong system. Pretty useless for "real" games, especially since you can't mix modes like on the 400/800/5200 or the 7800, so scores have to be done using these graphical Duplo blocks.

 

Mode 0 is the default. 8x8 character cells, two colors per cell. Long after the rise and fall of the NES, two-color character cells can be unbelievably bland looking.

 

Mode 3 is the only thing left. You can rig it up to be a full bitmap mode by assigning each cell to a different pattern table entry. This takes up over 12K of the 16K. And you have to write eight times as much data. But each 8-pixel horizontal slice still gets only... two colors.

 

Sprites aren't any better. You only get ONE color for a sprite (the other color is always "transparent"). Sure, you can overlay them for multiple colors, but guess what? You're only allowed to put four sprites on any one scan line!

 

And for the icing on the cake, the colors come from a fixed palette! That's right, you only get one gray (light), and no brown! (one of the yellows is sort of brownish, but it's a sandy brown, not a woody brown)

 

Bland? You bet. I fired up Elevator Action in an MSX emulator and was stunned to see just how much detail had to be sacrificed to wedge it into the TMS9918 on the MSX1.

 

 

Nintendo got it right. The standard mode (as I understand it) is like Mode 0 from the TMS9918, except you get four colors per cell. Sprites, too. You can do a LOT with four colors per character cell. And there's a proper palette to choose from, like on the Atari 2600. And they added scrolling registers. The MSX version of Mappy scrolls like a bad joke.

 

At least it's a lot easier to get a basic screen going than on the 7800. And it's Z-80 code, which is much easier for me to write.

 

So anyhow, this little project that I'm working on, I went ahead and used Mode 3 (making use of being able to choose which two colors you get on each scan line), and I went ahead and stacked sprites to get one of 3 colors. I'm amazed that I was able to get it to look as good as it does with all the limitations of the 9918.

Link to comment
Share on other sites

  • 3 weeks later...
  • 6 months later...
Mode 3 is the only thing left. You can rig it up to be a full bitmap mode by assigning each cell to a different pattern table entry. This takes up over 12K of the 16K. And you have to write eight times as much data. But each 8-pixel horizontal slice still gets only... two colors.

 

How much of those 12K can be written in a single frame?

Link to comment
Share on other sites

Mode 3 is the only thing left. You can rig it up to be a full bitmap mode by assigning each cell to a different pattern table entry. This takes up over 12K of the 16K. And you have to write eight times as much data. But each 8-pixel horizontal slice still gets only... two colors.

 

How much of those 12K can be written in a single frame?

 

If I remember correctly, something around 6KB.

Link to comment
Share on other sites

Of course you can only get the maximum speed if you start with a vertical blank and know how long it lasts. The delays in VDP data write code are to handle the worst case, which is while the chip is currently displaying data. You could probably do an OTIR instruction during vertical blank. But you do have to know what you're doing, because the VDP will simply ignore the data if you feed it too fast.

 

And that link was referring to scrolling speeds. As long as you only want to scroll one of the three 8-line areas, you just need to rewrite the name table and keep track of which line is which for later updates. For the full screen you would have to copy over two lines of pattern data, preferably with the whole screen cached in local memory, of which the Coleco doesn't have anywhere near enough for this.

Edited by Bruce Tomlin
Link to comment
Share on other sites

  • 1 month later...

Wonder what TI had in mind? Wonder why the part no. starts with TMS-99? Well... I suppose what TI had in mind was what the chip was first used for... the TI-99 home computer, which happened to be the first computer I had. And that one already was developed in the late 70's. And it was supposed to be a home computer, not a game machine, yet TI put out some pretty good games for it. Atarisoft did, as well - they only weren't good at doing music. It also had the same sound chip as the Coleco (and many arcade games of that era, for that matter), only running at a slightly slower clock rate.

OK, so the graphical results weren't that good, but many home computers of that era were far worse off... having no sprites at all. So you could say that the TI chip catered more for gaming applications than other chips of that era.

I think the only other home computer out in that era who had something resembling sprites were the Atari 400/800, which had player/missile graphics. But those were also monochrome and basically only 8 pixels wide. And you also only had 4 of them per scanline. But what's worse, the Atari couldn't manage more than 4 sprites by itself... you had to rewrite the sprite locations on specific raster lines to get more independent sprites... the TMS9918 does that for you, for up to 32 sprites. Not even the C-64 has that many sprites. OK, you get 8, and those are bigger and multicolored if you want. And you can display all of them in one scanline. But to get more than 8, you have to do the same like on the Atari's...

Background graphics wise, it's hard to judge who leads. OK, you do have a 4 color mode on the Atari 400/800. And you get to chose those 4 colors out of a huge pallette of available colors. But if you do hi-res graphics, those 4 colors are the same for the whole screen! (OK, you can change those too per scanline by clever programming, of course)

 

If you compare it to other video game consoles of that era... there's none with multicolored sprites, except for the NES, but here in Austria, the NES wasn't released until 1987, that's 4 years after the Colecovision. So the Coleco's competitors at that time were the Atari 2600, the Intellivision and the Magnavox G7000 and (in Europe) G7400 / Odyssey^2 (in the USA). And those consoles all don't allow for multicolored sprites. The Atari 2600 does have a huge pallette, but only 4 color registers shared by the various objects. The G7000 can display many freely moveable characters on screen, but all of them are only 8x8 pixels, and only 4 of them are freely definable. The Intellivision is best off, even having scroll registers, but its background graphics only have half the resolution of the Coleco's, and it also works with a fixed 16-color pallette (as far as I know).

 

Below I've created an example of what you can do on a TMS9918 in bitmap mode, with clever color mixing.

 

post-8393-1156101305_thumb.jpg

Edited by Kurt_Woloch
Link to comment
Share on other sites

OK, so the graphical results weren't that good, but many home computers of that era were far worse off... having no sprites at all. So you could say that the TI chip catered more for gaming applications than other chips of that era.

I think it is significant that both the MSX and the SMS/Genesis were derived from the TMS9918. But I still think TI should have put in some palette registers.

Link to comment
Share on other sites

OK, so the graphical results weren't that good, but many home computers of that era were far worse off... having no sprites at all. So you could say that the TI chip catered more for gaming applications than other chips of that era.

I think it is significant that both the MSX and the SMS/Genesis were derived from the TMS9918. But I still think TI should have put in some palette registers.

 

Should have.. should have... but they didn't. In fact, back then no computer or video game did have 16 color registers to choose out of a palette (at least no affordable one!). There basically were two approaches to the color problem: 1. a bigger, fixed palette or 2. an even bigger palette with color registers selecting from it.

The C-64, the Intellivision, the Odyssey^2, the TMS9918 (whichever machine it was used in), the VIC-20 and the ZX-Spectrum all followed approach 1, and mostly had 16 colors available, which lets you store foreground and background colors of a character in one byte - and they typically have character modes where you can choose foreground and background colors for each tile (character) (except for the Odyssey^2 which doesn't have fixed tiles, only a grid for background graphics).

The Atari 2600, the Atari 400/800 and the Bally Professional Arcade followed approach 2. The 2600 has 4 color registers and a pallette of 128 colors, the Atari 400 has 9 out of 256, and the Bally (I think) 4 out of 128 (or was it 256?). No machine of that era hat 16 color registers! The first machine that had 16 or more color REGISTERS was the NES with 25 colors (13 for background tiles, 12 for sprites) out of 64 (+ Tricks), and the first home computer I know of having 16 color registers was the Atari ST. This was topped by the Amiga having 32 out of 4096 (+ HalfBrite + HAM modes for more), interestingly improving on the Atari 8-bit's graphical architecture (which was in turn improving on the Atari 2600's architecture). Before that came the Atari 7800, but as far as I know, it also has only 13 color registers (to choose out of 4 4-color palettes sharing the same background color).

 

Arcade machines are a different story, of course. The Pac Man machine, for instance, uses a far more complicated scheme than all of the computers or consoles of its era (the single color value of a character or sprite selects one of many 4-color sets, with each of the 4 colors of the set pointing to a 32-entry lookup table defining colors out of the "actual" 256-color palette - OK, maybe the NES comes close, but not quite), with subsequent arcade machines following similar schemes, only improving on the number of colors in a palette, the number of colors actually possible for each pointing layer and the number and size of layers and sprites displayed.

Edited by Kurt_Woloch
Link to comment
Share on other sites

Before that came the Atari 7800, but as far as I know, it also has only 13 color registers (to choose out of 4 4-color palettes sharing the same background color).

You actually have 8 palletes of 3 colors + background giving 25 colors. DLI's are also possible to get more colors on other rows just like the 8-bit computers.

You can display as many as 12 colors + background (or transparent) in a tile/object

Link to comment
Share on other sites

The first machine that had 16 or more color REGISTERS was the NES with 25 colors (13 for background tiles, 12 for sprites) out of 64 (+ Tricks), and the first home computer I know of having 16 color registers was the Atari ST.

 

The PCjr and Tandy 1000 series had 16 color registers. The machines only had 16 output colors anyway, so they didn't increase the number of colors that could be displayed, but the palette registers were nonetheless useful for palette-cycling animations and other such tricks. Would have been even cooler if the machines had used two 16x4 RAMs and a multiplexor cued to the 14MHz clock. That would have allowed for 256 colors, though what exact colors would be produced might be hard to predict.

 

Actually, come to think of it, didn't the TI 99/4A have than 16 foreground color registers and 16 background color registers in its default display mode? Unfortunately, the mapping of on-screen characters to those color registers was done using the 4 MSB's of the character data, which made things rather nuisancesome to say the least.

 

On a related note, is there some reason a 4-bit latch and a 16-byte ROM was cheaper than an 8-bit latch? The SID chip in the Commodore 64 used four bits to specify attack, decay, and release; the values written were fed into lookup tables, the output of which drove the envelope generator. I wonder why they didn't just use 8-bit latches?

Edited by supercat
Link to comment
Share on other sites

Actually, come to think of it, didn't the TI 99/4A have than 16 foreground color registers and 16 background color registers in its default display mode? Unfortunately, the mapping of on-screen characters to those color registers was done using the 4 MSB's of the character data, which made things rather nuisancesome to say the least.

The TMS9918A only had 15 fixed colors. Period. (the 16th "color" was "transparent") That's what this whole thread is about.

Link to comment
Share on other sites

Actually, come to think of it, didn't the TI 99/4A have than 16 foreground color registers and 16 background color registers in its default display mode? Unfortunately, the mapping of on-screen characters to those color registers was done using the 4 MSB's of the character data, which made things rather nuisancesome to say the least.

 

Technically, no. It has 8 control registers and 1 data register. Maybe what you're referring to is the color table in Mode 0 (Graphics Mode), which is located in video RAM and may start at any byte location which is dividable by 16 (256 different possible locations). But this one has 32 entries of one foreground and one background color each, setting the color for 8 consecutive character definitions. That's the 5 MSB's, not the 4 one, as far as I can see.

If that's nuisancesome depends on the type of display you want to achieve. If the objects with the same shape should all appear in the same color, you're fine off... you set the color once and don't have to manipulate it anymore if you place the same object elsewhere on screen. However, if you have objects with the same shape which should appear in different colors, you have a problem.

I think that's one way the technical engineers tried to achieve "color" on screen with the least RAM used possible, to the best result. In this case the colors are tied to the character definitions, so each set of 8 defined characters get one foreground and one background color, which gets used anywhere that character appears on screen. In contrast to that, on the C-64 (and on the Pac Man machine, for that matter), you always have to write two bytes to define one character... one for the actual character, and another for its color (or, at least one of its colors... depending on the mode you use). This, of course, gives you the flexibility to put the same characters on screen in different colors.

But the C-64's color RAM is 1000 bytes... same size as its character RAM, where as the TI chip's color table is only 32 bytes. So, at least for mode 0, they made it to implement color using only 32 additional bytes. I still like that method better than the one on the NES, which only lets you select 1 out of 4 4-color palettes (with the same background color for each) for each block of 2x2 characters (16 pixels), so that you really don't get too colorful pictures out of this.

To better understand that greed, maybe you should know that the unexpanded TI-99/4, which the chip initially was designed for, stores BASIC programs in the video RAM, since there are only 256 bytes of CPU RAM in the system. Thus, 32 bytes used for color saves you 736 bytes for your BASIC programs over the 768 bytes a full color RAM would have taken.

Link to comment
Share on other sites

and the first home computer I know of having 16 color registers was the Atari ST. This was topped by the Amiga having 32 out of 4096 (+ HalfBrite + HAM modes for more), interestingly improving on the Atari 8-bit's graphical architecture (which was in turn improving on the Atari 2600's architecture).

 

I suppose the 520ST just came out in 86, right? In this case the MSX2 came out first, in 85, with 16 color registers (out of 512), and the SMS also in 85 with 16 colors out of 64. Interestingly both are derived from the TMS9918...

 

Eduardo

Link to comment
Share on other sites

 

I suppose the 520ST just came out in 86, right? In this case the MSX2 came out first, in 85, with 16 color registers (out of 512), and the SMS also in 85 with 16 colors out of 64. Interestingly both are derived from the TMS9918...

 

Eduardo

 

I'm not entirely sure now... as far as I remember, the 520ST was already out in late 1985 here in Austria. But I could be wrong... anyway, I totally forgot about the Amstrad / Schneider CPC which definitely already came out in 1985 (or even 1984) and also had 16 color registers... but only out of a palette of 27!

Link to comment
Share on other sites

Maybe what you're referring to is the color table in Mode 0 (Graphics Mode), which is located in video RAM and may start at any byte location which is dividable by 16 (256 different possible locations). But this one has 32 entries of one foreground and one background color each, setting the color for 8 consecutive character definitions. That's the 5 MSB's, not the 4 one, as far as I can see.

 

I guess my memory was a little foggy. Does the TMS9918 fetch a byte of fg/bg color data with every character fetch, or does it cache them in 32 bytes if internal storage. If the former, it would seem strange that AFAIK it does not have a character mode that uses 768 bytes for characters and 768 bytes for colors (it does, IIRC, have a hires mode that uses 12K of display memory, but that's not as practical in many applications).

Link to comment
Share on other sites

I guess my memory was a little foggy. Does the TMS9918 fetch a byte of fg/bg color data with every character fetch, or does it cache them in 32 bytes if internal storage. If the former, it would seem strange that AFAIK it does not have a character mode that uses 768 bytes for characters and 768 bytes for colors (it does, IIRC, have a hires mode that uses 12K of display memory, but that's not as practical in many applications).

You mean 768 cells for characters and colors? 768 * 8 * 2 = 12288. That IS the 12K mode. Two bits of either the pattern or color table base register (can't remember which) are mask bits for the pattern/color address. The name table gets combined with the masked A8 and A9 of the name table index to create a 10-bit pattern/color table index. Then you just fill the name table with 0..255 three times.

Link to comment
Share on other sites

  • 1 year later...

Yeah, the lack of colors has been bugging me with my CRPG design on the TI-99/4a. I've had to use some odd combinations (magenta for cliffs, dark yellow for wood) in order to keep a pleasing mix. Still looks rather muddy in NTSC, though.

 

Fifteen colors is low, especially compared to the NES, and the lack of flexibility isn't cool either, but for the era it was produced in, this was the norm. Nobody could justify spending money on palette registers until the mid-80's. Heck, the TMS9918a at least could display all 15 at once with no restrictions in all modes except text mode. The Apple II had four, II+ had six, and the Atari 8-bit/Tandy Color Computer squeezed out four (white, black, red, blue) through color artifacting.

 

One way you can reduce the memory footprint of bit-map mode on the TMS9918a is to use address masking in the video registers to reduce the number of tables. The screen is hard-divided into three regions of 256 characters apiece (32x8), and you can reduce this to two or even one table is you want. This lets you have the color depth of bitmap but with a display more like normal graphics mode, and only for 4k. (2k for patterns, 2k for color). Yeah, you're not doing high-res line graphics, but the TMS9918a is not the best chip for that sort of work anyway.

Link to comment
Share on other sites

One way you can reduce the memory footprint of bit-map mode on the TMS9918a is to use address masking in the video registers to reduce the number of tables. The screen is hard-divided into three regions of 256 characters apiece (32x8), and you can reduce this to two or even one table is you want. This lets you have the color depth of bitmap but with a display more like normal graphics mode, and only for 4k. (2k for patterns, 2k for color). Yeah, you're not doing high-res line graphics, but the TMS9918a is not the best chip for that sort of work anyway.

Warning, some emulators do not emulate well this "two or one charset" setting for Graphic Mode 2. I had the bad surprise to notice that problem on the coleco emulator for psp I tested last year. Also, for no logical reason, this setting seems to affect sprites in some cases, not in other cases. And unfortunatly, the reccent versions of BlueMSX seems to wanting too much simulating this sprite glitch when it's not an effect that occurs all the time.

Link to comment
Share on other sites

Warning, some emulators do not emulate well this "two or one charset" setting for Graphic Mode 2. I had the bad surprise to notice that problem on the coleco emulator for psp I tested last year. Also, for no logical reason, this setting seems to affect sprites in some cases, not in other cases. And unfortunatly, the reccent versions of BlueMSX seems to wanting too much simulating this sprite glitch when it's not an effect that occurs all the time.

 

That's interesting... If you don't change the VDP registers to move the sprite tables into appropriate places, it's very possible to end up with overlap situations. A particular sore point with the TI-99/4a sprite implementation is their "auto-motion" system is dependent upon the sprite attribute tables being located in a fixed point of video memory... in order to have auto-motion in any form of graphics 2 mode you have to re-write the auto-motion routine as a user interrupt instead of relying on the ROM version.

 

Still, this sounds like a case where the video chip emulation was more simulation, I.E. designed to expect only the most common cases, rather than virtually emulate the chip's entire behavior. There's a simulator for the TI, Win994a, that works pretty well, but with my graphics 2 mode programming has had some oddball side-effects.

 

Good to know, though, that there's some pitfalls with it. I was considering the idea of doing a conversion of my CRPG to Z80 assembly so it could be potentially executed on a MSX1 system. When the TI version's finished, of course. :)

Link to comment
Share on other sites

  • 8 months later...
Yeah, the lack of colors has been bugging me with my CRPG design on the TI-99/4a. I've had to use some odd combinations (magenta for cliffs, dark yellow for wood) in order to keep a pleasing mix. Still looks rather muddy in NTSC, though.

 

Fifteen colors is low, especially compared to the NES, and the lack of flexibility isn't cool either, but for the era it was produced in, this was the norm. Nobody could justify spending money on palette registers until the mid-80's. Heck, the TMS9918a at least could display all 15 at once with no restrictions in all modes except text mode. The Apple II had four, II+ had six, and the Atari 8-bit/Tandy Color Computer squeezed out four (white, black, red, blue) through color artifacting.

The standard modes of those computers support that many colors. There were ways of getting more. Look at DragonFire on the coco. The coco normally had two 4 color palettes and you could swap them on the fly. Artifacting produced more on the CoCo and the Apple II+. Check out many of the graphic adventures such as Sands of Egypt on the CoCo.

Actually, artifacting could be used on a lot of different machines including the Atari.

 

BTW, the TI chip should also be able to do some artifacting.

Edited by JamesD
Link to comment
Share on other sites

Good to know, though, that there's some pitfalls with it. I was considering the idea of doing a conversion of my CRPG to Z80 assembly so it could be potentially executed on a MSX1 system. When the TI version's finished, of course. :)

How is your project CRPG? Any good development for this project after all these months?

Link to comment
Share on other sites

  • 1 month later...
How is your project CRPG? Any good development for this project after all these months?

 

Going slow... got a new great job that's keeping me busy, and been doing a lot of online gaming with my brother and sis-in-law, so I have been a bit off task. :cool:

 

My present plan is to have the skeletal combat engine (rich features disabled, basic combat flow) written up in a stand-alone framework by year's end, so that I can start filling it out and figuring out how much I can do in the limited memory area. I won't deny one fear of mine that's kept me from progressing is running out of RAM and having to make serious cuts or do something drastic, like page in code from disk. (Not fun, horrible to maintain due to static addressing issues, and a logistical mess.)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...