Sega System 24 Hardware Notes (2013-06-16)
From Sega Retro
 |
This is a copy of an "unofficial" document containing original research, for use as a source on Sega Retro. This page likely exists for historical purposes - the contents should ideally be copy-edited and wikified to make better use of Sega Retro's software. Original source: https://web.archive.org/web/20140318183124/cgfm2.emuviews.com/new/s24hw.txt |
Sega System 24 Hardware Notes
(C) 2013 Charles MacDonald
[6/16/13]
- Added ABSEL override mode description.
- Added line scroll description.
- Clarified I/O chip address connections.
- Fixed some typos.
[4/1/13]
- Initial release.
----------------------------------------------------------------------------
System overview
----------------------------------------------------------------------------
Memory map
Custom chip 315-5295 at IC5 does address decoding for both CPUs:
000000-07FFFF : BIOS ROM (CPU B DRAM if accessed by CPU B)
080000-0FFFFF : CPU A DRAM
100000-1FFFFF : BIOS ROM (accessible to both CPUs)
200000-3FFFFF : 315-5292 (Tilemap chip)
400000-5FFFFF : 315-5294 (Mixer chip and color RAM)
600000-7FFFFF : 315-5293 (Sprite chip)
800000-9FFFFF : 315-5296 (I/O chip)
A00000-AFFFFF : 315-5295 (315-5295 at IC7, timer and interrupt controller)
B00000-BFFFFF : Expansion (CN2, /EXCS0)
C00000-CFFFFF : Expansion (CN2, /EXCS1)
D00000-DFFFFF : Expansion (CN5, /EXCS2)
E00000-EFFFFF : Expansion (To test point)
F00000-F3FFFF : CPU B DRAM
F40000-F7FFFF : CPU B DRAM
F80000-FBFFFF : CPU A DRAM
FC0000-FFFFFF : CPU A DRAM
DRAM is 256K, mirrored twice in each 512K region it is mapped to.
Some versions of the BIOS test to see if the DRAM is 512K or 256K.
See the board revisions section for more details.
ROM is 256K, mirrored repeatedly throughout the 1MB area it is assigned to.
Bus structure
The various components in the memory map are split across two independent
busses in the system
T-bus (CPU A)
- CPU A DRAM
- BIOS ROM
- Interrupt controller and timer (IC7) ("INTC")
- I/O chip
- YM2151
- CN2 expansion connector (System 24 specific I/O, FDC, and ROM boards)
- CN5 expansion connector (Compatible with earlier Sega I/O boards)
P-bus (CPU B)
- CPU B DRAM
- Tilemap generator
- Object generator
- Mixer chip
- Color RAM
System timing
Wait states for CPU A when accessing memory with CPU B held
in the reset state (/RESP=L).
BIOS ROM : No wait states.
INTC registers : No wait states.
Color RAM / Mixer regs : No wait states.
CN5 expansion area : No wait states.
Tilemap registers : No wait states.
CN2 expansion areas : Subject to external DTACK pin connection.
No wait states for the I/O, FDC, ROM boards.
I/O chip : 1 clock added per access.
Tilemap RAM (either) : 6 clocks added per access.
This happens regardless of horizontal or
vertical blanking or if layers are blanked.
DRAM (CPU A work RAM) : Every 20us an access has 4 clocks added.
DRAM (CPU B work RAM) : Every 20us an access has 4 clocks added.
Sprite RAM : Variable. When rendering it ranges from 3 to 22
clocks added, when idle the minimum is 3 clocks
added per access (e.g. 1st command is $C000).
Wait states for CPU A when CPU B is running.
CPU A accessing same : 4 clocks added per access.
T-bus address as CPU B
CPU A accessing same : 4 clocks added per access.
P-bus address as CPU B
CPU A accessing other : ? (Seems unclear, but different than above cases)
T-bus than CPU B
CPU A accessing other : ? (Seems unclear, but different than above cases)
P-bus than CPU B
The DRAM used for work RAM (MB81464) needs to be refreshed every 4ms, and
it seems like the system refreshes it much faster than necessary.
----------------------------------------------------------------------------
Board revisions
----------------------------------------------------------------------------
837-6442
Original board type.
837-6442-01
New board type. It has the following changes compared to the original
board:
- Added 7805 regulator which provides a +5V source derived from the +12V
input from the edge connector. This is used for the audio section
exclusively.
- Added IC83 (74HC245) to buffer port H of the I/O chip and in turn drive
the audio DAC's R-2R resistor array. This was needed now that the I/O
chip and audio have their own +5V supplies and are no longer common.
- IC77 has been replaced with a SOIC equivalent to free up room
for newly added IC83.
- Added IC84 (74HC04) to buffer the 10 MHz clock output of IC65 (74F74)
which goes to both CPUs and the 315-5295 at IC5. Two gates are used
to provide a non-inverted clock; the remaining four gates are unused.
- Narrow DIP switches are used instead of the full size ones.
- Sprite RAM is implemented with eight MB81464 DRAMs (64Kx4 each) soldered
to the board like the original version, but now an array of four sockets
(IC85-88) have been added for MB81C4256 DRAMs. Jumper J1 and resistors
R64 and R65 have been added to enable one of the two DRAM banks.
The MB81C4256 is 256Kx4 compared to the MB81464 which is 64Kx4, so if the
MB81C4256s are installed and enabled, sprite RAM is 512K instead of 256K.
When jumper J1 connects pins 2-3 ("256"), the MB81464 bank is enabled.
When it connects pins 1-2 ("1M"), the MB81C4256 bank is enabled. If the
jumper is left unconnected both banks are disabled. Disabled bank(s)
respond to writes but not reads.
While this change allowed the hardware to transition to MB81C4256
DRAMs as they became cheaper and/or more available, it seems unusual that
they'd permanently install MB81464s and provide sockets for the
MB81C4256s as well as have a circuit that supported both being installed
and operating at the same time. In theory it might have been an option to
support older software that wouldn't work with 512K of RAM being
installed, but it isn't known if any games have such an issue.
Other specifics for this revision:
Jumper J1
1 - ("1M") - To ZIP sockets pin 1 (IC85-88) (MB81C4256 OE#) and R64 pullup.
2 - From 315-5293 pin 26 (/OE)
3 - ("256") - To ZIP sockets pin 5 (IC42-48) (MB81464 OE#) and R65 pullup.
MB81C5256 address line connections:
Pin 11 (A0) - Pin 31 (CGAD8)
Pin 12 (A1) - Pin 33 (CGAD6)
Pin 13 (A2) - Pin 34 (CGAD5)
Pin 14 (A3) - Pin 35 (CGAD4)
Pin 16 (A4) - Pin 32 (CGAD7)
Pin 17 (A5) - Pin 36 (CGAD3)
Pin 18 (A6) - Pin 37 (CGAD2)
Pin 19 (A7) - Pin 38 (CGAD1)
Pin 20 (A8) - Pin 39 (CGAD0)
On the original board CGAD8 is unconnected and goes to a test point.
837-6442-02
Used by Quiz Ghost Hunter. Seems almost identical to revision 1 board.
It uses four 2-pin DIP MB81C4256's for a total of 512K of sprite RAM.
The old MB81464 ZIP array, MB81C4256 ZIP sockets, and DRAM selection
jumper are removed.
BIOS checks for board revisions
The EPR-12186/12187 BIOS tests for 512K of CPU A work RAM by determining
if RAM address $0C0000 is a mirror of $080000. Revisions 0 and 1 do not
have extra CPU work RAM. It isn't known how much RAM the revision 2 board
has, but it was produced much later after this BIOS was developed.
This check that the BIOS performs may have been included to support a
development system with more RAM, or for a planned board revision for
more RAM that was never released.
----------------------------------------------------------------------------
I/O chip
----------------------------------------------------------------------------
Overview
The 315-5296 I/O chip is similar in design to the Sony CXD1095Q I/O chip
used on earlier boards. It has the following features:
- Eight 8-bit I/O ports (A through H)
- Three output-only pins (CNT2-0)
- Chip select for a peripheral device (/FMCS)
- Clock output for a peripheral device (CKOT)
- Programmable clock divider
Reset state
After a reset, all I/O ports are configured as inputs.
Address decoding
The chip has a 6-bit address bus assigned as follows:
$00-$1F : I/O chip internal locations
$20-$3F : Unused by I/O chip; /FMCS asserted for this range.
Of the first 32 locations, only the first 16 are used and the latter
16 have no function.
Register map
$00 : Port A data
$01 : Port B data
$02 : Port C data
$03 : Port D data
$04 : Port E data
$05 : Port F data
$06 : Port G data
$07 : Port H data
$08 : Identifier #1
$09 : Identifier #2
$0A : Identifier #3
$0B : Identifier #4
$0C : Mode control register #1 (mirror)
$0D : Mode control register #2 (mirror)
$0E : Mode control register #1
$0F : Mode control register #2
$10-$1F : Unused
$20-$3F : /FMCS area
Identifier
These locations return the ASCII values "SEGA" when read.
I/O ports
Each I/O port consists of an 8-bit output latch and 8-bit input buffer.
Regardless of the port direction, writing to a register loads the
port's output latch.
If the port is an input, reading returns the real-time state of the pins
through the input buffer. If the port is an output, reading returns the
current value of the output latch.
Control register #1
MSB LSB
dd-- ---- : CKOT clock divider (0= CLK/4, 1= CLK/8, 2= CLK/16, 3= CLK/2)
--dd ---- : CNT2 clock divider (0= CLK/4, 1= CLK/8, 2= CLK/16, 3= CLK/2)
---- e--- : CNT2 output mode (1= Clock output, 0= Programmable output)
---- -210 : Output level of CNT2-0 pins (1= high, 0= low)
This register defines how CNT2-0 operate, if CNT2 is a secondary clock
output, and the frequency of the primary and secondary clock ouputs.
When CNT2 is configured as clock output, bit 2 of this register has
no effect on the output level of CNT2.
Control register #2
MSB LSB
h--- ---- : Direction of I/O port H (1= output, 0= input)
-g-- ---- : Direction of I/O port G (1= output, 0= input)
--f- ---- : Direction of I/O port F (1= output, 0= input)
---e ---- : Direction of I/O port E (1= output, 0= input)
---- d--- : Direction of I/O port D (1= output, 0= input)
---- -c-- : Direction of I/O port C (1= output, 0= input)
---- --b- : Direction of I/O port B (1= output, 0= input)
---- ---a : Direction of I/O port A (1= output, 0= input)
This register defines the direction of each I/O port.
System 24 specifics
The 68000 address lines are connected to the chip in the following manner:
I/O 68K
A0 A1
A1 A2
A2 A3
A3 A4
A4 A5
A5 A8
This segments the 64-byte space into two regions:
$800001-$80003F : I/O chip registers
$800101-$80013F : /FMCS area
Register map
$800001 : Port A data
$800003 : Port B data
$800005 : Port C data
$800007 : Port D data
$800009 : Port E data
$80000B : Port F data
$80000D : Port G data
$80000F : Port H data
$800011 : Identifier #1
$800013 : Identifier #2
$800015 : Identifier #3
$800017 : Identifier #4
$800019 : Mode control register #1 (mirror)
$80001B : Mode control register #2 (mirror)
$80001D : Mode control register #1
$80001F : Mode control register #2
$800021-$80003F : Unused
$800101-$80013F : /FMCS area, specifically:
$800101 : YM2151 address 0
$800103 : YM2151 address 1
I/O port summary
Port A : Optocoupled inputs from edge connector (active low).
Port B : Optocoupled inputs from edge connector (active low).
Port C : Connected via bus transceiver to edge connector pins.
Output pin CNT0 controls the direction (0= input, 1= output).
Port D : Output, bits 7-4 driven by LS367 to CN3 pins (digital outputs,
TTL level) and bits 3-0 driven by ULN2003 to edge connector
(open collector, high current outputs).
Port E : Optocoupled inputs from edge connector (active-low).
Port F : DIP switch #1 inputs.
Port G : DIP switch #2 inputs.
Port H : Output to 8-bit audio DAC.
I/O chip pin connections
- CLK driven at 16 MHz.
- CNT2 connected to YM2151 /IC. (reset line)
- CNT1 connected to 315-5295 (IC5) pin 81 (/RESP)
This is the CPU B reset line, 0= reset, 1= running.
- CNT0 connected to 74LS245 (IC77) DIR.
- CKOT connected to YM2151 clock input.
I/O chip initialization
The BIOS initializes the I/O chip as follows:
MOVE.B #$04,$0080001D
MOVE.B #$00,$00800007
MOVE.B #$88,$0080001F
This initializes the system as follows:
- Ports D,H are outputs, remaining are inputs.
- CNT2 is driven high, CNT1-0 are driven low.
Meaning CPU B is held in a reset state (/RESP=L) and is inactive.
- CNT2 is a programmable output and not a clock output.
- CKOT outputs a an 8 MHz clock to the YM2151 (16 MHz / 2).
- Port D outputs are driven low.
----------------------------------------------------------------------------
Timer and interrupt controller
----------------------------------------------------------------------------
Custom chip 315-5295 (IC7) has an interrupt controller and timer
peripheral. It has four internal registers that are word-wide.
Register overview
$A00000 : ---- cccc cccc cccc : Timer reload count
$A00002 : ---- ---- ---- --mm : Timer mode
$A00004 : ---- ---- --65 432- : CPU A interrupt enable (1= enabled, 0=disabled)
$A00006 : ---- ---- --65 432- : CPU B interrupt enable (1= enabled, 0=disabled)
Reading any address returns the real time state of the timer count.
Interrupt sources
Level 2 : YM2151 /IRQ (/INT0)
Level 3 : Timer
Level 4 : Tilemap /XINT (/INT1)
Level 5 : Sprite /DMAO and /DMAI tied together (/INT2)
Level 6 : CN2 expansion connector (/INT3)
Interrupt request behavior
The timer interrupt request signal is asserted until the corresponding
CPU interrupt enable register is read or written, either by byte or word
access. Typically software will read that register and discard the value
to acknowledge the interrupt as follows:
__level3_irq:
tst.w $A00004
rte
One CPU can acknowledge an interrupt for the other one, for example CPU A
can acknowledge a timer interrupt on CPU B by writing or reading $A00006.
The V-Blank interrupt request signal from the tilemap chip is asserted for
exactly one scanline, or 656 cycles. If the interrupt handler exits
before that duration is over the interrupt will immediately be
triggered again.
The sprite interrupt request signal from the sprite chip is asserted for
exactly one scanline, or 656 cycles. If the interrupt handler exits
before that duration is over the interrupt will immediately be
triggered again.
Timer
The timer is a 12-bit up-counter. The counter can be read back by reading
any word offset in $A00000. When the counter overflows it is reloaded
with the last value written to $A00000. Writing to that register while
the timer is counting does not affect it until the next overflow and
reload.
The timer's clock source can be an 8 MHz clock that is synchronous to
the 16 MHz pixel clock, and the HOUT signal generated by the tilemap
chip that is pulsed once per scanline.
The counter counts up on the positive edge of the selected clock signal.
When the count is $0FFF and a positive edge is detected, the counter
is loaded with the value of the reload register and an IRQ is requested.
The timer continues to count even if the interrupt is not processed or
not acknowledged.
There are four timer modes as follows:
0 - Timer off.
There is a bug in the hardware; if the reload count is $0FFF an
interrupt is generated just like mode 1. E.g. one interrupt triggered
on every scanline.
1 - Scanline timer
The timer clock source is HOUT. If HOUT is not generated the counter
state will not change.
2 - Pixel timer
The timer behaves like mode 3, but the count is also reloaded on the
rising edge of HOUT. This allows you to trigger an interrupt at a
specific location within a scanline, specified in units of two pixels.
The timer clock source is 8 MHz. If HOUT is not generated the counter
state will behave exactly like mode 3.
Valid reload count values in this mode are:
0000-0EB7 : No interrupts generated (counter reloaded before it expires)
0EB8 : 1 interrupt per scanline
:
0F5B : 1 interrupt per scanline
0F5C : 2 interrupts per scanline
:
0F92 : 2 interrupts per scanline
0FFF : Interrupt triggered at every 8 MHz clock
As the counter reloads after each interrupt, using large
counts will cause the interrupt to trigger multiple times in one
scanline.
Adjusting the position of HOUT shifts the location that the interrupt
is triggered at on a given scanline.
3 : 8 MHz clock
The counter increases on the rising edge of the 8 MHz clock.
The CPU can't process interrupts fast enough at some of the
highest timer counts.
Comments in mode 2
The problem with mode 2 is that it does not function as a one-shot timer,
so for large count values the timer will overflow multiple times per
scanline and you'll get several interrupts on a single line.
In theory mode 2 would allow for a positional interrupt, but because of
this reload behavior you are limited to counts that position the
interrupt in the right half of the screen only, unless you have a more
complex interrupt handler that disables itself for other interrupts after
the first one.
For a true positional interrupt at the cost of distorting the sprites,
you can use timer mode 1 and adjust the HOUT register. This gives
very fine (16 MHz) positioning rather than the coarse positioning
of mode 2 without the troublesome reload behavior.
----------------------------------------------------------------------------
Mixer chip and color RAM
----------------------------------------------------------------------------
The mixer chip combined the output of three pixel data busses (tilemap A,
tilemap B, sprite framebuffer) and generates indices in color RAM
specifying RGB color data to be displayed for each pixel on the screen.
Address map
400000-403FFF : Color RAM, more specifically:
400000-401FFF : Tilemap palettes (256 palettes of 16 colors)
402000-4021FF : Sprite palette (256 colors)
402200-403FFF : Unused RAM
404000-407FFF : Mixer chip internal registers (16 locations)
Color RAM format
MSB LSB
s--- ---- ---- ---- : Shadow (0) or highlight (1) select.
-b-- bbbb ---- ---- : Blue component bits 0,4,3,2,1.
--g- ---- gggg ---- : Green component bits 0,4,3,2,1.
---r ---- ---- rrrr : Red component bits 0,4,3,2,1.
Registers
Each register is 3 bits (D2-D0) and can be read and written.
404001 : Background A priority code for low priority tiles
404003 : Background A priority code for high priority tiles
404005 : Window A priority code for low priority tiles
404007 : Window A priority code for high priority tiles
404009 : Background B priority code for low priority tiles
40400B : Background B priority code for high priority tiles
40400D : Window B priority code for low priority tiles
40400F : Window B priority code for high priority tiles
404011 : Sprite priority code for pens $C0-$FF
404013 : Sprite priority code for pens $80-$BF
404015 : Sprite priority code for pens $40-$7F
404017 : Sprite priority code for pens $00-$3F
404019 : Control register #1
40401B : Control register #2
40401D : Control register #1 (mirror)
40401F : Control register #2 (mirror)
Control register #1
D2 : ?
D1 : ?
D0 : ABSEL mode enable (1= on, 0= off)
Control register #2
D2 : Unused (connects from pin 37 "EXT" to test point near C118)
0= Test point driven low, 1= Driven high.
D1 : Screen flip (1= on, 0= off) (from pin 36 "EX0" labelled "2P")
D0 : Screen blanking (1= on, 0= off)
Priority ordering
A priority of 0 is the lowest, 7 is the highest. If priority codes are
equal the mixer chip uses a hardwired priority ordering.
----------------------------------------------------------------------------
Tilemap chip
----------------------------------------------------------------------------
Overview
The 315-5292 generates two tilemap layers and all display timing signals
for the system.
Terminology
Planes A, B - The two scrolling tilemaps generated by the chip.
Background - The primary tilemap associated with a given plane.
Window - The alternate tilemap associated with a given plane.
Layer - Either the background or the window of a plane.
Mask - A bitmap that selects if the background tilemap or
window tilemap should be shown within a 8x1 pixel
area of the display.
Individual pixel data for planes A and B are fed to the mixer chip. This
data includes the pixel value (4 bits), palette number (8 bits), priority
flag (1 bit) and background/window indicator (1 bit).
The mixer chip assigns a 3-bit priority code based on a pixel's priority
flag, then evaluates the priority of pixel data from both planes to
determine which plane appears on top.
Bit 0 of mixer control register #2 enables use of the ABSEL signal, which
the tilemap chip generates at a user-defined pixel position on every
scanline. To the left of this point plane A is shown exclusively, to
the right plane B is shown exclusively. If this mode is not used, the ABSEL
signal position can still be freely defined but it has no impact on the
display.
Layer transparency
Normal display mode (ABSEL=0)
Zero value pixels from the topmost layer are considered transparent.
Zero value pixels from the bottommost layer show color 0 of the specified
palette.
If the topmost layer is blanked, it is considered transparent.
If the bottommost layer is blanked, it is filled with color 0 of palette 0.
ABSEL display mode (ABSEL=1)
Pixel 0 is not transparent, so color 0 of the associated palette is shown.
If any layer is blanked, it is filled with color 0 of palette 0.
Memory map
200000-20FFFF : VRAM (64K)
220000-23FFFF : ABSEL register (any word offset)
240000-25FFFF : HOUT register (any word offset)
260000-26FFFF : VOUT register (any word offset)
270000-27FFFF : Display mode register (any word offset)
280000-2FFFFF : Tile pattern RAM (512K; 128K present)
VRAM memory map
200000-201FFF : Plane A background name table
202000-203FFF : Plane A window name table
204000-205FFF : Plane B background name table
206000-207FFF : Plane B window name table
208000-2083FF : Plane A background line scroll table
208400-2087FF : Plane A window line scroll table
208800-208BFF : Plane B background line scroll table
208C00-208FFF : Plane B window line scroll table
209000-209FFF : (Unused)
20A000-20A00F : Video registers ("soft" registers stored in RAM)
20A010-20BFFF : (Unused)
20C000-20CFFF : Plane A window mask
20D000-20DFFF : Plane B window mask
20E000-20FFFF : (Unused)
280000-29FFFF : Tile pattern RAM (128K)
2A0000-2BFFFF : Tile pattern RAM (mirror)
2C0000-2DFFFF : Tile pattern RAM (mirror)
2E0000-2FFFFF : Tile pattern RAM (mirror)
Name table data
MSB LSB
p--- ---- ---- ---- : Priority bit (0= low, 1= high)
-ccc cccc c--- ---- : Palette number (0-255)
--nn nnnn nnnn nnnn : Tile number (0-16383) [Other hardware]
---- nnnn nnnn nnnn : Tile number (0-4095) [System 24]
System 24 only has 128K of 512K RAM installed for tile patterns. The
name field is 14 bits, but only the lower 12 bits select the tile to
be displayed.
The palette and tile number fields overlap so palette numbers and tile
numbers cannot be freely defined in all cases.
Video registers
20A000 : Background A horizontal scroll
20A002 : Window A horizontal scroll
20A004 : Background B horizontal scroll
20A006 : Window B horizontal scroll
20A008 : Background A vertical scroll
20A00A : Window A vertical scroll
20A00C : Background B vertical scroll
20A00E : Window B vertical scroll
These registers are latched close to the negative edge of H-Sync on
the last line of the frame (the scanline before the first line of the
active display). While the specific timings aren't known, it seems
the registers at $20A008 are read before $20A000.
This latching behavior prevents mid-frame changes to the display from
taking effect. One workaround is to use the line scroll table function.
Horizontal scroll register
MSB LSB
s--- ---- ---- ---- : Line scroll enable (1= on, 0= off)
---- --xx xxxx xxxx : Horizontal scroll
If line scrolling is enabled the scroll field has no effect on the display.
Vertical scroll register
MSB LSB
e--- ---- ---- ---- : Layer enable (1= blanked, 0= shown)
-ss- ---- ---- ---- : Playfield size (for backgrounds only, not windows)
---- --yy yyyy yyyy : Vertical scroll
Line scrolling
The line scroll tables consist of 512 entries of 16-bit words with the
following format:
MSB LSB
e--- ---- ---- ---- : ABSEL override flag (Plane A window only)
---- --xx xxxx xxxx : Horizontal scroll
If line scrolling is enabled the horizontal scroll value specified here
is used instead of the one in the soft registers at $20A00x.
ABSEL override function
The plane A window line scroll table has a secondary function. When ABSEL
mode is enabled and bit 15 of a particular line scroll entry is set,
plane A is shown for the entire width of the corresponding scanline
regardless of the ABSEL position. Plane B will not be visible on that line.
This allows the screen to be split horizontally by the ABSEL register
into two halves, and vertically into any number of segments on a line by
line basis. This function works regardless of line scrolling being enabled
or not, or the plane A window layer being enabled or not. So even if
line scroll was disabled for all layers and the plane A window was disabled,
this function still operates as described.
From a hardwawre point of view, the state of bit 15 is output on the
DSPABH pin to the mixer chip for a duration of one scanline (656 pixels).
If consecutive lines have this bit set, the output remains high with
no gaps. Since the tilemap chip doesn't know about the state of the ABSEL
mode bit in the mixer chip it will control DSPABH even if ABSEL mode
is disabled.
Playfield size field
The playfield size is defined as follows
D14 D13
0 0 : 64x64 (Normal)
A reset mask bit shows the background name table using background
scroll registers.
A set mask bit shows the window name table using window
scroll registers.
0 1 : 64x128 (Tall playfield)
The 64x128 playfield uses the background name table for the top
64x64 area, and the window name table for the bottom 64x64 area.
This forms a composite 64x128 layer using both name tables.
A reset mask bit shows the composite layer using background
scroll registers.
A set mask bit shows the composite layer using window scroll
registers.
If the background and window scroll registers are programmed
identically you can't distinguish areas where the mask bits
are set or reset.
1 0 : 128x64 (Wide playfield)
The 128x64 playfield uses the background name table for the left
64x64 area, and the window name table for the right 64x64 area.
This forms a composite 128x64 layer using both name tables.
A reset mask bit shows the composite layer using background
scroll registers.
A set mask bit shows the composite layer using window scroll
registers.
If the background and window scroll registers are programmed
identically you can't distinguish areas where the mask bits
are set or reset.
1 1 : 64x64 (Window-only)
A reset mask bit shows the window name table using background
scroll registers.
A set mask bit shows the window name table using window
scroll registers.
The background name table cannot be displayed in this mode.
Display quirks
The same hardware that is used to render the background layer is used for
the window layer. This causes a problem when the lower 3 bits of the
horizontal scroll are nonzero between tiles that are adjacent to each other
and come from different layers as specified by the mask bit.
The 8-pixel shift registers are only loaded once every 8 pixels. So in this
case the shift register will still contain data from the left tile, which
is shifted out into the right tile.
If the layer to the left has a scroll value of zero, then the shift
register is empty. Pixels 1-7 of the layer to the right are filled in
with the background color of the left tile instead.
For example if the background is displayed and the window is blanked, and
the mask bit is set, a blank tile from the window is shown. However the
hardware is still loading data from the window which was ultimately
not displayed, and if the horizontal scroll is 1-7, you'll see the
unblanked window data shifted out into the background until the shift
registers reload with background tile data.
Tilemap hardware registers
Registers are write only.
ABSEL register ($220000)
MSB LSB
---- --xx xxxx xxxx : Pulse width of ABSEL signal.
See the timing section below for specifics.
HOUT register ($240000)
MSB LSB
---- --xx xxxx xxxx : Horizontal position of HOUT pulse.
VOUT register ($260000)
MSB LSB
---- ---y yyyy yyyy : Vertical position of VOUT pulse.
Mode register ($270000)
MSB LSB
---- ---- ---- ---m : Sync mode (0= normal, 1= invalid)
Tilemap signals
Tilemap and mixer interface
SA0-SA3 4-bit pixel data from tile pattern RAM.
To mixer input SA3-0. (SB3-0)
SA4-SA12 8-bit palette number from name table (bits 14-7).
To mixer input SA12-4. (SB12-4)
SA13 1-bit priority field from name table bit 15.
To mixer input FA (FB).
SKA Background/window indicator.
To mixer input WA (WB).
ABSEL Overlapping or side-by-side background indicator.
To mixer input AXBV.
DSPABH ABSEL override flag. Outputs the state of bit 15 of the
current scanline in the Plane A Window line scroll table
for one scanline (656 pixels).
To mixer input AXBH.
----------------------------------------------------------------------------
System timing
----------------------------------------------------------------------------
Display timing
656 pixels per scanline:
69 pixels from /HSYNC high to /BLANK high (left border)
496 pixels from /BLANK high to /BLANK low (active display)
43 pixels from /BLANK low to /HSYNC low (right border)
48 pixels from /HSYNC low to /HSYNC high (horizontal sync. pulse)
424 scanlines per frame:
25 scanlines from /VSYNC high to /BLANK high (top border)
384 scanlines from /BLANK high to /BLANK low (active display)
11 scanlines from /BLANK low to /VSYNC low (bottom border)
4 scanlines from /VSYNC low to /VSYNC high (vertical sync. pulse)
The pixel clock is 16 MHz, giving an effetive frame rate of 57.52
frames per second.
In the invalid display mode, horizontal timings are the same, vertical
timings are approximately as follows.
512 scanlines per frame:
64 scanlines blanked
35 scanlines visible
4 lines sync during active display
409 scanlines visible
There are some other quirks in this mode such as positioning of the
interrupts, two VOUT pulses per frame which retriggers the sprite
rendering, etc. This mode is not useful.
ABSEL timing
Ranges for this 10-bit counter are:
$0000 : Plane B fills the whole screen
$0001 : 1 pixels plane A, 495 pixels plane B
$00F8 : 248 pixels plane A, 248 pixels plane B
$01EF : 495 pixels plane A, 1 pixel plane B
$01F0-: Plane A fills the whole screen
-$03FF : Plane A fills the whole screen
ABSEL is generated ahead of the blanking and sync signals by the tilemap
generator because the mixer chip needs a few pixel clock cycles to process
the data. It leads those signals by 4 pixels. The actual pulse width
is can be wider than the display, but only the ranges listed above have
any impact on the screen.
Interrupt timing
The V-Blank interrupt is generated on line 383 of 424, the last visible
scanline of the active display. The interrupt request line is asserted on
the negative edge of H-Sync before blanking is disabled, and is held for one
scanline (656 pixels) such that it is negated on the negative edge
of H-Sync of the next scanline, line 384.
The sprite interrupt is generated 15 scanlines after the line where VOUT
is pulsed. On the scanline where it is going to trigger, the interrupt
request line is asserted 35 pixels after the negative edge of HOUT, and is
held for one scanline (656 pixels) such that it is negated 35 pixels after
the negative edge of HOUT on the next scanline.
Note that if the V-Blank or sprite interrupt handlers exit before one
scanline's worth of time is up, the interrupt line will still be asserted
and the interrupt will be triggered again on the same line. Typically
the V-Blank interrupt will do enough processing for this time to elapse,
but some care may be needed with the sprite interrupt handler which may
not have much to do before returning.
When the timer uses HOUT as the clock source, the interrupt request line
is is asserted on the rising edge of HOUT (e.g. one pixel after HOUT is
pulsed) and held until the corresponding CPU interrupt enable register
is read or written.
Example timings using the BIOS defaults:
HOUT = FFC6
VOUT = FFF0
- V-Blank interrupt occurs on line 383 (last active line of display)
- VOUT pulsed on line 409
- HOUT pulsed 39 pixels after the falling edge of HSYNC
- Sprite interrupt occurs on line 424, 74 pixels after the falling edge
of HSYNC (35 pixels after the falling edge of HOUT).
----------------------------------------------------------------------------
Sprites
----------------------------------------------------------------------------
Command list
Each command is 16 bits. The command counter is 11 bits wide, so only
2048 commands starting at address zero can be processed. This restricts
the command list to the first 32K of sprite RAM.
Draw command
00 : 00z- -lll llll llll : Independent zoom enable, link
02 : wwww wwww hhhh hhhh : Horizontal zoom, vertical zoom
04 : --nn nnnn nnnn nnnn : Tile number
06 : pp-- cccc cccc cccc : Global pen modifier bits, CLUT address
08 : vhhh yyyy yyyy yyyy : Vertical flip, sprite height, Y-coordinate
0A : hwww xxxx xxxx xxxx : Horizontal flipp, sprite width, X-coordinate
0C : ---- ---- ---- ---- : Unused
0E : ---- ---- ---- ---- : Unused
Color look-up tables (CLUTs)
CLUTs are 16 bytes and can be positioned anywhere within the first 64K
of sprite RAM. The sprite chip loads a CLUT into internal memory if
the CLUT specified in drawing command is different from the one used
by the last drawing command. The pen modifier function (see below) can
also force a CLUT reload even if two sprites have identical CLUTs
specified.
For example you can force a reload of the CLUT on every sprite by
alternating bit 0 of word #6 for each draw command.
Sprite size
The 3-bit size field is as follows:
0 : 8 pixels
1 : 16 pixels
2 : 32 pixels
3 : 64 pixels
4 : 128 pixels
5 : 256 pixels
6 : 512 pixels
7 : 1024 pixels
Coordinates
Sprites are positioned in a 4096x4096 virtual space. Position 0,0 is
coordinate (0,0) of the framebuffer, $0FFF is one pixel to the left/
one pixel above off screen. Sprites drawn near the edges of that
virtual space wrap around, so you can draw a 64x64 sprite at (4000,4000)
and part of it will appear in the upper left corner of the display.
Zooming
Normally the horizontal zoom value specified the zoom value for both
axes. If bit 13 is set, they can be independently specified. Zoom
values are:
0F : 1/4 size
1F : 1/2 size
3F : Normal size as specified by width/height
7F : 2x size
FF : 4x size
A zoom word of $7B4E zooms a 256x256 sprite to exactly 496x384 pixels.
Rendering timing
There is enough time to process all 2048 commands. There is also enough
time to render 2048 8x8 sprites, but it is near the upper limit of how
much drawing time is available. There is also enough time to process
1024 clip commands and 1024 8x8 sprite draw commands when they are
interleaved.
Drawing time goes down sharply as larger sized sprites or scaled-up
sprites are used.
If a sprite is 1024 pixels wide and 512 or 1024 pixels tall, there is only
enough time to draw about 272 rows of 1024 pixels across to the framebuffer.
A scaled-down sprite takes the same amount of time to draw as a normal
sized one. A scaled-up sprite takes more time to draw proportional to
the final scaled size.
Sprites that are off-screen take the same amount of time to draw as
an on-screen sprite.
Other comments on rendering
For performance reasons it seems like end codes should have been added to
this system. They were included in the similar sprite hardware of System 32
and the Saturn.
Similarly there is little feedback about the rendering state and no way
to manually control framebuffer updates. So you can't lower the rendering
rate to 30 Hz and draw more objects in two passes. This limitation was
accounted for in the Saturn.
For a double buffered display, an ideal method of preparing sprites is to
have two sprite command lists in RAM, and change the link field of the
first entry to point to one or the other. This would allow you to completely
modify one list while the hardware renders from the other.
Even though there is enough time to draw 2048 sprites, the sprite chip
can also only process 2048 commands. If you split the RAM into two lists
you can have two lists of about 1024 entries each. This artificially halves
the on-screen sprite count just because there aren't enough addressable
commands left, even though there is sufficient drawing time. If the command
list counter was 13 bits instead of 12 this limit would not exist. Given
how large sprite RAM can be (256K to 512K) it seems unusual to limit the
commands to the first 32K and CLUTs to the first 64K.
Skip command
00 : 10-- ---- ---- ---- : Skip command
00 : ---- -lll llll llll : Link field
02 : ---- ---- ---- ---- : Unused
04 : ---- ---- ---- ---- : Unused
06 : ---- ---- ---- ---- : Unused
08 : ---- ---- ---- ---- : Unused
0A : ---- ---- ---- ---- : Unused
0C : ---- ---- ---- ---- : Unused
0E : ---- ---- ---- ---- : Unused
The skip command provides a quick way to disable sprites by setting bit
15 of their lead entry. All other fields are unused, and processing
continues with the next command specified by the link field.
End command
00 : 11-- ---- ---- ---- : End command
02 : ---- ---- ---- ---- : Unused
04 : ---- ---- ---- ---- : Unused
06 : ---- ---- ---- ---- : Unused
08 : ---- ---- ---- ---- : Unused
0A : ---- ---- ---- ---- : Unused
0C : ---- ---- ---- ---- : Unused
0E : ---- ---- ---- ---- : Unused
This command ends rendering. No more commands will be parsed until
the next frame.
Rendering can also end when you run out of drawing time (too many large
objects rendered), or if the link fields create a loop. When this happens
the loop is repeatedly processed until rendering time is over.
Clip command
00 : 01-- ---- ---- ---- : Clip command
00 : ---- -lll llll llll : Link field
02 : hv-- ---- ---- ---- : Horizontal flip flag, vertical flip flag (1=on)
02 : --c- ---- ---- ---- : Clip mode (1=inclusive, 0=exclusive)
02 : ---- ---- ---- --pp : Global pen modifier bits
04 : ---- ---t tttt tttt : Top scanline of clipping rectangle
06 : ---- ---l llll llll : Left pixel column of clipping rectangle
08 : ---- ---b bbbb bbbb : Bottom scanline of clipping rectangle
0A : ---- ---r rrrr rrrr : Right pixel column of clipping rectangle
0C : ---- ---- ---- ---- : Unused
0E : ---- ---- ---- ---- : Unused
Flip flags
The flip flags affect how the framebuffer is addressed, it isn't related
to the per-sprite flip flags.
If the horizontal flip bit is set, the X position to draw at is 511-X.
If the vertical flip bit is set, the Y position to draw at is 383-Y.
For example if both flip bits are set, a sprite at (0,0) that would normally
drawn to the right and downwards from that position is now drawn at
(511,383) to the left and upwards from that new position.
Clip mode
If the clip mode is set to 0 (inclusive), the clipping rectangle defines
an area where sprites can be drawn. Sprites outside that area are not drawn.
If the clip mode is set to 1 (exclusive), the clipping rectangle defines
an area where sprites cannot be drawn. Sprites outside that area are drawn.
If the top coordinate is larger than the bottom coordinate, or if the left
coordinate is larger than the right coordinate, the clipping function
is disabled regardles of the clip mode.
If the top coordinate is equal to the bottom coordinate, or if the left
coordinate is equal to the right coordinate, clipping is enabled for a
single pixel (point, column, or row) area.
For example if all clip coordinates have the same value, the clip area
is a single pixel at that coordinate.
Clipping does not speed up sprite rendering, even if a sprite is partially
or entirely clipped.
There is only enough state for one clipping window; the hardware doesn't
support two clip windows (e.g. an inclusive and exclusive window).
Global pen modifier
This function modifies bits 7,6 of the 8-bit pixel written to the
framebuffer. It is controlled globally by the clip command and locally
by the draw command as follows:
- Clip command, word #4, bits 1,0
- Draw command, word #4, bits 15,14
The possible settings are:
Clip Draw Function
0000 0000 No change
0000 4000 No change
0000 8000 No change
0000 C000 No change
0001 0000 Reset bit 6
0001 4000 Set bit 6
0001 8000 Reset bit 6
0001 C000 Set bit 6
0002 0000 Reset bit 7
0002 4000 Reset bit 7
0002 8000 Set bit 7
0002 C000 Set bit 7
0003 0000 Reset bits 7,6
0003 4000 Reset bit 7, set bit 6
0003 8000 Set bit 7, reset bit 6
0003 C000 Set bits 7,6
The processing flow is as follows:
1. Read pixel nibble from tile data, look up corresponding value in CLUT
2. If CLUT value is zero treat pixel as transparent
3. Modify CLUT index, look up value in CLUT
4. If CLUT value is zero treat pixel as transparent
Because transparency is evaluated twice, this ensures a pixel that maps
to a CLUT value of $00 is always transparent, even if the modification
would have made it opaque.
Conversely the modifications can make an opaque pen transparent; such
as if the CLUT value was $C0 and the modifier to reset bits 7,6 was used.
This function simplifies modifying the priority (or palette) for sprites
without having to go through and modify multiple sprite attributes in RAM.
Cache behavior
Even if two sprites have the same CLUT specified in draw command word #4,
if the pen modifier function changes the final CLUT used during rendering
then the CLUT cache is reloaded.
Issuing a clip command itself does not affect the last cached CLUT value.
Framebuffer scanning
When the sprite chip scans out the framebuffer data to be combined with the
tilemap chip's pixel stream, this scanning operation needs to be
synchronized to the display signals. To do this, the sprite chip inputs
three signals from the tilemap chip:
- 16 MHz pixel clock.
- HOUT, a one pixel wide negative pulse.
- VOUT, a one scanline (656 pixel) wide negative pulse.
HOUT is generated by a comparator that compares the horizontal pixel
counter to a 16-bit register at $240000. When the count matches the
register contents, HOUT is asserted. This happens on every scanline
of the display, or 424 times per frame
VOUT is generated by a comparator that compares the vertical scanline
counter to a 16-bit register at $260000. When the count matches the
register contents, VOUT is asserted. This happens once per frame.
If the HOUT and VOUT registers are programmed to have invalid values such
that one or both signals are not pulsed, the sprite generator uses the
last valid settings they were set to. This allows the sprite chip to
continue to scan out the framebuffer with a complete absence of any
video synchronization signals other than the pixel clock.
To accomplish this, I can only assume it has its own internal
pixel and scanline counters. By counting durations between HOUT and VOUT
pulses it can determine the frame extents:
- Two HOUT pulses are 656 pixels apart
- Two VOUT pulses are 424 scanlines apart
This allows it to continue to generate internal timing signals even
when they aren't supplied externally.
Using HOUT and VOUT
Changing these values allow the framebuffer layer to be scrolled relative
to the tilemap layer. However this also affects when the sprite chip
interrupt is generated relative to the V-Blank interrupt. It seems to
be more useful as a way to center the 512x384 framebuffer within
the 496x384 visible display.
Based on the display width and height as defined by the HOUT and VOUT
pulses, which define an internal screen state, the sprite chip only
outputs the 512x384 framebuffer for the upper left corner of the
656x424 frame.
If the HOUT and VOUT registers are set up so that a non-visible portion of
the framebuffer is shown in the active display, the sprite chip outputs a
zero value on the pixel bus. You do not see any framebuffer data that is
repeated within that area, nor is garbage shown.
This would allow adjustment of HOUT and VOUT to "shake" the sprite layer
for a game effect without revealing repeated data or garbage outside of
the framebuffer extents.
With the BIOS defaults of HOUT=$FFC6, VOUT=$FFF0, this aligns framebuffer
position (8,0) with display position (0,0), which provides an 8-pixel wide
off-screen area to the left of the visible portion of the framebuffer.
To map framebuffer position (0,0) to display position (0,0) a value
of $FFCE should be used for HOUT.
HOUT can be changed per-scanline to change the framebuffer horizontal
scroll on every scanline. VOUT seems to be latched at multiple points in
a frame outside of the active display, but at least during the active
display it cannot be used to adjust the vertical scrolling on a line by
line basis.
Settings for HOUT and VOUT ranges
VOUT ranges
This is a 9-bit register. Pulse locations:
0000 : Pulse triggered on first line of active display
017F : Pulse triggered on last line of active display
0180-
01D7 : No match
01D8 : Pulse triggered on first line of vertical blanking
01FF : Last line of vertical blanking
0200 : Pulse triggered on first line of active display
HOUT ranges
This is a 10-bit register. Pulse locations:
0000 : 97 pixels from falling edge of H-sync
0001 : 98 pixels from falling edge of H-sync
0014 : 117 pixels from falling edge of H-sync (synch. with +ve edge of BLANK)
0204 : 613 pixels from falling edge of H-sync (synch. with -ve edge of BLANK)
022E : 656 pixels from falling edge of H-sync
022F : 0 pixels from falling edge of H-sync (synch. with -ve edge of SYNC)
0230-: No match
-039F : No match
03A0 : 1 pixels from falling edge of H-sync
03CF : 48 pixels from falling edge of H-sync (synch. with +ve edge of SYNC)
03FF : 96 pixels from falling edge of H-sync
----------------------------------------------------------------------------
End
----------------------------------------------------------------------------