trunk/src/mame/drivers/coolridr.c
| r21211 | r21212 | |
|---|
| 245 | 245 | |
| 246 | 246 | ******************************************************************************************************/ |
| 247 | 247 | |
| 248 | /* |
| 248 | 249 | |
| 250 | some Sprite compression notes from Charles and Andrew |
| 251 | |
| 252 | OK so here's what we know. Andrew and I were playing with the ROMs and |
| 253 | Guru traced out connections on the board at the time: |
| 254 | |
| 255 | The ten graphics ROMs are IC1-IC10. Each is 16 bits, and all have a |
| 256 | common enable and common A20 input. All data lines are unique; nothing |
| 257 | is shared. |
| 258 | |
| 259 | There are two independent address buses: |
| 260 | - One drives A0-A19 of IC1-IC5 |
| 261 | - The other drives A0-A19 of IC6-IC10 |
| 262 | |
| 263 | So the ROMs are arranged as 4,194,304 x 160-bit words (very wide), and |
| 264 | are divided into two banks of 2,097,152 x 160-bit words per bank, |
| 265 | where the common A20 input selects which bank is currently being used. |
| 266 | This bank bit may not come from the graphics hardware and could just |
| 267 | be a spare I/O pin on some other chip, we don't know. |
| 268 | |
| 269 | Then, within the current bank selected, the video chip can generate |
| 270 | independent addresses for IC1-5 and IC6-10 in parallel, so that it can |
| 271 | read 80 bits from IC1-5 at one address, and 80 bits from IC6-10 at |
| 272 | another address simultaneously. Or it can drive the same address and |
| 273 | read a 160-bit word at once. Regardless both addresses are restricted |
| 274 | to the same bank as defined through A20. |
| 275 | |
| 276 | From looking at the ROMs there seem to be structures that may be |
| 277 | tables. A table would be needed to associate a tile number with RLE |
| 278 | data in ROM, so that would be a likely function of tables in the ROM. |
| 279 | It may be that the split address design allows the chip to read table |
| 280 | data from one 80-bit port while reading in graphics data from the |
| 281 | other. |
| 282 | |
| 283 | Now this next bit is just an interpretation of what's in the patent, |
| 284 | so you probably already know it: |
| 285 | |
| 286 | The primitive unit of graphics data is a 10-bit word (hence all the |
| 287 | multiples of 10 listed above, e.g. 80 and 160-bit words) The top two |
| 288 | bits define the type: |
| 289 | |
| 290 | 0,x : $000 : Type A (3-bit color code, 5-bit run length, 1 bit "cell" flag) |
| 291 | 1,x : $800 : Type B (7-bit color code, 2-bit run length) |
| 292 | 1,1 : $C00 : Type C (8-bit color code) |
| 293 | |
| 294 | Because the top two bits (which identify the type) are shared with the |
| 295 | color code, this limits the range of colors somewhat. E.g. one of the |
| 296 | patent diagrams shows the upper 4 bits of a Type A pixel moved into |
| 297 | the bottom four bits of the color RAM index, but for type A the most |
| 298 | significant bit is always zero. So that 4-bit quantity is always 0-7 |
| 299 | which is why type A has a limit of 8 colors. |
| 300 | |
| 301 | This is why one of the later diagrams shows the Type B pixel ANDed |
| 302 | with 7F and the Type C pixel ANDed with 3FF, to indicate the two |
| 303 | indicator bits are being stripped out and the remaining value is |
| 304 | somewhat truncated. |
| 305 | |
| 306 | We figured due to the colorful graphics in the game there would be a |
| 307 | large groups of Type C pixels, but we could never find an |
| 308 | rearrangement of data and address bits that yielded a large number of |
| 309 | words with bits 9,8 set. Some of the data looks like it's linear, and |
| 310 | some of it looks like bitplanes. Perhaps tables are linear and |
| 311 | graphics are planar. |
| 312 | |
| 313 | We tried the usual stuff; assuming the 16-bit words from each ROM was |
| 314 | a 160-pixel wide array of 10-bit elements (linear), or assuming each |
| 315 | bit from each ROM was a single bit of a 10-bit word so 16 bits defined |
| 316 | 16 10-bit words in parallel (planar), and never got useful output. |
| 317 | |
| 318 | There may be some weird data/address scrambling done to put data in an |
| 319 | order easiest for the hardware to process, which would be |
| 320 | non-intuitive. |
| 321 | |
| 322 | Also the two indicator bits may have different polarities, maybe 0,0 |
| 323 | is Type C instead of 1,1. |
| 324 | |
| 325 | */ |
| 326 | |
| 327 | |
| 249 | 328 | #include "emu.h" |
| 250 | 329 | #include "debugger.h" |
| 251 | 330 | #include "cpu/sh2/sh2.h" |