[???]

Empire City 1931
Seibu/Taito/Romstar 1986

M6100165B
S-0086-002-B0


12MHz                       Z80   4U    2U   5565

                                             SWB
                                             SWA
      2018 6148

                           3032.6K    68705P5

                        2016  3031.5D Z80 YM2203 YM2203
         82S123.A7

S-0086-002A-A0

     3048.9X 3047.8X 3046.7X 3045.6X   2018 2018
     2114   2114
     2114   2114
     2114
     2114                     2016         2P
     
     3044.8K 3043.7K   3042.5K 3041.4K 3040.3K 3039.2K
     3038.8D 3037.7D   3036.5D 3035.4D 3034.3D 3033.2D




[Jul/13/98]

        STREET FIGHT   CHIP PLACEMENT

USES TWO Z80 CPU'S W/TWO TM2203 SOUND
HAS 8-82S129 PROMS THAT WERE NOT SOCKETED ON REAR BD
HAS 1-82S129 & 1-82S123 PROMS ON CONN BD
 
A GAME FROM WEST GERMANY

CHIP #  POSITION   ALL ROMS ARE 27256 EXCEPT A-21 IS  27128
----------------
A-1      4Q      CONN BD
A-2      2Q       "
A-3      5H       "
A-4      5C       "
A-5      9V      BOTTOM BD
A-6      8V       "
A-7      7V       "
A-8      6V       "
A-9      8K       "
A-10     7K       "
A-11     5K       "
A-12     4K       "
A-13     3K       "
A-14     2K       "
A-15     8C       "
A-16     7C       "
A-17     5C       "
A-18     4C       "
A-19     3C       "
A-20     2C       "
A-21     2O       "


-



[???]

Street Fight (c) Seibu Kaihatsu (1986)


0) GENERAL.

The game has two Z80s.
The second CPU controls the two YM2203 sound chips.
There is an OKI M5205 ADPCM chip fed directly from a ROM.
Screen resolution is 256x224 (horizontal CRT).
256 colors on screen.
128 sprites (16x16).


1) ROM CONTENTS.

SF01    Main program code (encrypted)
SF02    Main program code bank-switched? into main cpu space
SF03    Sound program code
SF04    ADPCM voice data
SF05-07 Foreground tile pixel data
SF09    Foreground map data
SF10    Foreground map/tile data
SF11-14 Background tile pixel data
SF15    Background map data
SF16    Background map/tile data
SF17    Character pixel data
SF18-21 Sprite pixel data

All ROMS are 32K except SF17 which is 8K.

Graphics format is a little messy, the 4 planes come from a bit in
the high and low nibble of each byte of a consecutive pair of roms.

All graphics are made of 16x16 (composite) tiles, each of which is composed
of 4 consecutive 8x8 tiles. In all there are 1024 composite (16x16) tiles
for each of the foreground, background and sprite layers. These can be
considered as four banks each of 256 tiles.

Text characters are defined as 8x8 tiles.


2) CPU.

The board has a single? crystal @12.000 MHz.
Both CPU clocks run at 3MHz (12/4).

The main Z80 runs in Interrupt mode 0 (IM0), the game program expects
execution of two different restart (RST) instructions.
RST 10,the main IRQ, is to be triggered each time the screen is refreshed.
RST 08 must be triggered in order to make the game work properly. I haven't
ascertained the exact frequency of this interrupt yet, though the game
appears to run at the correct speed with RST08 at 30Hz. Curiously a trace
on the interrupt pin shows two interrupts occuring at 60Hz, obviously the
VBlank interrupt followed by a second interrupt some 3.3ms later. At some
stage I'll get around to probing the data lines to find the interrupt
vector addresses.

Sound CPU runs in IM1.

The sound CPU lies idle waiting the external IRQ occurrence executing code
from $0100 to $010D.

Game code/data is directly accessible by the main CPU. There is what
appears to be some level data in the second half of sf02 that may
never be bank-switched in!?! Graphics data, ADPCM samples and level maps
are not accessed by the CPUs.

Text video RAM is situated at $D000-$D7FF.


3) MAIN CPU MEMORY MAP.

$0000-$7FFF R   ROM sf01 (encrypted)
$8000-$BFFF R   ROM sf02 (2 x 16k banks selected by D2 of ?)
$C000-$C1FF W   Palette RAM
$C200       R   player 1 controls hard value (negative logic)
                - MSB:x,x,B2,B1,RIGHT,LEFT,DOWN,UP
$C201       R   player 2 controls hard value (negative logic)
                - MSB:x,x,B2,B1,RIGHT,LEFT,DOWN,UP
$C202       R   start buttons (negative logic)
                - MSB:x,x,x,P2,P1,x,x,x:LSB
$C203       R   dipswitch #1 hard value (negative logic)
                - 76543210
                  xxxxx000  - coin A - 1 coin  / 1 credit
                  xxxxx001           - 2 coins / 1 credit
                  xxxxx010           - 1 coin  / 3 credits
                  xxxxx011           - 4 coins / 1 credit
                  xxxxx100           - 1 coin  / 2 credits
                  xxxxx101           - 3 coins / 1 credit
                  xxxxx110           - 1 coin  / 5 credits
                  xxxxx111           - 5 coins / 1 credit
                  xxx00xxx  - coin B - 1 coin  / 1 credit
                  xxx01xxx           - 2 coins / 1 credit
                  xxx10xxx           - 1 coin  / 2 credits
                  xxx11xxx           - 2 coins / 3 credits
                  xx1xxxxx  - test mode setting
                  x1xxxxxx  - continue setting
                  1xxxxxxx  - bullet colour setting
$C204       R   dipswitch #2 hard value (negative logic)
                - 76543210
                  xxxxxxx1  - cabinet style
                  xxxxx11x  - difficulty
                  xxx11xxx  - number of lives (-1)
                  x00xxxxx  - 10,000 & 30,000
                  x01xxxxx  - 20,000 & 40,000
                  x10xxxxx  - 30,000 & 60,000
                  x11xxxxx  - 40,000 & 80,000
                  1xxxxxxx  - demo sound on/off
$C205       R   read to determine coin circuit check status
$C500       W   play fm number
$C600       W   play voice number
$C700       W   ?coin mechanism control?
$C804       W   ?watchdog?
$C806       W   ???
$C807       W   current sprite bank h/w register
                - bank = b2,b0
$D000-$D3FF W   VRAM (Character RAM)
$D400-$D7FF W   VRAM (Attribute RAM)
                - b7    Character bank from SF17
                - b6    Flip Y
                - b5    Flip X
                - b4    ?
                - b3-0  ? Colour/Palette
$D800-$D801 W   foreground layer x coordinate h/w register
$D802-$D803 W   foreground layer y coordinate h/w register
$D804-$D805 W   background layer x coordinate h/w register
$D806,$D808 W   background layer y coordinate h/w register
$D807       W   layer control h/w register
                - b7 = text layer
                - b6 = sprite layer
                - b5 = background layer
                - b4 = foreground layer
                - b0 = video orientation (1=upside-down)
$E000-$FFFF RW  RAM SRM2064C (8k)
$Fxx0-$Fxx3 W   Sprite Ram (every 32 ($20) bytes)
                - xx0 sprite number
                - xx1 sprite attribute
                  - b7  sign extension of x coord
                  - b4  flip x
                - xx2 y coord of sprite
                - xx3 x coord of sprite

4) SOUND CPU MEMORY MAP.

$0000-$7FFF R   ROM (sf03)
$C000       W   YM2203 #1 address register
$C001       W   YM2203 #1 data register
$C800       W   YM2203 #2 address register
$C801       W   YM2203 #2 data register
$E800       W   ??
$F000       R   FM Voice number to play
                - b7    set for valid data latched
                - b6-b0 voice number
$F800-$FFFF RW  RAM


5) COLOR RAM

The palette system is dynamic, the game can show up to 256 different
colors on screen.

Each color component (RGB) depth is 4 bits, two bytes $100 apart are used
for each color code (12 bits).

format: unknown - probably RRRRGGGG - 0000BBBB

I suspect that the colors are organized in sub-palettes, since the graphics
layers are all 4 bits (16 colors) each. Each of the text/graphics layers
have 'attribute' bytes associated with them that would define the palette
usage for each character/tile.

The 16 colours at offset $C0 appear to be the text palette. This group of
colours does not appear to change throughout the game, and the lower 192
colours fade in/out independantly of these 16 - consistent with observations
of the real game. You'd think then that the palette would be reaonably
easy to deduce from the text video ram attribute byte - go ahead and try! :P

The mapping of graphics pixels to palette similarly escapes me, though I
must admit I haven't exhausted all avenues of investigation just yet!

There is a related mystery with the transparency colour. For the most part
colour 15 corresponds to the transparent colour, except in a few cases.

6) TILE-BASED LAYERS

The foreground and background layers comprise static virtual layers which
are 8 screens wide and 16 screens deep. The hardware scrolls around the
layers by reading registers which are updated by sofware every VBlank.
The text layer is fixed and cannot scroll.

The maps that define the foreground and background layers are stored in
ROMs accessed directly by the hardware. They consist of 256 bytes for
each screen which define the tile number, and a corresponding byte in
a matching ROM which defines the tile bank and presumably palette info.

The top and bottom rows of the screen are not visible - resulting in a
256x224 viewport rather than 256 square. The layers can be individually
enabled/disabled. Inactive sprites are 'parked' at row 0.

The rom layout for the foreground and sprite tiles are as you would expect,
with the four 8x8 tiles that make a single composite tile consecutive in
address. The background tiles are interleaved for presumably some good
reason, the first two 8x8 tiles from composite tile n are followed by two
8x8 tiles from the (n+512)'th composite tile.

The map roms are similarly interleaved for the background layer only.

7) SPRITES

The sprites are mapped into RAM locations $F000-$FFFF using only the first
4 bytes from each 32-byte slice. Intervening addresses appear to be
conventional RAM. See the memory map for sprite data format.


[06/03/99]

Street Fight
------------
(c) Seibu Kaihatsu 1986

2 x Z80A (3MHz)
2 x YM2203C (1.5MHz)
1 x OKI 5205 ADPCM (8kHz)

Romset 1
=========

Board 1
-------
01 6P D27256D   sf01.bin
02 9P D27256D   sf02.bin
03 5C D27256D   sf03.bin
04 5H D27256D   sf04.bin

Board 2
-------

05 2C D27256D   sf05.bin
06 3C D27256D   sf06.bin
07 4C D27256D   sf07.bin
08 5C D27256D   sf08.bin
09 7C D27256D   sf09.bin
10 8C D27256D   sf10.bin
11 2H D27256D   sf11.bin
12 3H D27256D   sf12.bin
13 4H D27256D   sf13.bin
14 5H D27256D   sf14.bin
15 7H D27256D   sf15.bin
16 8H D27256D   sf16.bin
17 2L MBM2764   sf17.bin
18 6S D27256D   sf18.bin
19 7S D27256D   sf19.bin
20 8S D27256D   sf20.bin
21 9S D27256D   sf21.bin


Romset 2
--------
A1.4Q          (sf01.bin)

This is exactly the same except for a call to display a
German distribution notice which has been patched out of
the first romset.


[Jan/31/99]

Empire City : 1931
Seibu Kaihatsu Inc., 1986.

Dumped 31/01/1999.

CPU: Z80
SND: Z80 + 2 x YM2203C
RAM: 1x64 (z80) + 1x16 (z80 snd) + 1x16 + 1x16 + 2x16 (near roms 5-8)
OSC: ?

Note about rom IC27.21, this rom is an Intel 27C64 with pins 27 & 26 soldered
together. If i read it as 27C64 i get only FF, if i read it as 27C128 like
all other roms on the board i got datas in the second half, dunno is they are
good.

The board is jamma and is in working state.



[Jan/31/2000]

EMPIRECITY:1931 (JPN Ver.)
(c)1986 SEIBU/TAITO

S-0086-002-B0

MAIN PRG
 1.BIN
 2.BIN

Other ROMs are the same.

Dumped 02/01/2000



[Mar/25/98]

Here are the proms for Empire City!
I couldn't test the board therefor I dont know the Manufakturer, sorry.
1 Z80 and 1 z80 for the sound
2 YM 2203
Unable to see the numbers on the OSC.

-
