From 664dbc718ae199600d377c49f6a8ca6819bbc952 Mon Sep 17 00:00:00 2001 From: David Haywood Date: Wed, 20 Feb 2013 15:26:43 +0000 Subject: [PATCH] some sprite compression notes from Charles & Andrew, if they're not wanted in here I'll strip them out. --- src/mame/drivers/coolridr.c | 79 +++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) diff --git a/src/mame/drivers/coolridr.c b/src/mame/drivers/coolridr.c index 6d116fc8888..d7db4ecebe9 100644 --- a/src/mame/drivers/coolridr.c +++ b/src/mame/drivers/coolridr.c @@ -245,6 +245,85 @@ Note: This hardware appears to have been designed as a test-bed for a new RLE ba ******************************************************************************************************/ +/* + +some Sprite compression notes from Charles and Andrew + +OK so here's what we know. Andrew and I were playing with the ROMs and +Guru traced out connections on the board at the time: + +The ten graphics ROMs are IC1-IC10. Each is 16 bits, and all have a +common enable and common A20 input. All data lines are unique; nothing +is shared. + +There are two independent address buses: +- One drives A0-A19 of IC1-IC5 +- The other drives A0-A19 of IC6-IC10 + +So the ROMs are arranged as 4,194,304 x 160-bit words (very wide), and +are divided into two banks of 2,097,152 x 160-bit words per bank, +where the common A20 input selects which bank is currently being used. +This bank bit may not come from the graphics hardware and could just +be a spare I/O pin on some other chip, we don't know. + +Then, within the current bank selected, the video chip can generate +independent addresses for IC1-5 and IC6-10 in parallel, so that it can +read 80 bits from IC1-5 at one address, and 80 bits from IC6-10 at +another address simultaneously. Or it can drive the same address and +read a 160-bit word at once. Regardless both addresses are restricted +to the same bank as defined through A20. + +From looking at the ROMs there seem to be structures that may be +tables. A table would be needed to associate a tile number with RLE +data in ROM, so that would be a likely function of tables in the ROM. +It may be that the split address design allows the chip to read table +data from one 80-bit port while reading in graphics data from the +other. + +Now this next bit is just an interpretation of what's in the patent, +so you probably already know it: + +The primitive unit of graphics data is a 10-bit word (hence all the +multiples of 10 listed above, e.g. 80 and 160-bit words) The top two +bits define the type: + +0,x : $000 : Type A (3-bit color code, 5-bit run length, 1 bit "cell" flag) +1,x : $800 : Type B (7-bit color code, 2-bit run length) +1,1 : $C00 : Type C (8-bit color code) + +Because the top two bits (which identify the type) are shared with the +color code, this limits the range of colors somewhat. E.g. one of the +patent diagrams shows the upper 4 bits of a Type A pixel moved into +the bottom four bits of the color RAM index, but for type A the most +significant bit is always zero. So that 4-bit quantity is always 0-7 +which is why type A has a limit of 8 colors. + +This is why one of the later diagrams shows the Type B pixel ANDed +with 7F and the Type C pixel ANDed with 3FF, to indicate the two +indicator bits are being stripped out and the remaining value is +somewhat truncated. + +We figured due to the colorful graphics in the game there would be a +large groups of Type C pixels, but we could never find an +rearrangement of data and address bits that yielded a large number of +words with bits 9,8 set. Some of the data looks like it's linear, and +some of it looks like bitplanes. Perhaps tables are linear and +graphics are planar. + +We tried the usual stuff; assuming the 16-bit words from each ROM was +a 160-pixel wide array of 10-bit elements (linear), or assuming each +bit from each ROM was a single bit of a 10-bit word so 16 bits defined +16 10-bit words in parallel (planar), and never got useful output. + +There may be some weird data/address scrambling done to put data in an +order easiest for the hardware to process, which would be +non-intuitive. + +Also the two indicator bits may have different polarities, maybe 0,0 +is Type C instead of 1,1. + +*/ + #include "emu.h" #include "debugger.h"