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: http://www.angelfire.com/ny/dezmoowu/Sega/progscd.txt |
/-------------------------\
| 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. :-)
Structure
---------
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
onscreen.
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
system):
- 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:
CPU:
68000 (12.5MHZ)
Memory:
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
yet)
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)
03 : WORDRAM CONTROL
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.
04 : TRANSFER TYPE AND STATUS
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
0A : TRANSFER OFFSET
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)
.0
move.w #$20,d0 ;start reading CD data blocks function
jsr $5F22.w ;CD Library
move.w #600,d7 ;10 seconds (NTSC)
.1
jsr $5F10.w ;wait for software VINT
.2
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
.error
rts
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
Etc.
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
deasserted.
The Communication RAM for the two 68K processors is as follows:
0xA1200E/0xFF800E
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
MAIN CPU.
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
for.
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
it.
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
anymore!
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.
----------------------------------------------------------------------
V.4. BIOS
----------------------------------------------------------------------
*** 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 Cdx_bin.zip ***
*** (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:
http://homepage.psp.net/cschiller
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 (www.mirabilis.com/1689964)
Fido-Net: 2:2454/470.64
or, if it´s REALLY urgent, via phone: +49-621-8280921
----------------------------------------------------------------------
*** END OF FILE ***
----------------------------------------------------------------------