Actions

Difference between revisions of "TMS9918"

From Sonic Retro

m
(resync with wikipedia)
Line 1: Line 1:
 
[[Image:TMS9918.jpg|frame|right|TMS9918 chip]]
 
[[Image:TMS9918.jpg|frame|right|TMS9918 chip]]
−
==General Information==
+
The '''TMS9918''' is a Video Display Controller (VDC) manuafactured by [[Texas Instruments]].
−
The [[Texas Instruments]] '''TMS9918''' videochip was used in systems like MSX, Coleco Vision, TI-99 and Sega [[SG-1000]]/[[SC-3000]]. There are several variants called TMS9918A, TMS9928A and TMS9929A, where the 'A' indicates a second version of the chip which added new features, most prominently the addition of the Graphic II mode. The non-A version was only used in the TI-99/4, the TI-99/4A and the other computers did have the A version VDP. The TMS9918A and TMS9928A output NTSC, while the TMS9929A outputs a [[PAL]] signal. The difference between the TMS9918A and TMS9928A is that the '1' version outputs [[NTSC]] composite, while the '2' versions (including TMS9929A) basically outputs a form of RGB. All these chips are usually generically referred to as TMS9918 (sometimes with an A postfix).
 
  
−
The TMS9918A got its successor in the form of the Yamaha v9938, which added bit map modes, more colorful [[sprite]]s, a vertical scroll register and a customizable [[palette]]. The v9938 in turn was succeeded by the v9958, which added some high colour modi and finally a horizontal scroll register as well. These chips were only used on the MSX 2 and MSX 2+/turboR systems, although rumor says the v9958 was also used in a generation of the Photo Play arcades. Yamaha also produced a v9990, which is considered the follow-up of the v9958 by some, but it is not backwards compatible. A graphic chip extension utilizing the v9990 exists for the MSX in the form of the 'Graphics9000' cartridge by Sunrise (http://www.msx.ch/).
+
==General information==
 +
The TMS9918 was used in systems like MSX, ColecoVision, Texas Instruments TI-99/4, Memotech MTX500/MTX512/RS128 and [[SG-1000|Sega SG-1000]]/[[SC-3000]]. Modified versions with additional display modes and registers were used in the [[Sega Master System]], [[Sega Game Gear]], and [[Sega Mega Drive]]. Note that the Genesis VDP cannot access any of the TMS9918 display modes discussed below.
 +
 
 +
There are several variants called TMS9918A, TMS9928A and TMS9929A, where the 'A' indicates a second version of the chip which added new features, most prominently the addition of a bitmap mode (Graphic II). The non-A version was only used in the TI-99/4; the TI-99/4A and the other computers had the A version VDC. The TMS9918A and TMS9928A output a 60Hz video signal, while the TMS9929A outputs 50Hz. The difference between '1' and the '2' in 'TMS9918A' and 'TMS9928A' is that the '1' version outputs [[composite video|composite]] [[NTSC]] video, while the '2' versions (including the TMS9929A) outputs YPbPr, more precisely the Y, R-Y and B-Y colour differences (luminance and color difference signals). The need for the latter was predominant in the 50Hz world, including Europe, due to the different video signal standards [[PAL]] and [[SECAM]].  It was more cost-effective to output Y, R-Y and B-Y and encode them into PAL or SECAM in the [[RF modulator]], than to try and have a different console for every different color standard.  All of the ICs in this family are usually referred to by the TMS9918 name, sometimes with an 'A' postfix.
 +
 
 +
Texas Instruments' TMS9918A was succeeded by Yamaha's Yamaha V9938, which added additional bitmap modes, more colorful [[sprite]]s, a vertical scroll register and a customizable [[palette]]. The V9938 was used in a third-party upgrade to the TI-99/4A — the Geneve 9640 'computer-on-a-card'. The V9938, in turn, was succeeded by the Yamaha V9958, which added some additional high-colour modes and a horizontal scroll register. These chips were used in the "TIM" upgrade card for the TI-99/4A, as well as on the MSX 2 and MSX 2+/turboR systems, although rumor has it that the V9958 was also used in a generation of the Photo Play arcades. Yamaha also produced a Yamaha V9990, which is considered the follow-up of the V9958 by some, but it is not backwards compatible. A graphic chip extension utilizing the V9990 exists for the MSX in the form of the 'Graphics9000' cartridge by [http://www.msx.ch/ Sunrise].
  
 
==Interface==
 
==Interface==
−
The TMS9918 has its own 16kB of video memory, outside the address space of the CPU. Data is transferred by writing bytes to a port using the "OUT" command. As a byte is written, the TMS9918 increments its internal address register. The disadvantage is that for random access, the CPU has to write 2 additional bytes to set the address register. Some advantages of this approach are that the video framebuffer reads don't slow the system memory, and that the video address space is not subtracted from your valuable 8 bit CPU 64 kB addressing space, so you can have a 80 kB setup without getting into banking issues. When copying a block of data, all the CPU has to do is use two initial "OUT" instructions to set the video memory access address of the VDP. So no additional CPU address register is required, nor the incrementation thereof. Data transfer is roughly 2 kB per [[PAL]] video frame (100 kB/s).
+
The TMS9918 has its own 16k x 8 bit video memory, outside the address space of the [[CPU]]. This memory is not mapped onto the CPU memory space - the VDC's data memory bus is a private (although external) bus, separated from that of the CPU. A separate addressing space means that the CPU has to write a two-byte command word to the VDC's control port to set the address register, but it also means that the VDC doesn't slow the main processor down when it reads data out of its memory, and since the memory is not mapped onto the CPU's addressing space, there is more address space available for other memory and memory-mapped hardware.
 +
 
 +
The CPU communicates with the VDC through an additional 8-bit port on the VDC, and data is transferred between the two via port writes. As a byte is written, the TMS9918 increments its internal address register - this is important, because the CPU does not have to send an address update for every byte access. This facilitates quicker reads and writes of blocks of data. Writes to other ports can set various internal registers.
  
−
==Screen Modi==
+
==Screen modes==
−
There are 4 different screen modi available in the TMS9918A (as mentioned before, the TMS9918 lacks mode Graphic II):
+
There are 4 different screen modes available in the TMS9918A (as mentioned before, the TMS9918 lacks mode Graphic II):
  
−
'''Text:''' 40x24 characters monochrome. As the display is 256 [[pixel]]s width, the character set is only 6 pixels wide. This mode doesn't support [[sprite]]s, nor a separate border colour setting.
+
'''Mode 0 (Text):''' 40×24 characters monochrome. As the display is 256 pixels width, the character set is only 6 pixels wide. This mode doesn't support sprites, nor a separate border color setting.
  
−
'''Graphic I:''' 32x24 characters (256x192 bitmap), where for each 8 characters in the character set the foreground and background colour can be set. The chars "0"-"7" for example all have the same attributes.
+
'''Mode 1 (Graphic 1):''' 32×24 characters (256×192 bitmap), where for each 8 characters in the character set the foreground and background color can be set. The chars "0"-"7" for example all have the same attributes.
  
−
'''Graphic II:''' 32x24 characters (256x192 bitmap), with a 2-color limitation for each 8 pixel wide line inside a character. More about mode 2 below.
+
'''Mode 2 (Graphic 2):''' 32×24 characters (256×192 bitmap), with a 2-color limitation for each 8 pixel wide line inside a character.
  
−
'''Multicolor:''' 64x48 mode, very blocky and rarely used. Each 'pixel' can have its own colour defined though, hence the name. Its sprites still have the same [[resolution]] as in screen modes 1 and 2.
+
'''Mode 3 (Multicolor):''' 64×48 mode, very blocky and rarely used. Each 'pixel' can have its own color defined though, hence the name. Its sprites still have the same resolution as in screen modes 1 and 2.
  
−
The TMS9918 has a 16 color [[palette]], which is hardwired. e.g. colour 4 is always dark blue.
+
The TMS9918 has a fixed 16-color palette (actually 15 colors + transparent).
  
 
==Sprites==
 
==Sprites==
−
There can be 32 monochrome sprites of either 8x8 or 16x16 pixels on screen, each of which can have its own color. However sprite bandwidth is limited to max. 4 sprites per scanline. I.e. if there are more than 4 sprites next to each other horizontally, then the rest will disappear. In that case only the sprites with the highest priority (lowest position in the spritelist) are shown. If necessary, games often attack this problem by rotating sprite priorities. This way, every video frame a different set of sprites disappears in areas where there are more than
+
In modes 1, 2, and 3, the VDC can render sprites. There can be 32 monochrome sprites of either 8×8 or 16×16 pixels on screen, each of which can have its own color. There can be no more than 4 sprites on a single scanline; any additional sprites' horizontal pixels are dropped. Sprites with a higher priority are drawn first. The VDP reports in a status register the number of the first dropped sprite. The CPU can get around this limitation by rotating sprite priorities so that a different set of sprites is drawn on every frame. Instead of disappearing entirely, the sprites will flicker. This technique is known as sprite multiplexing.
−
4 per scanline. Instead of disappearing entirely, the sprites will flicker (sprite multiplexing). This is a common technique, for example the Atari 2600 had max. 2 sprites per scanline and still the Pac-Man faced 4 ghosts (which would start to flicker as soon as more than one was on the same scanline. One hardware sprite was used for the ghosts, the other for the Player, which didn't flicker).
 
  
−
There is a status bit "5th sprite" that tells that one or more sprites disappeared due to bandwidth overload. By checking this bit, software can determine whether it needs to enable the abovementioned technique.
+
Automatic sprite movement is not handled by the VDC.  What is done, in practice, is that the CPU will pick up on the VDC's 'vertical interrupt' - a standard VDC output, which is triggered automatically once every 50th or 60th of a second (depending on chip variant), during the VBI (vertical blanking interval).  The CPU then jumps to some sprite-handling routine in software, which in turn tells the VDC where to reposition the sprites.
  
−
There also is a sprite collision flag, which becomes set when two sprites overlap. This is useful for triggering more advanced collision detection routines inside the software which can then determine the exact location and act upon it (for instance show 'Game Over' because Pac-Man got eaten by a ghost).
+
When two non-transparent pixels in any pair of sprites collide, the sprite collision flag is set. This is useful for triggering more advanced collision detection routines inside the software which can then determine the exact location and act upon it. Note that unlike the Atari 2600's Television Interface Adapter and the Commodore 64's VIC-II, the VDC cannot tell the program which two sprites have collided, just that individual sprites have been involved in a collision.
  
−
Konami games such as Nemesis had the priority rotation always active (as can be seen when getting an "option", flying into it (with no further sprites positioned in the affected scanlines), and then pressing F1 for Pause). Method: A sprite position ring buffer is held in main memory. Up to 32 of the leading entries are copied to TMS9918 memory. Next video frame, the start position of the ringbuffer is incremented by 4 entries (this value leads to minimum flicker on a chip that can do 4 sprites per scanline). If the ringbuffer got more than 32 entries, then even without 5th sprite condition (more than 4 sprites per scanline), sprites start to flicker. But even more than 32 sprites are visible, i.e. the max 32 sprites onscreen limit is broken the same way as the max 4 sprites per scanline limit. It can happen that rotation of the list is nessesary even when no 5th sprite condition occurred (when there are more than 32 enemies), and it can happen that objects collide without the videochip noting it (because the sprite multiplexer displayed them in distinct video frames), which is why an advanced game engine does not use those hardware flags.
+
==Screen mode 2 detail==
 +
Technically, mode 2 is a character mode with a colorful character set. The screen is vertically divided into three 256×64 pixel areas, each of which gets its own character set. By sequentially printing the characters 0 through 255 in all three areas, the program can simulate a graphics mode where each pixel can be set individually. However, the resulting [[framebuffer]] is non-linear.
  
−
==Screen Mode 2 Detail==
+
The program can also use three identical character sets, and then deal with the screen like a text mode with a colorful character set. Background patterns and sprites then consist of colorful characters. This was commonly used in games, because to fill/scroll the entire screen, only 32×24 bytes had to be moved. Games on other home computers such as the Commodore 64 also worked on a character basis. The graphics have to be drawn such that the 8×8 pixel borders are not too obvious, an art where Konami was particularly well known for their excellence.
−
Technically mode 2 is a character mode whose charset is colorful. The screen is vertically divided into three areas which each got its own character set. Each such area is 256x64 pixels size. I.e. 256 characters of 8x8 pixels exactly cover one such area. By sequentially printing the characters 0 through 255 in every area, you get a graphics mode where each pixel can be set individually.
 
  
−
However, you can also use three identic character sets, and then deal with the screen like a text mode with a colorful character set. Background patterns and big enemies then consist of colorful characters. This was commonly used in games, because to fill/scroll the entire screen, only 32x24 bytes had to be moved. Games on other home computers such as the Commodore64 also worked on a character basis. The graphics have to be drawn such that the 8x8 pixel borders are not too obvious, an art where Konami was particularly well known for their excellence.
+
This is the TMS9918 screen mode 2 challenge: every 8×1 pixel area has two colors, foreground and background. They may be freely picked out of the 16 color palette. But within each 8×1 pixel area, only two different colors can exist. When manipulating the screen in BASIC with the LINE command, one easily could exceed the limit of max 2 colors per 8×1 area and end up with "color spill".
  
−
This is the TMS9918 screen mode 2 challenge: every 8x1 pixel area has two colors, foreground and background. They may be freely picked out of the 16 color palette. But within each 8x1 pixel area, only two different colors can exist. When manipulating the screen in BASIC with the LINE command, one easily could exceed the limit of max 2 colors per 8x1 area and end up with "color spill". It is a big challenge to the graphics artist. Cheap game conversions from other computers usually lead to monochrome games, whilst Konami, 'the master of 9918', pixeled wonderfully around the 8x1 limitation. In turn, you faced a 256x192 16 color screen, which looked closer to "16 bit" home computer backgrounds than the usual blocky 160x200 resolution of "8 bit" homecomputers.
+
In comparison, the Commodore 64 limit was 4 colors per 4×8 fat-pixel area. This meant that there was less local color pressure, but more global color pressure: only three of the 4 colors actually could be freely picked out of 16, the other color had to be the same over the entire screen. That color could be redefined every scan line for various results.
  
−
In comparison, the Commodore 64 limit was 4 colors per 4x8 fat-pixel area. So there was less local color pressure, but more global color pressure: only one of the 4 colors actually could be freely picked out of 16, the other 3 had to be the same over the entire screen. Globally the graphics were less colorful (although the 3 colors could be redefined every scanline to make a rainbow effect ("copper bars") and similar).
+
The TMS9918 does not have any scroll registers. Scrolling must be done in software.
  
−
So the TMS9918 was suited for colorful 256x192 resolution backgrounds, where a high fraction of the 16 colors were actually used. But it had one major drawback: it was missing scroll registers as found in C64. The screen had to be scrolled in 8 pixel jumps, or by manipulating the character tables.
+
==Tradeoffs used in games==
 +
Some games tried to get around the 8 pixel scroll limitation, by scrolling the character set itself. This was too slow to be feasible, so the game filled the character set with 8 different versions of a single character.
  
−
==Tradeoffs Used in Games==
+
Circus Charlie (MSX) scrolled horizontally, and hence bumped into the maximum of 2 colors per 8×1 area limit. The graphics were "monochrome-ish" and there were some glitches halfheartedly covered by sprites.
−
Some games tried to get around the 8 pixel scroll limitation, by scrolling the character set itself (and because this is not possible speed-wise, actually the character set was filled with 8 times the graphics, each one in a different position, which cut down the number of actually usable characters by a factor of eight).
 
  
−
Circus Charlie (MSX) scrolled horizontally, and hence bumped into the maximum of 2 colors per 8x1 area limit. The graphics were "monochrome-ish" and there were some glitches halfheartedly covered by sprites. Yet, a game smoothly scrolling horizontally on the TMS9918 is quite exceptional.
+
Pippols (MSX) scrolled vertically. Because this isn't affected by the 8×1 area limit, the player character could walk along smoothly scrolling colorful flowers and other such graphical fourishes. However there aren't many distinct objects onscreen, because the character set is cut down by factor 8. Pippols seems to be even below that limit by some factor.
  
−
Pippols (MSX) scrolled vertically. Because this isn't affected by the 8x1 area limit, you walk along smoothly scrolling colorful flowers etc. However there aren't many distinct objects onscreen, because the character set is cut down by factor 8. Pippols seems to be even below that limit by some factor. Unfortunately Konami never further explored this topic. By using a background pattern of a 8x4 size, you could even have a parallax scroller.
+
When moving at full speed in Road Fighter (MSX, vertically scrolling racing game), the screen moves 8 pixels each frame. This results in a smooth scroller in spite of the 8 pixel jumps. For many games this scrolling speed is not feasible, though.
  
−
When you are at full speed in Road Fighter (MSX, vertically scrolling racing game), the screen moves 8 pixels each frame. This results in a smooth scroller in spite of the 8 pixel jumps. For many games this scrolling speed is not feasible, though. A creative approach could be seen in Ghost'n'Goblins (Schneider/Amstrad CPC): as you walk near the border, the scene scrolls quickly (8 pixels/frame) until the player is near the other side of the border. Then you walk for a while with no scrolling at all. A perfect solution for this type of game.
+
In Knightmare (MSX), the scene scrolls vertically so slowly that the 8 pixel jump doesn't disturb much. Zanac scrolls vertically fairly fast, but due to the soft backgrounds which you never collide with it is a minor issue. It is most problematic in Nemesis ("R-Type style" horizontal space shooter). On the other hand, the Nemesis 2 backgrounds are really of "16 bit" beauty.
  
−
In Knightmare (MSX), the scene scrolls vertically so slowly that the 8 pixel jump doesn't disturb much. Zanac scrolls vertically fairly fast, but due to the soft backgrounds which you never collide with it is a minor issue. It is most problematic in Nemesis ("R-Type style" horizontal space shooter). On the other hand, the Nemesis 2 backgrounds are really of "16 bit" beauty.
+
==Specifications==
 +
* Video RAM: 16 KB
 +
* Text modes: 40 × 24 and 32 × 24
 +
* Resolution: 256 × 192 (15 colours + transparent)
 +
* Sprites: 32, 1 colour, max 4 per horizontal line
 +
 
 +
==Amateur's Tool==
 +
TMS9918 still has plenty of fans who nowadays create lots of PC tools for character design, sprite design and for converting true color images to screen 2. With respect to this latter application, it is worth to underline the use of dithering algorithms (e.g. Floyd-Steinberg) in order to overcome to the color clash problem and the limitations of the fixed palette.
 +
 
 +
For tools implementing dithering in screen 2 conversion look at:
 +
[http://msx.jannone.org/conv/ Online screen 2 converter] and to [http://www.msx.org/modules.php?op=modload&name=Downloads&file=index&req=visit&lid=859 Offline screen 2 converter + C sources]
  
−
Last but not least there is Penguin Adventure (MSX). It does scroll "3D", "Outrun style" (the scene aproaches from ahead). The character set is defined to hold objects in multiple zoom levels. The lack of scroll registers plays no role here, and what goes on on screen is incredible considering an "8 bit" computer. Here, the TMS9918 is at its best. Penguin Adventure also is very much worth playing due to Konami gameplay/humour, but that is another story.
+
==External links==
 +
*[http://emu-docs.org/VDP%20TMS9918/Datasheets/TMS9918.pdf Online datasheet]
  
 +
[[Category:Mega Drive Hardware]]
 
[[Category:Master System Hardware]]
 
[[Category:Master System Hardware]]

Revision as of 22:21, 18 March 2008

File:TMS9918.jpg
TMS9918 chip

The TMS9918 is a Video Display Controller (VDC) manuafactured by Texas Instruments.

General information

The TMS9918 was used in systems like MSX, ColecoVision, Texas Instruments TI-99/4, Memotech MTX500/MTX512/RS128 and Sega SG-1000/SC-3000. Modified versions with additional display modes and registers were used in the Sega Master System, Sega Game Gear, and Sega Mega Drive. Note that the Genesis VDP cannot access any of the TMS9918 display modes discussed below.

There are several variants called TMS9918A, TMS9928A and TMS9929A, where the 'A' indicates a second version of the chip which added new features, most prominently the addition of a bitmap mode (Graphic II). The non-A version was only used in the TI-99/4; the TI-99/4A and the other computers had the A version VDC. The TMS9918A and TMS9928A output a 60Hz video signal, while the TMS9929A outputs 50Hz. The difference between '1' and the '2' in 'TMS9918A' and 'TMS9928A' is that the '1' version outputs composite NTSC video, while the '2' versions (including the TMS9929A) outputs YPbPr, more precisely the Y, R-Y and B-Y colour differences (luminance and color difference signals). The need for the latter was predominant in the 50Hz world, including Europe, due to the different video signal standards PAL and SECAM. It was more cost-effective to output Y, R-Y and B-Y and encode them into PAL or SECAM in the RF modulator, than to try and have a different console for every different color standard. All of the ICs in this family are usually referred to by the TMS9918 name, sometimes with an 'A' postfix.

Texas Instruments' TMS9918A was succeeded by Yamaha's Yamaha V9938, which added additional bitmap modes, more colorful sprites, a vertical scroll register and a customizable palette. The V9938 was used in a third-party upgrade to the TI-99/4A — the Geneve 9640 'computer-on-a-card'. The V9938, in turn, was succeeded by the Yamaha V9958, which added some additional high-colour modes and a horizontal scroll register. These chips were used in the "TIM" upgrade card for the TI-99/4A, as well as on the MSX 2 and MSX 2+/turboR systems, although rumor has it that the V9958 was also used in a generation of the Photo Play arcades. Yamaha also produced a Yamaha V9990, which is considered the follow-up of the V9958 by some, but it is not backwards compatible. A graphic chip extension utilizing the V9990 exists for the MSX in the form of the 'Graphics9000' cartridge by Sunrise.

Interface

The TMS9918 has its own 16k x 8 bit video memory, outside the address space of the CPU. This memory is not mapped onto the CPU memory space - the VDC's data memory bus is a private (although external) bus, separated from that of the CPU. A separate addressing space means that the CPU has to write a two-byte command word to the VDC's control port to set the address register, but it also means that the VDC doesn't slow the main processor down when it reads data out of its memory, and since the memory is not mapped onto the CPU's addressing space, there is more address space available for other memory and memory-mapped hardware.

The CPU communicates with the VDC through an additional 8-bit port on the VDC, and data is transferred between the two via port writes. As a byte is written, the TMS9918 increments its internal address register - this is important, because the CPU does not have to send an address update for every byte access. This facilitates quicker reads and writes of blocks of data. Writes to other ports can set various internal registers.

Screen modes

There are 4 different screen modes available in the TMS9918A (as mentioned before, the TMS9918 lacks mode Graphic II):

Mode 0 (Text): 40×24 characters monochrome. As the display is 256 pixels width, the character set is only 6 pixels wide. This mode doesn't support sprites, nor a separate border color setting.

Mode 1 (Graphic 1): 32×24 characters (256×192 bitmap), where for each 8 characters in the character set the foreground and background color can be set. The chars "0"-"7" for example all have the same attributes.

Mode 2 (Graphic 2): 32×24 characters (256×192 bitmap), with a 2-color limitation for each 8 pixel wide line inside a character.

Mode 3 (Multicolor): 64×48 mode, very blocky and rarely used. Each 'pixel' can have its own color defined though, hence the name. Its sprites still have the same resolution as in screen modes 1 and 2.

The TMS9918 has a fixed 16-color palette (actually 15 colors + transparent).

Sprites

In modes 1, 2, and 3, the VDC can render sprites. There can be 32 monochrome sprites of either 8×8 or 16×16 pixels on screen, each of which can have its own color. There can be no more than 4 sprites on a single scanline; any additional sprites' horizontal pixels are dropped. Sprites with a higher priority are drawn first. The VDP reports in a status register the number of the first dropped sprite. The CPU can get around this limitation by rotating sprite priorities so that a different set of sprites is drawn on every frame. Instead of disappearing entirely, the sprites will flicker. This technique is known as sprite multiplexing.

Automatic sprite movement is not handled by the VDC. What is done, in practice, is that the CPU will pick up on the VDC's 'vertical interrupt' - a standard VDC output, which is triggered automatically once every 50th or 60th of a second (depending on chip variant), during the VBI (vertical blanking interval). The CPU then jumps to some sprite-handling routine in software, which in turn tells the VDC where to reposition the sprites.

When two non-transparent pixels in any pair of sprites collide, the sprite collision flag is set. This is useful for triggering more advanced collision detection routines inside the software which can then determine the exact location and act upon it. Note that unlike the Atari 2600's Television Interface Adapter and the Commodore 64's VIC-II, the VDC cannot tell the program which two sprites have collided, just that individual sprites have been involved in a collision.

Screen mode 2 detail

Technically, mode 2 is a character mode with a colorful character set. The screen is vertically divided into three 256×64 pixel areas, each of which gets its own character set. By sequentially printing the characters 0 through 255 in all three areas, the program can simulate a graphics mode where each pixel can be set individually. However, the resulting framebuffer is non-linear.

The program can also use three identical character sets, and then deal with the screen like a text mode with a colorful character set. Background patterns and sprites then consist of colorful characters. This was commonly used in games, because to fill/scroll the entire screen, only 32×24 bytes had to be moved. Games on other home computers such as the Commodore 64 also worked on a character basis. The graphics have to be drawn such that the 8×8 pixel borders are not too obvious, an art where Konami was particularly well known for their excellence.

This is the TMS9918 screen mode 2 challenge: every 8×1 pixel area has two colors, foreground and background. They may be freely picked out of the 16 color palette. But within each 8×1 pixel area, only two different colors can exist. When manipulating the screen in BASIC with the LINE command, one easily could exceed the limit of max 2 colors per 8×1 area and end up with "color spill".

In comparison, the Commodore 64 limit was 4 colors per 4×8 fat-pixel area. This meant that there was less local color pressure, but more global color pressure: only three of the 4 colors actually could be freely picked out of 16, the other color had to be the same over the entire screen. That color could be redefined every scan line for various results.

The TMS9918 does not have any scroll registers. Scrolling must be done in software.

Tradeoffs used in games

Some games tried to get around the 8 pixel scroll limitation, by scrolling the character set itself. This was too slow to be feasible, so the game filled the character set with 8 different versions of a single character.

Circus Charlie (MSX) scrolled horizontally, and hence bumped into the maximum of 2 colors per 8×1 area limit. The graphics were "monochrome-ish" and there were some glitches halfheartedly covered by sprites.

Pippols (MSX) scrolled vertically. Because this isn't affected by the 8×1 area limit, the player character could walk along smoothly scrolling colorful flowers and other such graphical fourishes. However there aren't many distinct objects onscreen, because the character set is cut down by factor 8. Pippols seems to be even below that limit by some factor.

When moving at full speed in Road Fighter (MSX, vertically scrolling racing game), the screen moves 8 pixels each frame. This results in a smooth scroller in spite of the 8 pixel jumps. For many games this scrolling speed is not feasible, though.

In Knightmare (MSX), the scene scrolls vertically so slowly that the 8 pixel jump doesn't disturb much. Zanac scrolls vertically fairly fast, but due to the soft backgrounds which you never collide with it is a minor issue. It is most problematic in Nemesis ("R-Type style" horizontal space shooter). On the other hand, the Nemesis 2 backgrounds are really of "16 bit" beauty.

Specifications

  • Video RAM: 16 KB
  • Text modes: 40 × 24 and 32 × 24
  • Resolution: 256 × 192 (15 colours + transparent)
  • Sprites: 32, 1 colour, max 4 per horizontal line

Amateur's Tool

TMS9918 still has plenty of fans who nowadays create lots of PC tools for character design, sprite design and for converting true color images to screen 2. With respect to this latter application, it is worth to underline the use of dithering algorithms (e.g. Floyd-Steinberg) in order to overcome to the color clash problem and the limitations of the fixed palette.

For tools implementing dithering in screen 2 conversion look at: Online screen 2 converter and to Offline screen 2 converter + C sources

External links

Retrieved from "https://info.sonicretro.org/index.php?title=TMS9918&oldid=55330"