Sega System 16B hardware notes by Charles MacDonald WWW: http://cgfm2.emuviews.com Unpublished work Copyright 2001, 2002, 2003 Charles MacDonald This document is in a very preliminary state and is subject to change. Most everything within has been tested and verified on a System 16 board, but please be aware that my testing methods or interpretations of results could be flawed. I can't guarantee that everything is 100% accurate. What's new: [01/12/03] - Added information on ROM board 171-5704 - Added some ROM board connector pin assignments [12/31/02] - Added information on ROM boards 171-5358, 171-5797. - Added information about tile and sprite banking. - Added information on custom 68000 and MCUs. - Added information about alternate background layers. - Expanded description of sprite RAM attributes. - Expanded description of configuration registers. - Removed System 18 information (see s18tech.txt instead) Initial release: - Added information on sprite X coordinate range - Added priority information - Added wire harness pinout and I/O information - Added information on Z80 sound command address - Added more information about I/O area memory map - Added information on sprite rendering - Added info on foreground/background layers Table of contents 1. Hardware overview 2. 68000 memory map 3. Sprites 4. Display timing and interrupts 5. Palette 6. Background and tile RAM 7. Text layer and text RAM 8. Layer priorities 9. Custom CPUs and MCUs 10. Wire harness pinout 11. Assistance needed 12. Credits and acknowledgements 13. Disclaimer ---------------------------------------------------------------------------- 1. Hardware overview ---------------------------------------------------------------------------- The Sega System 16B hardware consists of the following: 68000 - 16-bit CPU used for game logic, inputs, video Z80-B - 8-bit CPU used for sound playback YM2151 - 8-channel 4-operator FM sound chip, for music & effects uPD7759C - ADPCM sample player, used for voices & effects It also has a socket for a 8751 microcontroller which seems to be present in certain versions of some games. I confirmed that the 68000 runs at 10MHz, but I don't know about the other parts. Sega custom IC's: 315-5195 - Unknown (connected to 68000, MCU) 315-5196 - Sprite generator 315-5197 - Tilemap generator 315-5213 - Unknown (PAL) 315-5214 - Unknown (PAL) Memory: 2x TC5565APL-12 - 8Kx8 for the 68000 1x TMM2115BP-10 - 2Kx8 for the Z80-B 2x TMM2115BP-10 - 2Kx8 for the color RAM 2x TMM2115BP-10 - 2Kx8 text layer name table 2x HM65256BLSP-10 - 32Kx8 for the foreground/background layer name tables 2x TMM2018D-45 - 2Kx8 ? 4x TMM2018D-45 - 2Kx8 ? If the System 16B hardware implements sprites anything like Galaxy Force II, then of the latter six 2K RAMs listed, two are used with the high address bit tied to ground to form 2Kx16 sprite RAM. The remaining four make up two 512 entry by 12-bit word line buffers, which is probably for doing double buffered sprite rendering. But apart from the sprite RAM, the rest of this memory isn't accessible by the CPU. ROM boards The System 16B hardware has three types of boards which hold all of the ROMs. Each one can implements sprite banking differently, and can optionally have tile banking and extra hardware for software to use. System 16B mainboard to ROM board connector pinout (incomplete): CN4 A15 - /OE for region 1 CN4 B15 - /OE for region 2 CN4 B16 - /OE for region 3 CN2 A9 - Sprite bank bit 0 (CGB0) CN2 B9 - Sprite bank bit 1 (CGB1) CN2 A10 - Sprite bank bit 2 (CGB2) CN2 B10 - Sprite bank bit 3 (CGB3) CN1 A13 - Background tile index bit 12 CN4 A13 - /CE for all program ROMs (should be unique? 171-5358 only) CN4 B13 - /LWR from 68000 (?) ROM board descriptions Board number: 171-5358 Used by: Shinobi, Tough Turf, etc. Socket Type Description A1 27512 68000 program code (odd) A2 27512 68000 program code (odd) A3 27512 68000 program code (odd) A4 27512 68000 program code (even) A5 27512 68000 program code (even) A6 27512 68000 program code (even) A7 27256 Z80 program code A8 27256 uPD7759 samples A9 27256 uPD7759 samples A10 27256 uPD7759 samples A11 27256 uPD7759 samples B1 27512 Sprite data (odd, bank 0) B2 27512 Sprite data (odd, bank 1) B3 27512 Sprite data (odd, bank 2) B4 27512 Sprite data (odd, bank 3) B5 27512 Sprite data (even, bank 0) B6 27512 Sprite data (even, bank 1) B7 27512 Sprite data (even, bank 2) B8 27512 Sprite data (even, bank 3) B9 27512 Background tiles, bitplane 0 B10 27512 Background tiles, bitplane 1 B11 27512 Background tiles, bitplane 2 Region 0 is used for the chip enable for program ROMs A1 and A4. Region 1 is used for the chip enable for program ROMs A2 and A5. Region 2 is used for the chip enable for program ROMs A3 and A6. Any unpopulated program ROM sockets return the prefetch value when read. There are no provisions for tile banking, so bit 12 of each background tile index has no special meaning. The 4-bit sprite bank value taken from sprite RAM is used as a chip select for each of the four sprite ROM banks: CGB3 : 0= Enable bank 3, 1= Disable bank 3 CGB2 : 0= Enable bank 2, 1= Disable bank 2 CGB1 : 0= Enable bank 1, 1= Disable bank 1 CGB0 : 0= Enable bank 0, 1= Disable bank 0 If multiple banks are enabled there is a bus conflict and random data from the enabled banks is shown. If no banks are enabled it looks like a constant value is shown for every group of four pixels, across the entire width of the display as no end marker is being read. This repeats for the full height of all sprites on-screen. Board number: 171-5704 Used by: Tetris, Altered Beast, Cotton, etc. Socket Type Description A1 27010 Sprite data (odd, pair e) A2 27010 Sprite data (odd, pair f) A3 27010 Sprite data (odd, pair g) A4 27010 Sprite data (odd, pair h) A5 27010 68000 program code (odd) A6 27010 68000 program code (odd) A7 27010 68000 program code (even) A8 27010 68000 program code (even) A10 27256 Z80 program code A11 27010 uPD7759 samples A12 27010 uPD7759 samples A13 27010 uPD7759 samples A14 27010 Background tiles, bitplane 0 (banks 0,1) A15 27010 Background tiles, bitplane 1 (banks 0,1) A16 27010 Background tiles, bitplane 2 (banks 0,1) B1 27010 Sprite data (odd, pair a) B2 27010 Sprite data (odd, pair b) B3 27010 Sprite data (odd, pair c) B4 27010 Sprite data (odd, pair d) B5 27010 Sprite data (even, pair a) B6 27010 Sprite data (even, pair b) B7 27010 Sprite data (even, pair c) B8 27010 Sprite data (even, pair d) B10 27010 Sprite data (even, pair e) B11 27010 Sprite data (even, pair f) B12 27010 Sprite data (even, pair g) B13 27010 Sprite data (even, pair h) B14 27010 Background tiles, bitplane 0 (banks 2,3) B15 27010 Background tiles, bitplane 1 (banks 2,3) B16 27010 Background tiles, bitplane 2 (banks 2,3) Region 0 is used for the chip enable for program ROMs A5 and A7. Region 1 is used for the chip enable for program ROMs A5 and A6. Region 2 is used for tile banking. Tile banking is implemented with a PLS153. The entire area of region 2 maps to it's tile banking registers (The region 2 /OE signal is tied to it's enable input). The PLS153 uses data bits 2-0 and address bit 1 when decoding this area, to form a four byte region with two 3-bit registers mapped to the odd bytes only: $0001 - Bits 2-0 specify the tile bank for text layer tiles and background tiles with bit 12 cleared. $0003 - Bits 2-0 specify the tile bank for background tiles with bit 12 set. This divides the tile ROMs into eight banks of 4096 tiles. Reading any location in this range returns the prefetch value. The PLS153 initializes the tile banks to $07 on power-up. Sprite banking The 4-bit sprite bank value is shared between an address line of the ROM sockets and a 74LS138 as follows: CGB3 = Input C of 74LS138 CGB2 = Input B of 74LS138 CGB1 = Input A of 74LS138 CGB0 = A16 of each 27C010 Outputs 1Y0-1Y7 map directly to chip enables for sprite ROM pairs a-h. This gives the following table of what ROMs and address offsets are selected depending on the bank value used: Bank bits ROMs enabled Offset selected 0 0 0 0 B1/B5 00000-0FFFF 0 0 0 1 B1/B5 10000-1FFFF 0 0 1 0 B2/B6 00000-0FFFF 0 0 1 1 B2/B6 10000-1FFFF 0 1 0 0 B3/B7 00000-0FFFF 0 1 0 1 B3/B7 10000-1FFFF 0 1 1 0 B4/B8 00000-0FFFF 0 1 1 1 B4/B8 10000-1FFFF 1 0 0 0 A1/B10 00000-0FFFF 1 0 0 1 A1/B10 10000-1FFFF 1 0 1 0 A2/B11 00000-0FFFF 1 0 1 1 A2/B11 10000-1FFFF 1 1 0 0 A3/B12 00000-0FFFF 1 1 0 1 A3/B12 10000-1FFFF 1 1 1 0 A4/B13 00000-0FFFF 1 1 1 1 A4/B13 10000-1FFFF Some games such as Tetris do not have some or most of the sockets populated, so bank values selecting those sockets are invalid. The sprite data shown in this case looks the same way as when no banks are selected for the 171-5358 board. Board number: 171-5797 Used by: E-Swat, Golden Axe, etc. Socket Type Description A1 27020 68000 program code (odd) A2 27020 68000 program code (even) A11 27010 uPD7759 samples A12 27010 uPD7759 samples A13 27256 Z80 program code B1 27020 Sprite data (odd, pair a) B2 27020 Sprite data (odd, pair b) B3 27020 Sprite data (odd, pair c) B4 27020 Sprite data (even, pair a) B5 27020 Sprite data (even, pair b) B6 27020 Sprite data (even, pair c) B7 27020 Sprite data (odd, pair d) B8 27020 Sprite data (even, pair d) B11 27020 Background tiles, bitplane 0 B12 27020 Background tiles, bitplane 1 B13 27020 Background tiles, bitplane 2 Region 0 provides the chip select for the program ROMs. Region 1 provides the chip select for the tile bank and math chip hardware. It's not clear what region 2 is used for. Overview The board has two main components, a PLS153 PAL used to implement tile banking, and the 315-5248 / 315-5250 custom chips. These are part of a set of chips used in several games: 315-5248 : Math chip (multiplication) in After Burner, Galaxy Force II 315-5249 : Math chip (division) in After Burner, Galaxy Force II 315-5250 : Math chip (compare) and Z80 sound command latch in After Burner A 74LS139 is used to divide the memory map into four regions. The /OE signal for region 1 enables the 74LS139, and 68K A13, A12 are used as select inputs. 1Y0 goes to the /CEx pins of the 315-5248, 1Y1 goes to the /MCCS pin of the 315-5250, and 1Y2 goes to pin 6 of the PLS153. 1Y3 is unconnected. This gives the following offsets in region 1: xx0000-xx0FFF : Multiplication registers (315-5248) xx1000-xx1FFF : Compare registers (315-5250) xx2000-xx2FFF : Tile banking (PLS153) xx3000-xx3FFF : Unused (1Y3 is unconnected) xx is the address specified by the base address and memory control registers for region 1. This 16K area is repeated througout the bank(s) allocated to region 1. Offsets $0000-$0FFF hold the input and output registers for multiplication. The 315-5248 can multiply two signed 16-bit numbers and provide a signed 32-bit result. It has four word sized registers that repeat throughout the 4K space mapped to it: Offset Read Write $0000 - Return operand A Set operand A $0002 - Return operand B Set operand B $0004 - Return high 31-16 of result Set operand A $0006 - Return bits 15-0 of result Set operand B The result is always ready after updating the operand registers. Reading the result in the opposite order, or multiple times, has no effect. Writing to the operand registers in opposite order or multiple times also does not change the expected result. When writing in byte-sized units, writes to odd addresses have no effect and writes to even addresses duplicate data in the LSB to the MSB. For example: move.b #$AB, $3E0006 move.b #$CD, $3E0007 This will set operand B to $ABAB, not $ABCD as expected. On the other hand, byte reads from any address function normally. Offsets $1000-$1FFF are for the internal registers of the 315-5250. Based on the After Burner schematics, this chip handles comparisons. To the CPU it looks like 24 word-sized registers that repeat throughout the 4K area it's mapped to. I haven't done any testing with it at the moment. Offsets $2000-$2FFF are for tile banking. The PLS153 uses data bits 2-0 and address bit 1 when decoding this area, to form a four byte region with two 3-bit registers mapped to the odd bytes only: $2001 - Bits 2-0 specify the tile bank for text layer tiles and background tiles with bit 12 cleared. $2003 - Bits 2-0 specify the tile bank for background tiles with bit 12 set. This divides the tile ROMs into eight banks of 4096 tiles. Reading any location in this range returns the prefetch value. The PLS153 initializes the tile banks to $07 on power-up. Offsets $3000-3FFF are unused. Writes do nothing and reads return the prefetch value. Regarding region 2, E-Swat initializes the memory map like so: Region 1 at $3E0000, 64K in size Region 2 at $3F0000, 512K in size This setup makes region 2 actually occupy $380000-$3FFFFF, with region 1 overlapping at $3E0000-$3EFFFF. E-Swat uses $3E2001 for tile banking only, and doesn't try to use the math chip or any part of region 2. Trying to access region 2 for the multiplication features of the math chip seems to return the correct values on occassion, but mostly $FFFF is read back. Maybe it's for expansion only, and without extra hardware conflicts with the math chip. Sprite banking The 4-bit sprite bank value is used like so: CGB3 = A17 of each 27C020 CGB2 = Select B1 input of 74LS139 CGB1 = Select A1 input of 74LS139 CGB0 = A16 of each 27C020 Outputs of the 74LS139: (which is always enabled) 1Y0 - /CE for sprite ROM sockets B1 and B4 1Y1 - /CE for sprite ROM sockets B2 and B5 1Y2 - /CE for sprite ROM sockets B3 and B6 1Y3 - /CE for sprite ROM sockets B7 and B8 This gives the following table of what ROMs and address offsets are selected depending on the bank value used: Bank bits ROMs enabled Offset selected 0 0 0 0 B1/B4 00000-0FFFF 0 0 0 1 B1/B4 10000-1FFFF 0 0 1 0 B2/B5 00000-0FFFF 0 0 1 1 B2/B5 10000-1FFFF 0 1 0 0 B3/B6 00000-0FFFF 0 1 0 1 B3/B6 10000-1FFFF 0 1 1 0 B7/B8 00000-0FFFF 0 1 1 1 B7/B8 10000-1FFFF 1 0 0 0 B1/B4 20000-2FFFF 1 0 0 1 B1/B4 30000-3FFFF 1 0 1 0 B2/B5 20000-2FFFF 1 0 1 1 B2/B5 30000-3FFFF 1 1 0 0 B3/B6 20000-2FFFF 1 1 0 1 B3/B6 30000-3FFFF 1 1 1 0 B7/B8 20000-2FFFF 1 1 1 1 B7/B8 30000-3FFFF There are several games (E-Swat, Golden Axe) which do not have sockets B7 and B8 populated, so bank values of 6/7 and E/F are invalid. The sprite data shown in this case looks the same way as when no banks are selected for the 171-5358 board. PLS153N pinout As used for tile banking in 171-5358, 171-5704 boards 1 = 68000 D0 20 = To tile ROM /OE (all) 2 = 68000 D1 19 = To tile ROM /CE (Low three ROMs) 3 = 68000 D2 18 = To tile ROM /CE (High three ROMs) 4 = From CN1 A13 17 = ? 5 = 68000 A1 16 = ? 6 = Enable input 15 = ? 7 = From CN4 B13 14 = ? 8 = (Unused) 13 = ? 9 = (Unused) 12 = ? 10 = Ground 11 = +5v Pin 6 enables the PLS153N internal registers when held low. Pin 4 is an input from bit 12 of the tilemap generator tile index. Pin 7 is the /LWR signal from the 68000. ---------------------------------------------------------------------------- 2. 68000 memory map ---------------------------------------------------------------------------- On power up, the first 64K of 68000 program ROM is mapped to the first 64K of the 68000's address space. The memory map can be changed by software through a set of configuration registers. There are 32 of these write-only, byte sized registers mapped to odd addresses within any 64K bank which has not been defined through the registers themselves. They are mirrored every 64 bytes. Most games access the registers at the following locations: $FE00xx, $FF00xx, $C000xx The first 16 do nothing except as follows: $05 : 68000 is halted when any value is written. $07 : Value written is sent to Z80 sound command latch, and an NMI signal is sent to the Z80. $09 : 68000 is repeatedly reset when any value is written. The remaining 16 control the 68000 memory map: $21 : Memory control for region 0 $23 : Bits 23-16 of region 0 base address $25 : Memory control for region 1 $27 : Bits 23-16 of region 1 base address $29 : Memory control for region 2 $2B : Bits 23-16 of region 2 base address $2D : Memory control for region 3 $2F : Bits 23-16 of region 3 base address $31 : Memory control for region 4 $33 : Bits 23-16 of region 4 base address $35 : Memory control for region 5 $37 : Bits 23-16 of region 5 base address $39 : Memory control for region 6 $3B : Bits 23-16 of region 6 base address $3D : Memory control for region 7 $3F : Bits 23-16 of region 7 base address Word access to even addresses is OK, the data must be in the LSB. Riot City does this when setting up the memory map. It would seem that for each region, any addresses that fall within the defined memory range cause a unique chip enable signal to be generated. The memory map is divided into 64K banks, though the memory control register can allocate more banks for a particular region. Regions 1 and 2 can be used for additional program ROMs or other hardware. All games use the remaining regions as follows: Region 0 - Program ROM Region 3 - 68000 work RAM Region 4 - Text/tile RAM Region 5 - Object RAM Region 6 - Color RAM Region 7 - I/O area The memory control register has the following layout: MSB LSB ----mmss s = These bits define how many 64K banks are allocated for a particular region. Bits 20-16 of the base address specified are masked out depending on the total size: D0 D1 Size Mask 0 0 64K None ($FF0000) 0 1 128K $FE0000 1 0 512K $F80000 1 1 2MB $E00000 If whatever is mapped to a region is smaller than the number of banks allocated for it, it is repeatedly mirrored throughout that region. For example, allocating 2MB for object RAM results in the 2K of RAM being mirrored 1024 times. Tile/text RAM must be set to 128K or larger. Normally the hardware places the tile RAM first and the text RAM at the next bank up. If the size is 64K, then using an even bank only has the text RAM mapped to it, and using on odd bank only has the tile RAM mapped to it. m = The exact use is unknown. For all areas but text/tile RAM, having none or either bit set has no effect, but having both set causes a lock-up. For tile/text RAM only, both bits must be set. If not, the tile/text RAM areas are not mapped to memory and a combination of the prefetch value mixed with garbage data is returned from where the tile/text RAM areas should be. E-Swat sets bit 3 for the I/O area. This causes offsets $0000-0FFF and $3000-$3FFF to have seemingly random data returned in the lower 4 bits of data read from these areas. Maybe it enables more I/O ports. - = Unknown, probably unused All unmapped memory locations return the last word left on the data bus, which is usually the opcode of the instruction following the one that read memory, due to the prefetching. For example: move.w #$330000, d0 ; Assume $33xxxx is unmapped nop ; D0 = $4E71 A few addresses in the I/O area only use some bits of the data bus, and the unused ones are set as shown above. I/O information The I/O area is 16K in size, mirrored repeatedly throughout the 64K segment it's mapped to (e.g. Shinobi has the I/O area set to $C40000, and that address is the same as $C44000 or $C48000). The 16K chunk is divided as so: $0000-0FFF : Reads from any address return the next value off the data bus. Writes to any address go to the miscellaneous control register. (described later) $1000-1FFF : Returns inputs 0, 1, 2, 3 in the LSB of each word, the MSB is set to the next value off the data bus. Only A0 and A1 are used, so the inputs are mirrored every four bytes. $2000-2FFF : Returns DIP switches 0, 1 in the LSB of each word, the MSB is set to the next value off the data bus. Only A0 is used, so the DIP switches are mirrored every two bytes. $3000-3FFF : Reads from any address return the next value off the data bus. Shinobi writes to $C43007 once on startup and modifies bits 1 and 2 of $C43001 during gameplay, though I don't know what this is for (or how these bits are mirrored). The following is a description of various addresses in the I/O area. I'm using the addresses that Shinobi accesses, but remember that the I/O area can be mapped to different addresses and that some locations are mirrored within their respective 4K areas. For inputs 1-4, they all come from the wire harness. (CN1) $C40001 : Miscellaneous control D7 : ? D6 : 1= Screen flip, 0= Normal screen display D5 : 1= Display on, 0= Display off D4 : ? D3 : Output to lamp 2 (1= On, 0= Off) D2 : Output to lamp 1 (1= On, 0= Off) D1 : (Output to coin counter 2?) D0 : Output to coin counter 1 When the screen is flipped through bit 6, the background and text layers are flipped vertically and horizontally, and the sprites are flipped horizontally but *not* vertically - so you'd have to swap the top and bottom line values for each sprite to get them to display properly. Bits 3 and 2 are for the lamps, Alien Syndrome uses them and the same pins are assigned to lamps on the System 24 board. I haven't been able to test bit 1, but the wire harness does allow for two coin counters so in all likelihood this is the second one. $C41001 : Input #1 D7 : Pin a D6 : Pin Z D5 : Pin Y D4 : Pin X D3 : Pin 23 D2 : Pin 22 D1 : Pin 21 D0 : Pin 20 $C41003 : Input #2 D7 : Pin 15 D6 : Pin 14 D5 : Pin 13 D4 : Pin 12 D3 : Pin 11 D2 : Pin 10 D1 : Pin 9 D0 : Pin 8 $C41005 : Input #3 D7 : Pin W D6 : Pin V D5 : Pin U D4 : Pin T D3 : Pin 19 D2 : Pin 18 D1 : Pin 17 D0 : Pin 16 $C41007 : Input #4 D7 : Pin S D6 : Pin R D5 : Pin P D4 : Pin N D3 : Pin M D2 : Pin L D1 : Pin K D0 : Pin J $C42001 : DIP switch #2 D7 : Switch 1 (0= ON, 1=OFF) D6 : Switch 2 (0= ON, 1=OFF) D5 : Switch 3 (0= ON, 1=OFF) D4 : Switch 4 (0= ON, 1=OFF) D3 : Switch 5 (0= ON, 1=OFF) D2 : Switch 6 (0= ON, 1=OFF) D1 : Switch 7 (0= ON, 1=OFF) D0 : Switch 8 (0= ON, 1=OFF) $C42003 : DIP switch #1 D7 : Switch 1 (0= ON, 1=OFF) D6 : Switch 2 (0= ON, 1=OFF) D5 : Switch 3 (0= ON, 1=OFF) D4 : Switch 4 (0= ON, 1=OFF) D3 : Switch 5 (0= ON, 1=OFF) D2 : Switch 6 (0= ON, 1=OFF) D1 : Switch 7 (0= ON, 1=OFF) D0 : Switch 8 (0= ON, 1=OFF) ---------------------------------------------------------------------------- 3. Sprites ---------------------------------------------------------------------------- General information The System 16 sprites are fairly unique, while most video hardware implements sprites as collections of tiles, the System 16 sprites are made out of horizontal strips of graphics data that can span any height and length. A single sprite is defined by 16 bytes of sprite RAM. There is enough space to define 128 sprites. Each entry has the following format: MSB LSB 00: bbbbbbbbtttttttt 02: -------xxxxxxxxx 04: eh-----fpppppppp 06: aaaaaaaaaaaaaaaa 08: 1111bbbbppcccccc 0A: 000000vvvvvhhhhh 0C: ---------------- 0E: mmmmmmmmmmmmmmmm b : Bottom line of sprite t : Top line of sprite x : Sprite X position e : 1= Hide this sprite and remaining sprites in list h : 1= Hide this sprite f : 1= Flip sprite horizontally p : Sprite pitch (width, signed) a : Start address of sprite graphics within 128K bank (word address) 1 : Either unused or more sprite bank select bits b : Sprite bank select bits. (implementation dependant) p : Sprite priority level c : Sprite palette 0 : Sprite Y zoom information v : Sprite Y zoom (0=normal, 31=50% reduction in height) h : Sprite X zoom (0=normal, 31=50% reduction in width) m : Sprite end address - : Unused The bottom and top line values define the sprite height. If the top value is equal to or greater than the bottom value, the sprite is not displayed. The sprite X position defines the starting location of the sprite. The leftmost pixel of the screen is $00B6, and the rightmost is $1F5. The two hide bits are used to disable individual sprites or to mark the end of the sprite list, which prevents the current sprite and all following sprites from being drawn. The sprite pitch is a signed 8-bit number which is added to the sprite bank address after each line is rendered. If the pitch is zero, then the address never changes and the same graphics data is shown for every line. A negative pitch is used to draw vertically flipped sprites, by setting the start address to the last line of the sprite and stepping backwards through the graphics data. The start address specifies a word offset within a 128K bank. The address is used internally by the sprite hardware and is not modified; the final address used when the sprite has been rendered is written to the sprite end address field (word 7) of the sprite RAM entry. The sprite bank bits are output to the ROM board while a sprite is being rendered. Hardware on the board uses the value to select what 128K bank will be selected. See the section on ROM boards for more information. The sprite priority level defines where sprites are placed between the tile and text layers. See the section on priority for more information. The sprite palette selects which one of 64 16-color palettes will be use to draw the sprite. A palette of $3F is a special case and enables shadow/hilight processing, see the palette section for more information. The X and Y zoom values shrink the sprite by skipping pixels and lines to cause up to a 50% reduction of height and width. Not all games use this feature. Word 7 of each entry is filled in by the sprite generator. It writes the address of the last word it accessed within a sprite bank while rendering a sprite. If the sprite has a pitch of zero, is hidden, or if the bottom line is smaller than the top line, the start address is written as the end address. (so no sprite data accessed) The end address is only affected by the start address, height, pitch, and Y zoom. The sprite X position, horizontal scaling and flip, and actual graphics data from a bank has no effect on it. In the same way bits 15-10 of word 5 of each entry are also filled in by the sprite generator. Normally zero is written if the Y zoom value is zero, and it changes based on a non-zero Y zoom value, the start address, pitch, and top/bottom line values. I'm not sure what it is supposed to represent, however. It may be the top few bits of a larger internal value, such as the number of words skipped during zooming. The sprite generator writes this information sometime after the active display period, probably during vblank. If you write a value into the high bits of the zoom word or the end address word, you can read the value back until the sprite hardware renders sprites for this frame and fills in the values itself. Sprite data Sprite pattern data is arranged as groups of words, within each word every four bits defines one pixel, like so: MSB LSB aaaabbbbccccdddd a = Pixel 0 b = Pixel 1 c = Pixel 2 d = Pixel 3 Some sprite pixel values have special meanings. Zero is transparent; such pixels are not displayed. A value of 15 indicates an end marker - this is also transparent, but additionally tells the sprite generator to stop drawing the current line of a sprite. It's the end markers that define the width of the sprite, which can vary on every line. I'll discuss the end markers later on. The pitch attribute for each sprite defines the value added to the start address after a line of the sprite has been rendered. The value is a signed byte, so $01 is 1 word, $FF is -1 word, and $00 really is zero, meaning the address is never changed. To draw vertically flipped sprites, the sprite pitch is made negative and the address is set to the end of the sprite rather than the beginning. The sprite generator will draw the last line of the sprite, then decrement the address to point the next to last line, render it, and so on. Sprite rendering For normal sprites, the sprite generator adds the pitch to the base address first, then starts reading words from the current bank and displays pixels accordingly. If the last pixel of any four pixel group is set to $0F, it stops rendering the sprite once the other pixels have been drawn. The pitch is then added to the base address, and the process repeats for the next line. This occurs on all lines that the sprite falls within. For horizontally flipped sprites, the sprite generator starts reading words from the base address plus an offset which is set to the pitch value. The offset is decreased as each group of four pixels is displayed. If the first pixel from any four pixel group is set to $0F, it stops rendering the sprite once the other pixels have been drawn. Sprite banks Graphics data for the sprites is stored in banks that are 128K in size, comprised of two 8-bit ROMs which are interleaved to form a 64K-word bank. While the starting address in the sprite attributes is only 16 bits in size, the sprite generator fetches data in units of one 16-bit word at a time, so this is enough to span an entire 128K bank. When the sprite generator accesses data from a bank, it's address into the bank wraps at $FFFF back to zero. For example, a particularly large sprite that had data at $FE80 would use data up to $FFFF, and then start using data from $0000 onwards, of the *same* bank. ---------------------------------------------------------------------------- 4. Display timing and interrupts ---------------------------------------------------------------------------- The video hardware generates a 262-line frame 60 times a second. Within each frame, the active display period uses 224 lines and the remainder is for vertical blanking and retrace. At the start of line 223, a level 4 interrupt is generated which signifies the beginning of the vertical blanking period. Since this happens on the last line of the active display area, changes to the palette (or any other kind of memory that alters the display) will still be visible. The level 4 interrupt is automatically acknowledged by the video hardware. If it is masked by SR when it is supposed to occur, the interrupt will be generated as soon as SR is changed to permit it (even on a different scanline or frame). ---------------------------------------------------------------------------- 5. Palette ---------------------------------------------------------------------------- The output of the tilemap and sprite generators is combined by custom hardware which determines priority between the various layers and ends up with a 12-bit index into the 4K of color RAM. Each 16-bit entry in color RAM has the following layout: D15 : Shade hi/lo D14 : Blue bit 0 D13 : Green bit 0 D12 : Red bit 0 D11 : Blue bit 4 D10 : Blue bit 3 D9 : Blue bit 2 D8 : Blue bit 1 D7 : Green bit 4 D6 : Green bit 3 D5 : Green bit 2 D4 : Green bit 1 D3 : Red bit 4 D2 : Red bit 3 D1 : Red bit 2 D0 : Red bit 1 Shadow / hilight mode is explained later. Up to 32768 colors can be generated by the video hardware. Palette usage: Tiles from the text layer use color entries 0 to 63, divided into eight 8-color palettes. Tiles from the foreground and background layers use color entries 0-1023, divided into 128 8-color palettes. Sprites use color entries 1024-2047, divided into 64 16-color palettes. The backdrop color is shown behind all layers in the active display area and is selected from palette entry #0. The remainder of the frame (meaning overscan, vertical retrace, and vertical blank) is always shown as black. If the display is turned off through bit 5 of $C40001, the affected lines are also shown as black. Palette flicker: The color RAM has one data bus that is shared between the video hardware and the CPU. If you try to read or write color RAM during the active display period, the CPU access has precendence and the data it reads or writes will select the color for the current pixel being displayed. This does not occur outside of the active display period or when the display is turned off, since color RAM is not being used. Shadow / hilight processing: If a sprite uses palette $3F, its' pixels with values 1 to 14 change how underlying pixels from the background are shown (Values 0 and 15 are still treated as transparent). For each background pixel that is obscured by the sprite in question, bit 15 of its' corresponding entry from color RAM is checked. If cleared, the color is shown at half intensity. If set, the color is shown at double intensity (or brightness, if that's a better way to describe it). The actual sprite pixel is not shown at all. Most games leave bit 15 cleared in all entries, so any sprite using palette $3F will create a shadow. Sprite priority still works in the same way: if a shadow or hilight sprite is behind one layer but in front of another, only the pixels behind the sprite are affected. Shadow and hilight processing affects the backdrop color, text layer, and both the foreground and background layers. It has no effect on other sprites. If two sprites overlap each other and one of them uses palette $3F, the last one drawn (having the highest inter-sprite priority) will select how the background is affected. ---------------------------------------------------------------------------- 6. Background and tile RAM ---------------------------------------------------------------------------- The System 16 video hardware has two tiled backgrounds, which are called the background and foreground. Each one is defined by a 128x64 virtual name table, which is itself composed of four smaller 64x32 name tables. The tile RAM holds sixteen 64x32 name tables which are selected through the page selection registers (in text RAM). The four nibbles from the page select register sets up the corresponding layer like so: Name Table A Name Table B Name Table C Name Table D The advantage of this system is that the same subtables can be used to save space while forming a larger virtual name table. Each entry in tile RAM is one word. Some bits have several attributes mapped to them, so the following layout shows each function for each bit: MSB LSB ---nnnnnnnnnnnnn Tile index (0-8191) ---ccccccc------ Palette (0-127) p--------------- Priority flag -??------------- Unknown The tile index picks one of 8192 tiles to display. Depending on the ROM board used, some games implement tile banking by using bit 12 of the tile index to select one of two banks, and the remaining bits as an offset into a 4096-tile bank. See the section on ROM boards for more details. The palette is associated with the tile index used. Some games have the same graphics duplicated in the tile ROMs so they can be used with different palettes. The priority flag is explained in the priority section later on. It affects the background tile's relation with sprites only, not with other layers. Bits 14, 13 have no effect on the tile priority (with the sprites or background), the tile colors, or the tile index. They could be unused. ---------------------------------------------------------------------------- 7. Text layer and text RAM ---------------------------------------------------------------------------- Text RAM is used to store the name table data for the text layer, as well as holding data for controlling the background and foreground layers. There is 4K of text RAM, and it is mapped 64K higher than the base of the tile RAM. Text RAM layout: $000-DFF : Text layer name table (64x28) $E00-E7F : Unused $E80-EFF : Unused, except for the following addresses: $E80 : Foreground page select $E82 : Background page select $E84 : Foreground page select (alternate) $E86 : Background page select (alternate) $E90 : Foreground vertical scroll / column scroll enable $E92 : Background vertical scroll / column scroll enable $E94 : Foreground vertical scroll (alternate) $E96 : Background vertical scroll (alternate) $E98 : Foreground horizontal scroll / row scroll enable $E9A : Background horizontal scroll / row scroll enable $E9C : Foreground horizontal scroll (alternate) $E9E : Background horizontal scroll (alternate) $F00-F3F : Foreground column scroll table $F40-F7F : Background column scroll table $F80-FBF : Foreground row scroll table $FC0-FFF : Background row scroll table Text layer name table format: MSB LSB p???cccnnnnnnnnn p : Priority. If 0, sprites with priority level 3 are shown over the text. If 1, the text layer is shown over sprites regardless of priority. c : Color palette n : Tile index to use ? : Unknown The name table is 64x28, but only 40x28 is shown. The viewable portion of the name table starts at column 24 and goes to column 63, which maps to screen columns 0 through 39. Page select registers: MSB LSB aaaabbbbccccdddd a : Page # for upper left page b : Page # for upper right page c : Page # for lower left page d : Page # for lower right page Vertical scroll / column scroll enable registers: MSB LSB e??????yyyyyyyyy e : 1= Enable column-based scroll, 0= Enable whole screen vertical scroll y : Scroll value for whole screen vertical scroll ? : Unknown Horizontal scroll / row scroll enable registers: MSB LSB e?????xxxxxxxxxx e : 1= Enable row-based horizontal scroll, 0= Enable whole screen horizontal scroll y : Scroll value for whole screen horizontal scroll ? : Unknown Column scroll table format: MSB LSB ???????yyyyyyyyy y : Scroll value ? : Unknown Row scroll table format: MSB LSB e?????xxxxxxxxxx e : Enable alternate foreground or background layer for this row x : Scroll value ? : Unknown The row scroll works on units of 8 scanlines, the column scroll works on units of 16 pixels (two tiles). In column scroll mode, the columns aren't affected by horizontal scrolling (either whole screen or row based), rather the vertical scroll value from the column scroll table is applied to the display based on the current pair of tiles being displayed (0 to 19). Each column is offset to the right by the lower 3 bits of the horizontal scroll value, and the upper 7 bits select an offset into the name table (this is almost identical to how the Sega Genesis VDP handles column-based vertical scrolling). For any entry in the row scroll table, having bit 15 set disables the main foreground or background layer respectively and enables an alternate foreground or background layer for that row only, which uses the page and scroll values provided by the alternate layer registers. The alternate layers cannot have row or column scrolling applied. They are shown in replacement of the main layers, and are not additional ones (so still only one foreground and one background plane are available) This feature would be most useful for split screens and status screens, which would otherwise need an entire background layer used exclusively for them, or require use of raster effects. ---------------------------------------------------------------------------- 8. Layer priorities ---------------------------------------------------------------------------- The priority order is as follows: Highest Lowest T1 > S3 > T0 > F1 > S2 > F0 > B1 > S1 > B0 > S0 > G Key: G = Backdrop color S = Sprites (0-3) B = Background layer (0-1) F = Foreground layer (0-1) T = Text layer (0-1) The foreground, background, and text layer have two priority levels, while sprites have four. The tilemap priority settings only affect sprites; they cannot make tiles from any layer appear over or under any others. (So the default order is always T > F > B > G not counting sprites) And likewise, the sprite priority settings only affect their relationship with the tilemaps; the inter-sprite priority is not changed. ---------------------------------------------------------------------------- 9. Custom CPUs and MCUs ---------------------------------------------------------------------------- Some System 16B games have a custom 68000 or Z80 that executes encrypted program code. They may also have an Intel 8751 MCU. The custom 68000 is a black epoxy block with a plastic shell around it. The shell has a metal lid over the top which covers a small rectangular recession, containing a regular CR2032-looking battery that is connected to two wires that come from holes in either wall. A third wire is soldered from the battery to the underside of the metal lid, meaning the battery will be ripped out if the lid is removed too quickly or without enough caution. The metal lid has the text "HITACHI FD1094", and a sticker labeled "SEGA 315-0197". This number changes depnding on the game it's used with, all encrypted games have different Sega part numbers. The 68000 executes encrypted program code. It will not run unencrypted code located in the ROM area or at higher addresses outside of the ROM region (I tried tile RAM at $400000). The initial PC and SP values are also encrypted, and the rest of the vector table is not encrypted. The custom Z80 used in some versions of Shinobi is a black epoxy block with a plastic shell around it. The shell has the text "NEC MC-8123B 651" printed on the top, and a sticker labeled "SEGA 317-0054". Inside the epoxy block is a 3 volt battery, the one I have was labeled "MATSUSHITA ELECTRIC BR1125 LITHIUM". There's also a Fujitsu MB3771 power supply monitor which switches between the battery or the regular 5 volt source when the board is powered on. I think the drain on the battery is fairly low, as the board I have is from 1986 and still works with very infrequent usage. The custom Z80 can be replaced with a regular Z80-B and unencrypted program code from another version of Shinobi (but System 16B only, as the System 16A sound hardware is a bit different), and the sound will work - I've read that this has been done to fix boards that had no sound output but otherwise worked OK. Presumably in this case the battery had died and the Z80 could no longer decrypt the program code. Here are my observations of how an 8751 MCU is used in Tough Turf: The MCU reads the input ports (player 1, 2, service) and stores their values into 68000 work RAM. It also accesses the Z80 sound command latch itself, presumably taking the proper value to use from a location in work RAM. It seems that if the first 32K-48K or so of ROM data is modified, the MCU causes the hardware to lock up. Perhaps it compares a checksum of ROM to an expected value, and hangs the machine if they don't match. If the MCU is removed, the game functions normally except for missing inputs and no sound. ---------------------------------------------------------------------------- 10. Wire harness pinout ---------------------------------------------------------------------------- The System 16B boards use a non-JAMMA pinout that is also used with the System 24 board. (and possibly others) Component Side Pin # Solder Side Ground 1 A Ground Ground 2 B Ground +5 Volts DC 3 C +5 Volts DC +5 Volts DC 4 D +5 Volts DC +12 Volts DC 5 E +12 Volts DC Coin Meter 1 6 F Coin Meter 2 Lamp 1 7 H Lamp 2 Input 8 J Input Input 9 K Input Input 10 L Input Input 11 M Input Input 12 N Input Input 13 P Input Input 14 R Input Input 15 S Input Input 16 T Input Input 17 U Input Input 18 V Input Input 19 W Input Input 20 X Input Input 21 Y Input Input 22 Z Input Input 23 a Input Speaker (+) 24 b Speaker (-) Monitor Red 25 c Monitor Green Monitor Blue 26 d Composite Sync Ground 27 e Ground Ground 28 f Ground Since the function of the various inputs is dependant on the game used, I haven't listed any specifics (such as joystick or button use). I modified the System 24 pinout found on spies.com for the above layout, so thanks to whomever typed that up in the first place. ;) ---------------------------------------------------------------------------- 11. Assistance needed ---------------------------------------------------------------------------- - Schematics for pre System-16, System 16A/16B or System 18 boards would be greatly appreciated. :) - Are there any other types of ROM boards beyond than the three I've documented? ---------------------------------------------------------------------------- 12. Credits and acknowledgements ---------------------------------------------------------------------------- - Sega for their great arcade games. - Thierry Lescot and Nao for the System 16 emulator. - The MAME team for the System 16/18 drivers. - Sixtoe for maintaining the Sega Museum / System 16 website. ---------------------------------------------------------------------------- 13. Disclaimer ---------------------------------------------------------------------------- If you use any information from this document, please credit me (Charles MacDonald) and optionally provide a link to my webpage (http://cgfm2.emuviews.com/) so interested parties can access it. The credit text should be present in the accompanying documentation of whatever project which used the information, or even in the program itself (e.g. an about box). Regarding distribution, you cannot put this document on another website, nor link directly to it.