├── 1980_Arizona_Technical_Symposium_Draft.pdf ├── 9918 pcb.pcb ├── 9918 schematic.sch ├── CMU-ECE-1984-010.pdf ├── F18a └── F18A documentation.pdf ├── Hi-Res Graphics TMS9918 BYTE 0882.pdf ├── MSX 9958.pdf ├── README.md ├── SRAM+Replacement+for+TMS99x8+VRAM.pdf ├── TI-VDP-PRG.pdf ├── TMS9918.pdf ├── Timex 1000 Mod ├── Oliger TMS9918 Timex 1000 (SyncWare News).7z.001 ├── Oliger TMS9918 Timex 1000 (SyncWare News).7z.002 ├── Oliger TMS9918 Timex 1000 (SyncWare News).7z.003 ├── Oliger TMS9918 Timex 1000 (SyncWare News).7z.004 └── README.md ├── V9958 example circuit.png ├── V9958-Technical-manual_v1.0.pdf ├── _config.yml ├── sppa004a.pdf ├── synetix-supersprite-owners-manual-cs.pdf └── tms9918a.txt /1980_Arizona_Technical_Symposium_Draft.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/1980_Arizona_Technical_Symposium_Draft.pdf -------------------------------------------------------------------------------- /9918 pcb.pcb: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/9918 pcb.pcb -------------------------------------------------------------------------------- /9918 schematic.sch: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/9918 schematic.sch -------------------------------------------------------------------------------- /CMU-ECE-1984-010.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/CMU-ECE-1984-010.pdf -------------------------------------------------------------------------------- /F18a/F18A documentation.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/F18a/F18A documentation.pdf -------------------------------------------------------------------------------- /Hi-Res Graphics TMS9918 BYTE 0882.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/Hi-Res Graphics TMS9918 BYTE 0882.pdf -------------------------------------------------------------------------------- /MSX 9958.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/MSX 9958.pdf -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # TMS9918 2 | Various documents for the TMS9918/TMS9928 and TMS9958 VDP's that I've collected over the years. 3 | 4 | 5 | ### Useful Links 6 | 7 | http://forum.6502.org/viewtopic.php?f=4&t=3564&start=0 8 | 9 | https://hackaday.io/project/5789-6502-homebrew-computer/log/18434-video-output 10 | 11 | Great example of using the TMS in a homebrew computer based off the 6809: 12 | 13 | https://github.com/74hc595/Ultim809/tree/master/circuit 14 | 15 | 16 | ### Special Thanks 17 | 18 | Special Thanks to David Anderson (factus10) for providing these files: 19 | 20 | 1980_Arizona_Technical_Symposium_Draft.pdf 21 | CMU-ECE-1984-010.pdf 22 | Oliger TMS9918 Timex 1000 (SyncWare News).pdf 23 | TI-VDP-PRG.pdf 24 | tms9918a.txt 25 | 26 | 27 | And thanks goes to bissonex for discovering a missing page in the Apple II Byte article (Hi-Res Graphics TMS9918 BYTE 0882.pdf). 28 | 29 | https://github.com/bissonex 30 | 31 | 32 | -------------------------------------------------------------------------------- /SRAM+Replacement+for+TMS99x8+VRAM.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/SRAM+Replacement+for+TMS99x8+VRAM.pdf -------------------------------------------------------------------------------- /TI-VDP-PRG.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/TI-VDP-PRG.pdf -------------------------------------------------------------------------------- /TMS9918.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/TMS9918.pdf -------------------------------------------------------------------------------- /Timex 1000 Mod/Oliger TMS9918 Timex 1000 (SyncWare News).7z.001: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/Timex 1000 Mod/Oliger TMS9918 Timex 1000 (SyncWare News).7z.001 -------------------------------------------------------------------------------- /Timex 1000 Mod/Oliger TMS9918 Timex 1000 (SyncWare News).7z.002: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/Timex 1000 Mod/Oliger TMS9918 Timex 1000 (SyncWare News).7z.002 -------------------------------------------------------------------------------- /Timex 1000 Mod/Oliger TMS9918 Timex 1000 (SyncWare News).7z.003: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/Timex 1000 Mod/Oliger TMS9918 Timex 1000 (SyncWare News).7z.003 -------------------------------------------------------------------------------- /Timex 1000 Mod/Oliger TMS9918 Timex 1000 (SyncWare News).7z.004: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/Timex 1000 Mod/Oliger TMS9918 Timex 1000 (SyncWare News).7z.004 -------------------------------------------------------------------------------- /Timex 1000 Mod/README.md: -------------------------------------------------------------------------------- 1 | Original PDF provided by David Anderson. 2 | 3 | GitHub did not allow me to upload the single PDF file of 40 MB. 4 | 5 | So, using 7zip, I split the file into 10 MB chunks. 6 | 7 | There should be FOUR of them total. 8 | 9 | The final filename should be: Oliger TMS9918 Timex 1000 (SyncWare News).pdf 10 | 11 | Thank you David! 12 | 13 | Enjoy.. 14 | 15 | ~cbmeeks -------------------------------------------------------------------------------- /V9958 example circuit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/V9958 example circuit.png -------------------------------------------------------------------------------- /V9958-Technical-manual_v1.0.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/V9958-Technical-manual_v1.0.pdf -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-minimal -------------------------------------------------------------------------------- /sppa004a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/sppa004a.pdf -------------------------------------------------------------------------------- /synetix-supersprite-owners-manual-cs.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cbmeeks/TMS9918/4d4e3e773e6a3dae668869a447929962a88b6f95/synetix-supersprite-owners-manual-cs.pdf -------------------------------------------------------------------------------- /tms9918a.txt: -------------------------------------------------------------------------------- 1 | 2 | Texas Instruments TMS9918A VDP 3 | Almost complete description including undocumented features 4 | 5 | By Sean Young (sean@msxnet.org) 6 | Version 0.4.2 September 2002 7 | 8 | 9 | In this document I'll try to give a complete description of the TMS9918A in 10 | software behaviour and display output. I only know the VDP in the MSX system, 11 | in other systems it may have features not described here. 12 | 13 | You can always find the latest version of this document at: 14 | 15 | http://www.msxnet.org/tech/ 16 | 17 | 1) Overview 18 | 1.1) Colours 19 | 1.2) Registers 20 | 1.3) External Video 21 | 22 | 2) I/O with the VDP 23 | 2.1) Memory access 24 | 2.2) Register access 25 | 2.3) I/O Ports quirks 26 | 2.4) Interrupts 27 | 28 | 3) Display modes 29 | 3.1) Mode 0 30 | 3.2) Mode 1 31 | 3.3) Mode 2 32 | 3.4) Mode 3 33 | 3.5) Undocumented Mode 1 + 2 34 | 3.6) Undocumented Mode 2 + 3 35 | 3.7) Other (Mode 1+3 and Mode 1+2+3) 36 | 37 | 4) Sprite system 38 | 4.1) Sprite attribute 39 | 4.2) Sprite pattern sizes 40 | 4.3) Illegal sprites and collisions 41 | 42 | 5) Hardware 43 | 5.1) Pin outs 44 | 45 | 6) To-do 46 | 47 | 7) References 48 | 49 | 50 | 1) Overview 51 | ----------- 52 | 53 | The TMS9918a is quite a simple VDP with 16kB or 4kB of video memory. The 54 | display always has a resolution of 256 pixels horizontal and 192 pixels 55 | vertical. Around this area, there is the border colour (back drop) which can 56 | be set in the registers. There also is a sprite subsystem, with maximum of 57 | 4 sprites on a horizontal line. 58 | 59 | There is a PAL version of the chip, and a NTSC version. The interrupt speed 60 | is different: 50Hz for PAL and 60Hz for NTSC. Also the colours are different. 61 | 62 | The TMS9918A was used in quite a few systems: MSX1, Coleco, TI99/4A and 63 | probably more. I only know it in the MSX1 system. 64 | 65 | 66 | 1.1) Colours 67 | 68 | Taken from mess/vidhrdrw/tms9928a.c in MESS, by Raphael Nabet. 69 | 70 | The first 3 columns are taken from the TI datasheet (in volts). The next 3 71 | columns are based on this formula: 72 | 73 | Y = .299*R + .587*G + .114*B (NTSC) 74 | 75 | The coefficients are likely to be slightly different with PAL. I assumed the 76 | "zero" for R-Y and B-Y was 0.47V. The last 3 coeffs are the 8-bit values. 77 | 78 | Colour Y R-Y B-Y R G B R G B 79 | 0 Transparent 80 | 1 Black 0.00 0.47 0.47 0.00 0.00 0.00 0 0 0 81 | 2 Medium green 0.53 0.07 0.20 0.13 0.79 0.26 33 200 66 82 | 3 Light green 0.67 0.17 0.27 0.37 0.86 0.47 94 220 120 83 | 4 Dark blue 0.40 0.40 1.00 0.33 0.33 0.93 84 85 237 84 | 5 Light blue 0.53 0.43 0.93 0.49 0.46 0.99 125 118 252 85 | 6 Dark red 0.47 0.83 0.30 0.83 0.32 0.30 212 82 77 86 | 7 Cyan 0.73 0.00 0.70 0.26 0.92 0.96 66 235 245 87 | 8 Medium red 0.53 0.93 0.27 0.99 0.33 0.33 252 85 84 88 | 9 Light red 0.67 0.93 0.27 1.13! 0.47 0.47 255 121 120 89 | A Dark yellow 0.73 0.57 0.07 0.83 0.76 0.33 212 193 84 90 | B Light yellow 0.80 0.57 0.17 0.90 0.81 0.50 230 206 128 91 | C Dark green 0.47 0.13 0.23 0.13 0.69 0.23 33 176 59 92 | D Magenta 0.53 0.73 0.67 0.79 0.36 0.73 201 91 186 93 | E Gray 0.80 0.47 0.47 0.80 0.80 0.80 204 204 204 94 | F White 1.00 0.47 0.47 1.00 1.00 1.00 255 255 255 95 | 96 | 97 | 1.2) Registers 98 | 99 | The VDP has 8 control registers (0-7) and one status register. 100 | 101 | Control Registers: 102 | 103 | Reg/Bit 7 6 5 4 3 2 1 0 104 | 0 - - - - - - M2 EXTVID 105 | 1 4/16K BL GINT M1 M3 - SI MAG 106 | 2 - - - - PN13 PN12 PN11 PN10 107 | 3 CT13 CT12 CT11 CT10 CT9 CT8 CT7 CT6 108 | 4 - - - - - PG13 PG12 PG11 109 | 5 - SA13 SA12 SA11 SA10 SA9 SA8 SA7 110 | 6 - - - - - SG13 SG12 SG11 111 | 7 TC3 TC2 TC1 TC0 BD3 BD2 BD1 BD0 112 | 113 | Status Register: 114 | 115 | 7 6 5 4 3 2 1 0 116 | INT 5S C FS4 FS3 FS2 FS1 FS0 117 | 118 | The function of the bits is as follows: 119 | 120 | M1,M2,M3 Select screen mode 121 | EXTVID Enables external video input. 122 | 4/16K Selects 16kB RAM if set. No effect in MSX1 system. 123 | BL Blank screen if reset; just backdrop. Sprite system inactive 124 | SI 16x16 sprites if set; 8x8 if reset 125 | MAG Sprites enlarged if set (sprite pixels are 2x2) 126 | GINT Generate interrupts if set 127 | PN* Address for pattern name table 128 | CT* Address for colour table (special meaning in M2) 129 | PG* Address for pattern generator table (special meaning in M2) 130 | SA* Address for sprite attribute table 131 | SG* Address for sprite generator table 132 | TC* Text colour (foreground) 133 | BD* Back drop (background). Sets the colour of the border around 134 | the drawable area. If it is 0, it is black (like colour 1). 135 | FS* Fifth sprite (first sprite that's not displayed). Only valid 136 | if 5S is set. 137 | C Sprite collision detected 138 | 5S Fifth sprite (not displayed) detected. Value in FS* is valid. 139 | INT Set at each screen update, used for interrupts. 140 | 141 | The exact meaning of all these bits should become clear in the remainder of 142 | this document. 143 | 144 | The bits marked with `-' are "don't care": set or reset, doesn't make any 145 | difference. However, to maintain upwards compatibility, you should 146 | reset these bits. 147 | 148 | 149 | 1.3) External Video 150 | 151 | Tursi writes: 152 | 153 | The 9918A processor is capable of genlocking with an external video signal 154 | and providing video overlay - this is the purpose of the Transparent color. 155 | (I don't know about the 9918 -- perhaps in that chip it *is* B&W, as I've 156 | heard of 99/4s (no A) outputting only B&W video, but I haven't seen it so 157 | I can not confirm or deny it.) 158 | 159 | Anyway, so far as the 9918A goes, the EXTVDP and _RESET/SYNC pins (using 160 | the names in your doc) are used to input external video and video sync. 161 | When Register 0 bit 0 is reset, the chip performs normally. When it is set, 162 | video sync is taken in through the sync pin, and the VDP's video is mixed 163 | on top of any video being fed into the EXTVDP pin. 164 | 165 | I have experimentally confirmed that this does in fact work. Although the 166 | TI-99 is not designed to use this feature, I hacked together a quick circuit 167 | many years ago to attempt it. I was not successful in getting the sync to 168 | work to my liking (mostly due to inexperience), but I did confirm the 169 | operation of this bit as switching the external video on and off. 170 | 171 | 172 | 2) I/O with the VDP 173 | ------------------- 174 | 175 | The VDP has two I/O ports (#0 and #1) which can be read or written. In the MSX 176 | system, they are mapped to port 98h and 99h. The VDP also has an INT output, 177 | which can be used by the CPU to detect screen updates (or vertical blank). 178 | 179 | 180 | 2.1) Memory access 181 | 182 | The video memory can't be accessed directly; only through the I/O ports. To 183 | the contrary to what many (official!) docs say, there is only one read/write 184 | address where the VDP reads or writes in the memory. There also is a 185 | read-ahead buffer, which stores one byte. Memory is "read ahead", so when a 186 | read is requested, it can give the value immediately. 187 | 188 | This memory address (the r/w address) can be set by writing two bytes to port 189 | #1. Despite the fact there is only one address, a distinction is made between 190 | setting it for reading or writing (this because of the read-ahead buffer). 191 | 192 | The two bytes are formatted as follows: 193 | 194 | 7 6 5 4 3 2 1 0 195 | Byte #0 A7 A6 A5 A4 A3 A2 A1 A0 196 | Byte #1 0 R/W A13 A12 A11 A10 A9 A8 197 | 198 | A13-A0 make up the address. R/W specifies whether you want to read or write 199 | from that address. It should be 0 for reading, 1 for writing. 200 | 201 | What happens internally in the VDP is interesting. This depends on what you 202 | set the R/W bit to: 203 | 204 | Write (1): Simply set the r/w address to the A* value specified. 205 | Read (0): Read the contents of the A* address from the VRAM and put it 206 | in the read-ahead buffer. Set the r/w address to A* + 1. 207 | 208 | Now that the r/w address is set, we can start reading from or writing to it. 209 | After each access it is increased. By reading port #0 we can read from the 210 | address, by writing to it we write to the address. What happens internally is: 211 | 212 | Read: Return value in read-ahead buffer. Read next value from the r/w 213 | address, put it in the read-ahead buffer. Increase the r/w address. 214 | Write: Write back the value to the r/w address, then increase the r/w address. 215 | Interestingly, the value written is also stored in the read-ahead 216 | buffer. 217 | 218 | After 3fffh (16kB limit) the r/w address wraps to zero. 219 | 220 | In 4Kb mode addressing works differently. Charles MacDonald explains: 221 | 222 | I wanted to contribute some information to your TMS9918 document. The 4K/16K 223 | bit of register #1 tells the TMS9918 how to form addresses when accessing 224 | VRAM. However, memory is not really limited to 4K, the full 16K range is 225 | addressable. This does have consequences if you write to VRAM in one 226 | setting, then change the bit and try to read data back. 227 | 228 | The modified addresses look like this: 229 | 230 | VDP address VRAM address 231 | (Column) 4K mode 8/16K mode 232 | AD0 VA0 VA0 233 | AD1 VA1 VA1 234 | AD2 VA2 VA2 235 | AD3 VA3 VA3 236 | AD4 VA4 VA4 237 | AD5 VA5 VA5 238 | AD6 VA12 VA6 239 | AD7 Not used Not used 240 | (Row) 241 | AD0 VA6 VA7 242 | AD1 VA7 VA8 243 | AD2 VA8 VA9 244 | AD3 VA9 VA10 245 | AD4 VA10 VA11 246 | AD5 VA11 VA12 247 | AD6 VA13 VA13 248 | AD7 Not used Not used 249 | 250 | ADx - TMS9928 8-bit VRAM address/data bus 251 | VAx - 14-bit VRAM address that the VDP wants to access 252 | 253 | In 4K mode the most significant bit of the DRAM row and column contains the 254 | high-order address bits (VA12/VA13). Normally you'd think these bits would 255 | be forced to zero, thereby limiting VRAM to 4K and making it appear mirrored 256 | throughout the rest of the 16K space. 257 | 258 | This has to do with how the cells in a DRAM chip are arranged, they are in a 259 | 64x64 array for 4Kx1, and 128x64 or 128x128 for 8Kx1 or 16Kx1. The 4K/16K 260 | select bit determines the 'width', meaning how many bits are allocated for 261 | the row and column addresses. (mainly 64 versus 128) 262 | 263 | I had tested and determined these results from a TMS9929A in an old Sega 264 | personal computer, which used eight 16Kx1 chips for 16K of VRAM. I'm fairly 265 | sure it also applies to the TMS9918 and TMS9928 as well. 266 | 267 | 268 | 2.2) Register access 269 | 270 | The status register can only be read; the control registers can't be read so 271 | they can only can be written. 272 | 273 | By reading port #1, you get the value of the status register. After reading 274 | it, bit 7 (INT bit) and bit 5 (C bit) are reset. 275 | 276 | By writing to port #1, a control register is set. Two bytes must be written 277 | to port #1: 278 | 279 | 7 6 5 4 3 2 1 0 280 | Byte #0 V7 V6 V5 V4 V3 V2 V1 V0 281 | Byte #1 1 ? ? ? ? R2 R1 R0 282 | 283 | The V* bits make up the value written to the register, which is specified 284 | with the R* bits. Bits 6-3 of the second byte are "don't care": it doesn't 285 | matter what value you set them. Officially, they must be 0. It is best to 286 | set them to 0. The upwards TMS9918A compatible V9938 and V9958 have more 287 | registers and so these bits do have meaning. So, for compatibility, set them 288 | to 0. Bit 7 must be set, to indicate you want to write to a register; otherwise 289 | you're changing the r/w address. 290 | 291 | 292 | 2.3) I/O Ports quirks 293 | 294 | As you've probably noticed, writes to port #1 must always go in pairs of two 295 | bytes. Suppose you would write one byte to port #1, and let normal programming 296 | continue .. you'd assume that the byte order of any port #1 write is wrong and 297 | strange things happen. But that isn't true. 298 | 299 | What happens internally is this. After writing the first byte to port #1, a 300 | flag is set to indicate that the next byte written to port #1 is the second of 301 | the pair and completes the register write or r/w address set. This flag is 302 | reset after that. 303 | 304 | But this flag is also reset whenever you read port #1, or read or write port 305 | #0. This probably done to prevent an accidental single write to port #1 mess up 306 | the whole programming (which without this setup, would require a hard reset or 307 | another write to port #1 to return to normal operation). 308 | 309 | So, in between writing two bytes to port #1, never access any other port of the 310 | VDP. This is why interrupts must be disabled during writing to port #1: the 311 | interrupt service routine most likely accesses the VDP (status register read 312 | for example) and that will mess it up. 313 | 314 | 315 | 2.4) Interrupts 316 | 317 | The VDP can generate interrupts for the CPU. It works as follows: at the end 318 | of the last line of the screen (after vertical line 192, last of the drawable 319 | screen; at the beginning of the bottom part of the backdrop) bit 7 of status 320 | register is set. 321 | 322 | If bit 7 of the status register is set (INT), and bit 5 of control register #1 323 | is set (GINT), the INT output line is low (requesting an interrupt), otherwise 324 | it is high (not requesting an interrupt). 325 | 326 | So if bit 5 of control register #1 is reset, interrupts are never requested. 327 | 328 | After the status register is read, bit 7 is reset. The INT line goes high 329 | again, so it isn't requesting an interrupt anymore. That's why this register 330 | must always be read in an interrupt routine: otherwise the INT is remains low 331 | and the interrupt service routine is called again and again. 332 | 333 | Another interesting fact is this: if bit 5 of control register #1 is reset, 334 | and you set it while bit 7 of the status register is set, the INT line goes 335 | low immediately and an interrupt is requested. This is important for emulators 336 | too: if this isn't emulated properly, the MSX game Track & Field 1 and 2 slows 337 | down considerably. 338 | 339 | 340 | 3) Screen modes 341 | --------------- 342 | 343 | There are 4 official screen modes but 3 mode bits (8 possibilities). The 344 | modes define how the screen is built up. In some modes, the sprite subsystem 345 | is active which is described in section 4). 346 | 347 | All screen modes are character based. 348 | 349 | Screen mode x simply means the respective Mx bits are set. Mode 0 indicates 350 | none of the M* bits are set. 351 | 352 | 353 | 3.1) Mode 0 354 | 355 | This screen mode is known as SCREEN 1 in MSX BASIC, and GRAPHIC 1 in the 356 | V9938 Technical Data Book. 357 | 358 | Like most screen modes, it has width 32 characters and 24 characters vertical. 359 | The sprite subsystem is active. 360 | 361 | Since the size is 32 x 24, the Pattern Name Table (PN) has 32 x 24 = 768 362 | elements, which are bytes referring to the Pattern Generator Table (PG) and 363 | Colour Table (CT). 364 | 365 | The first character is the top-left one, the second the one to the right of 366 | it. Character no. 32 the first character of the second row. 367 | 368 | Each character is 8 x 8. The character number refers to an character pattern in 369 | the PG, which has 256 characters patterns. Each pattern is 8 bytes, so the 370 | entire PG is 256 x 8 = 2048 bytes. Each byte is a pixel line of the character 371 | (top first). If a bit is set, the foreground colour in the CT is shown, 372 | otherwise the background colour in the CT. 373 | 374 | The CT sets the colour of the character. Each byte in the CT sets the colour 375 | of 8 complete characters, so the CT is 32 bytes. The high four bits set the 376 | foreground colour, the low the background colour. If either of these is 0, 377 | it is transparent and the colour of the backdrop (BD) is used. To calculate 378 | the element in the CT, divide the character number in PN by 8. 379 | 380 | The TC in control register #7 is not used in this mode. 381 | 382 | 383 | 3.2) Mode 1 384 | 385 | This mode is known as SCREEN 0 in MSX BASIC, and as TEXT 1 in the V9938 386 | Technical Data Book. 387 | 388 | In this mode, the screen has width 40 characters and 24 characters vertical. 389 | Only two colours are used, TC and BD from control register #7. Since the 390 | characters are 6 pixels wide, the width is 40 x 6 = 240. There is a 8 pixels 391 | border at the left and right side of the screen (with the colour of the back 392 | drop). The sprite subsystem is inactive. 393 | 394 | Since the size is 40 x 24, the Pattern Name Table (PN) has 40 x 24 = 960 395 | elements, which are bytes refering to the Pattern Generator Table (PG). The 396 | Colour Table (CT) is not used. 397 | 398 | The first character is the top-left one, the second the one to the right of 399 | it. Character no. 40 the first character of the second row. 400 | 401 | Each character is 6 x 8 pixels. The character number refers to a character 402 | pattern in the PG, which has 256 characters patterns. Each pattern is 8 bytes, 403 | so the entire PG is 256 x 8 = 2048 bytes. Each byte is a pixel line of the 404 | character (top first). If a bit is set, the TC in control register #7 is shown, 405 | otherwise BD in the same register. The two highest bits of each byte in the PG 406 | are ignored. 407 | 408 | 409 | 3.3) Mode 2 410 | 411 | This mode is known as SCREEN 2 in MSX BASIC, and as GRAPHIC 2 in the V9938 412 | Data Book. It is the most complex and has the most possibilities of all the 413 | modes of the TMS9918A. 414 | 415 | Like most screen modes, it has width 32 characters and 24 characters vertical. 416 | The sprite subsystem is active. 417 | 418 | Since the size is 32 x 24, the Pattern Name Table (PN) has 32 x 24 = 768 419 | elements, which are bytes refering to the Pattern Generator Table (PG) and 420 | Colour Table (CT). 421 | 422 | The first character is the top-left one, the second the one to the right of 423 | it. Character no. 32 the first character of the second row. There are three 424 | colour and three pattern tables. The character number is as follows: 425 | 426 | The first 8 rows: byte from PN + 000h 427 | The middle 8 rows: byte from PN + 100h 428 | The bottom 8 rows: byte from PN + 200h 429 | 430 | Each character is 8 x 8. The character number refers to an character pattern 431 | in the PG, which has 768 characters patterns (three distinct tables). For the 432 | first 8 rows of the screen, the first 256 entries are used. For the second 8 433 | rows, the second 256 patterns, and for the last 8 rows the third 256 patterns 434 | (depending on the value of control register #4, see below). So the entire PG is 435 | 3 x 256 x 8 = 6144 bytes. Each byte is a pixel line of the character (top 436 | first). If a bit is set, the foreground colour in the CT is used, otherwise 437 | the background colour in the CT. 438 | 439 | Control register #4 which sets the PG address of the PG has a different 440 | function in mode 2. Only bit 2, PG13, sets the address of the PG (so it's either 441 | address 0 or 2000h). Bits 0 and 1 are an AND mask over the character number. 442 | The character number is 0 - 767 (2FFh) and these two bits are ANDed over the 443 | two highest bits of this value (2FFh is 10 bits, so over bit 8 and 9). So in 444 | effect, if bit 0 of control register #4 is set, the second array of 256 445 | patterns in the PG is used for the middle 8 rows of characters, otherwise the 446 | first 256 patterns. If bit 1 is set, the third array of patterns is used in 447 | the PG, otherwise the first. 448 | 449 | The relation PN -> CT is the same as PN -> GT. Each byte in the CT sets the 450 | colour of one pixel line of a character. The high four bits set the foreground 451 | colour, the low the background colour. If either of these is 0, it is 452 | transparent and the colour of the backdrop (BD) is used. 453 | 454 | Also control register #3 has a different meaning. Only bit 7 (CT13) sets the CT 455 | address. Somewhat like control register #4 for the PG, bits 6 - 0 are an AND 456 | mask over the top 7 bits of the character number. 457 | 458 | The TC in control register #7 is not used in this mode. 459 | 460 | 461 | 3.4) Mode 3 462 | 463 | This mode is known as SCREEN 3 in MSX-BASIC, and as MULTICOLOR in the V9938 464 | Technical Data Book. In this mode, each `unit' on the screen is 4 x 4 pixels. 465 | In these units all the pixels have the same colour. Unlike all the other modes 466 | there is no colour spill (each pixel can have any colour). The sprite subsystem 467 | is active. 468 | 469 | The characters are 8 x 8 pixels. There are 32 x 24 characters on the screen, 470 | so the pattern name table (PN) has 768 elements (bytes) which refer to a 471 | pattern in the pattern generator table (PG). Only two bytes of the 8 bytes in 472 | the pattern are used. Which two bytes depends on the vertical row (0 - 23). 473 | The address in the PG can be calculated as follows: 474 | 475 | PG + (byte in PN) x 8 + (row AND 3) x 2 476 | 477 | Each character is 4 units. Each byte sets the color of two blocks of 4 x 4 478 | pixels. The lower four bits set the colour of the left block, the highest four 479 | bits set the colour of the right block. If either is 0, the block is transparent 480 | and the backdrop (BD) is visible. 481 | 482 | The TC in control register #7 is not used in this mode, neither is the colour 483 | table (CT). 484 | 485 | 486 | 3.5) Undocumented Mode 1 + 2 487 | 488 | This mode is very much like Mode 1; the difference is that there can be three 489 | different pattern tables, and control register #4 has a different meaning. 490 | 491 | The pattern table now has 3 x 256 patterns; the screen is divided in three 492 | parts (the top 8 character rows, the middle 8, the bottom 8). Each part can 493 | use a different part of the pattern generator table (the first 256, the second 494 | 256, the last 256). The top part always uses the first 256 patterns in the PG. 495 | 496 | Control register #4: 497 | bit 7 - 3 : ignored 498 | bit 2 : PG13; if set, PG = 2000h otherwise 0 499 | bit 1 : if set, the last 8 rows use the 3rd pattern table otherwise 1st. 500 | bit 0 : if set, the middle 8 rows use the 2nd pattern table otherwise 1st. 501 | 502 | This undocumented mode is not available in the V9938 as far as I know. 503 | 504 | 505 | 3.6) Undocumented Mode 2 + 3 506 | 507 | This mode is very much like Mode 3; it differs in the same way that 508 | undocumented mode 1 + 2 differs from mode 1. See section above for details. 509 | 510 | 511 | 3.7) Other (Mode 1+3 and Mode 1+2+3) 512 | 513 | There are two undocumented modes left: 1+3 and 1+2+3. Something weird happens 514 | in both modes: no longer do the tables have any influence on how the screen 515 | looks like. The screen simply shows 40 vertical lines of text colour (TC). By 516 | the looks of it, it's 4 pixels TC, 2 pixels BD. Like in mode 1, there is a 8 517 | pixel border with colour backdrop (BD) at the left and right of the screen. 518 | It seems possible that memory refresh isn't done any more, but Tursi 519 | tested this, and memory was still intact after a couple 520 | of frames. 521 | 522 | The sprite subsystem is inactive. 523 | 524 | 525 | 4) Sprite system 526 | ---------------- 527 | 528 | In all modes except when M1 is set or BL is reset, the sprite subsystem is 529 | active. Sprites can be either 8 x 8 pixels, or 16 x 16; also these pixels can 530 | be enlarged (twice the size; "zoomed"). 531 | 532 | 533 | 4.1) Sprite attribute table 534 | 535 | 32 different sprites can be display at the same time on the same screen, with 536 | the exception that no more than 4 four sprites can be displayed on one 537 | horizontal pixel line. The location and colour of the sprites is specified in 538 | the sprite attribute table (SA). For each of the 32 sprites, there are four 539 | bytes. 540 | 541 | SA -> 0 Y sprite 0 542 | 1 X sprite 0 543 | 2 sprite pattern 0 544 | 3 colour sprite 0 + EC 545 | 4 Y sprite 1 546 | 5 X sprite 1 547 | 6 sprite pattern 1 548 | 7 colour sprite 1 + EC 549 | . 550 | . 551 | 552 | The values have special meanings. If the Y coordinate is 0, it's displayed on 553 | the second pixel line from the top. With value 255 it's exactly on the the top 554 | line, and with coordinate 254 the top line isn't visible any more, with 253 to 555 | two top lines aren't visible any more, etc. 556 | 557 | If Y is 208, that sprite and all following sprites in the table are not 558 | displayed. 559 | 560 | The X coordinate is simply, as you would expect, the X coordinate from 0 to 561 | 255. If bit 7 of the ``colour sprite'' is set (Early Clock -- EC), the sprite 562 | is moved 32 pixels to the left; in this way it's possible to partially display 563 | the sprite at the left side. 564 | 565 | The lower 4 bits of ``colour sprite'' define the colour. Bit 7 is the EC. 566 | Bits 6 - 4 should be zero officially, but they are ignored. If the colour is 567 | 0, the sprite is transparent (not visible). 568 | 569 | 570 | 4.2) Sprite generator & sizes 571 | 572 | These options are in the control register #1. If bit 0 (MAG) is set, the 573 | sprites are enlarged. If bit 1 (SI) is set, the sprites are 16 x 16 in size, 574 | otherwise 8 x 8. 575 | 576 | The sprite pattern defines which pattern to use. In the case of 8 x 8 sprites, 577 | there are 8 bytes for the sprite pattern, and there are 256 patterns in the 578 | sprite generator table (SG). So simply multiply the sprite pattern by 8 to 579 | get the address in the SG. Each of these bytes set the colour of the pixels 580 | of the sprite. If a bit is set, the pixel has the colour of the ``colour 581 | sprite'' -- unless it is 0, in which case it is transparent. 582 | 583 | In the case of 16 x 16, it is slightly more complex. The SG is still 256 x 8 584 | bytes, and each pattern is 32 bytes now. To calculate the address in the 585 | SG: ((pattern number) AND 252) x 8. The first 16 bytes set the colour of the 586 | left 8 pixels of the sprite, the next 16 bytes set the colour of the right 587 | 16 pixels of the sprite. If it is 0, it is transparent. 588 | 589 | If bit 0 of control register 1 (MAG) is set, the sprites are enlarged. The 590 | starting coordinates are the same, but every pixel of the sprite is 2 x 2 591 | real pixels. 592 | 593 | 594 | 4.3) Illegal sprites & sprite collision 595 | 596 | On each horizontal pixel line, only 4 sprites are allowed. Any more than that 597 | are not displayed. These sprites that aren't displayed are known as ``illegal 598 | sprites''. The first sprite illegal sprite that is detected is put in the 599 | status register. Bit 6 (5S) is set, to show an illegal sprite is detected. The 600 | sprite number (SA element number) is stored in the FS* bits. Note that even 601 | transparent (colour 0) sprites count for illegal sprites, and sprites that 602 | aren't displayed because they're of the left or right side of the screen. 603 | 604 | If no illegal sprite was found, 5S won't be set and FS* contains the highest 605 | sprite number in the SA, either the last (31) or the first with Y coordinate 606 | 208 (if it exists). Note that isn't fully checked (but probably not really 607 | important). 608 | 609 | Remember the screen is built line by line from top to bottom; the first illegal 610 | sprite is on the highest pixel line with an illegal sprite. 611 | 612 | If anywhere on the screen two or more sprites overlap, the C bit of the status 613 | register is set. The colour of the sprite is not important (can even be 0), the 614 | pattern is. If a sprite line is not displayed because it is illegal, it does 615 | not count for sprite collision. The C bit of the status register is reset 616 | after the register is read. 617 | 618 | 619 | 5) Hardware 620 | ----------- 621 | 622 | 5.1) Pin-outs 623 | 624 | TMS9918A 625 | 626 | +--------------+ 627 | _RAS | 1 40 | XLAT2 628 | _CAS | 2 39 | XLAT1 629 | AD7 | 3 38 | CPUCLK 630 | AD6 | 4 37 | GROMCLK 631 | AD5 | 5 36 | COMVID 632 | AD4 | 6 35 | EXTVDP 633 | AD3 | 7 34 | _RESET / SYNC 634 | AD2 | 8 33 | Vcc 635 | AD1 | 9 32 | RD0 636 | AD0 | 10 31 | RD1 637 | R/_W | 11 30 | RD2 638 | Vss | 12 29 | RD3 639 | MODE | 13 28 | RD4 640 | _CSW | 14 27 | RD5 641 | _CSR | 15 26 | RD6 642 | _INT | 16 25 | RD7 643 | CD7 | 17 24 | CD0 644 | CD6 | 18 23 | CD1 645 | CD5 | 19 22 | CD2 646 | CD4 | 20 21 | CD3 647 | +--------------+ 648 | 649 | 650 | TMS9928A 651 | 652 | +--------------+ 653 | _RAS | 1 40 | XLAT2 654 | _CAS | 2 39 | XLAT1 655 | AD7 | 3 38 | R-Y 656 | AD6 | 4 37 | GROMCLK 657 | AD5 | 5 36 | Y 658 | AD4 | 6 35 | B-Y 659 | AD3 | 7 34 | _RESET / SYNC 660 | AD2 | 8 33 | Vcc 661 | AD1 | 9 32 | RD0 662 | AD0 | 10 31 | RD1 663 | R/_W | 11 30 | RD2 664 | Vss | 12 29 | RD3 665 | MODE | 13 28 | RD4 666 | _CSW | 14 27 | RD5 667 | _CSR | 15 26 | RD6 668 | _INT | 16 25 | RD7 669 | CD7 | 17 24 | CD0 670 | CD6 | 18 23 | CD1 671 | CD5 | 19 22 | CD2 672 | CD4 | 20 21 | CD3 673 | +--------------+ 674 | 675 | 676 | 6) To-do 677 | 678 | There are some things still need finding out. 679 | 680 | o How to emulate by scanline: what are the exact timings, when are the 681 | different tables read. 682 | 683 | o What are the colours in PAL mode. 684 | 685 | 686 | 7) References 687 | ------------- 688 | 689 | MSX Handboek voor gevorderden 690 | A Dutch MSX1 technical manual. It's full of mistakes but very complete. 691 | 692 | V9938 MSX-Video Technical Data Book 693 | The be-all, end-all guide to the MSX2 VDP; some things are true for the 694 | TMS9918A VDP too. 695 | 696 | http://www.msxnet.org/tech/tmsposting.txt 697 | A posting by Paul Urbanus (urb@onramp.net) in comp.emulators.misc. 698 | Very interesting stuff about timings and the one r/w address. 699 | 700 | http://home.swipnet.se/~w-16418/tech_vdp.htm 701 | This is an expanded version of my original tms9918a document. It's more 702 | complete than my old version, but this document should be better. :-) 703 | 704 | http://www.mess.org/ 705 | The MESS emulator, includes a TMS9928A emulator nearly all 706 | undocumented features described here are emulated. 707 | 708 | http://www.spies.com/~arcade/dataSheets/ti/TMS9918.pdf 709 | TMS9918 Data Book 710 | --------------------------------------------------------------------------------