|
KONAMI CUSTOM CHIPS
[ Home ] - [ Konami Hardware Page ]
052526 and 053248 and 052001 are mostly the same thing, the special konami cpu that they abused for the simpsons.
Konami 1
CPU |
| The Konami-1 is based on a 6809 with some minor modifications, it was Konami's first custom chip |
005885
Tilemap Generator |
Some games use two of these in pair. Jackal even puts together the two 4bpp tilemaps to form a single 8bpp one.
It manages sprites and 32x32 or 64x32 tilemap (only Double Dribble uses the 64x32 one).
The chip also generates clock and interrupt signals suitable for a 6809.
It uses 0x2000 bytes of RAM for the tilemaps and sprites, and an additional 0x100 bytes, maybe for scroll RAM and line buffers. The maximum addressable ROM is 0x20000 bytes (addressed 16 bits at a time). Tile and sprite data both come from the same ROM space. Double Dribble and Jackal have external circuitry to extend the limits and use separated addressing spaces for sprites and tiles.
All games use external circuitry to reuse one or both the tile flip attributes as an additional address bit.
Two 256x4 lookup PROMs are also used to increase the color combinations.
All tilemap / sprite priority handling is done internally and the chip exports 5 bits of color code, composed of 1 bit indicating tile or sprite, and 4 bits of ROM data remapped through the PROM. |
007121
Tilemap Generator |
This is an interesting beast. It is an evolution of the 005885, with more features. Many games use two of these in pair.
It manages sprites and two 32x32 tilemaps. The tilemaps can be joined to form a single 64x32 one, or one of them can be moved to the side of screen, giving a high score display suitable for vertical games.
The chip also generates clock and interrupt signals suitable for a 6809.
It uses 0x2000 bytes of RAM for the tilemaps and sprites, and an additional 0x100 bytes, maybe for scroll RAM and line buffers. The maximum addressable ROM is 0x80000 bytes (addressed 16 bits at a time). Tile and sprite data both come from the same ROM space.
Two 256x4 lookup PROMs are also used to increase the color combinations.
All tilemap / sprite priority handling is done internally and the chip exports 7 bits of color code, composed of 2 bits of palette bank, 1 bit indicating tile or sprite, and 4 bits of ROM data remapped through the PROM. |
007324
Tilemap Generator |
The 007342 manages 2 64x32 scrolling tilemaps with 8x8 characters, and optionally generates timing clocks and interrupt signals. It uses 0x2000 bytes of RAM, plus 0x0200 bytes for scrolling, and a variable amount of ROM.
It cannot read the ROMs. |
007420
Sprite Generator |
| 8 bytes per sprite with zoom. It uses 0x200 bytes of RAM, and a variable amount of ROM. Nothing is known about its external interface. |
051316
Tilemap Generator - Zoom and Rotate |
Manages a 32x32 tilemap (16x16 tiles, 512x512 pixels) which can be zoomed, distorted and rotated.
It uses two internal 24 bit counters which are incremented while scanning the picture. The coordinates of the pixel in the tilemap that has to be drawn to the current beam position are the counters / (2^11).
The chip doesn't directly generate the color information for the pixel, it just generates a 24 bit address (whose top 16 bits are the contents of the tilemap RAM), and a "visible" signal. It's up to external circuitry to convert the address into a pixel color. Most games seem to use 4bpp graphics, but Ajax uses 7bpp.
If the value in the internal counters is out of the visible range (0..511), it is truncated and the corresponding address is still generated, but the "visible" signal is not asserted. The external circuitry might ignore that signal and still generate the pixel, therefore making the tilemap a continuous playfield that wraps around instead of a large sprite. |
051550 |
| This does the coin counters and the power on reset function for the graphics chips/sound section. |
051733 |
Sort of a protection device, used for collision detection, and for arithmetical operations.
It is passed a few parameters and returns the result. |
051960 / 051937
Sprite Generators |
Designed to work in pair.
The 051960 manages the sprite list and produces and address that is fed to the gfx ROMs. The data from the ROMs is sent to the 051937, along with color code and other stuff from the 051960. The 051937 outputs up to 12 bits of palette index, plus "shadow" and transparency information.
Both chips are interfaced to the main CPU, through 8-bit data buses and 11 bits of address space. The 051937 sits in the range 000-007, while the 051960 in the range 400-7ff (all RAM). The main CPU can read the gfx ROM data though the 051937 data bus, while the 051960 provides the address lines.
The 051960 is designed to directly address 1MB of ROM space, since it produces 18 address lines that go to two 16-bit wide ROMs (the 051937 has a 32-bit data bus to the ROMs). However, the addressing space can be increased by using one
or more of the "color attribute" bits of the sprites as bank selectors. Moreover a few games store the gfx data in the ROMs in a format different from the one expected by the 051960, and use external logic to reorder the address lines.
The 051960 can also genenrate IRQ, FIRQ and NMI signals. |
051961
CPU |
| Old games use 051961 instead of 052109, it is an earlier version functionally equivalent (maybe 052109 had bugs fixed). The list always shows 052109 because the two are exchangeable and 052109's are found also on original boards whose schematics show a 051961 |
052109 / 051962
Tilemap Generators |
These work in pair.
The 052109 manages 3 64x32 scrolling tilemaps with 8x8 characters, and optionally generates timing clocks and interrupt signals. It uses 0x4000 bytes of RAM, and a variable amount of ROM. It cannot read the ROMs : instead, it exports 21 bits (16 from the tilemap RAM + 3 for the character raster line + 2 additional ones for ROM banking) and these are externally used to generate the address of the required data on the ROM; the output of the ROMs is sent to the 051962, along with a color code. In theory you could have any combination of bits in the tilemap RAM, as long as they add to 16.
In practice, all the games supported so far standardize on the same format which uses 3 bits for the color code and 13 bits for the character code.
The 051962 multiplexes the data of the three layers and converts it into palette indexes and transparency bits which will be mixed later in the video chain.
Priority is handled externally: these chips only generate the tilemaps, they don't mix them.
Both chips are interfaced with the main CPU. When the RMRD pin is asserted, the CPU can read the gfx ROM data. This is done by telling the 052109 which dword to read (this is a combination of some banking registers, and the CPU address lines), and then reading it from the 051962. |
053245 / 053244
Sprite generators |
The 053245 has a 16-bit data bus to the main CPU.
The sprites are buffered, a write to 006 activates to copy between the main ram and the buffer. |
053247 / 053246
Sprite generators |
Nothing is known about their external interface.
The sprite RAM format is very similar to the 053245 (above) |
053251
Priority encoder |
The chip has inputs for 5 layers (CI0-CI4); only 4 are used (CI1-CI4), CI0-CI2 are 9(=5+4) bits inputs, CI3-CI4 8(=4+4) bits
The input connctions change from game to game
E.g. In Simpsons:
CI0 = Ground (background color)
CI1 = sprites
CI2 = FIX
CI3 = A
CI4 = B
in Lightning Fighters:
CI0 = Ground (background color)
CI1 = sprites
CI2 = FIX
CI3 = B
CI4 = A
There are three 6 bit priority inputs, PR0-PR2
Simpsons:
PR0 = 111111
PR1 = xxxxx0 x bits coming from the sprite attributes
PR2 = 111111
Lightning Fighters:
PR0 = 111111
PR1 = 1xx000 x bits coming from the sprite attributes
PR2 = 111111
Also two shadow inputs, SDI0 and SDI1 (from the sprite attributes)
The chip outputs the 11 bit palette index, CO0-CO10, and two shadow bits. |
053252 |
| From the Vendetta schematics this seems to be just a timing/interrupt controller |
054000 |
Sort of a protection device, used for collision detection.
It is passed a few parameters, and returns a boolean telling if collision happened. It has no access to gfx data, it only does arithmetical operations on the parameters. |
054156 / 054157
Tilemap Generators |
These work in pair. Similar in principle to the 052109/051962, they manage 4 64x32 or 64x64 tilemaps. They also handle linescroll on each layer, and optional tile banking. They use 4000 to 10000 bytes of RAM, organized in 1000 or 2000 bytes banks.
Known configurations:
4 1000 bytes banks, tile banking, 64x32 tilemaps - asterix
4 2000 bytes banks, no tile banking, 64x32 tilemap: - gijoe, bucky 'o hare
8 2000 bytes banks, no tile banking, 64x32 or 64x64 tilemaps - xexex
Preliminary results indicate that konami system gx seems to use a similar chip with 16 banks and 128x64 tilemaps. |
054539 |
| A 8 channel sound chip and can play ADPCM, 8-bit, or 16-bit samples |
055555 |
| A 5-bit-per-pixel priority encoder with 6 inputs. It can do variable alpha blending and probably a few other special graphics tricks that are currently undocumented |
055673 |
| A replacement for the 053247 that is compatible but allows 5 bits per pixel instead of the 4 in the 053247, and is still paired with the 53246 |
056800 |
| Sound latch (lets the main CPU communicate with the sound). Used on pretty much everything GX and later it looks like. |
056832 |
| A replacement for the 054157 that is compatible but allows 5 bits per pixel instead of the 4 in the 054157, and is still paired with the 54156 |
058141 |
| Basically 2 x 54539's integrated onto the same ship / 16 channel sound chip and can play ADPCM, 8-bit, or 16-bit samples |
|
