Sega CD programming FAQ (1998-12-06)

From Sega Retro

This is a copy of an "unofficial" document containing original research, for use as a source on Sega Retro. This page likely exists for historical purposes - the contents should ideally be copy-edited and wikified to make better use of Sega Retro's software.
Original source:

                       | Sega CD programming FAQ |
                        12/06/1998: revision 0.15

                     compiled by: Christian Schiller

                      This document is dedicated to
                        all Sega emulator authors
                            in the world. :-)


  I.     History & purpose
  II.    Acknowledgements
  III.   General information & gossip
  IV.    Hardware information
  V.     Programming details
           1. Memory maps, gate array and other registers
           2. Graphics chip
           3. Sound chip
           4. BIOS
           5. Datel CDX Pro
  VI.    Contacting the author

I.   History & purpose

*** 12/06/1998: updated gate array & CDX info, added first GPU info
*** 11/29/1998: added some more info on registers and CD controller
*** 11/22/1998: project begun

In 1995, I was infected by the emulation virus when I saw the first
emulator - a C64 emulator. And in 1996, Markus Gietzen released
GenEm v0.17, the first-ever working Genesis emulator. The next
milestone was Genecyst v0.12 on the 30th of June 1997, and Steve
Snake released the first version KGen in August 1997. From then
on, these two emulators were improved constantly by Sardu and Steve,
but the process came to a halt in mid/late 1998. Both emulators do
now emulate the Genesis nearly perfectly. Several other emulators
were released in the meantime, but none of them has reached the
perfection of Genecyst or KGen98 yet.

Now, new challenges await the emulator authors. I have always been
one of the "few" people who adored Sega´s CD add-on for the Genesis,
called Sega CD (respectively Mega CD in Japan and Europe). And that
is the reason why I was constantly searching for information
regarding this device. During this process, my site became the
largest Sega CD resource on the net.

The only thing missing was detailed information about the Sega CD...
BIOS dumps were available, some technical specifications, but that
was almost all. Now, with this FAQ, the situation changes. Since the
beginning of 1998 I collected many bits of information. In November
1998 I was contacted by Joseph Fenton who gave me lots of detailed
information because he reverse-engineered the BIOS in order to write
an emulator for PowerPC/AmigaPPC.

At last, I had enough information to start this FAQ - This document
will be updated constantly as long as I get new information about the
Sega CD. I hope to make this document the "bible" of all Sega CD
programmers and emulator authors. 

Of course, right now there´s still a lot of gossip in this FAQ,
on the one hand because I didn´t have enough time yet to structure
it, and on the other hand because there are many tidbits which are
mere theory and not confirmed yet.

II.  Acknowledgements

Let´s give BIG cheers to these people without whom this FAQ would
never have been possible:

  Charles, Daemon, Flavio, Jim, Randy, Sardu, Steve
  and especially  J o s e p h  F e n t o n.

III. General information & gossip

*** This chapter just gives some very fuzzy information about the 
*** structure of the Genesis/Sega CD combo. More detailed information
*** follows in the next two chapters.

The general structure of Sega CD games seems to be the following:
two 68k programs run at the same time. One on the SCD´s 68k, the
other on the Genesis´ 68k. But only the Genesis 68k has access to the
VDP and sound registers of the Genesis soundchip. That leaves only
three tasks for the SCD´s 68k:

 1) accessing the CD drive,
 2) accessing the custom chips and
 3) computing.

The SCD´s 68k (or the special graphics chip) for example does all
the sprite/playfield zooming and rotation in games like Sonic CD or
Thunderhawk. Then the Genesis 68k simply downloads the pre-calulated
data via the connector port (which is, simply said, "just" a second
cartridge port) and displays it on screen.

One of the hardest parts of Sega CD emulation will be the fact that
two 68k engines (one running at 7.9MHz, the other at 12.5MHz) and a
Z80 engine (running at 4MHz) must run synchronized. This will take a
lot of CPU power. And don´t forget: the normal Genesis´ functions
like raster effects and so on have to be emulated as well. Steve
Snake´s estimation is that a nicely coded SCD emu would run at about
1/3 normal speed on a Pentium 200 MMX. But then again, the best games
on the Sega CD are RPGs and adventures. Which means: a frameskip of
4 or 5 should be acceptable for this kind of games. :-)

This is a small excerpt of the discussion Steve and I lead,
concerning the general method of programming the Sega CD:  
I asked Steve the following:  

  I´ll go through one example: let´s imagine we load some bitmap
  graphics from CD in order to display them onscreen. According to
  what you´ve said, we´d need to do the following:

    1) give a load command to load the gfx file into the CD buffer
    2) copy the gfx from the cd buffer to the main RAM (512K?) of
       the CD processor  
    3) maybe rotate/zoom the gfx using the CD graphics chip...
    4) switch main RAM to Genesis CPU
    5) copy gfx data from main RAM to Genesis RAM  
    6) copy gfx data from Genesis RAM to VDP RAM to display it

Steve´s answer:  

  Essentially, YES, that's EXACTLY what you have to do ! except, of
  course, that if you want to run, say, full motion video at 20
  frames per second, you have to somehow compress your data, so that
  3 frames worth of CD ( 3 sectors = 6144 bytes ) can make up one
  frame of data. Then, the SCD processor (cos it's faster and is
  doing nothing except copying CD data when the IRQ comes in)
  decompresses this into main RAM, switches to the Genesis CPU. Then
  the Gen CPU copies it to RAM, then to VRAM. (I don't remember if
  the SCD RAM lies within the first 4Mb area of normal Gen RAM -
  if it does you could theoretically use DMA to send it straight
  from this RAM to VRAM.)  

IV.  Hardware information

*** This chapter of the FAQ merely gives the known hardware details,
*** i.e. which chips the Sega CD uses and so on.

Uses a Motorola 68k running at 12.5 MHz as main processor.
Has overall 768KB of RAM. 512 KB are accessible to the 68000. The
remaining 256KB might be used as CDROM buffer and/or sound buffer.

Additional chips used: an 8-channel PCM sound chip, and a special
graphics chip ("ASIC"?) used for zooming/rotating and another
soundchip which has not been identified yet.

These are the descriptions of the special ICs used in the Sega CD
(taken from my first-generation Japanese Mega CD 1 front-loader

 - Sega 315-5476 (IC 3)   
 - Sanyo LC8951 (IC 15)   
 - Sega 315-5477 (IC 2)

Maybe someone has detailed information on these...  
These are the official specifications of the Sega CD, as appeared in
the US manual:  
  68000 (12.5MHZ)  
    6 Mbit (program, picture Data, sound data)  
  512 Kbit (PCM waveform memory)  
  128 Kbit (cd-rom data cache memory)  
   64 Kbit (backup memory)  

Boot ROM:  
  1 Mbit (CD game BIOS, cd player software, CD+G compatible)  
Sound Circuitry:  
  PCM sound source: Stereo 8 channels, sampling wavelength 32 khz max
  D/A converter: 16 bit D/A converter, 8x internal oversampling
                 digital filter, PCM and CD sound mixing, Mixing
                 with mixing terminal possible  
Audio characteristics:  
  wavelength characteristics: 20hz-20khz  
  signal v. noise (s/n):over 90dB(1khz)(line out)  
  timing range: over 90 dB   
Battery back-up secondary duration:
  approx 1 month

V.   Programming details

*** This chapter deals with the registers, the RAM access modes, the
*** graphics chip access, the PCM chip access, BIOS functions and
*** every other thing that needs a detailed, ASM-based description.

The Genesis 68K is referred to as the MAIN CPU
The Sega CD 68K is referred to as the SUB CPU
I will use this terminology in the whole FAQ.

V.1. RAM access, gate array and other registers

The Sega CD´s special registers (respectively, the BIOS functions)
appear to be located somewhere around $a10000-$a?FFFF because the
boot code accesses this address space. In the Genesis programming
documents, this area is referred to as "reserved". This is also the
area where some 32X registers are located.
The Sega CD CPU has an IRQ which is generated each 1/75 second, but
only when data is being loaded from the CD. The IRQ routine which is
executed when the interrupt occurs is used to copy the sector which
has been loaded from CD (2048 bytes) to the main RAM. This interrupt
applies only to the Sega CD 68k, not to the Genesis 68k.
The Sega CD 68k can be synchronized with the Genesis 68k by flagging
the Genesis VINT (each 1/60 second) into the Sega CD RAM. Steve
Snake used this method when he ported NBA Jam to the Sega CD.

Memory map of the MAIN CPU
000000-01ffff : BIOS ROM  
020000-03ffff : SUB CPU Program RAM - bankswitched in 4 * 128K blocks.
                (see later)  
200000-21ffff : SUB CPU 'WORD RAM' - 128K (when in 1M mode)
200000-23ffff : SUB CPU 'WORD RAM' - 256K (when in 2M mode)
a12000-a120xx : GATE ARRAY.  
ff0000-ff???? : MAIN CPU Program/Data RAM.  

The SUB CPU program RAM can only be accessed when the SUB CPU is in
BUSREQ (stopped) state. The SUB CPU 'WORD RAM' is for data only - and
is only visible by one processor at a time. Note that it IS in the
normal Genesis ROM area, so DMA is possible. The Genesis 68K is only
permitted to run code in it's standard RAM - from $ff0000 onwards.
Note that some of this RAM is used by BIOS functions - you only get
about 24K, as far as I can tell. Writing below or above a certain
address causes the machine to lock.  

Memory map of the SUB CPU
000000-07ffff : SUB CPU Program RAM (512K) - 000000-005fff is used
                by the BIOS. Certain other parts of this seem to be
                used for CD buffers etc.
080000-0bffff : SUB CPU 'WORD RAM' - 256K (when in 2M mode.)
0c0000-0dffff : SUB CPU 'WORD RAM' - 128K (when in 1M mode.)
ff0000-ff7fff : Sound HW / Video HW / CD HW / Sound RAM (unknown as
ff8000-ff80xx : GATE ARRAY.  

There seems to be a way of write protecting the SUB CPU program RAM -
I haven't worked this out yet.

GATE ARRAY (incomplete)

These offsets added to GATE ARRAY base for each processor.  

00 : RESET. (bit 0 : reset SUB CPU)
            (bit 1 : BUSREQ SUB CPU)
            (bit 8 : Interrupt Level 2)
                     Bit 8 is used to generate a 60Hz IRQ at the
                     SUB CPU, as I talked about before. The MAIN CPU
                     writes a 1 into this bit in it's 60Hz IRQ, and
                     this in turn generates a 60Hz IRQ at level 2 on
                     the SUB CPU.  
02 : MEMMODE. (bit 2 : MODE. (sets the 1M or 2M mode as listed above.
                              Unsure which way round this is as yet.)
              (bits 6 & 7 : BANK. Sets which bank of the SUB CPU
                            program RAM appears to the MAIN CPU. (0-3)

     b2 1 = 2 bank mode (2 banks of 128K)
        0 = 1 bank mode (1 bank of 256K)

     b1 1 always set on US games I have seen.

     b0 bank switch
        if in 1 bank mode 1 = Genesis has access to bank
                          0 = SEGA CD has access to bank
        if in 2 bank mode 1 = SEGA CD accesses bank 1
                              Genesis accesses bank 0
                          0 = SEGA CD accesses bank 0
                              Genesis accesses bank 1

     From the SUB CPU, the WordRAM is at 0x80000 to 0xBFFFF in
     1 bank mode, and at 0xC0000 to 0xDFFFF in two bank mode.

     From the MAIN CPU, the WordRAM is at 0x200000 to 0x23FFFF AND
     0x400000 to 0x43FFFF in 1 bank mode, and at 0x200000 
     to 0x21FFFF in 2 bank mode.

     W:b2-b0 Transfer Type
     R:b7 1 = DMA DONE (always set if not a DMA transfer)
          0 = DMA IN PROGRESS
       b6 1 = DATA AVAILABLE (use for CPU transfer)
          0 = NO DATA

     Valid Transfer Types are:
     2 - transfer the data nowhere using DMA (verify data)
     3 - transfer the data using the CPU
     4 - transfer the data to PCM RAM using DMA
     5 - transfer the data to Program RAM using DMA
     7 - transfer the data to Word RAM using DMA

     On DMA transfers, this hold the offset into the selected
     RAM bank shifted right 3 bits.  Because of this, DMA
     transfers MUST be to addresses that are 8 byte aligned.

Typical sequence for reading blocks:

The Genesis 68K asks for blocks by sending the block
number and number of blocks to the CD 68K using the
communication ram (other methods may be used, but that
is typical). The CD 68K then does the following:

  lea     packet,a0
  move.l  block,(a0)
  move.l  length,4(a0)
  move.w  #$20,d0       ;start reading CD data blocks function
  jsr     $5F22.w       ;CD Library
  move.w  #600,d7       ;10 seconds (NTSC)
  jsr     $5F10.w       ;wait for software VINT
  move.w  #$8A,d0       ;check if data in CD Cache RAM function
  jsr     $5F22.w
  dbcc    d7,.1         ;loop until data or 10 seconds
  bcs     .error
  move.b  #3,$FF8004    ;transfer using CPU
  move.w  #$8B,d0       ;start transfer from CD Cache RAM function
  jsr     $5F22.w
  bcs.b   .0            ;error, retry read
  lea     databuffer,a0  ;normal cd data for the block
  lea     extrabuffer,a1 ;extra cd data like ecc
  move.w  #$8C,d0       ;read data into buffers using CPU function
  jsr     $5F22.w
  blo.b   .0            ;error, retry read
  move.w  #$8D,d0       ;done reading CD Cache RAM function
  jsr     $5F22.w
  lea     packet,a0
  addq.l  #1,(a0)       ;next block (in case of retry)
  subq.l  #1,4(a0)      ;one less (in case of retry)
  bne.b   .2            ;continue transfer of data

Using the DMA mode allows the CD 68K to process previously
fetched data while the next data is loading.  A typical
sequence would be:
  Read Data into WordRAM bank 0
  Start Data Read into WordRAM bank 1
  Process Data in Bank 0
  Start Data Read into WordRAM bank 0
  Process Data in bank 1

Night Trap appears to use the DMA in this manner for
smooth full-screen video.

Another possibility to explain the gate array is the following; it is
probably less confusing to treat them as seperate bytes.

    0xA12000/0xFF8000 bit 0 = 1 assert IRQ2 to SUB CPU

    0xA12001/0xFF8001 bit 0 = 0 assert RESET to SUB CPU
                            = 1 deassert RESET to SUB CPU
                      bit 1 = 0 deassert BUSREQ to SUB CPU
                            = 1 assert BUSREQ to SUB CPU

The SUB CPU does the Reset vector once the reset is deasserted;
clearing the bit will hold the SUB CPU in the reset state until it is

The Communication RAM for the two 68K processors is as follows:

   One word that can be read or written by either 68K; the bits are
   used individually for signals and handshaking (in software).

 0xA12010/0xFF8010 to 0xA1201F/0xFF801F
   Four longs that are written by the MAIN CPU and read by the
   SUB CPU; this is how the MAIN CPU sends messages to the SUB CPU.

 0xA12020/0xFF8020 to 0xA1202F/0xFF802F
   Four longs that are written by the SUB CPU and read by the
   MAIN CPU; this is used for the SUB CPU to send messages to the

All locations are strictly RAM and cause no exceptions or interrupts
or have any hardware affected by them.

CD-ROM controller

The CD controller reads the data directly into the CD Cache RAM; the
user may then read the Cache RAM to get the data.

Status Register (BYTE Read)
  MAIN CPU: 0xA12004
  SUB CPU : 0xFF8004

Index Register (BYTE Write)
  MAIN CPU: 0xA12005
  SUB CPU : 0xFF8005

Data Register (BYTE Read/Write)
  MAIN CPU: 0xA12007
  SUB CPU : 0xFF8007

Data IO Port (WORD Read)
  MAIN CPU: 0xA12008
  SUB CPU : 0xFF8008

Feature Register (BYTE Write)
  MAIN CPU: 0xA12033
  SUB CPU : 0xFF8033

Abort/Reset Register (BYTE Write)
  MAIN CPU: 0xA12037
  SUB CPU : 0xFF8037

ECC Status Register (BYTE Read)
  MAIN CPU: 0xA12069
  SUB CPU : 0xFF8069

ECC Data Register (0x100 BYTES Read)
  MAIN CPU: 0xA12100
  SUB CPU : 0xFF8100

Status Register:
  bit 7=0 error
  bit 6=1 cd data ready
  bit 2=0 extra longword of data

Index/Data Registers:
  write the index to the index register, then write one or more
  bytes to the data register.

Index 1: Get State info
  1st byte - a status byte of some kind

Index 2: Read CD Cache RAM
  1st byte=LSB of block length - 1
  2nd byte=MSB of block length - 1
  3rd byte=LSB of Address in CD Cache RAM
  4th byte=MSB of Address in CD Cache RAM
  5th byte=0

  This is done/checked after every IRQ5

Index 4: Get Transfer Block Address and Cache Address
  1st byte - xx
  2nd byte - Min (BCD)
  3rd byte - Sec (BCD)
  4th byte - Frame (BCD)
  5th byte - MSB of Cache Address where this data is
  6th byte - LSB of Cache Address

Index 7: Stop CD Cache RAM Read
  1st byte - 0

  This is done/checked after every IRQ5

Index 0xA: Start transfer of data from CD into Cache RAM
  2 bytes - I think they are related to the type of info to read
            and/or the address to write to in the cache ram.

  This is done/checked after every IRQ5

Index 0xC: Get Transfer Status
         1st byte - status
         2nd byte - status
         3rd byte - status
         4th byte - status

  The four bytes contain bits that determine what type of data has
  been read (data, ecc, subcodes,...), how much has been read, and
  whether any errors occured.  I'm still working on what they stand

A typical sequence would be like this:

  1- Write the RB Address to 0xFF8042-4B
  2- Wait until 0xFF8038-41 indicates it is there
  3- Init the CD Controller
  4- Wait for Irq5
  5- Get state, transfer and cache address, and transfer status
  6- Do 0xA/0xA0,0xF8
  7- Wait for Irq5
  8- Get state, transfer and cache address, and transfer status
  9- Update CD Cache info vars
  10- Do 0xA/0xA4,0xD8
  11- Wait for Irq5
  12- Get state, transfer and cache address, and transfer status
  13- Update CD BIOS vars
  14- Do 0xA/0xA7,0xF0
  15- Wait for Irq5
  16- Get state, transfer and cache address, and transfer status
  17- Update CD Cache info vars
  18- Do 0xA/0xA3,0xB0
  19- Wait for Irq5
  20- Get state, transfer and cache address, and transfer status
  21- Update CD BIOS vars
  22- go back to 6

Feature Register:
  bit 6 = 0 seems to suspend the controller
        = 1 resumes normal processing
  bit 5 = 0 clear this before initializing the controller
            (0x38->I(1) and 0x3A->I(1))

ECC Status Register:
  bit 7 = 1 = okay
        = 0 = ECC error
  bit 6-0 = offset in data area of ECC error

If you find bit 7 = 0, read the ECC Data Register + offset (read 96
bytes) and then do a standard ECC routine over that data. This seems
to be what the bios does.

The ECC data is actually the subchannel info and the decoding
is just seprating the bits into the P-W channels.

Function 0x0013 is the play audio track function; you pass a
pointer to the track to be played (a word) in a0 and 0x0013
in d0, then jsr $5F22.

The registers at 0xA12038/0xFF8038 are used to get and set
the frame to go to.  They are organized as nibbles as such:

Get Current RB Address:
38 = 0x0S MSN of status
39 = 0x0S LSN of status
3A = 0x0M MSN of Minute (BCD)
3B = 0x0M LSN of Minute (BCD)
3C = 0x0S MSN of Second (BCD)
3D = 0x0S LSN of Second (BCD)
3E = 0x0F MSN of Frame (BCD)
3F = 0x0F LSN of Frame (BCD)
40 = 0x00 MSN of Checksum
41 = 0x0C LSN of Checksum

The checksum is the first 8 bytes added together, inverted (NOT),
and then ANDed with 0x000F.

Set Current RB Address:
42 = 0x0S MSN of Command
43 = 0x0S LSN of Command
44 = 0x0M MSN of Minute (BCD)
45 = 0x0M LSN of Minute (BCD)
46 = 0x0S MSN of Second (BCD)
47 = 0x0S LSN of Second (BCD)
48 = 0x0F MSN of Frame (BCD)
49 = 0x0F LSN of Frame (BCD)
4A = 0x00 MSN of Checksum
4B = 0x0C LSN of Checksum

The checksum is computed the same as above.

Commands I have found so far (as bytes in nibble form):
02 00 ?
04 00 goto the specified RB Address
06 00 seems to be recalibrate or something similar
07 00 ?

Battery backed-up RAM (BB RAM)

On the CD side, the BB RAM is indeed at 0xFE0000 and goes to 0xFE3FFF
on odd addresses only.  The CD 68K can read and write it at any time.
The Genesis 68K has access to the BB RAM at 0x600000 through 0x603FFF
on odd addresses and can read it at any time, but must set bit 0 of
0x7FFFFF to a 1 to write enable the BB RAM and a 0 to write protect

I think the CD 68K BB RAM at 0xFE0000 is the built-in BB RAM and the
Genesis BB RAM at 0x600000 may be the Cartridge BB RAM.

The BB RAM functions for the Genesis 68K are at 70EE in the US bios,
but may be overridden by a ram cart.

Country protection of the games

This is what we found out regarding removing the country protection
of Sega CD games:
 1) changing the byte at $1f0 has NO effect, neither is it of any use
    to change $190 or the phrase at $100. Afterwards, the games are
    still only recognized on the machines they were sold for.
 2) the address which is stored at offset $42 of the image points to
    the location where the GAME code starts
 3) the BOOT code ALWAYS starts at $200
 4) on ALL US CDs, the code from $200-$783 is EXACTLY the same;
    on ALL JP CDs, the code from $200-$354 is EXACTLY the same;
    on ALL EUR CDs, the code from $200-$76d is EXACTLY the same;
    (which makes me think: may there be a checksum somewhere???
    Anway, the BIOS code which aims at the copy protection MUST
    have something to do with these areas.)
 5) in the JAP boot block, the graphics data for the Sega logo is
    stored at $236-$30c                    
 6) if you "implant" the proprietary JAP boot code into a US game,
    the option "CDROM" (which makes it possible to start the game) is
    displayed on the JAP BIOS screen, but after booting, the game
    crashes. The same thing happens if you implant proprietary US
    boot code into a JAP game. The option to start the game is
    displayed on the US BIOS screen, but after booting the game
    crashes. If you change but ONE BYTE in the proprietary boot code,
    the option "CDROM" is is not displayed on the BIOS screen
The Japanese boot code checks the following:    
  000002B0 BNE $000002A8;***If 0xa12003(bit 1)=0 proceed, else hang
  which means: Japanese Mega CD: 0x00A12003 has bit 1 RESET (zero)
The American boot code checks:    
  000005E4 BNE $000005DA;***If 0xa12003(bit 1)=1 proceed, else hang
  which means: American Sega CD: 0x00A12003 has bit 1 SET (one)

V.2. Graphics chip

The Gfx Coprocessor in the SEGA CD is located at

0xFF8058 WORD  READ: b15 = 1 indicates the coprocessor is busy
              WRITE: probably the command word, values seen
                     so far are $0000, $0004, and $0007
0xFF805A WORD WRITE: seems to be control bits for the operation
                     typical values $8000, $3D80, $DA80, etc
0xFF805C WORD WRITE: typically $001B, $0015, $0011, or $000B
0xFF805E WORD WRITE: I think this is an offset, values are
                     typically like $1500 or $1A80
0xFF8060 WORD WRITE: related to the scaling/rotating
                     generally see the 3 lsb of the x and y
                     slopes/angles in b5-3 and b2-0
0xFF8062 WORD WRITE: this is definately the bitmap width
                     typical values are 320, 256, or 40
0xFF8064 WORD WRITE: this is definately the bitmap height
                     typical values are 224, 176, and 40
0xFF8066 WORD WRITE: this is (offset in Word RAM >> 2) for a
                     table; I think the table is offsets for
                     the line data for the bitmap, but it is
                     definately the offset >> 2.

You wait on +58 bit7 = 0, then set the registers; setting +66
starts the operation.  You do not have to set all the registers
each time, only the changed ones and +66.

It seems that 0xFF8003 also controls the Coprocessor's access
to Word RAM, as well as the CD and the Genesis:

 b3 = 0 Coprocessor cannot access Word RAM
      1 Coprocessor can access Word RAM (automatically set when
        operation started)
 b4 = 1 abort current operation (I think); you MUST wait on
        +58 bit 15 = 0 before starting the next operation.

Eye of the Beholder clears b3 and b4 before setting the coprocessor
registers; BattleCorps only waits on the op done flag unless aborting
the previous operation.

V.3. Sound chip

PCM audio is only accessible by the CD 68K as far as I can tell.

0xFF0011: PCM Channel Enable
          b7 = 0 = channel 7 on, 1= channel 7 off
          b6 = 0 = channel 6 on, 1= channel 6 off
          b5 = 0 = channel 5 on, 1= channel 5 off
          b4 = 0 = channel 4 on, 1= channel 4 off
          b3 = 0 = channel 3 on, 1= channel 3 off
          b2 = 0 = channel 2 on, 1= channel 2 off
          b1 = 0 = channel 1 on, 1= channel 1 off
          b0 = 0 = channel 0 on, 1= channel 0 off

0xFF000F: PCM RAM Bank Select
          b7-6 = 10          
          b5-4 = xx          
          b3-1 = channel (0-7)
          b0 = 0 = lower 4K
               1 = upper 4K

The PCM RAM selected is accessible at 0xFF2000-0xFF3FFF at odd
addresses (4K).

0xFF000F: PCM Controllers
          b7-6 = 11
          b5-3 = xxx
          b2-0 = channel (0-7)

The different controlls for each channel are then accessible at:

0xFF0001 (BYTE) I´m pretty sure this byte is the volume, where 0 is
                min and 0xFF is max.  It appears that when a note off
                event is received, the player uses a variable
                representing the release rate to decrement the value
                stored into 0xFF0001 until it reaches 0, at which
                point, the flag saying the channel is in use is
                reset. Pretty well has me convinced...

0xFF0003 (BYTE) This seems to always be written with 0xFF.

0xFF0005 (BYTE) LSB of the Channel Frequency.

I'm not sure what the 12 bits in regs 0xFF000B/0xFF0009 are...
they are to big for a pan.  I now believe the pan is at 0xFF0003.
It is normally set to 0xFF (which I assume is centered), but can
be changed by a music event to a the byte after the event code.
That is the only access to 0xFF0003 other than when the channel
is initialized by the instrument.  The 12bits I mentioned above
are set when you set the instrument, and never set again, so I
don't believe they can be the pan.


*** Note: This info may only apply to the Sega CD BIOS v1.10 ***
***       which Joseph Fenton used to analyze. The file is   ***
***       available in my download section, see chapter VI   ***
***       for the URL!                                       ***

The BIOSes which are available at my site (1.01, 1.10 and 2.00) are
the BIOS ROMs that appear in the Genesis map at 0x000000 to 0x01FFFF;
This BIOS decompresses a "new" BIOS into the SUB CPU RAM at 0x000000
to 0x01FFFF. The BIOS on the MAIN CPU side is NOT visible to the SUB
CPU; that is why the MAIN CPU decompresses code into the SUB CPU RAM.

There seems to be a jump table for the BIOS functions starting at
address $280 of the BIOS.   

The BB RAM functions for the Genesis 68K are at 70EE in the US bios,
but may be overridden by a ram cart.

The entry points for the SUB CPU modules in the BIOS are:
Module 1: 0x000000 CD BIOS
Module 2: 0x006000 Boot Module
Module 3: 0x018000 Music Player Module

This is a commented ASM listing of the SUB CPU BIOS boot process:

Startup		tst.w	($00C00004).L
000544          ori.w	#$0700,sr
000548		moveq	#-$01,d1
00054A		bsr.w	lbC0014B2
00054E		clr.b	($00FFFE53).W
000552		btst	#$06,($00A1000D).L
00055A		beq.b	ColdStart
00055C		movea.l	($00).W,sp
WarmStart	move.w	($00C00004).L,d3
000566		btst	#$01,d3
00056A		bne.b	WarmStart
00056C		bsr.w	lbC0007C2	;check country code
000570		bsr.w	VerifyBootBlock
000574		bne.w	lbC000884
lbC000578	st	($00FFFE53).W
00057C		bsr.w	lbC000610	;setup z80 and cd 68k
000580		move.w	#$4EF9,($00FFFD00).W	;jmp Restart
000586		move.l	#Restart,($00FFFD02).W
00058E		jmp	($00400200).L	;do boot block code
ColdStart	jsr	(lbC000A6C-CartStart).W
000598		jsr	(lbC000AB8-CartStart).W
00059C		bsr.w	lbC0007C2	;check country code
0005A0		bsr.w	lbC000754	;clear cd program ram
0005A4		bsr.w	lbC0007A4	;clear shared ram
Restart		ori.w	#$0700,sr	;disable
0005AC		bsr.w	VerifyBootBlock	;check boot block at 400000
0005B0		beq.b	lbC000578	;found boot block, do it
0005B2		bsr.b	lbC0005EC	;setup z80, cd 68k, and cdport
lbC0005B4	moveq	#$01,d0
0005B6		moveq	#$04,d1
0005B8		jsr	(lbC001468,pc)	;bset #2,A1200E
0005BC		moveq	#$04,d0
0005BE		bsr.w	lbC00064C	;set FFFDDA
lbC0005C2	lea	($00FFFDDA).W,a0
0005C6		move.w	(a0),d0
0005C8		andi.w	#$7FFC,d0
0005CC		jsr	(lbC0005D2,pc,d0.w)
0005D0		bra.b	lbC0005C2

V.5. Datel CDX Pro

*** The info below corresponds to the CDX Pro version 1.8I, which ***
*** is available at my site as                        ***
*** (URL: see chapter VI.)                                        ***

The CDX Pro only works on the MAIN CPU. When the CD first comes up,
the CDX has it's own rom so up at 0 and the normal bios is at
0x400000.  It sets up the video, shows a version and then checks the
bios at 0x400000 to see if it is supported; if it is, it sets the
CDX Pro hardware to patch up to 4 words.

The hardware address compare latches are at:
  0x100000, 0x100008, 0x100010, and 0x100018
  +0 = replacement word
  +2 = A8-A1
  +4 = A16-A9
  +6 = A23-A17

After setting all four compare latch groups, 0xFFFF is stored to
0x100020 to switch out the CDX Pro bios and activate the CDX Pro
compare circuits. The four words replaced do the following: one word
replaces the country code cmp.b with a cmp.b d0,d0 to make it always
pass; the other three words cause a jmp abs.l to the CDROM startup
address in the CDROM boot block.

With Thunderhawk/Thunderstrike, the CDX additionally patches some 
addresses to neutralize the language & 50/60Hz checks the Core Design
programmers used.

VI.  Contacting the author

Home site of this document:

You can reach me via email at one of the following addresses:

             [email protected]
             [email protected]
  [email protected]
            [email protected]

Other possibilities to reach me are:

  ICQ     : UIN 1689964 (
  Fido-Net: 2:2454/470.64

  or, if it´s REALLY urgent, via phone: +49-621-8280921

*** END OF FILE ***