pcetech.txt

 TurboGrafx-16 Hardware Notes
 by Charles MacDonald
 WWW: http://cgfm2.emuviews.com

 Unpublished work Copyright 2001, 2002 Charles MacDonald

 Revision history:

 [09/22/01]
 - Initial revision
 [09/23/01]
 - 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
 [09/24/01]
 - 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
 [09/25/01]
 - 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
 [09/28/01]
 - 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
 [10/01/01]
 - Added read result for VCE address registers
 - Added preliminary Super System Card information
 - Added details of BRAM unlock sequence
 [10/07/01]
 - Added information on VDC register $05
 - Added information on VDC/VCE accesses
 - Added sprite section
 - Added details on invalid pattern name values
 [10/08/01]
 - 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
 [10/10/01]
 - Added information of P state within interrupts
 - Added information on T flag and RTI
 - Added better description of TMA #$00 results
 [10/11/01]
 - Added information on when CRT registers can be changed
 - Added DMA section
 [10/25/01]
 - 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
 [10/27/01]
 - Added more details to the timer section
 - Added a note about ADC
 [12/02/01]
 - Added information on how TAM and TMA work
 - Rewrote description of RCR register
 [12/07/01]
 - Added observations about CD-ROM registers
 - Added information on ADPCM hardware
 - Added more information about block transfers
 [12/08/01]
 - Added more information on TMA #$00
 - Added information on IRQ2
 - Added information on initial timer and IRQ register values
 - Added a note about SBC
 [01/25/02]
 - 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
 [02/28/02]
 - 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
   speeds.

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

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

 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 0    1    CPU BAT CPU ??? CPU CG0 CPU CG1
 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:

    MSB          LSB
    ppppnnnnnnnnnnnn

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

 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.

 Notes:

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

 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:

    MSB          LSB
    -------GGGRRRBBB

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

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

 Overview

 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
 commands:

 00 - TEST UNIT READY
 03 - REQUEST SENSE
 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
 CD_SEEK.

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

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

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

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

 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
 follows:

        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
 }
 else
 if ($18C1 == $AA && $18C2 == $55)
 {
    X = $18C3 | $80, A = $68, carry = 0
 }
 else
 {
    /* 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:

 Width  HDS HSW HDE HDW CLK
 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:

 Height VDS VSW VDW VDW VCR
 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
 (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.