Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
1753 lines (1352 sloc) 74.9 KB
TurboGrafx-16 Hardware Notes
by Charles MacDonald
Unpublished work Copyright 2001, 2002 Charles MacDonald
Revision history:
- Initial revision
- Added CD-ROM details to memory map
- Added CD sense bit to I/O port
- Fixed description of read latch loading
- Added display parameter list
- Formatted and cleaned up document
- Added BRAM details
- Added display layout information
- Re-tested the effect of illegal instructions on P and S
- Re-tested P startup value
- Re-tested MPR startup value
- Rewrote T-flag section
- Rewrote CD-ROM section
- Added details to VCE section
- Added more details to VCE section
- Added joypad connector pinout
- Added 2-button controller details
- Added Turbo Tap information
- Added information on block transfer instructions
- Added description of MWR register and CG mode processing
- Added description of VDC addresss and register access
- Added sprite information
- Added background information
- Confirmed use of status flag bits
- Added several registers to register reference
- Added read result for VCE address registers
- Added preliminary Super System Card information
- Added details of BRAM unlock sequence
- Added information on VDC register $05
- Added information on VDC/VCE accesses
- Added sprite section
- Added details on invalid pattern name values
- Added details on $0800-$17FF data buffer
- Added information on invalid TAM/TMA arguments
- Added information on store immediate instructions
- Added information on BRK and B flag
- Confirmed cycle count for illegal instructions
- Added information on cross-page/bank branches
- Added information on RMW instructions
- Added information on JMP,indirect
- Added information of P state within interrupts
- Added information on T flag and RTI
- Added better description of TMA #$00 results
- Added information on when CRT registers can be changed
- Added DMA section
- Added timer section
- Added interrupt section
- Fixed VCE dot clock information
- Made minor changes to a few sections
- Confirmed CPU speed at power-up
- Added timing section
- Added more details to the timer section
- Added a note about ADC
- Added information on how TAM and TMA work
- Rewrote description of RCR register
- Added observations about CD-ROM registers
- Added information on ADPCM hardware
- Added more information about block transfers
- Added more information on TMA #$00
- Added information on IRQ2
- Added information on initial timer and IRQ register values
- Added a note about SBC
- Added details about VCE palette flicker
- Added details on flag calculation for some instructions
- Rewrote display details section
- Fixed description of VDC's VD flag
- Added some notes about the PSG
- Added lots of information to the CD section
- Added a note about $180D
- Added a note about block transfer instructions
- Added details on CSL, CSH
Table of contents:
1.) Introduction
2.) HuC6280 - CPU
2.1) Interrupts
2.2) Timer
2.3) T flag
2.4) Timing
3.) Memory map
4.) I/O port
5.) HuC6260 - Video Display Controller
5.1) Register reference
5.2) Background
5.3) Sprites
5.4) DMA
6.) HuC6270 - Video Color Encoder
7.) Display details
8.) CD-ROM
8.1) Super System Card
9.) Display parameter settings
10.) Programmable Sound Generator
11.) Acknowledgements
12.) Contact
13.) Disclaimer
1.) Introduction
This document is in a very preliminary state and is subject to change.
Everything within has been tested and verified on a TurboGrafx-16 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.
At the moment, some parts of this document are simply a compilation of
notes and test results, while others are detailed descriptions of the
hardware. I'll try to get everything coordinated as time progresses.
2.) HuC6280 - CPU
- Block transfer instructions push Y, A, X to the stack in that order, and
then pop X, A, Y from the stack in that order when finished.
- For the alternating block transfer instructions (TAI and TIA), they
alternate the source or destination address by adding and then
subtracting one; not by inverting bit 0 of the address.
- The length parameter to a block transfer instruction specifies the
number of bytes to transfer. For example, $0010 will transfer 16 bytes,
and $0000 will transfer 64K bytes, not zero.
- Block transfer instructions cannot be interrupted. If an interrupt
is supposed to occur, it occurs once the instruction finishes.
- When using any block transfer instruction to read addresses $0800 through
$1400 in the I/O page, the value zero is always returned for every
address, regardless of the CPU speed. (So you can't read the joystick
port, timer, or IRQ registers) The I/O buffer is not changed either.
Writing to the same range of addresses using the block transfer
instructions will work, and the I/O buffer will be modified.
- Stack and zero page operations always use logical addresses $2000-$21FF.
For example, ROM data can be read by using instructions that access the
zero page or stack.
- On power-up, MPR 7 is set to zero, and the other MPRs are loaded
with random values.
- The TMA instruction transfers the contents of an MPR register to the
accumulator. Bits 7 to 0 in the operand specify which MPR register to
read from, bit 7 is MPR #7 and bit 0 is MPR #0.
If an operand of $00 is used, the accumulator is loaded with the last
value that was written with TAM (only if one or more of it's operand bits
were set), or the last value that was read with TMA. I think the CPU
treats zero as a 'no change' value and the MPR selecting logic isn't
updated from the last time it was set.
If multiple bits are set in the operand to TMA, the values from several
MPRs are combined together and returned. However, I have not figured out
exactly how this works.
- The TAM instruction transfers the contents of the accumulator to an MPR
register. Bits 7 to 0 in the operand specify which MPR register to write
to, bit 7 is MPR #7 and bit 0 is MPR #0.
If an operand of $00 is used, none of the MPR registers are written to.
This does not change the last MPR value that can be read by TMA #$00.
If multiple bits are set in the operand to TAM, each MPR register selected
is loaded with the accumulator. For example, an operand of $FF would load
all MPR registers.
- ST0, ST1, ST2 write immediate data directly to the VDC (at physical
addresses $1FE000-$1FE003), the address is not translated through the
CPUs memory mapping hardware.
- When an interrupt occurs (I've tested the timer and IRQ1), P is pushed
with the current state of D and T. Within the interrupt subroutine, the
CPU clears D, T and sets I, preventing further interrupts from occuring.
- The B flag is set at all times. The only exception is when an interrupt
occurs, (I've tested the timer and IRQ1) in this case the value of P
pushed to the stack has B cleared. (but B is set if P is read again
within the interrupt subroutine) The BRK instruction pushes P with B set.
- BRK pushes the return address plus one to the stack; the next byte after
the BRK instruction is always skipped.
- The CSL and CSH instructions change the CPU's clock speed. CSL selects
low speed mode which is 1.78 MHz, CSH selects high speed mode which is
7.16 MHz. On power-up the CPU is in low speed mode.
CSH and CSL take 3 cycles each, but that was tested with the CPU already
set to the respective clock speed. It currently isn't known if either
instruction takes more or less time when switching between different
- On power-up, the timer count is set to zero and the IRQ disable mask is
set to zero.
6502/65C02 bugs and features compared against the HuC6280:
- On power-up, A, X, Y, and S hold random values. P always has T and D
cleared, I and B set, and N, Z, V, C are random.
- A branch instruction that crosses a 256-byte or 8192-byte boundary does
not take any additional cycles.
- An indirect JMP instruction with the low byte of the address set to $FF
will correctly read the high byte at the next address, instead of wrapping
to address 0 like the 6502 does. (so jmp [$FEFF] reads the MSB from
address $FF00, not $FE00)
- Illegal opcodes are treated as a NOP, and take 2 cycles each.
They do not change the state of the A, X, Y, S, or P registers, with the
exception that the T flag will be cleared if set prior to executing an
illegal opcode (check the section on the T flag for more information).
I tested the following opcodes:
E2, 63, 33, 0B, 2B, 4B, 6B, 8B, AB, CB, EB, 1B, 3B, 5B, 7B, 9B,
BB, DB, FB, 5C, DC, FC
- Read-modify-write instructions read the effective address once, then
write the modified value. There are no dummy writes (like the 6502) or
reads. (like the 65C02)
- The decimal mode versions of ADC and SBC do not change the state of the
overflow flag.
Flag calculation
I haven't tested all of the instructions, just those that I wasn't sure
Logical Shift Right (LSR)
N = 0
C = Bit 0 of operand
Z = Set if result is zero
Pull X, Pull Y (PHX, PHY)
N = Bit 7 of pulled byte
Z = Set if pulled byte is zero
Rotate Left (ROL)
C = Bit 7 of operand
N = Bit 6 of operand
Z = Set if result is zero
Rotate right (ROR)
N = Set if carry is set
C = Bit 1 of operand
Z = Set if result is zero
Test and Set Bits (TSB)
Test and Reset Bits (TRB)
N = Bit 7 of result
V = Bit 6 of result
Z = If result is zero
Test (TST)
N = Bit 7 of operand
V = Bit 6 of operand
Z = Set if if operand & immediate byte is equal to zero
Bit (BIT)
N = Bit 7 of operand
V = Bit 6 of operand
Z = Set if if operand & accumulator is equal to zero
For the immediate form of this instruction, the flags are still calculated
in the same way. So 'BIT #$C0' would set N and V, for example.
2.1) Interrupts
The HuC6280 has several interrupt sources:
NMI - Not used. It isn't connected to anything internally nor is it
available on any connector.
IRQ2 - Available on the HuCard and backplane connectors. It's used by the
CD-ROM's ADPCM hardware, and the BRK instruction also uses the IRQ2
IRQ1 - Connected to the VDC.
Timer - Generated by the HuC6280's internal timer.
The patents mention an external input used to test timer interrupts,
but I believe this isn't used in the TurboGrafx-16.
Interrupts can be disabled through the CPU, the I flag of the P register
disabled interrupts (except NMI, BRK) when set. In addition, there are
four registers, two of which are usable, that control interrupts:
$1400 : Writes do nothing, reads return the I/O buffer contents.
$1401 : Writes do nothing, reads return the I/O buffer contents.
$1402 : Bits 2-0 are interrupt enable/disable bits, which can be read as
well as written.
bit 2 - 1= Disable timer interrupt, 0= Enable timer interrupt
bit 1 - 1= Disable IRQ1 interrupt, 0= Enable IRQ1 interrupt
bit 0 - 1= Disable IRQ2 interrupt, 0= Enable IRQ2 interrupt
Bits 7-3 return the I/O buffer contents.
$1403 : Writing any value acknowledges the timer interrupt.
Reads return the interrupt state in bits 2-0:
bit 2 - 1= Timer interrupt pending, 0= No timer interrupt
bit 1 - 1= IRQ1 interrupt pending, 0= No IRQ1 interrupt
bit 0 - 1= IRQ2 interrupt pending, 0= No IRQ2 interrupt
Bits 7-3 return the I/O buffer contents.
The enable/disable register does not actually stop the interrupt from
occuring; for example if the VDC asserts the IRQ1 line, and bit 1 of $1402
is set, then an interrupt isn't generated. But you can still read the state
of the IRQ1 line through $1403, and bit 1 would be set in this case.
All interrupts need to be acknowledged. If not, the interrupt in question
occurs after every instruction that is executed (unless the I flag or
interrupt disable registers are used)
2.2) Timer
The HuC6280 has a 7-bit timer that is decremented once every 1024 clock
cycles. This is based on a 7.16 MHz clock, and is unrelated to the CPU
speed determined by CSL/CSH.
The timer is controlled by two registers:
$0C00 : Timer value (bits 6-0)
A value of $00 counts as 1, $7F counts as 128.
Bit 7 is unused.
$0C01 : Timer enable (bit 0)
Bits 7-1 are unused.
Data written to $0C00 is copied to a 7-bit latch. When the timer is
enabled, a 7-bit counter is loaded with the contents of the latch. The
counter is decremented once every 1024 clock cycles, and the timer
interrupt request line is asserted when the counter underflows from zero
to $7F. (not when the timer goes from one to zero) However, when this
occurs the counter is reloaded, so after reading zero from the timer
registers you will read the value that's been reloaded into the counter,
not $7F.
The interrupt can then be acknowledged by writing any value to $1403. If
this is not done an interrupt will occur after every instruction.
Reading $0C00 or $0C01 returns the current value in the counter, or if the
timer is disabled, then the last value the counter had prior to it being
disabled. If the timer is disabled and then enabled again, it is reloaded
with the last value written to $0C00.
When the timer expires, it is reloaded with the last value written to $0C00.
The timer begins to count down immediately, it does not wait for the
interrupt to be acknowledged. (so the timer is reloaded and counts down
within the timer interrupt routine)
Bit 7 of $0C00 and $0C01 return the contents of the I/O buffer.
2.3) T flag
The HuC6280 assigns the T flag to bit 5 of the processor status register.
It allows all forms of the ADC, AND, ORA and EOR instructions to be
processed differently, while the other instructions execute normally.
When the T flag is set, the accumulator is replaced with a zero page memory
location indexed by the X register. The operation defined by the
instruction is performed using the memory location as one operand, and the
effective address as the other. The result is stored in the memory
location, leaving the accumulator undisturbed.
It seems that the T flag is cleared each time the CPU fetches an
instruction. For example, both BRK and PHP (which save the status of P on
the stack) always push it with the T flag cleared when prefixed by SET.
T can be set by the SET instruction, or by pushing a byte with bit 5 set
and pulling it into P via PLP (in which case the instruction after PLP
will be affected as if SET came before it).
If you want to use this feature with ADC for processing BCD numbers,
you must execute SED before SET, otherwise the T flag will be cleared.
Like PLP, RTI keeps the T flag set. If an interrupt occurs after a SET
instruction which causes P to be pushed with T set, or if the stack
is manipulated to have T set, the instruction following the return address
used by RTI will be affected as if it was prefixed with SET.
The Mitsubishi 740 series of 65C02-derived CPUs also have a similar
feature, with some differences. The T flag remains set until cleared with
a CLT instruction or when P is modified. It also supports SBC, LDA and CMP
as valid instructions to use with the T flag.
2.4) Timing
The TurboGrafx-16 has a 21.47727 MHz master clock which is used to drive
several components:
- Divided by three in high speed mode (7.16 MHz) or twelve in low speed
mode (1.78 MHz) to provide the CPU clock. This is controlled by the
CSL and CSH instructions.
- Divided by three to run the timer. (7.16 MHz)
- Divided by six for the PSG clock. (3.58 MHz)
The PSG patents say the clock is 7.16 MHz, but all of the formulas for
determining frequency multiply the result by two, effectively making
the clock 3.58 MHz.
- The VCE divides the master clock by 2, 3, or 4, for 10.8 MHz, 7.16 MHz,
and 5.36 MHz dot clocks. The VDC presumably runs at whatever speed the
VCE does.
3.) Memory map
The HuC6280 has a 21-bit address bus. All of the address decoding is
handled internally by the CPU.
The address space is divided into 256 8K pages, and the following memory
map refers to the page number only:
$00-$7F : HuCard ROM (1)
$80-$F7 : Unused (always returns $FF) (2)
$F8-$FB : Work RAM (pages $F9-$FB mirror page $F8)
$FC-$FE : Unused (always returns $FF)
$FF : Hardware page
1. Depending on the configuration of the HuCard, ROMs smaller
than 1MB may be mirrored within this range.
2. See the CD-ROM section for more details.
Hardware page ($FF)
$0000-$03FF : VDC (registers mirrored every 4 bytes) (3)
$0400-$07FF : VCE (registers mirrored every 8 bytes) (3)
$0800-$0BFF : PSG (1)
$0C00-$0FFF : Timer (registers mirrored every 2 bytes) (1)
$1000-$13FF : I/O port (mirrored every byte) (1)
$1400-$17FF : Interrupt control (registers mirrored every four bytes) (1)
$1800-$1BFF : Always returns $FF (2)
$1C00-$1FFF : Always returns $FF
1. The last value read from or written to $0800-$17FF is saved in an
internal 8-bit buffer. Reading $0800-$17FF will return this value,
though readable locations will modify certain bits in the buffer.
Here are some details:
$0800-$080F : All addresses return the buffer value in full.
$0C00-$0C01 : Both locations return the buffer value in bit 7.
$1000-$1000 : Always returns the I/O port value. (no bits are from
the buffer)
$1400-$1403 : $1400/$1401 return the buffer value in full, $1402/$1403
return the buffer value in the upper five bits.
Some example code to illustrate how the buffer works:
stz $0C01 ; Buffer = $00
stz $0C00 ; Buffer = $00
lda #$05
sta $1402 ; Buffer = $05
lda #$FF
sta $080F ; Buffer = $FF
lda $1400 ; Read $FF, Buffer = $FF
lda $1402 ; Read $FD, Buffer = $FD
sta $1000 ; Buffer = $FD
lda $0C00 ; Read = $80, Buffer = $80
2. See the CD-ROM section for more details.
3. When accessing the VDC or VCE, an additional cycle is taken. This occurs
for reads and writes (regardless of addressing mode) and instruction
execution. (e.g. jsr $0002) I figured this had something to do with the
VDC and VCE being external to the CPU, however the CD-ROM registers are
not affected.
4.) I/O port
Here is the layout of the I/O port bits:
D7 : CD-ROM base unit sense bit (1= Not attached, 0= attached)
D6 : Country detection (1= PC-Engine, 0= TurboGrafx-16)
D5 : Always returns '1'
D4 : Always returns '1'
D3 : Joypad port pin 5 (read)
D2 : Joypad port pin 4 (read)
D1 : Joypad port pin 3 (read) / pin 7 (write)
D0 : Joypad port pin 2 (read) / pin 6 (write)
The TurboGrafx-16 uses a 9-pin connector for peripherals. I use the naming
conventions from the Develo Box schematics:
Pin 1 - Vcc
Pin 2 - D0
Pin 3 - D1
Pin 4 - D2
Pin 5 - D3
Pin 6 - SEL
Pin 7 - CLR
Pin 8 - Gnd
Pin 9 - Gnd
2-button controller details:
The 2-button controller has a four-way directional pad and four buttons:
Select, Run, II and I. A multiplexer is used to determine which values
(directions or buttons) are returned when D3-D0 are read. The SEL line of
the I/O port selects directions when high, and buttons when low. The state
of D3-D0 are inverted, so '0' means a switch is closed and '1' means a
switch is open.
SEL = 0 SEL = 1
D3 : Run Left
D2 : Select Right
D1 : Button II Down
D0 : Button I Up
Games use a small delay after changing the SEL line, before the new data is
read (a common sequence is PHA PLA NOP NOP). This ensures the multiplexer
has had enough time to change it's state and return the right data.
When the CLR line is low, the joypad can be read normally. When CLR is
high, input from the joypad is disabled and D3-D0 always return '0'.
Turbo Tap details:
The Turbo Tap is a 5-player adapter that plugs into the joypad port. It
allows five controllers to be read in a serial fashion, one after the other.
This is handled by an internal counter that is incremented each time there
is a zero-to-one transition of the SEL line while CLR is zero.
The counter can be reset by holding SEL high and doing a zero-to-one
transition on CLR. At this point, you can then strobe SEL five times
to read each controller. Once all five controllers have been read,
the Turbo Tap will return $00 in D3-D0 until the counter is reset again.
Unconnected controllers always return $0F in D3-D0.
There is also a quirk in how the data is returned during the reset
sequence. When $01 is written to $1000, D3-D0 are returned as zero,
even though the CLR line isn't high. When $03 is written to $1000, D3-D0
now return the direction pad data for controller #1, although now the CLR
line is high and should disable joypad input.
After resetting the Turbo Tap, reading continues normally. You can set
SEL high to read the directions, low to read the buttons, and the next high
transition will increment the counter and return data from controller #2,
and so on up to controller #5.
5.) HuC6260 - Video Display Controller
The Video Display Controller (VDC) manages a background layer, sprites,
and display generation. It has 20 internal 16-bit registers, and can
address up to 128K of video RAM (VRAM).
The TurboGrafx-16 only has 64K VRAM available, so the latter half of
the 128K area mirrors the former half. Sometimes reading mirrored VRAM
returns corrupted data, and writes to the mirrored half of VRAM are always
ignored (this includes VWR access or through VRAM to VRAM DMA).
The VDC is mapped to addresses $0000-0003 in the hardware page, and these
locations are repeatedly mirrored throughout the $0000-03FF area.
VDC addresses:
$0000 : VDC register latch
$0001 : Unused (writes do nothing, reads return $00)
$0002 : VDC data (LSB)
$0003 : VDC data (MSB)
The lower five bits of $0000 select which register will be accessed
at $0002 and $0003. Only registers $00-$02, $05-$13 are valid; selecting
registers $03-$04 or $14-1F and trying to access them has no effect.
Likewise, reading $0002 or $0003 when any other register but VRR is
selected will return the contents of the read buffer; but reading $0003
will not update MARR.
You can update registers in part by writing to the LSB or MSB; the new
data written will immediately have an effect. Some registers have special
properities when the MSB is written to. See the register reference section
for more details.
Reading $0000 returns a set of status flags. The letters in parenthesis
are the names of the flags from the Develo Book (I think):
D7 : Unused, always returns '0'
D6 : Set when the VDC is waiting for a CPU access slot during
the active display area. (BSY)
D5 : Set when the vertical blank interrupt occurs. (VD)
D4 : Set when the VRAM to VRAM DMA completion interrupt occurs. (DV)
D3 : Set when the VRAM to SAT DMA completion interrupt occurs. (DS)
D2 : Set when the raster compare interrupt occurs. (RR)
D1 : Set when the sprite overflow occurance interrupt occurs. (OR)
D0 : Set when the sprite #0 collision detection interrupt occurs. (CR)
Bit 6 is set when the VDC is waiting to read or write data requested by
the CPU when it accesses VRR/VWR. For more information, see register $09
in the register reference section.
Bits 5-0 are set when a condition occurs which would trigger an interrupt,
as dictated by the corresponding interrupt enable bits in register $05
and $0F. If the interrupt enable bits are not set, the matching status
bits will not be set, even if the condition occurs. Bits 5-0 are cleared
after the status port is read.
Bit 5 is set on the first line after the active display area ends, which
signifies the vertical blanking period has started. This will occur even
if the line after the active display area is off-screen, such as within
the first 14 lines of the frame (top blanking) or the bottomost 7 (bottom
blanking and vertical sync)
If the active display area uses more than 261 lines (assuming VSW and VDS
are zero) the interrupt will always occur on line 261, which is the next
to last line in the frame. So even if VDW was set to something unusual
like $1FF, the interrupt would occur on line 261 within the frame.
Bit 4 is set when a VRAM to VRAM DMA transfer has finished.
Bit 3 is set when a VRAM to SAT transfer has finished, which seems to
always happen four lines after the last line in the active display period.
It's not known when the transfer actually starts. The exact line affected
depends on the setting of VSW, VDS and VSW.
Bit 2 is set when the current scanline matches the value in register $06.
See the register reference section for more details.
Bit 1 is set when there are more than 16 sprites on the current scanline.
See the sprite section for more details.
Bit 0 is set when an opaque pixel in sprite #0 overlaps another opaque
pixel from any other sprite. See the sprite section for more details.
All interrupts caused by the VDC must be acknowledged by reading the
status flags once within the IRQ handler. If this is not done, the IRQ
line is not lowered and the interrupt occurs as soon as the handler RTIs.
5.1) Register reference
$00 - Memory Address Write Register (MAWR)
Bits 15-0 select a word offset in VRAM that will be used for VRAM writes.
$01 - Memory Address Read Register (MARR)
Bits 15-0 select a word offset in VRAM that will be used for VRAM reads.
After you have written the MSB of this value, a word from VRAM is read
and stored in the read buffer. On power-up, the contents of the read
buffer are indeterminate. (usually $FFFF)
$02 - VRAM Read Register / VRAM Write Register (VRR/VWR)
When you write to the LSB of this register, the CPU data is stored in a
temporary location called the write latch. When the MSB is written, the
entire 16-bit value composed of the write latch and MSB are written into
the VRAM address specified by MAWR. MAWR is then incremented by the
increment factor selected by register $05.
Writing to the LSB multiple times only updates the lower half of the
write latch and does not change MAWR or VRAM data. Writing to the MSB
multiple times will write the previously latched LSB data along with the
new MSB.
Reading the LSB will return the lower byte of the read buffer, and
reading the MSB will return the upper byte of the read buffer. MARR is
then incremented by the increment factor selected by register $05, and
a word of VRAM is read from the new address into the read buffer.
$03 - Unused
This register doesn't seem to have any effect when written to.
$04 - Unused
This register doesn't seem to have any effect when written to.
$05 - Control Register (CR)
D16-D15 : Unused
D12 : Increment width select (bit 1)
D11 : Increment width select (bit 0)
D10 : 1= DRAM refresh enable
D9 : DISP terminal output mode (bit 1)
D8 : DISP terminal output mode (bit 0)
D7 : 1= Background enable
D6 : 1= Sprite enable
D5 : External sync (bit 1)
D4 : External sync (bit 0)
D3 : 1= Enable interrupt for vertical blanking
D2 : 1= Enable interrupt for raster compare
D1 : 1= Enable interrupt for sprite overflow
D0 : 1= Enable interrupt for sprite #0 collision
Bits 7 and 6 enable and disable the background and sprite layers, and
can be changed at any time. Games use these to clip sprites within a region
of the display, or to give a letterboxed effect to the background layer.
Within a single frame, the overscan area outside of the active display
period is filled with color #0 from sprite palette #0, and the active
display area is filled with color #0 from background palette #0.
So even if only the sprites were enabled, they would still be drawn over
color #0 from background palette #0.
If bits 7 and 6 are cleared by the time the next frame starts (1), they are
locked for the duration of the frame. Changes to them will not be taken
into effect until the next frame. During this time, every line in the
active display area is filled with color #0 of sprite palette #0.
The VDC patent refers to this as "BURST" mode, where the VDC does not
read VRAM for background and sprite rendering. The CPU has unlimited
access to VRAM, and in addition VRAM to VRAM DMA can be done during
this time. Simply clearing both bits during the active display area does
not cause BURST mode to become enabled, it only happens as soon as the
active display period ends (which is incidentally when VRAM to SAT DMA
occurs), and remains effective in the next frame only if both bits remain
reset before the next frame starts.
1. I'm not sure if they are locked when the next frame starts, or when the
next active display period starts. I'm assuming the former for now.
Bits 3-0 will, when set, allow status flags to be set when a certain
condition occurs. In addition the VDC will generate an IRQ1 interrupt,
though interrupts can always be disabled through the CPUs IRQ control
registers or the P register's I flag.
$06 - Raster Compare Register (RCR)
The value stored in this register is compared to the current scanline.
If there is a match and the raster compare interrupt enable bit in register
$05 is set, then bit 2 of the status flags is set and an interrupt occurs.
The range of the RCR is 263 lines, relative to the start of the active
display period. (defined by VSW, VDS, and VCR) The VDC treats the first
scanline of the active display period as $0040, so the valid ranges for
the RCR register are $0040 to $0146.
For example, assume VSW=$02, VDS=$17. This positions the first line of
the active display period at line 25 of the frame. An RCR value of $0040
(zero) causes an interrupt at line 25, and a value of $0146 (262) causes an
interrupt at line 24 of the next frame.
Any other RCR values that are out of range ($00-$3F, $147-$3FF) will never
result in a successful line compare.
$09 - Memory Width Register (MWR)
D15-D8 : Unused
D7 : CG mode
D6 : Virtual screen height
D5 : Virtual screen width (bit 1)
D4 : Virtual screen width (bit 0)
D3 : Sprite dot period (bit 1)
D2 : Sprite dot period (bit 0)
D1 : VRAM dot width (bit 1)
D0 : VRAM dot width (bit 0)
The VDC was designed to work with slower video memory. The TurboGrafx-16
happens to use the fastest kind available, but you can still set up the VDC
to handle VRAM as if it was slower.
During the active display period of a scanline, the VDC can do one 16-bit
access to VRAM on each cycle of the dot clock. Bits 1-0 of MWR tell the VDC
how to divide this amongst several sources:
1. CPU (reading or writing a word via register $02)
2. Background character pattern generator data (one read is for bitplanes
0 and 1, another is for bitplanes 2 and 3, either one or two are needed
per character)
3. BAT data (character name and palette, one fetch needed per character)
Bit Dot Dot cycles within an 8-dot unit
1 0 Width 0 1 2 3 4 5 6 7
0 1 2 --BAT-- --CPU-- --CG0-- --CG1--
1 0 2 --BAT-- --CPU-- --CG0-- --CG0--
1 1 4 ------BAT------ ----CG0/CG1----
CPU - A read or write to register $02
BAT - The palette block and character name from the BAT
??? - Unknown, possibly an unused 'dummy' access
CG0 - Bitplanes 0, 1 from the character generator
CG1 - Bitplanes 2, 3 from the character generator
The default mode all games use is 0, as far as I can tell, modes 1, 2 are
identical, and mode 3 enables the CG mode bit as described later.
Bits 5-4 select the width of the virtual screen:
00 - 32 characters
01 - 64 characters
10 - 128 characters
11 - 128 characters
Bit 6 selects the height of the virtual screen:
0 - 32 rows
1 - 64 rows
There are no limits on the size of the BAT, at it's largest setting of
128x64 characters, the BAT is 16K.
Bit 7 selects which character generator bitplanes are read by the VDC
when the VRAM dot width is 3.
0 - Read bitplanes 0, 1, treat 2, 3 as zero
1 - Read bitplanes 2, 3, treat 0, 1 as zero
In either setting, background characters can only display four colors
out of 16 at any given time.
5.2) Background
The background generated by the VDC is a tiled layer composed of 8x8
characters. The background can be scrolled horizontally and vertically, and
it's size is definable in units of 32 characters in either direction,
from 32x32 up to 128x64.
The pattern data used by the characters is stored in a planar format.
Because the VDC always accesses VRAM in word units, the organization
of bitplanes reflect this. It takes 32 bytes of VRAM to define one tile;
the first eight words are bitplanes 0 and 1 for lines 0-7, and the next
eight words are bitplanes 0 and 1 for lines 0-7.
The background itself is defined by the block attribute table (BAT), which
starts at address zero in VRAM. Each word-wide entry in the BAT defines
a single character, and has the following layout:
p : Color palette (0-15)
n : Character name (0-4095)
Notice that there are no provisions for tile flipping or priority control.
Because the TurboGrafx-16 only has 64K of VRAM, only patterns 0-2047 should
be used. Patterns 2048-4096 are filled with 'garbage' data.
The color palette selects one of sixteen 16-color palettes for the
character to use. The background layer always uses the first 256 colors
in the 512-color VCE palette.
The BAT doesn't necessarily have to match the same size of the display.
If the BAT is too small, (e.g. it's 32x32 and the display is 40x28), then
the offset into the BAT wraps around and the graphics are repeated. In
the same vein, you don't have to use up the entire BAT space if the display
won't show all of it (e.g. it's 64x32 and the display is 32x16, you
wouldn't need to define entries for rows 17-31).
For more information about scrolling, see registers $07 and $08 in
the register reference section.
5.3) Sprites
The VDC can control 64 sprites up to 32x64 in size, composed of 16x16
Each sprite is defined by a four-word entry in the sprite attribute
table, (SAT) a memory area internal to the VDC that can only be written to
via VRAM to SAT DMA.
On power-up, the SAT is filled with garbage data and should either be
initialized or sprites should be turned off. See the register reference
section for more details about VRAM to SAT DMA.
Each SAT entry has the following format:
Word 0 : ------aaaaaaaaaa
Word 1 : ------bbbbbbbbbb
Word 2 : -----ccccccccccd
Word 3 : e-ffg--hi---jjjj
a = Sprite Y position (0-1023)
b = Sprite X position (0-1023)
c = Pattern index (0-1023)
d = CG mode bit (0= Read bitplanes 0/1, 1= Read bitplanes 2/3)
e = Vertical flip flag
f = Sprite height (CGY) (0=16 pixels, 1=32, 2/3=64)
g = Horizontal flip flag
h = Sprite width (CGX) (0=16 pixels, 1=32)
i = Sprite priority flag (1= high priority, 0= low priority)
j = Sprite palette (0-15)
Sprites are positioned in a virtual 1024x1024 space. The active display
area starts at offset (32, 64), allowing sprites to be partially shown
at the left and top edges, as well as giving sprites a place to be
hidden at when their coordinates are set to (0, 0).
The pattern index selects one of 1024 patterns, however the TurboGrafx-16
only has 64K of VRAM, so the first 512 should be used. Patterns 512-1023
are filled with 'garbage' data.
Each sprite pattern takes 128 bytes, and is arranged in four groups of
16 words. Each word corresponds to one 16-pixel line, and each group
corresponds to one bitplane. For example, words 0-15 define bitplane 0,
words 16-31 define bitplane 1, etc.
The CG mode bit is only valid when the sprite dot width field of the MWR
register is set to 2 or 3. When clear, bitplanes 0 and 1 are read, 2 and 3
are treated as zero. When set, bitplanes 2 and 3 are read, 0 and 1 are
treated as zero.
The vertical and horziontal flip flags flip an entire sprite (not just
one 16x16 pattern).
The CGX and CGY fields define the size of a sprite. Sprites larger than
16x16 use neighboring patterns to make up the rest of the sprite. Depending
on the size, the lower 3 bits of the pattern index are masked out. If CGX
is set, bit 0 of the pattern index is forced to zero. If CGY is 1, bit 1 of
the pattern index is forced to zero. If CGY is 2 or 3, bits 2 and 1 of the
pattern index are forced to zero. For example, a 16x16 sprite can use any
patterns, a 32x16 sprite can use every second pattern, and a 32x64 sprite
can only use every eighth pattern.
The priority and palette fields are discussed later on.
Sprite attribute table parsing:
During the horizontal blanking period of each scanline, the VDC parses the
SAT to collect information about what sprites will be displayed on the
next line. It progresses through the SAT one sprite at a time, working from
sprite #0 to #63. If a sprite is found that has the right Y coordinate
and height to make it fall on the next line, the sprite is added to an
internal 16-entry buffer. The VDC continues to parse the SAT until the
following conditions occur:
- All 64 sprite entries have been examined.
- All 16 buffer entries have been used.
- The horizontal blanking period ends. (1)
Sprites that are 32 pixels wide count as two sprites; in the event
that such a sprite is found but there is only one buffer position left,
then the left half of the sprite is added to the buffer, and the right half
is not displayed.
If all 16 buffer entries are used but there are more sprites that fall on
the line, an overflow condition occurs. If the interrupt enable bit of CR
is set, the overflow bit in the status register is set and the VDC will
generate an interrupt. Overflows can occur anywhere within a scanline in
the active display period, even if the sprites are off-screen.
During the next scanline, the VDC compares a counter (incremented by
the dot clock) to the X position of each buffered sprite. When the X
position is within range, the sprite bitplane data is shifted out serially,
forming a single four bit pixel. Only the first opaque pixel is shown,
pixel data from subsequent sprites is ignored. This is what defines the
priority when multiple sprites overlap each other; for example if sprites
0 through 3 were transparent, but 4 and 5 were not, only pixels from sprite
4 would be shown.
At this point, collisions between sprite #0 and any other sprite are
checked. If the bitplane data from sprite #0 is an opaque pixel, and any
other of the 16 buffered sprites also output an opaque pixel, a collision
occurs. If the interrupt enable bit of CR is set, the collision bit in the
status register is set and the VDC will generate an interrupt. Collisions do
not occur outside of the active display period.
The sprite pixel is then compared to the current background layer pixel
(or backdrop color) at the same location. If the sprite's priority flag
is set, then the sprite pixel overwrites the background pixel. If the
priority flag is clear, then the sprite pixel is only shown if the
background pixel is transparent.
Note that the background priority flag has no effect inter-sprite priority.
For example, if sprite #2 has it's priority flag cleared, it would appear
under a section of the background. If sprite #3 partially overlapped sprite
#2 and had it's priority flag set, it's pixels which shared the same
location as opaque pixels in sprite #2 would not be shown. (since sprite #2
comes first in the 16-entry buffer)
This technique is used in many games (Y's, Neutopia, Dungeon Explorer) to
force sections of the background to appear in front of sprites that have
their priority flag set but are of a lower sprite priority.
1. This happens when the width of the display is modified. If the display
is made smaller than 32 characters, two sprites at a time starting from
sprite 64 are dropped. This is why the Image 15-in-1 Collection does
not use sprites, it uses very small resolutions which reduce how many
sprites are available. (either the programmer didn't realize this was
happening, or simply chose to not use sprites) In the same vein, making
the display too wide cuts out multiple ranges of sprites at a time,
though the exact relation of which sprites are dropped based on the
display size is unclear.
5.4.) DMA
The VDC has two kinds of DMA: VRAM to VRAM copy, and VRAM to SAT transfer.
- The contents of MAWR, MARR, the read buffer, and the write latch, are
not changed by doing VRAM to VRAM DMA.
- The IW bits in CR do not change the value added to the source or
destination address during VRAM to VRAM DMA, this value is always one.
- LENR specifies how many words to transfer, 0=1 byte, $FFFF=64K.
Writing to the MSB triggers the transfer.
- During VRAM to VRAM DMA, SOUR, LENR, and DESR are modified (they act as
counters which are incremented and/or decremented in the course of a
transfer) At the end of the transfer, the registers retain their new
states instead the original values written. LENR is set to $FFFF, not
zero, when a transfer completes.
- VRAM to VRAM DMA can only occur outside of the active display period.
It seems to me that if it is still running when the active display
period starts, DMA is halted (not aborted), and resumes when the active
display period ends.
- Both VRAM to VRAM DMA and VRAM to SAT DMA can run at the same time.
I don't know which one has priority if they both access the same range
of addresses, however.
- The VRAM to SAT DMA transfer end interrupt occurs four scanlines after
the end of the active display period. (e.g. if the last line of the
active display is $DF, it happens happens at $E3)
6.) HuC6270 - Video Color Encoder
The VCE manages a palette used for the background and sprite layers.
The palette is composed of 512 9-bit entries, each entry being divided
into three groups of three bits for each of the red, green, and blue color
components, giving a total range of 512 possible colors.
The first 256 colors are used for the background layer, and the remaining
256 are used for sprites. Within these two groups, the palette can be
divided further into 16 groups of 16-color palettes; each palette is
selected by a 4-bit field in the BAT or SAT.
A pixel in a background character or sprite pattern with a value of zero
is treated as transparent. For sprites, this means the underlying background
data or backdrop color is shown. For background characters, this means
the underlying backdrop color is shown.
The backdrop color is displayed in the active display area if the sprites,
background, or both are enabled. This color is picked from color #0 from
background palette #0.
The overscan color is displayed outside of the active display area, and
only inside the active display area when both the background and sprites
are turned off. This color is picked from color #0 in sprite palette #0.
See the register reference section for more details.
Color #0 of the remaining 15 palettes in the background and sprite sections
cannot be displayed.
The VCE is mapped to $0400-0407, and these locations are repeatedly
mirrored throughout the $0400-07FF range in the hardware page.
$0400 - VCE control
(Write only, reads return $FF)
D7 : 1= Black and white video, 0= Color video
D6 : No effect
D5 : No effect
D4 : No effect
D3 : No effect
D2 : 1= Blur edges of graphics. (some games use this bit)
D1 : 1= 10 MHz dot clock.
D0 : 1= 7 MHz dot clock, 0= 5 MHz dot clock
Bits 1-0 select the dot clock. This determines how many pixels are displayed
on each horizontal line, but does not affect how many lines are shown per
frame. If bit 0 is set while the 10 MHz dot clock is used, the color
artifacting around the edges of characters is more prominent, while having
the bit cleared minimizes artifacting.
Bit 2 seems to blur the edges of the sprites and background characters.
This reduces artifacting between pixels, especially in the higher
In my opinion, it almost seems that when bit 2 is cleared, every other
line is offset horizontally by half a pixel. When bit 2 is set,
this is applied to either odd or even lines on odd or even frames.
This is especially noticable with vertically scrolling graphics; if a sprite
is moved vertically at the rate of one line per frame, the 'interlacing'
effect described above is lost, and the edges appear jagged. When the
sprite is stationary, the edges look smooth.
For what it's worth, the PC-FX patents describe this exact same feature;
though it's only usable for an interlaced display and is controlled through
a different register of the VCE (which is loosely based on the original
one used in the TurboGrafx-16).
$0401 - Not used
(Reads return $FF, writes do nothing)
$0402 - Color table address (LSB)
$0403 - Color table address (MSB)
(Both are write-only, reads return $FF)
These two registers form a 16-bit value, of which the lower 9 bits are
used as an index into the color table for subsequent reads and writes
by the data register. The remaining upper 7 bits are ignored.
You can update either the LSB or MSB independently and still perform
color data reads and writes; the address does not have to be specified
in full beforehand.
$0404 - Color table data (LSB)
$0405 - Color table data (MSB)
These two registers form a 16-bit value, of which the lower 9 bits
contain color data:
G = Green component
R = Red component
B = Blue component
Reading $0404 returns the lower byte of the color data. Reading $0405
returns the upper byte with bits 7-1 set to '1'. When the upper byte is
read, the color table address is advanced by one and will wrap when the
address is at $01FF.
Writing to $0404 sends a byte of data to the LSB of the current entry in
the color table. Writing to $0405 sends a byte of data to the MSB of the
current entry in the color table, and in addition, the address is advanced
by one and will wrap when the address is at $01FF.
Writing to $0405 multiple times will only update the MSB of each color
table entry, the LSB will remain undisturbed. You can also freely change
either half of the address (through $0402/$0403) between writes to the
color table data registers.
$0406 - Not used
(Reads return $FF, writes do nothing)
$0407 - Not used
(Reads return $FF, writes do nothing)
Palette flicker
The VCE color table can only be accessed by either the CPU or the VCE at
any given time, with CPU accesses taking priority. When the CPU reads
or writes VCE addresses $0404 or $0405 during the active display period,
the current pixel being displayed can't look it's color up through the
color table as the CPU is currently using the table itself.
Unlike other video hardware (e.g. Sega systems) where the pixel's color
will be replaced by the data read or written by the CPU, the VCE will
show the same color for the last pixel it displayed. While this still
causes distortion of the graphics, it is mostly masked when the current
image being displayed is a horizontal strip of the same color.
Note that this also occurs at the edges of the display, when the monitor
scans the border (overscan) area to the left and right of the active
display, reading or writing the color table will cause the right border
color to overlap into the active display, and likewise the active display
color can overlap into the left border.
One game that allows you to see this effect is Coryoon, it fades the display
in and out without waiting for the vertical blank period. You can easily
see on the screen where a read or write has occured as the single pixels
are stretched out into short horizontal lines due to the VCE displaying
the same pixel color while the CPU is busy accessing the color table.
7.) Display details
All aspects of the display are controlled by the VDC (which has several
registers that define where graphics are shown within the display), and
the VCE (which generates a dot clock, in turn defining the number of pixels
displayable). I will start with discussing the vertical control fields
in VDC registers $0C, $0D, and $0E.
The TurboGrafx-16 generates a NTSC display that is composed of 60 frames
shown per second, with each frame divided into 263 scanlines. These
scanlines are grouped as follows:
14 lines for the top blanking area (shown as light black).
242 lines for the active display area (graphics and/or overscan color).
4 lines for the bottom blanking area (shown as light black).
3 lines for the sync area (shown as pure black).
This layout is fixed, and cannot be changed by the vertical control
registers. They only define where the graphics data is displayed within
a single frame. If the active display area is positioned in a way that it
occupies the lines that are used for blanking or sync, those lines will
not be shown. The start of a frame is the first line after the vertical
retrace period, which is not necessarily the first line you can see on a
For the sake of discussion, assume the VDC has a two counters that are
reset at the start of a frame and incremented on each scanline. One is
used to track the position within each frame, and the VDC checks this
counter when generating the active display, top and bottom blanking areas,
and sync area. I'll call this the frame counter. The other counter is used
for tracking the graphics area within a frame, and can be reset multiple
times. I'll call this the display counter.
The display counter is compared to an offset made by the sum of VDS and
VSW. When they match, graphics data are displayed, or else the overscan
color is shown. Because there are 14 lines at the beginning of a frame
which make up the top border, the offset created by VDS and VSW must be
at least 14 lines. In addition, most monitors cut off the edges of the
display, so the offset may need to be larger.
For example, the standard 256x224 resolution used by most games has
VDS=$17 and VSW=$02, giving an offset of 25 lines. This clears the top
blanking area and gives 11 lines of overscan color before the 224 lines of
graphics data are shown.
After the display counter matches the offset created with VDS and VSW,
graphics are displayed until the counter now matches the previous offset
plus VDW. At this point, graphics are turned off and the overscan color is
shown for the remainder of the 242 lines that make up the active display
area. If VDW and/or the VSW+VDS offset are large enough that the graphics
are shown past line 242, then no overscan color is displayed and these
graphics are hidden by the bottom border and sync areas.
Assuming this isn't the case, and there are some lines left in the remainder
of the active display area (out of the available 242), the VDC will show
3 blanked lines filled with the overscan color. It will continue to do
this for as many lines as are specified in the VCR register.
After this point, the display counter resets. It will begin to show the
overscan and active display area again, following the same rules as above
except for everything is positioned relative to the last line of the frame
as specified by VDS+VSW+VDS+VCR+3.
VCR is normally used to prevent this situation, it can be set to the number
of lines remaining in the frame and thereby prevent the active display area
from being displayed twice.
Now for an example:
VDW = $07F, VCR = $00, VDS = $0E, VSW = $00
This positions the active display area at line 14 onwards, clearing the
top blanking area. The height of the active display area is 128 lines.
VCR is not used.
The display will show 14 black lines, 128 lines from the active display
area, and then 3 lines of overscan color. Now the display counter resets,
so 14 lines of the overscan color are displayed, followed by 97 lines
of the active display area. The frame counter has reached the bottom of
the frame, so you see 4 lines of the bottom border and finally 3 lines
of the sync area, for a total of 263 lines.
Now for the horizontal aspects of the display:
The number of characters per scanline is determined by the dot clock used,
and the horizontal parameters define what characters show graphics data and
which ones show the overscan color. You can't divide the dot clock further
by adjusting the horizontal parameters; for example, the 5 MHz dot clock
will always show roughly 342 dots per line, so a small resolution like 128
characters would have a large border on the left and right sides. Some of
these dots are off-screen, since they are used for the horizontal blanking,
retrace, and color burst areas.
VDC registers $0A and $0B can be modified at any time. Registers $0C, $0D,
and $0E can only be modified outside of the active display period. So it's
possible to change the horizontal resolution to any width at any line.
8.) CD-ROM
The TurboGrafx-16 CD hardware consists of the following:
- 64K general purpose RAM for the CD software to use
- 64K ADPCM RAM for sample storage
- 2K battery backed RAM for save game data and high scores
- Base unit which holds the above items, has stereo A/V outputs
- Stand-alone single speed CD drive that attaches to above base unit
- System Card (HuCard) that holds related libraries for using CD hardware
The CD drive is a SCSI compatible device. It supports the following
08 - READ
Command 00 is used when the machine is booting up, command 03 is commonly
used after each command to see if it succeeded or failed, and command 08
is used for many operations, such as CD_READ, AD_TRANS, AD_CPLAY, and
Everything else is assigned to the vendor specific commands:
D8, D9 - Play CD audio (entire track or section thereof)
DA - Pause CD audio
DD - Read Q sub-channel
DE - Used in CD_DINFO, returns various information about the CD
The READ function uses logical block addressing (LBA), which is a 21-bit
address that specifies 2048 byte blocks. This provides 4 gigabytes of space,
which is more than enough to span an entire CD-ROM. The READ function uses
Most of the vendor specific functions use a different form of addressing,
where the position on the disc is given by the track number, or the minutes,
seconds, and frames (MSF). A CD has 75 frames per second, 60 seconds per
minute, and typically 74 minutes per disc. Also, these numbers are
represented in BCD format (base 10), not hexadecimal.
For example CD_DINFO accepts a track number as the parameter, in BCD format
from 00 to 99. Track 15 would be represented as $15, not $0F.
Likewise, one of the CD_PLAY modes uses the MSF format, so specifying a
range of 08:16:32 to 10:32:00 would look like $08,$16,$32,$10,$32,$00 in
the command's parameter string, instead of $08,$10,$20,$0A,$20,$00.
Reading data from the CD is done in units of a single byte. It has a buffer
which holds return information or sector data, and the data is sent to the
CPU each time $1801 or $1808 is read. (the address depends on the command
used) The CD has no capability to transfer entire sectors or other data
directly to RAM using DMA.
On the other hand, the CD hardware can use DMA to send a single sector
at a time to ADPCM RAM. This is used in the AD_TRANS function and AD_CPLAY
which streams audio data from the CD to ADPCM RAM while audio is playing.
Battery backed RAM (BRAM)
The base unit has 2K of battery backed RAM which is used to save high
scores or the current progress in a game. The battery backed RAM is said
to hold it's contents for at least two months, at which point NEC advises
you to power on your unit or else the contents will eventually be lost.
BRAM is mapped to physical addresses $1EE000-1EE7FF, e.g. the first 2K of
page $F7. It is not mirrored outside of this range. On power-up BRAM is
locked, meaning that writes to it are ignored and reads from it always
return $FF regardless of the actual contents. BRAM can be unlocked by
setting bit 7 of port $1807. Likewise, you can lock BRAM by reading from
port $1803.
Some games unlock BRAM by writing the sequence $48, $75, $80 to $1807, but
the only value of importance is the last byte which has bit 7 set. The
System Card and Tennokoe Bank programs always access BRAM in the low speed
mode, which would seem to indicate that BRAM is slow enough that it cannot
be reliably used in high speed mode.
CD-ROM registers
$1800 - CDC status
When sending a command, $1800 is written to several times. Otherwise, it
returns a status value when read which is checked in nearly all of the CD
related functions.
$1801 - CDC command / status / data
This register is only written to when a command is being sent.
The sequence is $81, $FF, and then the command byte and it's parameters.
Otherwise, it seems to return a status byte and sometimes data.
Several System Card functions which read a few bytes worth of CD data at a
time retrieve the data from an internal sector buffer through $1801.
$1802 - ADPCM / CD control
This register is read and written to often in many of the CD and ADPCM
related functions in the System Card.
I tried writing values $00-FF to this register, and got an IRQ2 interrupt
to occur. I'm not sure exactly what values or sequence of values caused
Several functions which read data from the CD, as well as one function
which sends a SCSI comamnd to the CD hardware, will call a subroutine
at $EC0B after reading or writing each byte which sets bit 7, polls bit 6
of $1800, then clears bit 7. Perhaps this is used to tell the CD that data
has been read or written and it should prepare for the next read or write.
$1803 - BRAM lock / CD status
Reading from this address locks BRAM.
Bit 4 is set when the play button is pressed on the CD unit. It will remain
this way until the stop button is pressed, but only after the motor has spun
down. (which takes one or two seconds) It also stays on when the current
track is paused or when seeking between tracks, so it may be a on/off sense
bit for the CD-ROM spindle motor.
Bit 2 is set when ADPCM sample playback is in progress and less than half
of the sample data is remaining, and cleared when more than half of the
sample data is remaining. (according to AD_STAT)
$1804 - CD reset
Bit 2 is used to reset the CD hardware. The CD_RESET function sets bit 2,
waits for a few cycles, and then clears bit 2.
$1805 - Convert PCM data / PCM data
$1806 - PCM data
When $1805 is written to, the current audio data from the CD can be read
from $1805 and $1806 after about 112 cycles. They will return the same data
until $1805 is written to again. The exact value written seems unimportant.
I don't know what the format of the data is. If a CD is paused, stopped, or
if no disc is present, the data is zero. If a CD is playing, or is fast
forwarding or in reverse, the data values are between $00 and $FF. When
the volume level for either channel is very low, the data seems to be
around $F0 to $10 usually weighted towards zero. I'd guess this means the
data is signed.
CD audio consists of 2 channels with 16 bit samples, so it's not clear
how this data is returned through two 8 bit locations. An easy way to
test would be to play a CD which had one channel silent and the other one
containing sound, but I don't have any discs which happen to do this.
I think another hint about the purpose of these ports is that the function
using them is called CD_PCMRD, and the Develo Book refers to CD audio as
PCM. I'd also bet that the System Card's internal CD player which shows two
bars to represent the volume level of each channel uses these registers.
$1807 - BRAM unlock / CD status
Setting bit 7 will unlock BRAM.
Reading this register returns the same random value when read, however
when a seeking to a track or when the spindle motor is spinning up or down
the return value fluctuates rapidly. This does not occur after an audio
track begins playing, or when it is paused and unpaused. This also occurs
at the same time bit 4 is set or cleared in $1803, so they are most likely
related to each other.
The BIOS function CD_SUBRD copies the value of this register to $227E,
though I don't know what it's purpose is. It will also ensure that bit 4
of $1803 is set prior to reading, so it's safe to say CD_SUBRD is only
valid when a CD is being accessed.
$1808 - ADPCM address (LSB) / CD data
Writing to this port loads the lower 8 bits of a 16-bit address that
can be copied to the ADPCM read or write pointers.
Several System Card functions which read a sector's worth of data at a
time retrieve the data from an internal sector buffer through $1808.
$1809 - ADPCM address (MSB)
Writing to this port loads the upper 8 bits of a 16-bit address that
can be copied to the ADPCM read or write pointers.
$180A - ADPCM RAM data port
$180A allows access to the ADPCM RAM at the offset pointed to by the
write and read pointer. After each access, the read or write pointer is
There is a seperate address for reading and writing. So after setting the
read and write address, doing additional writes wouldn't change the read
address, nor would doing additional reads change the write address.
Reads are buffered, after setting the read address you have to read
and discard a byte from $180A. After each read, a byte from the current
address is loaded into the buffer and the address is then incremented.
If you read or write beyond $FFFF, the respective address will wrap to zero.
The current pointer value will change if you leave bits in $180D set when
reading or writing $180A. The exact effects are described later.
$180B - ADPCM DMA control
Bits 1 and/or 0 of $180B are set when an CD to ADPCM DMA transfer is in
progress. The AD_TRANS and AD_WRITE functions check these bits and abort
if they are set. Maybe this means reading ADPCM RAM at the same time would
still work, it does have a seperate read and write pointer, after all.
Bit 1 seems to request the transfer itself. The AD_TRANS function sets
the ADPCM write address, sends a READ command, and then sets bit 1 while
polling flags in bit 2 of $180C and bit 5 of $1803. Afterwards, it clears
bit 1 and exits.
$180C - ADPCM status
If bit 7 is set, the ADPCM controller is busy processing the last read
from $180A. The BIOS polls this bit before each read from $180A in AD_READ.
I've observed that bit 7 is cleared in about 24 cycles in high-speed mode,
immediately following a read from $180A.
If bit 3 is set, the ADPCM controller is busy. (according to AD_STAT)
If bit 2 is set, the ADPCM controller is busy processing the last write
to $180A. The BIOS polls this bit after each write to $180A in AD_WRITE.
If bit 1 is set, sample playback has been halted. (according to AD_STAT)
$180D - ADPCM address control
Bit 7 will cause the ADPCM hardware to be reset when it is set to one and
then zero. When this happens, the read buffer (at $180A) keeps it's contents
and the read and write pointers are set to zero.
Bits 6 and 5 seem to be used for ADPCM DMA, though I'm not sure how.
Bit 4 copies the contents of $1808/$1809 to a length counter which is used
when playing back a sample. A length of zero is treated as 64K. The AD_READ
function sets the length before reading data, but I've found this is not
ADPCM RAM can be accessed in units of single nibbles. The CPU always reads
or writes a byte, but the ADPCM controller can spread this over two nibbles
of two adjacent bytes. The primary reason for this is that ADPCM samples
are one nibble in size.
Bits 3 and 2 copy the current address in $1808/09 to the write pointer,
and optionally set the nibble offset to 1 or zero.
Bits 1 and 0 copy the current address in $1808/09 to the read pointer,
and optionally set the nibble offset to 1 or zero.
How exactly these bits are used seems to be dependant on the state of
one bit while the other changes state from 1 to 0.
I'm currently trying to document the various settings, which I will include
in a future update.
$180E - ADPCM playback rate
The lower four bits of this register set the playback rate for ADPCM
samples. According to a tghack-list post, the playback rate is as
Sample rate (KHz) = 32 / (16 - (value & $0F))
$180F - ADPCM and CD audio fade timer
I haven't tested the ADPCM fade, just the CD audio one.
When $180F is written to, a timer is started depending on the the lower 4
bits of the data which gradually fades the CD audio (PCM) and/or ADPCM audio
over a period of time. Writing the same value multiple times has no effect,
writing different data is described later. Valid settings are:
0-7 : No effect
8-9 : Fade CD audio (silence in about 8 seconds)
A-B : No effect
C-D : Fade CD audio (silence in about 2 seconds)
E-F : CD audio is unchanged, but canceling the fade causes the sound
to mute for an instant.
When a fade is in effect, writing different data again has some unusual
results. If 0-7 is written, the fade is cancelled and the fade timer is
reset, so another fade later on will restart from the beginning.
If A, B, E, or F is written for a fade value of 8 or C, the fade is
cancelled but the timer still runs, so if you fade again it the audio level
is reduced to whatever point the timer is currently at. If C is written for
a fade of 8, the fade timer speed is increased, and if 8 is written for a
fade of C, the fade timer speed is decreased.
When the audio is fading or is completely silent, cancelling the fade
restarts the audio. The CD never actually stops playing, only the volume
is controlled.
8.1) Super System Card
The Super System Card is an upgraded version of the original System Card
with more memory. It has 192K of RAM mapped to pages $68-$7F, which is
used in conjunction with the CD-ROM base unit's built in memory for a
total of 256K.
The only 'new' BIOS function (that I know of) is EX_MEMOPEN, which uses
entry $E0DE in the jump table. (replacing KEY_BIOS in earlier BIOS
revisions) It's purpose is to read some new registers mapped to $18Cx area
for identification. It does the following checks:
if ($18C5 == $55 && $18C6 == $AA)
X = $03, A = $68, carry = 0
if ($18C1 == $AA && $18C2 == $55)
X = $18C3 | $80, A = $68, carry = 0
/* Failure */
X = $00, carry = 1
I'm not sure what the purpose of X is supposed to be. Maybe it indicates
the hardware version? (making $18C3 storage for the version number?)
If you assume EX_MEMOPEN is only available on Super System Cards to begin
with, checking the extra registers as $18Cx seems unecessary. However, they
do solve the unlikely situation of having the SCD BIOS running on a regular
HuCard with no extra memory or special registers; the tests will fail in
this case. Not that you couldn't patch the BIOS to force a SCD game to run
anyway. (Dragon Slayer will run for a bit like this :)
9.) Display parameter settings
These settings were created using the Display Editor program, and are
included as a reference for emulator authors to see the largest possible
displays, as well as developers to use in their programs.
Key to following settings:
Overscan - Part of the display may be off-screen on some monitors.
Max - This is the largest viewable area possible. (I used a video
capture card to get around the limitations of a regular monitor)
CLK - Bits 1-0 of VCE register $0400
Horizontal settings:
240 03 02 04 1D 00
256 02 02 04 1F 00 (overscan)
288 00 02 04 23 00 (overscan, max)
320 05 02 04 27 01
336 04 02 04 29 01 (overscan)
376 02 02 04 2E 01 (overscan, max)
480 0C 02 04 3C 02
512 0B 02 04 3F 02 (overscan)
536 07 02 04 46 02 (overscan, max)
Vertical settings:
192 25 02 00 BF 0C
224 17 02 00 DF 0C
240 0F 02 00 EF 0C (overscan, max)
10.) Programmable Sound Generator
- The PSG channel frequency is 12 bits, $001 is the highest frequency,
$FFF is the next to lowest frequency, and $000 is the lowest frequency.
- When writing waveform data to a channel, the index is reset when the DDA
bit goes from one to zero, regardless of the other bits in $0804.
- Data can only be written to the waveform buffer when the channel enable
and DDA bits are reset. Otherwise, the data written is ignored and the
current index into the waveform is not changed.
11.) Acknowledgements
Special thanks to David Shadoff for hardware help, technical information,
and lots of advice.
- Cafe Noir for technical information.
- Chris MacDonald for testing and support.
- David Michel for Magic Engine and the Magic Kit package.
- Paul Clifford for the PSG documentation and help with patent numbers.
- Zeograd for Hu-Go!, HuC, and linking to my website. :)
- Everybody who contributed information to the tghack-list.
12.) Contact / Help
I've got a few questions about some things I can't test myself:
- Does anyone have a pin-out for the HuC6260, HuC6270, or HuC6280?
- Does anyone know the part numbers of any of the custom components
in the original CD-ROM unit? (not the Duo or other models)
- Does anyone know what subroutines or bugs were fixed and added between
the different revisions of the System Cards?
- Does anyone own a TurboBooster or TurboBooster+, and would be willing
to run some test programs? (assuming you had a copier to run them)
Feel free to ask any questions regarding this document, I promise to read
every message but cannot guarantee a response. :)
No ROM requests, please.
My e-mail address is: cgfm2 at hotmail dot com
13.) Disclaimer
If you use any information from this document, please credit me
(Charles MacDonald) and optionally provide a link to my webpage
( 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.