trunk/src/mame/drivers/coolridr.c
| r21214 | r21215 | |
|---|
| 7 | 7 | |
| 8 | 8 | TODO: |
| 9 | 9 | - decode compressed GFX ROMs for "sprite" blitter (6,141,122 is the patent number) |
| 10 | http://www.google.com/patents/US6141122 |
| 10 | 11 | - DMA is still a bit of a mystery; |
| 11 | 12 | - video emulation is pratically non-existant; |
| 12 | 13 | - SCSP; |
| r21214 | r21215 | |
|---|
| 322 | 323 | Also the two indicator bits may have different polarities, maybe 0,0 |
| 323 | 324 | is Type C instead of 1,1. |
| 324 | 325 | |
| 326 | --- CORRECTION from Charles 20/02/13 |
| 327 | |
| 328 | I was just playing around with decoding this morning, and now I feel |
| 329 | certain the ordering is to take the 16-bit output of each of the 10 |
| 330 | ROMs at a given address and divide that 160-bit word into sixteen |
| 331 | 10-bit words. |
| 332 | |
| 333 | When you do this, you get some kind of animation at 0x3898E0 which is |
| 334 | eight sequential frames of an object with a solid color fill in the |
| 335 | background. Because the size is constant it may be all Type C pixels |
| 336 | (e.g. no run-length) so that could be a good place to start with |
| 337 | shuffling bits/addresses to see how to get a lot of $3xx pixels. |
| 338 | |
| 339 | There's a similar animation at 0x73CEC0, smaller object, 32 frames. |
| 340 | |
| 341 | I think the 'background' data behind the object in both cases might be |
| 342 | a pen number that continuously increases, maybe for flashing effect as |
| 343 | you cycle through the animation. Otherwise you'd expect the background |
| 344 | pixels to be the same in each frame. |
| 345 | |
| 346 | I also wonder if a pixel value of 0000 (type A with run length=0) |
| 347 | indicates a single dot since there are a lot of 0000 words. |
| 348 | |
| 349 | There may be some bit/byte/address swapping needed to still get valid |
| 350 | output. And the tables may be encoded differently, there's a large one |
| 351 | at 0xDE60. |
| 352 | |
| 353 | |
| 354 | |
| 325 | 355 | */ |
| 326 | 356 | |
| 327 | 357 | |
| r21214 | r21215 | |
|---|
| 784 | 814 | if (m_indirect_zoom_enable) |
| 785 | 815 | { |
| 786 | 816 | // with this bit enabled m_blit10 is a look up to the zoom(?) value eg. 03f42600 |
| 817 | //UINT32 temp = space.read_dword(m_blit10); |
| 818 | //printf("road type blit %08x %08x %08x %08x %08x %08x %04x %04x %04x %04x %08x %08x (TEMP %08x) %d %d\n", m_blit0, m_blit1, m_blit2, m_blit3, m_blit4, m_blit5, m_vCellCount, m_hCellCount, m_vZoom, m_hZoom, m_blit10, data, temp, m_vPosition, m_hPosition); |
| 819 | |
| 820 | /* for the horizontal road during attract there are tables 0x480 bytes long (0x120 dwords) and the value passed points to the start of them */ |
| 821 | /* cell sizes for those are are 0011 (v) 0007 (h) with zoom factors of 0020 (half v) 0040 (normal h) */ |
| 822 | /* tables seem to be 2x 8-bit values, possibly zoom + linescroll, although ingame ones seem to be 2x16-bit (corrupt? more meaning) */ |
| 787 | 823 | |
| 788 | | //printf("road type blit %08x %08x %08x %08x %08x %08x %04x %04x %04x %04x %08x %08x %d %d\n", m_blit0, m_blit1, m_blit2, m_blit3, m_blit4, m_blit5, m_vCellCount, m_hCellCount, m_vZoom, m_hZoom, m_blit10, data, m_vPosition, m_hPosition); |
| 789 | 824 | } |
| 790 | 825 | |
| 791 | 826 | |
| 792 | 827 | bitmap_rgb32* drawbitmap; |
| 793 | 828 | |
| 794 | | // guess, you can see the different sizes of bike cross from the left screen to the right where the attract text is |
| 829 | // 0x30 - 0x60 are definitely the left screen, 0x90 - 0xc0 are definitely the right screen.. the modes seem priority related |
| 795 | 830 | if (m_blitterMode == 0x30 || m_blitterMode == 0x40 || m_blitterMode == 0x50 || m_blitterMode == 0x60) |
| 796 | 831 | drawbitmap = &m_temp_bitmap_sprites; |
| 797 | 832 | else // 0x90, 0xa0, 0xb0, 0xc0 |