View source for Sega Saturn hardware notes (2004-04-27)

{{unofficialDoc|source=http://dreamjam.co.uk/emuviews/txt/sattech.txt}}

<pre>

 Sega Saturn hardware notes
 by Charles MacDonald
 WWW: http://cgfm2.emuviews.com

 Unpublished work Copyright 2002-2004 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 Sega Saturn
 but please be aware that my testing methods or interpretations of
 results could be flawed. I can't guarantee that everything is 100% accurate.

 Last updated 04/27/04

 Table of contents

 - Introduction
 - SMPC
 - VDP2 Color RAM
 - VDP2 Display
 - VDP2 Registers
 - SH-2 Memory Map
 - Miscellaneous
 - Credits and Acknowledgements
 - Disclaimer

 Change log:

[04/27/04]
 - Added blanking area sizes for PAL display modes
 - Added description of CPU FRT and MINIT/SINIT regions.
 - Added notes about EXTEN register.
[05/29/03]
 - Added some information about the MPEG card.
 - Added some information about NTSC system timing
 - Added analog pad info
 - Added SMPC section
 - Rewrote VDP2 register descriptions a little
 - Added PAL display info (Thanks Anders)
 - Added exclusive monitor modes to display section
 - Added SCSP MEM4MB bit to memory map section
 - Added color RAM section
 - Fixed CRAM range typo in memory map
 - Fixed VDP2 register range typo in memory map (Thanks Stefano)

 ----------------------------------------------------------------------------
 Introduction
 ----------------------------------------------------------------------------

 I've used the following consoles for testing:

 MK-80000 : USA Saturn (1995, old style model with oval buttons)
 HST-3220 : Blue Skeleton Saturn (1998)

 ----------------------------------------------------------------------------
 SMPC
 ----------------------------------------------------------------------------

 The System Manager & Peripheral Control (SMPC) is a Hitachi 4-bit MCU with
 built-in program ROM. The actual part number is HD404920FS, but the chip
 is branded with a Sega custom part number of 315-5744.

 The SMPC carries out the following tasks:

 - Turn on/off other parts of the system. (CPU's, custom chips, etc.)
 - Maintain internal timekeeping functions.
 - Change the system clock speed generated by the PLL.
 - Poll peripherals in the I/O ports.
 - Provide SH-2 interface to I/O ports for direct programming.

 The SMPC is battery backed, and earlier models of the Saturn have a button
 in the battery compartment to force a SMPC reset.

 I/O Ports

 The Saturn has two 7-bit I/O ports. Here's a diagram of the port itself and
 a list of pin assignments. The names on the left are the Sega Genesis style
 naming conventions.

 Left            Right
  .-----------------.
 | 1 2 3 4 5 6 7 8 9 |
 +-=-=-=-=-=-=-=-=-=-+

 Pin 1 - +5v
 Pin 2 - D2         (Left)
 Pin 3 - D3         (Right)
 Pin 4 - D4         (TL)
 Pin 5 - D5         (TR)
 Pin 6 - D6         (TH)
 Pin 7 - D0         (Up)
 Pin 8 - D1         (Down)
 Pin 9 - Ground

 The SMPC uses the following registers for I/O port control:

 0x20100075 - PDR1  I/O port #1 pin output level (1=high, 0=low)
 0x20100077 - PDR2  I/O port #2 pin output level (1=high, 0=low)
 0x20100079 - DDR1  I/O port #1 pin direction (1=output, 0=input)
 0x2010007B - DDR2  I/O port #2 pin direction (1=output, 0=input)

 For each register, bits 6-0 correspond to TH,TR,TL,D3,D2,D1,D0. Bit 7 is
 unused and will latch whatever value was written to it.

 Pins defined as an output through DDRx will return the value you set in
 PDRx. Pins defined as an input return whatever value was sent to that pin
 by the peripheral in use.

 For an empty I/O port, each bit returns 1. (so $7F would be read from PDRx
 assuming the software hadn't set bit 7 beforehand)

 0x2010007D - IOSEL

 D1 - I/O port #2
 D0 - I/O port #1

 The lower two bits direct the SMPC to poll or ignore the corresponding
 I/O port. (0= poll, 1= ignore)

 This doesn't stop you from doing direct I/O anyway, but is used to prevent
 a conflict since the SMPC will attempt to poll it at the same time.

 Unused bits latch whatever value was last written.

 Saturn Control Pad

 The standard Saturn control pad can be read using direct I/O.
 To do this, set up the following registers like so:

 DDR1   = 0x60      Port 1 - pins TH,TR as outputs, TL,D3-D0 are inputs
 DDR2   = 0x60      Port 2 - pins TH,TR as outputs, TL,D3-D0 are inputs
 IOSEL  = 0x03      Use direct I/O mode instead of SMPC polling

 You can then get pad data by writing a 2-bit value to the TH,TR pins and
 reading the lower four bits of either input port. The values read back
 are the following:

 When PDRx = 0x60

 D4 : Always '1'
 D3 : Left shoulder button (0=pressed, 1=released)
 D2 : Always '1'
 D1 : Always '0'
 D0 : Always '0'

 When PDRx = 0x40

 D4 : Always '1'
 D3 : Start button (0=pressed, 1=released)
 D2 : Button A (0=pressed, 1=released)
 D1 : Button C (0=pressed, 1=released)
 D0 : Button B (0=pressed, 1=released)

 When PDRx = 0x20

 D4 : Always '1'
 D3 : Right direction (0=pressed, 1=released)
 D2 : Left direction (0=pressed, 1=released)
 D1 : Down direction (0=pressed, 1=released)
 D0 : Up direction (0=pressed, 1=released)

 When PDRx = 0x00

 D4 : Always '1'
 D3 : Right shoulder button (0=pressed, 1=released)
 D2 : Button X (0=pressed, 1=released)
 D1 : Button Y (0=pressed, 1=released)
 D0 : Button Z (0=pressed, 1=released)

 A small delay is needed between changing the state of PDR1 and reading
 the new button data. The pad I have seems to need no delay, but perhaps
 3rd party controllers using slower logic may need more time before they
 return new data after switching the input source.

 NiGHTS Analog Pad

 The controller that comes packaged with the NiGHTS video game has the
 same buttons as a standard controller, but also has an analog thumb pad,
 and the two shoulder buttons return analog as well as digital values.

 A switch on the pad selects analog pad mode and digital pad mode, I'll
 describe how both work.

 Analog mode

 The pad has some hardware that does the A-D conversion of the analog inputs
 and sends the data in nibble sized units through the I/O port. I'll call
 this hardware a state machine, though it could be something more complex
 like a microcontroller. (one of the chips is labeled 8751, which is the
 product number of a popular 8-bit MCU Sega has used in the past)

 Pins TH and TR are outputs, which are used to initialize the state machine
 and change states. Pin TL and D3-D0 are inputs, which give the machine's
 state and data values.

 The state machine is initialized by setting TH and TR to '1'. States are
 stepped through by leaving TH at '0' and setting TR to '0' then '1'.

 Assuming DDR1=0x60, PDR1=0x00, IOSEL=0x00, here's a description of how to
 poll the controller:

 Write      Read
 to PDRx    from PDRx   Description

 60         11          Probably indicates 'idle' state. Initializes transfer.
 * Leading 00 write after 60 is necessary to get 01 value below, otherwise
   a state is missed and some values fluctuate.
 00         11          Probably indicates 'idle' state
 00         01          ID? (01 for analog mode, 00 for digital mode)
 20         16          ID? (16 for analog mode, 12 for digital mode)
 00         0F          Direction keys: right, left, down up
 20         1F          Buttons: Start, A, C, B
 00         0F          Buttons: Right shoulder, X, Y, Z
 20         1F          Buttons: Left shoulder, 1, 1, 1
 00         08          Analog pad X axis MSB
 20         10          Analog pad X axis LSB
 00         08          Analog pad Y axis MSB
 20         10          Analog pad Y axis LSB
 00         00          Right shoulder MSB
 20         10          Right shoulder LSB
 00         00          Left shoulder MSB
 20         10          Left shoulder LSB
 00         00          No data (indicates end of transfer?)
 20         11          Probably indicates 'idle' state
 00         11          Probably indicates 'idle' state
 * Any further 20/00 writes return 11, no more data returned.
 60         11          Probably indicates 'idle' state. Ends transfer

 The data in the above table shows the value read from PDR with bits 7,6,5
 removed. Bit 4 is TL, which is an output from the state machine and
 toggles between 1 and 0 to show the current state. The lower four bits
 are D3-D0 which is the actual data being returned.

 The digital buttons return '0' when pressed and '1' when released.

 The two shoulder buttons return an unsigned value of $00 (not pressed)
 to $FF (fully pressed)

 The analog pad axis return $80,$80 at the center, $00 at the topmost
 or leftmost positions, and $FF at the bottommost or rightmost positions.

 The analog pad is in a circular shape, so some settings (such as $00,$FF
 for all the way left and down) are impossible to get.

 A delay between writing and then reading PDR is absolutely required. About
 ten NOPs seems to be enough. If you do not delay, then the data returned
 is almost random. (probably a corruption of various return values from
 the wrong states being sent at the wrong time)

 Digital mode

 In this mode the analog thumbpad is disabled, and the shoulder buttons
 return digital values only. The pad is programmed the same was as before,
 and here's another table:

 Write      Read
 to PDRx    from PDRx   Description

 60         11          Probably indicates 'idle' state. Initializes transfer.
 * Leading 00 write after 60 is necessary to get 00 value below, otherwise
   a state is missed and some values fluctuate.
 00         11          Probably indicates 'idle' state
 00         00          ID? (01 for analog mode, 00 for digital mode)
 20         12          ID? (16 for analog mode, 12 for digital mode)
 00         0F          Direction keys: right, left, down up
 20         1F          Buttons: Start, A, C, B
 00         0F          Buttons: Right shoulder, X, Y, Z
 20         1F          Buttons: Left shoulder, 1, 1, 1
 00         11          Probably indicates 'idle' state
 * Any further 20/00 writes return 11, no more data returned.
 60         11          Probably indicates 'idle' state. Ends transfer

 Again, a delay between PDRx accesses is necessary in this mode as well.

 When in digital mode, the pad does not return the same kind of data that
 the regular Saturn 6-button pads do, so it has to be read by changing
 states. So don't think of digital mode as being 100% compatible with
 a standard Saturn controller.

 ----------------------------------------------------------------------------
 VDP2 Color RAM
 ----------------------------------------------------------------------------

 The VDP2 has 4K of on-chip color RAM. This memory is mapped to the address
 range of $05F00000-$05F7FFFF, mirrored every 4K.

 Bits 13,12 of the RAMCTL register configure the CRAM mode:

 0 = CRAM is organized as 1024 words, color data stored in 5:5:5 format.
 1 = CRAM is organized as 2048 words, color data stored in 5:5:5 format.
 2 = CRAM is organized as 1024 longs, color data stored in 8:8:8 format.
 3 = CRAM is organized as 1024 longs, color data stored in 8:8:8 format.

 Mode 3 is undocumented, but appears to be identical to mode 2.

 In mode 0, values written to CRAM offsets $000-7FF are also written to
 offsets $800-FFF. Likewise, values written to offsets $800-FFF are written
 to offsets $000-7FF. So write mirroring is done for both parts of CRAM.

 In mode 1 there is no mirroring and the entire CRAM region can be
 accessed normally.

 In mode 2 and 3 the CRAM address bus has some bits shuffled around:

 MSB                                         LSB
 A11 A10 A09 A08 A07 A06 A05 A04 A03 A02 A01 A00 = Intended offset
  |   |   |   |   |   |   |   |   |   |   |   |
 A10 A09 A08 A07 A06 A05 A04 A03 A02 A01 A11 A00 = Actual offset

 This arrangement has the first two bytes of each four byte entry at
 CRAM offsets $000-7FF, and the last two bytes at offset $800-FFF.

 This distinction between how CRAM is addressed is important if a program
 reads or writes data in one mode that is to be used in a different mode.

 ----------------------------------------------------------------------------
 VDP2 Display
 ----------------------------------------------------------------------------

 The VDP2 generates the following types of displays:

 NTSC - 60 frames per second, 263 lines per frame
 PAL  - 50 frames per second, 313 lines per frame

 Here's a description of how each frame is composed. I have visually
 inspected the NTSC displays and provide more details about them, whereas
 for the PAL modes I can only divide the display into the active display
 and blanking/border/sync areas.

 NTSC, 224 lines:

 224 lines for the active display area
   8 lines for the bottom border area
   5 lines for the bottom blanking area
   3 lines for the vertical sync area
  15 lines for the top blanking area
   8 lines for the top border area

 NTSC, 240 lines:

 240 lines for the active display area
   5 lines for the bottom blanking area
   3 lines for the vertical sync area
  15 lines for the top blanking area

 PAL, 224 lines:

 224 lines for the active display area
  32 lines for the bottom border area
  25 lines for blanking and sync
  32 lines for the top border area

 PAL, 240 lines:

 240 lines for the active display area
  24 lines for the bottom border area
  25 lines for blanking and sync
  24 lines for the top border area

 PAL, 256 lines:

 256 lines for the active display area
  16 lines for the bottom border area
  25 lines for blanking and sync
  16 lines for the top border area

 A typical display frame looks like this:

 +----------------+ Scanline 0
 |                |
 | Active display | Graphics data is shown here.
 |                |
 +----------------+
 |                | Either black (BDCLMD=0) or set to the border color
 | Bottom border  | as defined by the back screen. The bottom border is
 |                | optional.
 +----------------+
 |                |
 | Bottom blanking| Appears as light black.
 |                |
 +----------------+
 |                |
 | Vertical sync  | Appears as pure black.
 |                |
 +----------------+
 |                |
 | Top blanking   | Appears as light black.
 |                |
 +----------------+
 |                | Either black (BDCLMD=0) or set to the border color
 | Top border     | as defined by the back screen. The top border is
 |                | optional.
 |                |
 +----------------+ Scanline 262 or 313

 Exclusive Monitor display modes

 When bit 2 of the HRESOx field is set, the exclusive monitor modes are
 enabled. It's not exactly clear what kind of monitor these modes are
 supposed to be used with, I would guess HDTV or possibly VGA.

 Depending on the screen width, the following types of displays are
 generated:

 320 or 640 pixels: (31kHz monitor)

 480 active display lines
  45 VBlank lines
 525 lines total

 352 or 704 pixels: (Hi-Vision monitor)

 479 active display lines
  82 VBlank lines
 561 lines total

 These display settings are identical between a NTSC and PAL Saturn.
 The VRESOx bits have no effect on the display size.

 It seems that while the LSMDx bits will enable an interlaced display,
 this is not required for the exclusive monitor modes. I would guess that
 enabling interlacing might adversely affect the display. The VDP2 manual
 recommends turning interlacing off entirely.

 ----------------------------------------------------------------------------
 VDP2 Registers
 ----------------------------------------------------------------------------

 0x25F80000 - Television Mode

 Bit    Name    Purpose
 D15    DISP    Display enable
 D8     BDCLMD  Border color mode
 D7     LSMD1   Interlace mode bits 1-0
 D6     LSMD0       "
 D5     VRESO1  Vertical screen size bits 1-0
 D4     VRESO0      "
 D2     HRESO2  Horizontal screen size bits 2-0
 D1     HRESO1      "
 D0     HRESO0      "

 DISP will blank the screen when cleared. During this time the VDP2 will
 not access VRAM or CRAM, and you have unlimited access to both. When DISP
 is set, VDP2 and VDP1 graphics are shown in the active display area.

 When DISP is cleared during the active display period, the screen will
 be turned off and will remain this way until VBlank. Any subsequent
 value written to DISP will be used for the next frame, and you can change
 DISP at any point until VBlank has ended.

 The BDCLMD bit determines what colors are shown in the border area and
 on scanlines where the display has been blanked by DISP. If BDCLMD is
 cleared then blanked lines and the borders always show black. If BDCLMD
 is set, then the following rules apply:

 If the back screen is in single color mode, the color value at the first
 address of the back screen table selects the color used for blanked lines
 and the borders.

 If the back screen is in line color mode, the last color output by the VDP2
 on a non-blanked line will be the color used for blanked lines and the
 borders. This is usually the data for line 223 (224 line mode), line 239
 (240 line mode), etc.

 The manual suggests that turning on BDCLMD without having the display
 turned on beforehand will cause the wrong colors to be displayed. I'd
 imagine this is because no color has been latched into whatever temporary
 storage the VDP2 uses to store the last back screen color displayed.

 Every display has left and right borders, but may not have top and bottom
 borders.

 LSMDx settings

 D7 D6
  0  0 = Normal display
  0  1 = Single density interlaced display (manual: setting not allowed)
  1  0 = Single density interlaced display
  1  1 = Double density interlaced display

 A setting of 01b is undocumented, but appears identical to 10b.

 The manual suggests these bits should be set to zero when using exclusive
 monitor modes. Enabling them in these modes seems to cause the display to
 become interlaced and adds an extra half-scanline at the end of each frame.

 As the exclusive monitor modes aren't supposed to be interlaced, I can
 only speculate that attempting to interlace the display might cause some
 side effects. (bad sync, flickering, etc.)

 VRESOx settings

 D5 D4
  0  0 = Display is 224 lines tall
  0  1 = Display is 240 lines tall
  1  0 = Display is 224 lines tall (NTSC) or 256 lines tall (PAL)
  1  1 = Display is 240 lines tall (NTSC) or 256 lines tall (PAL)

 For NTSC consoles settings of 10b and 11B are identical to 00b and 01b,
 respectively.

 For PAL consoles settings of 10b and 11b both enable a 256-line display.

 These bits are ignored when using exclusive monitor modes.

 HRESOx settings

 D2 D1 D0
  0  0  0 = Display is 320 pixels wide
  0  0  1 = Display is 352 pixels wide
  0  1  0 = Display is 640 pixels wide
  0  1  1 = Display is 704 pixels wide
  1  0  0 = Display is 320 pixels wide - Exclusive monitor mode enabled
  1  0  1 = Display is 352 pixels wide - Exclusive monitor mode enabled
  1  1  0 = Display is 640 pixels wide - Exclusive monitor mode enabled
  1  1  1 = Display is 704 pixels wide - Exclusive monitor mode enabled

 The 352/704 pixel modes require that you have increased the Saturn clock
 speed through the SMPC's clock change command. If you use these modes
 without changing the clock, the display goes out of sync.

 The last four settings are for the exclusive monitor mode which I believe
 is supposed to be HDTV or VGA compatible. In these modes, the display is
 480 scanlines tall and is non-interlaced. If you use these modes on a
 regular monitor, the display goes out of sync.

 0x25F80004 - Screen Status

 Bit    Name    Purpose
 D5     EXLTFG  HV counter latch flag
 D4     EXSYFG  External sync flag
 D3     VBLANK  Vertical blanking occurrence flag
 D2     HBLANK  Horizontal blanking occurrence flag
 D1     ODD     Even or odd frame flag
 D0     PAL     PAL display mode flag

 EXLTFG is set when the VDP2 has latched the HV counter, which can then be
 read through HCNT and VCNT. This bit is cleared when read. It seems to
 always return zero as the counter is not normally latched.

 EXSYFG always returns zero. It may be related to external video through
 the MPEG card.

 VBLANK is set when the display is in the vertical blanking period. It is
 also forcibly set when DISP of TVMD is cleared, regardless of the display
 state.

 It seems that for all display modes, the VBLANK flag is cleared for as many
 lines as there are in the active display area plus one, and it is set for
 all lines remaining in the frame.

 For example, for an NTSC 224-line display, the VBLANK flag is cleared on
 scanlines 0 to 224, and set on scanlines 225-262.

 HBLANK is set when the display is in the horizontal blanking period. It
 operates normally even when DISP of TVMD is cleared.

 ODD is set for odd frames in interlace modes or when not in an interlaced
 modes. It's cleared for even frames.

 PAL is always set for PAL consoles and cleared for NTSC consoles.

 0x25F80006 - VRAM Size / Version No.

 Bit    Name    Purpose
 D15    SIZE    VRAM size
 D3     VER3    VDP2 chip version bits 3-0
 D2     VER2        "
 D1     VER1        "
 D0     VER0        "

 Bit 15 specifies the size of the VDP2 VRAM chip. If cleared, VRAM is 512K.
 If set, VRAM is 1024K.

 The VDP2 only has 512K of VRAM. If you specify 1024K, then the VRAM space
 is broken down into 64K pages, where each odd 64K page mirrors the even one.
 In this way the 512K of memory is mirrored to fill the entire 1024K space.

 This probably has to do with how the VDP2 internally generates row and
 column addresses for the dynamic RAM chips used for VRAM.

 Bits 3-0 return the VDP2 chip version number. I believe this is always zero.

 None of the bits of this register retain their value when written to except
 for bit 15.

 ----------------------------------------------------------------------------
 SH-2 Memory Map
 ----------------------------------------------------------------------------

 All addresses are in hexadecimal.

 00000000-000FFFFF : Boot ROM (512K, mirrored every 512K)
 00100000-0017FFFF : SMPC registers (128 bytes, mirrored every 128 bytes)
 00180000-001FFFFF : Backup RAM (64K, mirrored every 64K) [1]
 00200000-002FFFFF : Work RAM Low (1MB)
 00300000-003FFFFF : Random data on every read (mostly $00)
 00400000-007FFFFF : Always returns $0000.
 00800000-00FFFFFF : Always returns $00000001000200030004000500060007.
 01000000-01FFFFFF : Always returns $FFFF. [4]
 02000000-03FFFFFF : A-Bus CS0
 04000000-04FFFFFF : A-Bus CS1
 05000000-057FFFFF : A-Bus Dummy
 05800000-058FFFFF : A-Bus CS2 [2]
 05900000-059FFFFF : Lockup when read
 05A00000-05AFFFFF : 68000 Work RAM (512K) [9]
 05B00000-05BFFFFF : SCSP registers (4K, mirrored every 4K)
 05C00000-05C7FFFF : VDP1 VRAM (512K)
 05C80000-05CFFFFF : VDP1 Framebuffer (256K, mirrored every 256K) [7]
 05D00000-05D7FFFF : VDP1 Registers [6]
 05D80000-05DFFFFF : Lockup when read
 05E00000-05EFFFFF : VDP2 VRAM (512K, mirrored every 512K)
 05F00000-05F7FFFF : VDP2 CRAM (4K, mirrored every 4K) [8]
 05F80000-05FBFFFF : VDP2 registers (512 bytes, mirrored every 512 bytes)
 05FC0000-05FDFFFF : Always returns $000E0000
 05FE0000-05FEFFFF : SCU registers (256 bytes, mirrored every 256 bytes)
 05FF0000-05FFFFFF : Unknown registers (256 bytes, mirrored every 256 bytes) [3]
 06000000-07FFFFFF : Work RAM High (1MB, mirrored every 1MB)

 The CS0 and CS1 regions of the A-bus are mapped to the cartridge port.
 These areas are set up differently depending on what kind of cart is used.

 Memory regions that return a constant value do so at all addresses within
 that region, in units of whatever size was specified.

 Notes:

 [1] Has 32K of battery backed RAM mapped to odd bytes only, even bytes
     return $FF. Writing to even bytes is the same as writing to odd ones.

 [2] The CD-ROM registers are mapped here, in 64 byte units mirrored
     every 64 bytes.

 [3] These registers are not mirrors of the SCU registers and are for
     something different. Not sure exactly what.

 [4] The SCU manual says $01000000 is the MINIT region and $01800000
     is the SINIT region. More specifically:

     The Dual CPU User's Guide says that the on-chip Free Running Timer (FRT)
     input capture signal of each SH-2 are connected to this region:

     01000000-017FFFFF : Data written goes to slave SH-2 FRT
     01800000-01FFFFFF : Data written goes to master SH-2 FRT

     The data size is 16-bits, and the area is write-only. When data is
     written, the corresponding SH-2's FRT will set a status flag and
     optionally (if programmed to) cause an interrupt. The SH-2 can wait
     for interrupts or poll the FRT to see when data is available.

     This feature is primarily used for communication between the
     two CPUs. I have not tried using it myself. :)

 [5] Some of the random data returned are 68000 opcodes. Maybe it's
     corrupted data taken from the 68000 work RAM.

 [6] Apart from the read-only registers at 05D00010-05D00017, all locations
     return garbage data which is usually $55AA on power-up.

 [7] The framebuffer that isn't being displayed is mapped to this region.
     On power-up it is filled with the value $55555AAAAA, though the BIOS
     will clear the upper-left 352x240 area.

 [8] Doing byte writes to even addresses overwrites the odd byte of the
     same word with a garbage value. Byte writes to odd addresses overwrite
     the even byte of the same word with a garbage value. Byte reads work
     normally.

 [9] If MEM4MB is cleared (bit 9 of $05B00400) the first 256K of work RAM
     is mirrored four times throughout the 05A00000-05AFFFFF range.

     Normally this bit should be set, which maps all 512K of work RAM to
     addresses 05A00000-05A7FFFF. The 05A80000-05AFFFFF region returns
     random data when read, some of which are words from the work RAM.

     I think this is whatever data was last left on the data bus, though
     that can be generated by several sources (DRAM refresh, 68000 fetches,
     and SCSP accesses).

 The SH7604 has a 32-bit address space. Of this, the lower 27 bits are mapped
 to the address bus, which give it a 128MB physical address space. Bits 28,27
 are not used, and bits 31-29 select special memory regions, which are as
 follows:

 31 30 29
  0  0  0 = Cache used (only if CE bit in CCR is set, otherwise no cache)
  0  0  1 = Cache not used
  0  1  0 = Associative purge area (Always returns $2312)
  0  1  1 = Direct access to cache addresses (1K data, mirrored every 1K)
  1  0  0 = Same as Cxxxxxxx
  1  0  1 = Same as 2xxxxxxx
  1  1  0 = Direct R/W access to cache data (4K data mirrored every 4K)
  1  1  1 = On-chip registers

 The on-chip register area is officially located at FFFFFE00-FFFFFFFF.
 The actual layout of the on-chip register area is as follows:

 MSB                                 LSB
 111x ???? ???? ???? ?1?x ???r rrrr rrrr

 x : See table below
 r : On-chip register offset
 ? : Bit value doesn't matter

 28 12
  0  0 : On-chip register offsets 0-255 map to garbage data.
  0  1 : On-chip register offsets 0-255 map to garbage data.
  1  0 : On-chip register offsets 0-255 map to garbage data.
  1  1 : On-chip register offsets 0-255 map to the registers.

 Offsets 256-511 always map to their respective registers regardless of the
 two above bits.

 The garbage data is $00000001000200030004000500060007.
 If bit 14 is cleared the SH-2 locks up when accessing this address.

 ----------------------------------------------------------------------------
 Miscellaneous
 ----------------------------------------------------------------------------

 Screen mode

 You can change the horizontal resolution between 320/640 or 352/704 pixels
 at any time in the display. Split screens with different resolutions are
 possible. Due to the time lag in changing the Saturn clock speed, I don't
 think changes between 320/352 or 640/704 resolutions are possible to do
 as part of a split-screen effect.

 Changing the VRESOx bits at the end of the frame will trick the VDP2 into
 enabling or disabling the top and bottom borders as well as changing the
 screen height. This technique works much the same way as it does on
 the SMS 2 and Genesis.

 Light gun

 This is all untested, but here are some thoughts about how light guns
 are supported on the Saturn:

 The SMPC can be configured through the EXLE register to allow bit 6 of
 either I/O port, when set up as an input, to trigger a signal to the SCU
 and VDP2. While the documentation is sparse, it seems that the SCU will
 generate an interrupt when this occurs. The VDP2 can be set up to latch
 the HV counter, and will show if this happened in the status flags.

 I would imagine your typical light gun game would set up both features,
 so the light-sensing feature of the gun would trigger an interrupt and
 simultaneously latch the HV counter, which the interrupt subroutine could
 investigate. I believe this is a mostly correct interpretation of how Saturn
 lightguns work, as I had modified a Saturn lightgun to work on the Genesis
 based on the same concepts.

 NTSC Saturn timing

 The Saturn has a PLL which uses a 14.31818 clock to generate two user
 selectable clocks:

 1. 26.8465875 MHz (master clock x2, minus 3.579545/2)
 2. 28.63636 MHz (master clock x2)

 The selectable clock source is used by both SH-2s, the VDPs, and SCU.
 The SCSP and SMPC are unaffected; I believe the SCSP has it's own clock,
 and the SMPC has a 4 MHz clock (for the CPU part) and a 32.768 Khz clock
 (for the RTC part).

 The VDP1 and VDP2 render pixels at a rate of 1/4th of the system clock,
 which gives:

 1. 6.711646875 MHz
 2. 7.159090 MHz

 Assuming the default of a 263-line display at 60 frames per second, you
 get the following amount of pixels per scanline:

 1. 425.3261644 pixels
 2. 453.6812421 pixels

 Clock 1 will work with a 320/640 pixel display only.
 Clock 2 will work with a 320/640 or 352/704 pixel display.

 I would assume that trying to use the 352/704 pixel display with clock 1
 doesn't work because there are not enough pixels for the various portions
 of the line to fit, e.g. blanking, sync, border, active portion, etc.
 This is why the screen goes out of sync.

 Note that the amount of pixels per scanline relates to the available range
 of values for timer 1, which is the pixel clock timer:

 1. $001-$1AA (1-426, for a 320/640 pixel display)
 2. $001-$1C6 (1-454, for a 352/704 pixel display)

 I haven't checked if the high end of the timer range is dependant on the
 current screen mode or system clock. It could be either one or both.

 Using a 320/640 pixel display with clock 1 results in a much larger overscan
 area on the right side of the display, because there are more pixels per
 line than needed. Either the VDP2 compensates by extending the right
 horizontal border period (unlikely), or you are seeing part of the right
 horizontal border that would normally be off-screen.

 MPEG card

 The MPEG card allows video CDs to be played back on the Saturn. There are
 different versions of the card from several manufacturers such as Sega,
 Victor, and Hitachi. Some are PAL or NTSC only, others support both regions.
 The Victor ones support Photo CD viewing as well.

 The MPEG card contains the following hardware: (this is from a stock PAL
 card made by Sega)

 - 2x Fast page DRAM (256Kx16) chips
 - 1x Mask ROM (Sega P/N MPR-17896-H)
 - 1x Hitachi HD814102F MPEG audio decoder
 - 1x Hitachi HD814101FE (Sega P/N 315-5765, MPEG video decoder?)

 The DRAM is most likely used to store decoded video frames. Apparently
 foreign MPEG cards don't work in Saturn consoles from a different territory,
 and this can be circumvented by using an Action Replay or similar device.
 I'd say the mask ROM most likely contains code for the SH-2 rather than the
 SH-1, since only the SH-2 has access to the SMPC for doing territory
 checking.

 The only details on the custom parts I could find are from a summary of the
 Hitachi Review Vol.44 No.6 edition:

 "The HD814103FE uses horizontal and vertical interpolation filters, and is
 capable of reproducing high quality pictures. It also supports various
 display functions such as expand, shrink, and move."

 The HD814102F supports MPEG1/Audio layers 1 and 2, and integrates internal
 memory to decode the audio signal, thus not requiring external memory."

 The HD814103FE it mentions could be related to the HD814101FE. If anyone has
 the full text of this article, datasheets for any of the parts, or a dump
 of the MPEG card ROM, please let me know.

 VDP2 EXTEN register

 One feature of the EXTEN register is to enable input of an external video
 source, which is not implemented in the Saturn. When DASEL and EXBGEN
 are set, the overscan area is not displayed and instead the entire overscan
 area is filled with garbage data.

 The data itself comes from the last values left in the internal circuitry
 of the background generating hardware in the VDP2. For example, data shown
 in the rightmost pixel of the display fills in the right overscan area
 horizontally, and also appears the next line down in the left overscan area.

 Likewise, the bottom and top borders are filled with pixel data from the
 last row of the last tile displayed, which is repeated horizontally across
 the display.

 Presumably if there was an external video source, the background generating
 hardware would be loaded with this data and it would be displayed properly.
 Instead the 'leftover' pixel data from the active display area is shown
 in it's place.

 ----------------------------------------------------------------------------
 Credits and Acknowledgements
 ----------------------------------------------------------------------------

 - Runik for PAL testing and advice.
 - Chris MacDonald for beta testing and support.
 - Anders M. Montonen for testing and support.
 - Stefano for fixes and testing suggestions.

 ----------------------------------------------------------------------------
 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.

</pre>