Sprinter/mame
2
0
Fork 0
mirror of https://github.com/holub/mame synced 2025-05-23 06:08:48 +03:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

updated comments to match comments from Charles, and fix error in 3wonders mapper table.

Browse Source
This commit is contained in:
Nicola Salmoria 2008-04-07 06:50:10 +00:00
parent 947697a18d
commit 5b36289ee7
1 changed files with 27 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
src/mame/video/cps1.c
View File

@ -120,30 +120,31 @@ Fixed registers
A special note has to be made about tile/sprite codes. Even if all graphics are A special note has to be made about tile/sprite codes. Even if all graphics are
stored together in the same ROMs, all test conducted on the boards seem to show stored together in the same ROMs, the hardware knows which part of the ROM space
that the hardware knows which part of the ROM space is 8x8 tiles, 16x16 tiles, is 8x8 tiles, 16x16 tiles, 16x16 spites, 32x32 tiles, and all games tested only
16x16 spites, 32x32 tiles, and only draws tiles if their code falls in the valid draw tiles if their code falls in the valid range. If a tile is out of range, it
range. If a tile is out of range, it is replaced by transparent pixels. is replaced by transparent pixels.
Ideally, this shouldn't be important as far as the emulation is concerned, since Ideally, this shouldn't be important as far as the emulation is concerned, since
games should only request tiles from valid ranges. In practice, many games contain games should only request tiles from valid ranges. In practice, many games contain
bugs which make them try to display out of range tiles. The masking applied by bugs which make them try to display out of range tiles. The masking applied by
the hardware therefore needs to be emulated properly, otherwise glitches appear. the hardware therefore needs to be emulated properly, otherwise glitches appear.
The ROM board (B-board) changes from game to game, so the implementation details The ROM board (B-board) changes from game to game, so the implementation details
may vary, but the tile ranges seem to be controlled by a PAL found on the B-board may vary, but in general the tile ranges are controlled by a PAL found on the
(see the table above). B-board (see the table at the top of this file).
The A-board passes, it seems (this hasn't been verified accurately), 23 bits of The A-board passes 23 bits of address to the B-board when requesting gfx ROM data.
address to the B-board when requesting gfx ROM data. The ROM board returns 64 The B-board selects 64 bits of data, that is 16 4bpp pixels, and returns half of
bits of data, that is 16 4bpp pixels. them depending on a signal from the C board.
The 23 address bits should be laid out like this (this is unverified speculation): The 23 address bits are laid out this way (note that the top 3 bits select the
tile type; the purpose of the top bit is unknown):
8x 8 tt??ccccccccccccccccyyy sprite 000ccccccccccccccccyyyy
16x16 tt?ccccccccccccccccyyyy scroll1 001?ccccccccccccccccyyy
32x32 tt?ccccccccccccccyyyyyx scroll2 010ccccccccccccccccyyyy
scroll3 011ccccccccccccccyyyyyx
where where
t is the tile type (8x8, 16x16 tile, 16x16 sprite, 32x32; not known which is which)
c is the tile code c is the tile code
y is the y position in the tile y is the y position in the tile
x is the x position in the tile (only applicable to 32x32 tiles) x is the x position in the tile (only applicable to 32x32 tiles)
@ -157,15 +158,15 @@ only one bank.
The above would mean that The above would mean that
1) 8x8 and 16x16 tiles have a 16-bit tile code, while 1) 8x8 and 16x16 tiles have a 16-bit tile code, while
32x32 tiles have a 14-bit tile code (possibly 15-bit, but no game needs that. 32x32 tiles have a 14-bit tile code
Some CPS2 games (ssf2, xmcota) set bit 14, but it seems redundant)
2) which ROM bank to use is determined by 2) which ROM bank to use is determined by
the top 9 bits of a 8x8 tile code, bits 15-7 of a 8x8 tile code,
top 10 bits of a 16x16 tile code, bits 15-6 of a 16x16 tile code,
top 11 bits of a 32x32 tile code bits 13-4 of a 32x32 tile code
Presumably, when the tile code is out of range, the PAL doesn't output any OE signal If the PAL decides that the tile code is out of range and doesn't output any /OE
so no ROM is read and 0xffffffffffffffff is returned. signal, no ROM is read and pullup resistors force the result to all 1 (which
means a transparent tile).
Note that there are several known cases (nemo, cawing, 3wonders, varth, etc.) where Note that there are several known cases (nemo, cawing, 3wonders, varth, etc.) where
16x16 tiles are used for BOTH sprites and scroll2. 16x16 tiles are used for BOTH sprites and scroll2.
@ -213,11 +214,7 @@ qad
* layer enable mask incomplete * layer enable mask incomplete
varth varth
* the background color during startup is brown, while it should most likely be * The boot screen of some CPS2 games has a blue background instead of black,
black. This is caused by the background color palette entry (0xbff), however
that entry is definitely correct and used by other games (3wonders, mtwins)
to make the background different from black.
The boot screen of some CPS2 games also has a blue background instead of black,
however that might be the correct behaviour. however that might be the correct behaviour.
@ -445,7 +442,7 @@ static const struct gfx_range mapper_0224B[] =
{ -1 } { -1 }
}; };
static const struct gfx_range mapper_MS24B[] = static const struct gfx_range mapper_MS24B[] = // verified from the PAL
{ {
/* start end type bank */ /* start end type bank */
{ 0x0000, 0x3fff, GFXTYPE_SPRITES, 0 }, { 0x0000, 0x3fff, GFXTYPE_SPRITES, 0 },
@ -507,7 +504,8 @@ static const struct gfx_range mapper_RT24B[] =
{ 0x7000, 0x7fff, GFXTYPE_SCROLL3, 0 }, { 0x7000, 0x7fff, GFXTYPE_SCROLL3, 0 },
{ 0x0000, 0x27ff, GFXTYPE_SCROLL3, 1 }, // 8000-a7ff physical { 0x0000, 0x27ff, GFXTYPE_SCROLL3, 1 }, // 8000-a7ff physical
{ 0x2800, 0x7fff, GFXTYPE_SPRITES | GFXTYPE_SCROLL2, 1 }, // a800-ffff physical { 0x2800, 0x77ff, GFXTYPE_SCROLL2, 1 }, // a800-f7ff physical
{ 0x7800, 0x7fff, GFXTYPE_SPRITES | GFXTYPE_SCROLL2, 1 }, // f800-ffff physical
{ -1 } { -1 }
}; };