Copy Link
Add to Bookmark
Report
Sega Saturn hardware notes by Charles MacDonald
Sega Saturn hardware notes
by Charles MacDonald
WWW: http://cgfm2.emuviews.com
Unpublished work Copyright 2002 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 11/29/02
Table of contents
- Introduction
- SMPC
- VDP2 Color RAM
- VDP2 Display
- VDP2 Registers
- SH-2 Memory Map
- Miscellaneous
- Credits and Acknowledgements
- Disclaimer
Change log:
- 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
89 lines for blanking and sync
PAL, 240 lines:
240 lines for the active display area
73 lines for blanking and sync
PAL, 256 lines:
256 lines for the active display area
57 lines for blanking and sync
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 312
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. I don't know what this means - maybe the
area is write-only and that's why no interesting data is being returned.
[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
----------------------------------------------------------------------------
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.
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.
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.
----------------------------------------------------------------------------
Credits and Acknowledgements
----------------------------------------------------------------------------
- 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.
