NEC SuperGrafx hardware notes
by Charles MacDonald
WWW: http://cgfm2.emuviews.com
Unpublished work Copyright 2003, 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 SuperGrafx console,
but please be aware that my testing methods or interpretations of results
could be flawed. I can't guarantee that everything is 100% accurate.
What's New:
[04/17/04]
- Completed S-EXP port pin assignments.
- Clarified information about I/O port.
[02/21/03]
- Added information about 74HC157 output state for the S-EXP port.
- Added information about VDC #2 interrupts.
Table of contents:
- Overview
- Memory map
- I/O port
- PAD connector
- S-EXP connector
- EXT BUS connector
- Video Priority Controller
- Miscellaneous
- SuperGrafx software
- Disclaimer
----------------------------------------------------------------------------
Overview
----------------------------------------------------------------------------
The SuperGrafx is an upgraded version of the original PC-Engine, which is
mostly backwards compatible with it. It's improved features are:
- 32K of work RAM for the HuC6280 instead of 8K like the original PC-Engine.
- A second VDC with 64K of VRAM.
- A video priority controller chip to mix the output of both VDCs, the
combined output is sent to the VCE for display.
It has the following components:
Hudson HuC6202 Video Priority Controller
Hudson HuC6260A Video Color Encoder
Hudson HuC6270 (x2) Video Display Controller
Hudson HuC6280A CPU
HSRM20256-LM10 32K SRAM for CPU work RAM
HSRM20256-M12 (x4) 128K SRAM for video RAM (32Kx2 per VDC)
MC74HC157N Quad 2-to-1 multiplexer for PAD and S-EXP ports
I don't know if the 'A' revisions of the VCE and CPU are different
from what was used in the original PC-Engine and TurboGrafx-16. Since
the VPC and VDC have no 'A' suffix, they are probably unchanged from
the first version of Hudson Soft's original C62 chip set.
Even though each VDC chip can support up to 128K of video RAM, each one
only has 64K available, just like the original PC-Engine.
The system has a switch located in the back of the unit which selects
either PC-Engine compatability mode or native SuperGrafx mode. This
switch is to support original PC-Engine games which try to access the
VDC at mirrored locations, which the SuperGrafx hardware uses.
The SuperGrafx has the same type of EXT-BUS connector used in the PC-Engine
and other systems to interface with a CD-ROM drive. However, the unique
shape of the SuperGrafx prevents it from fitting into the IFU-30 interface
tray for use with the original CD-ROM drive.
NEC sold an extension cable called the RAU-30 that clips on to the back of
the SuperGrafx, and has a PC-Engine shaped box on the other end of the
cable that fits into the IFU-30 to allow the two to work.
----------------------------------------------------------------------------
HuC6280 memory map
----------------------------------------------------------------------------
Bank map
00-7F : HuCard ROM
80-87 : Unused (returns $FF, optionally 64K of CD RAM goes here)
88-F6 : Unused (returns $FF)
F7 : Unused (returns $FF, optionally 2K of backup RAM goes here)
F8-FB : Work RAM (32K)
FC-FE : Unused (returns $FF)
FF : I/O region
The above layout assumes a stock machine with no special HuCards or
accessories being used. The full 32K of work RAM is always available
regardless of being in PC-Engine or SuperGrafx mode.
The I/O region has the following layout:
0000-03FF : Video chip area
0400-07FF : VCE registers
0800-0BFF : PSG registers
0C00-0FFF : Timer registers
1000-13FF : I/O port
1400-17FF : IRQ registers
1800-1BFF : Unused (returns $FF, optionally CD/backup registers go here)
1C00-1FFF : Unused (returns $FF)
The video chip area has two different arrangements. In PC-Engine mode,
VDC #1 has it's registers mapped here, mirrored repeatedly for every 4
bytes. In SuperGrafx mode, a 32-byte block is mirrored throughout the 1K
space containing more registers:
0000-0003 : VDC #1 registers
0004-0007 : VDC #1 registers (mirror)
0008-000F : VPC registers
0010-0013 : VDC #2 registers
0014-0017 : VDC #2 registers (mirror)
0018-001F : Unused (returns $FF)
----------------------------------------------------------------------------
I/O port
----------------------------------------------------------------------------
The HuC6280 contains an 8-bit input port and 8-bit output port as part of
it's on-chip peripherals. Writing to $1000-$13FF sets the state of the
output latch connected to the output port pins, and reading $1000-$13FF
returns the state of input port pins.
The inputs have pull-up resistors, so they return '1' when left unconnected
or not being actively driven low.
HuC6280 pin Description SuperGrafx use
22 Input port bit 0 From 74HC157 1Y (PAD pin G, S-EXP pin e) (D0)
24 Input port bit 1 From 74HC157 2Y (PAD pin F, S-EXP pin f) (D1)
25 Input port bit 2 From 74HC157 3Y (PAD pin E, S-EXP pin g) (D2)
26 Input port bit 3 From 74HC157 4Y (PAD pin D, S-EXP pin h) (D3)
27 Input port bit 4 Not connected
28 Input port bit 5 Not connected
29 Input port bit 6 Not connected
30 Input port bit 7 From EXT-BUS pin CD
31 Output port bit 0 To S-EXP pin p, PAD pin C (SEL)
32 Output port bit 1 To S-EXP pin o, PAD pin B (CLR)
33 Output port bit 2 To S-EXP pin n
34 Output port bit 3 To S-EXP pin m
35 Output port bit 4 To S-EXP pin j
36 Output port bit 5 To S-EXP pin a
37 Output port bit 6 To S-EXP pin b
38 Output port bit 7 To S-EXP pin c
Input port bits 3-0 are shared between the PAD and S-EXP connectors through
a multiplexer.
Input port bits 6-4 are not connected and return '1' when read.
Bit 6 is used by export software to detect if the system is PC-Engine
compatible (bit 6 = 1) or TurboGrafx-16 compatible (bit 6 = 0).
Bit 7 is used by pin CD of the EXT-BUS connector to determine if a device
is connected to it (bit 7 = 1) or if nothing is present (bit 7 = 0).
Output ports bit 0,1 (SEL and CLR) go to both the PAD and S-EXP connectors,
and are always active regardless of something being plugged into the
S-EXP connector or not.
----------------------------------------------------------------------------
PAD connector
----------------------------------------------------------------------------
This is a 8-pin female mini DIN connector, identical to the type used on
other NEC systems like the PC-Engine / Shuttle / Duo / R / RX consoles.
Left Right
A B C
D E F
G H
A = Ground
B = Output port bit 1 (CLR)
C = Output port bit 0 (SEL)
D = Input port bit 3 (D3)
E = Input port bit 2 (D2)
F = Input port bit 1 (D1)
G = Input port bit 0 (D0)
H = +5V
The plug notch is directly above pin B.
The controller circuit board has a 9-pin connector which the cable plugs
into. Here is it's pinout, assuming you are looking at the board with
the component side facing you.
Left Right
1 2 3 4 5 6 7 8 9
1 = +5V
2 = Input port bit 0 (D0)
3 = Input port bit 1 (D1)
4 = Input port bit 2 (D2)
5 = Input port bit 3 (D3)
6 = Output port bit 0 (SEL)
7 = Output port bit 1 (CLR)
8 = Ground
9 = Ground (Shield)
----------------------------------------------------------------------------
S-EXP connector
----------------------------------------------------------------------------
This is an 18-pin female connector located at the front of the unit. It
is an expanded version of the PAD connector with more output pins.
Left Right
a b c d e f g h i
j k l m n o p q r
a = Output port bit 5
b = Output port bit 6
c = Output port bit 7
d = Ground
e = Input port bit 0 (D0)
f = Input port bit 1 (D1)
g = Input port bit 2 (D2)
h = Input port bit 3 (D3)
i = +5V
j = Output port bit 4
k = Ground
l = Multiplexer select input (GND= S-EXP, +5V= PAD)
m = Output port bit 3
n = Output port bit 2
o = Output port bit 1 (CLR)
p = Output port bit 0 (SEL)
q = Ground
r = +5V
A 74HC157 multiplexer is used to share input port bits D3-D0 between the
PAD and S-EXP connectors. It is always enabled, and has the select input
tied to S-EXP pin l through a pull-up resistor. This means that normally
the PAD connector is used, and if something is plugged in to the S-EXP port,
the PAD connector inputs are disabled and bits D3-D0 of the input port are
routed to the S-EXP connector instead.
As far as I know, NEC only released one peripheral which used the S-EXP
port, which was a multi-function input device. I don't know if it was
commercially released or was only in the prototype stages; some magazines
have a picture of the unit with the SuperGrafx plugged into the back.
It's not known if any existing SuperGrafx software supports it.
----------------------------------------------------------------------------
EXT BUS connector
----------------------------------------------------------------------------
This is used to hook the SuperGrafx up to a CD-ROM peripheral, and most
likely works with other items like the various backup boosters, A/V
booster, and printer.
My unit had a modification made to the board; a wire was added to join the
/OE pin on the EXT BUS connector to the /RD pin on the HuCard card edge
connector. I don't know if all units have this or if it was a problem
with earlier models only. I've seen a photograph of another SuperGrafx
with the same modification as well.
----------------------------------------------------------------------------
Video Priority Controller
----------------------------------------------------------------------------
The VPC performs several functions:
- Controls address decoding for the video register area determined by the
compatability mode switch.
- Combines the video output of VDC #1 and VDC #2, passing the result to
the VCE for display.
- Allows the store-immediate instructions (ST0, ST1, ST2) to affect either
VDC #1 or VDC #2.
- Mananges two windows to allow modification of priority and visibility
between the VDC #1 and VDC #2 displays on a per-pixel basis.
Overview
The VDC has a 9-bit bus which transmits pixel data (4 bits), palette data
(4 bits), and a sprite/background indicator (1 bit). In other systems,
this bus is connected to the VCE and directly indexes it's 512-entry color
table. For the SuperGrafx this is connected to the VPC for further
processing.
Priority between backgrounds and sprites are managed internally to the
VDC, and no priority information is output for the VPC to use. This means
that the VPC cannot distinguish between the following:
- High priority or low priority sprites
- Background tiles with low-priority sprites in an earlier SAT position
behind them to mask out high-priority sprites with a later SAT position
in front.
The priority management that the VPC is responsible for is simply ordering
the four layers (VPC #1 background, sprites, VPC #2 background, sprites)
based on the sprite/background indicator bit and the transparency state
of the pixel data from each layer.
Windows
The VPC has two 10-bit registers which define the width of Window 1 and
Window 2. The windows start from the leftmost pixel of the physical screen,
not the active display area, which is a window width setting of $0040.
Values smaller than this disable the window, and values larger than this
make the window extend horizontally across the screen, from left to right,
A setting of $3FF makes the window take up the entire width of the screen.
Priority Control
VPC registers $0008 and $0009 make up four 4-bit register groups:
Bit 3 : Priority mode, bit 1
Bit 2 : Priority mode, bit 0
Bit 1 : VDC #2 display enable (0= off, 1= on)
Bit 0 : VDC #1 display enable (0= off, 1= on)
Store Immediate Control
The VPC manages video output from both VDC chips and determines which
pixel data from either VDC will be sent to the VCE to be displayed. It
seems to also handle address decoding for the VDC memory area, to map
the VDC #2 and it's own registers there.
The VPC controls two windows which individually select which VDC layers
are enabled and what the priority setting is. The windows can have their
width defined in units of single pixels, and are as tall as the height of
the display. There are four possible areas defined by the windows; where
there is no window, only window 1, only window 2, or where window 1 and
2 overlap.
Registers $0008 and $0009 make up four 4-bit values that define the
enabled layers and priority setting for the four possible window areas.
Each 4-bit value has the same format:
bit 3 : Bit 1 of priority setting
bit 2 : Bit 0 of priority setting
bit 1 : VDC #2 graphics are 0=disabled, 1=enabled
bit 0 : VDC #1 graphics are 0=disabled, 1=enabled
Bits 7-4 of $0008 are for the region occupied by window 2
Bits 3-0 of $0008 are for the region where window 1 and 2 overlap
Bits 7-4 of $0009 are for the region where no window is present
Bits 3-0 of $0009 are for the region occupied by window 1
Both registers return the value last written.
If both VDC graphics layers are disabled, color 0 from the VCE color
table is shown for all pixels in the region affected. This includes the
overscan area, which in a regular TurboGrafx-16/PC-Engine is filled
with color 256 (first entry of the sprite palette).
The default priority as as follows:
Back Front
SP2 > BG2 > SP2' > SP1 > BG1 > SP1'
BG2 = VDC #2 background
SP2 = VDC #2 low priority sprites
SP2'= VDC #2 high priority sprites
BG1 = VDC #1 background
SP1 = VDC #1 low priority sprites
SP1'= VDC #1 high priority sprites
The 2-bit priority field affects the layer ordering. The above default
priority setting is selected for values of 00b and 11b.
For 01b, VDC #1 sprites are shown behind the VDC #2 background. However,
the VDC #1 background has missing sprite-shaped areas where it's sprites
are, even though they are hidden behind both background layers.
For 10b, VDC #2 sprites are shown in front of the VDC #1 background and
behind VDC #1 sprites. However, low priority VDC #2 sprites are still
shown behind VDC #2 background tiles.
To my understanding, both VDC chips output a 9-bit code, which consists
of four bits for pixel data, four bits for palette data, and one bit
which is a background or sprite indicator. This is why a setting of 01b
has missing areas where the sprites are, because the VDC #1 isn't sending
any background graphics data for those pixels, only sprite data. For
the same reason, this is why a setting of 10b allows VDC #2 sprites to
appear over the VDC #1 background but still be shown behind the VDC #2
background if the sprite is low priority. The sprite and background priority
handling is done internally by the VDC, and the final image is output to
the VPC. The VPC can't tell the difference between low and high priority
sprites.
The window width is a 10-bit value. Values smaller than $40 mean the window
is hidden but I haven't checked to see if this affects the horizontal
overscan area. Here are the registers used:
$000A : Window 1 (LSB in D7-D0)
$000B : Window 1 (MSB in D1-D0)
$000C : Window 2 (LSB in D7-D0)
$000D : Window 2 (MSB in D1-D0)
Each register returns the value last written, though the MSB register
only retains data in bits 1 and 0.
When bit 0 of register $000E is set, the ST0, ST1, and ST2 instructions
send data to VDC #2 instead of VDC #1. Regular access (STZ, STX, etc.) to
the VDC #1 or #2 registers function normally. Reading this register always
returns $00.
Register $000F seems to be unused. Reading it always returns $00.
On power-up the VPC is initialized to the following settings for
registers $0008 through $000F:
$11 $11 $00 $00 $00 $00 $00 $00
This disables the windows and store immediate to VDC #2 mode, and has the
same priority setting with only VDC #1 enabled for all window regions.
----------------------------------------------------------------------------
Miscellaneous
----------------------------------------------------------------------------
On power-up, work RAM banks $F8 and $FA are initialized to mostly zero with
some random data, and banks $F9 and $FB are initialized to mostly $FF with
some random data.
When reading the VCE color data, odd addresses return random data in unused
bits 7-1. In a TurboGrafx-16 these bits are always fixed at '1'.
On power-up, most of the VCE color entries are initialized with many or all
of the bits set. This is why turning on a SuperGrafx with no game inserted
gives a white or bright pink, green, or blue screen. The color table address
is always reset to zero.
Even though the VPC window / priority settings affect the entire height of
the display, I think the designers assumed raster effects would be used to
split up the screen vertically.
Since the VCE controls the dot clock for both VDC chips and the VPC, it's
not possible to have mixed resolutions. However, each VDC can define how
much of the display it will use through it's own screen size registers.
The /IRQ1 input of the HuC6280 is shared with both VDC's. This means
that when an IRQ1 interrupt occurs, you have to read the status flags
from VDC #1 and #2 to determine which one caused it.
There's no conflict if they both request an interrupt at the same time,
but you do need to acknowledge the interrupt by reading the status flags
from VDC #1 and #2.
From a programming standpoint, as both video chips are in sync with each
other and are managed by the same CPU, it would be easier to disable
interrupts on VDC #2 and only use them on VDC #1. After all, there's no
point in having both of them cause a VD interrupt at the end of the frame.
----------------------------------------------------------------------------
SuperGrafx software
----------------------------------------------------------------------------
Here's a list of all of the SuperGrafx games I know of:
- Ghouls & Ghosts
- Grandzort
- Battle Ace
- Aldynes
- 1941 Counter Attack
Darius Plus is a regular PC-Engine game which uses the SuperGrafx (if
present) to add more sprites for less flicker. Darius Alpha is a
promotional version of the game which has the same feature, it was given
to people who had purchased the Darius Plus HuCard as well as the Super
Darius CD game.
Strider is not a SuperGrafx game and was released as a CD game which
required the Arcade Card. Even then, it is a pretty bad port of the
original game, though the redone soundtrack is nice. :)
There are no CD, SCD, or ACD games which were written for the SuperGrafx.
----------------------------------------------------------------------------
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.