Sega CD (US) BIOS Disassembly @ GitHub
Moderator: Mask of Destiny
-
- Interested
- Posts: 15
- Joined: Tue Mar 17, 2015 4:09 pm
- Location: Redmond, WA
Sega CD (US) BIOS Disassembly @ GitHub
Hi, SpritesMinders! As I mentioned in another thread, I few weeks ago I started working on a disassembly of the Sega CD 2.00w (US) BIOS. I'm happy to say that I'm ready to open up at least part of it to the community!
It's still very raw at the moment, and there are probably more subroutines I haven't rooted out than those I have. However, it does assemble to a byte-identical copy of the original, so at least it's a start! In addition, I'm currently only posting the Main-CPU portion of the BIOS. I have started looking into the Sub-CPU and Z80 portions, but those are even less polished, which is saying something.
Contributions to the Main-CPU code and/or documentation are more than welcome; as I said, I'm not ready to open up my work on the other two processors just yet. Hopefully this is useful for folks, and if possible I'd love to make this a complete, well-documented disassembly with everyone's help!
The repository itself is right here!
It's still very raw at the moment, and there are probably more subroutines I haven't rooted out than those I have. However, it does assemble to a byte-identical copy of the original, so at least it's a start! In addition, I'm currently only posting the Main-CPU portion of the BIOS. I have started looking into the Sub-CPU and Z80 portions, but those are even less polished, which is saying something.
Contributions to the Main-CPU code and/or documentation are more than welcome; as I said, I'm not ready to open up my work on the other two processors just yet. Hopefully this is useful for folks, and if possible I'd love to make this a complete, well-documented disassembly with everyone's help!
The repository itself is right here!
-
- Interested
- Posts: 15
- Joined: Tue Mar 17, 2015 4:09 pm
- Location: Redmond, WA
Those of you who are watching the GitHub repo have probably noticed by now that I've put up code for two out of the three sub-CPU program modules. (The third one is the CD player application, which I'm not too concerned about for now since I want to make my own software. I'll get to it eventually.) I've been making pretty good progress on it, but I can see a couple walls looming on the horizon that I'm likely to run into. I'm hoping you guys can help a bit.
First off, I'm having trouble wrapping my head around the communication between the two 68k processors. I can't quite keep track of what state each one is in as far as what the individual flag bits mean or what one is waiting for the other to do before continuing. The fact that there's interrupts that could jump in and change things at any given time doesn't make it any easier. Does anyone know of any good tools and/or techniques for managing all the different program flows?
Secondly, I have no idea what the CD drive itself is doing, as I can't find any documentation anywhere for the thing. I've been able to tease out a few subroutines, but without knowing what the different status bytes mean I'm going to have to start guessing at things before much longer. I might be able to figure out what's going on if I could stick a logic analyzer on it, but that's a tool that's way outside my budget right now. Any ideas?
First off, I'm having trouble wrapping my head around the communication between the two 68k processors. I can't quite keep track of what state each one is in as far as what the individual flag bits mean or what one is waiting for the other to do before continuing. The fact that there's interrupts that could jump in and change things at any given time doesn't make it any easier. Does anyone know of any good tools and/or techniques for managing all the different program flows?
Secondly, I have no idea what the CD drive itself is doing, as I can't find any documentation anywhere for the thing. I've been able to tease out a few subroutines, but without knowing what the different status bytes mean I'm going to have to start guessing at things before much longer. I might be able to figure out what's going on if I could stick a logic analyzer on it, but that's a tool that's way outside my budget right now. Any ideas?
Secondly, I have no idea what the CD drive itself is doing, as I can't find any documentation anywhere for the thing. I've been able to tease out a few subroutines, but without knowing what the different status bytes mean I'm going to have to start guessing at things before much longer. I might be able to figure out what's going on if I could stick a logic analyzer on it, but that's a tool that's way outside my budget right now. Any ideas?
Here is a copy of CDD_inf.txt from Stef (author of Gens) and Gerrie (author of Xega) which is the only existing doc on CDD protocol but is still incomplete and does not seem to exist online anymore:
Code: Select all
SegaCd CDD documentation
Version 2.0 (15/11/01)
by Stéphane Dallongeville and Michel Gerritse
E-mail: stef_d@caramail.com
E-mail: michel_gerritse@hotmail.com
----------------------------------------------------------------------------
Table of Contents
----------------------------------------------------------------------------
0.) Introduction
1.) Overview
2.) Register overview
3.) Command/Status layout
4.) CDD commands
----------------------------------------------------------------------------
0.) Introduction
----------------------------------------------------------------------------
This is a compilation of our notes on the SegaCd CDD.
Almost of them has been found by RE the bios and some sega CD games so
if you think that somes informations are wrong, or if you could provide
us new information, please contact Michel or Stéphane.
we decided to write this document because the CDD is totally undocumentated
(even in the official SegaCd manual).
Some parts of this document were taken from Eidolons
"Sega CD programming FAQ"
Visit http://www.eidolons-inn.de to download his SCD FAQ
----------------------------------------------------------------------------
1.) Overview
----------------------------------------------------------------------------
The CDD (Compact-Disk Drive) is used to access the SegaCd game CD (or a
normal audio CD)
It's is very similair to nowadays CD-ROM drives.
As far as I know, the CDD is custom made.
----------------------------------------------------------------------------
2.) Register overview
----------------------------------------------------------------------------
The CDD is only controlled by the SegaCd's 68000 CPU. The Genesis 68000
cannot access it.
- Register $FF8034 : CD Fader
Bit: F E D C B A 9 8 7 6 5 4 3 2 1 0
EFDT FD10 FD09 FD08 FD07 FD06 FD05 FD04 FD03 FD02 FD01 FD00 DEF1 DEF0 SSF ---
RD : 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
WR : 0 0/1 0/1 0/1 0/1 0/1 0/1 0/1 0/1 0/1 0/1 0/1 0/1 0/1 0/1 0
EFDT: End of fade data transfer
FD00-FD10: Fade volume data bits 0-11
DEF0-DEF1: De-emphasis flag
SSF: Spindle speed flag
- Register $FF8036 : CDD control
Bit: F E D C B A 9 8 7 6 5 4 3 2 1 0
--- --- --- --- --- --- --- D/M --- --- --- --- --- HOCK DRS DTS
RD : 0 0 0 0 0 0 0 0/1 0 0 0 0 0 0/1 0/1 0/1
WR : 0 0 0 0 0 0 0 0 0 0 0 0 0 0/1 WO WO
D/M : Data/muting
HOCK: Host clock
DRS : Data recieve status
DTS : Data transfer status
- Register $FF8038-$FF804A : Communication with CDD
Bit: F E D C B A 9 8 7 6 5 4 3 2 1 0
0 0 0 0 Recieve Status 0 0 0 0 0 Recieve Status 1
0 0 0 0 Recieve Status 2 0 0 0 0 Recieve Status 3
0 0 0 0 Recieve Status 4 0 0 0 0 Recieve Status 5
0 0 0 0 Recieve Status 6 0 0 0 0 Recieve Status 7
0 0 0 0 Recieve Status 8 0 0 0 0 Recieve Status 9
0 0 0 0 Transfer Command 0 0 0 0 0 Transfer Command 1
0 0 0 0 Transfer Command 2 0 0 0 0 Transfer Command 3
0 0 0 0 Transfer Command 4 0 0 0 0 Transfer Command 5
0 0 0 0 Transfer Command 6 0 0 0 0 Transfer Command 7
0 0 0 0 Transfer Command 8 0 0 0 0 Transfer Command 9
Note: The first 4 bits of every status/command byte is 0.
When recieve status 0-7 has been transferred to the SegaCd's gate-array, an interrupt level 4
will occure.
When transfer command 0-9 has been written by the SegaCd's 68000, the CDD starts executing the
written command.
----------------------------------------------------------------------------
3.) Command/Status layout
----------------------------------------------------------------------------
Layout of recieve status 0-9:
$FF8038 = 0x0S MSB of Status
$FF8039 = 0x0S LSB of Status
$FF803A = 0x0M MSB of Minute (BCD)
$FF803B = 0x0M LSB of Minute (BCD)
$FF803C = 0x0S MSB of Second (BCD)
$FF803D = 0x0S LSB of Second (BCD)
$FF803E = 0x0F MSB of Frame (BCD)
$FF803F = 0x0F LSB of Frame (BCD)
$FF8040 = 0x00 MSB of Checksum/Parameter
$FF8041 = 0x0C LSB of Checksum
Layout of transfer command 0-9:
$FF8042 = 0x0S MSB of Command
$FF8043 = 0x0S LSB of Command
$FF8044 = 0x0M MSB of Minute (BCD)
$FF8045 = 0x0M LSB of Minute (BCD)
$FF8046 = 0x0S MSB of Second (BCD)
$FF8047 = 0x0S LSB of Second (BCD)
$FF8048 = 0x0F MSB of Frame (BCD)
$FF8049 = 0x0F LSB of Frame (BCD)
$FF804A =Unused, always 0x00
$FF804B = 0x0C LSB of Checksum
Note: BCD = Binair Code Decimal
Example: 00100111 = 27
The checksum is computed in this way:
- Add the first 9 bytes of the status/command together
- Invert (NOT)
- AND with 0x000f
So the MSB of every checksum is 0x00 and the LSB of every checksum contains the checksum
data (with the first 4 bits being 0)
----------------------------------------------------------------------------
4.) CDD commands
----------------------------------------------------------------------------
This is probably the most interesting part of this document for emulators
authors.
The CDD works in the following way:
- SegaCd 68000 CPU writes data to the command buffer.
- When transfer command 9 has been written, the CDD executes the command
- The CDD writes the recieve status to the recieve buffer
- When RS7 has been written, an int 4 occurs.
If RS values aren't specified in return of a command, assume them
for 0 (except for RS8 and RS9).
Command 0x0000: Get CDD status
This command returns the current status of the CDD
RS0 = 0x00 : This indicates that no CD is present in the tray.
RS0 = 0x01 : This indicates the CDD is playing an audio track.
RS0 = 0x04 : This indicates that a CD is present in the tray
(no operation occuring).
RS0 = 0x05 : This indicates the CD tray is open.
RS0 = 0x09 : This indicates that a stop operation occured (0x0100) and
a CD was present.
Command 0x0100: Stop all operations
This is the Stop command (stops audio playback)
RS0 = 0x00 (only for this commandl, after that RS0 = 0x09)
Command 0x0200: Get TOC info
This command is related to the TOC (Table of Contents), TC3 (Transfer command 3) is a
parameter which indicates what TOC info is wanted.
RS0 = RS0 (unchanged)
RS1 = TC3.
TC3 = 0x00 : Get Current Position.
Position is returned in MSF format in RS registers.
TC3 = 0x01 : Get Current Position relative to the current track.
Position is returned in MSF format in RS registers.
TC3 = 0x02 : Get Current Track (during play/scan/read operation).
Current track is returned in RS2-RS3 in BCD format.
TC3 = 0x03 : Total length of CD wanted.
This returns the total length of the CD (including audio tracks) in MSF format.
Example: The total length of the CD is 53:16:11 (MSF) then the return
value will be:
RS0 = 0x04 (TOC data)
RS1 = 0x03 (CD length command)
RS2 = 0x05
RS3 = 0x03
RS4 = 0x01
RS5 = 0x06
RS6 = 0x01
RS7 = 0x01
RS8 = 0x00 (checksum)
RS9 = 0x0e (checksum)
TC3 = 0x04 : Number of tracks on disc
This returns the starting and end track of the CD in MSF format
Example: Our CD has 18 tracks.
RS2 = 0x00
RS3 = 0x01
RS4 = 0x01
RS5 = 0x08
RS2/RS3 decribes the starting track (BCD)
RS4/RS5 decribes the ending track (BCD)
TC3 = 0x05 : Start address (MSF) of track
This returns the start address of a track.
The track number is located in TC4 and TC5 (BCD)
RS2 - RS7 contains the start addres in MSF
RS8 contains the track number ANDed with 0xF
If a track is a data track (normally track 1) then RS6 = 0x08. In this way the
bios knows if a track is data or music (this probably could also be checked by reading
the D/M bit in the CDD control register)
TC3 = 0x06-0x0f : Unknown/invalid parameters
Command 0x0300: Read
The MSF part of this command (TC2-7) contains the start address (MSF), if we read
an audio track, datas will be also outputed to the LC7683 (DA fader).
RS0 = 0x01
RS1 = 0x02
RS2 - RS3 contains the track number currently read (BCD).
Command 0x0400 : Seek the MSF address
The MSF part define the location to reach.
RS0 = 0x02
Command 0x0500 : Unknown
Command 0x0600 : Stop read.
RS0 = 0x04 (if a cd is present) or 0x00 (if no CD).
Command 0x0700 : Resume play from current MSF.
See the play command for status return.
Command 0x0800 : Fast forward play
Still not be able to determine the sattus to return.
Command 0x0900 : Fast reverse play
Still not be able to determine the sattus to return.
Command 0x0a00 : Unknown
Command 0x0b00 : Unknown
Command 0x0c00 : Close CD tray
This command closes the CD tray
RS0 = 0x00
Command 0x0d00 : Open CD tray
This command opens the CD tray.
RS0 = 0x05
Command 0x0e00 : Unknown
Command 0x0f00 : Unknown
Code: Select all
/* CDD status */
0x01 = playing audio / reading data
0x02 = seeking audio / data
0x03 = scanning audio
0x04 = disc paused
0x05 = tray opened
0x09 = disc stopped
0x0B = no disc
0x0C = reading leadout
0x0E seems to be similar to 0x05 (tray open status) but not exactly, maybe it is related to motorized tray and indicates opening or closing is in progress.
You can also find some more infos about command / status words content in my CDD emulation code:
https://bitbucket.org/eke/genesis-plus- ... cdd.c-1431
PS: the CDD is actually a 4-bit MCU running proprietary code to communicate with the SUB 68K CPU through the Sega CD ASIC and controls/drives the CD unit. Various chips (Sony CXP4084, Hitachi HMC4xx, NEC UPD7500x, Sanyo LC663xx) were used depending on the Sega CD model and full documentation of the CDD commands/status would require dumping and disassembling the internal ROM.
-
- Interested
- Posts: 15
- Joined: Tue Mar 17, 2015 4:09 pm
- Location: Redmond, WA
Re:
I'm not entirely sure I understand your question, to be honest. Assuming you're talking about a game like Audiosurf where the CD audio is used to influence gameplay, I don't believe that's possible with the Sega CD. CD audio goes straight to the output ports; the 68k processor never gets a chance to look at it or do anything with it.HCKTROX wrote:I'd like to approach this situation to ask for something I wanted to know since the start: How are the CDDA decibels read? I must have being missing something, but I really can't find anything about.
-
- Very interested
- Posts: 624
- Joined: Thu Nov 30, 2006 6:30 am
Re: Sega CD (US) BIOS Disassembly @ GitHub
Doesn't the CDDA player in the BIOS have some sort of VU meter? I believe one of the Lunar games also peeks at audio data as it's being played back to sync animations which is why it sometimes does not work with poorly done ISO+MP3 rips. There's also FLUX which is a cartridge that has some visualizations that respond to CDDA somehow. The 68K isn't involved in actually ferrying CDDA data to the DAC, but it has some visibility into what's going on at least.
Re: Sega CD (US) BIOS Disassembly @ GitHub
CD-DA audio data is still sent to CDC (LC8951x chip which is normally used to decode CD-ROM data) and can just as well be read in buffered raw form by sub CPU. AFAIK, that's how internal CD player and Flux VU meters work. I didn't knew about Lunar animations though.
-
- Interested
- Posts: 15
- Joined: Tue Mar 17, 2015 4:09 pm
- Location: Redmond, WA
Re: Sega CD (US) BIOS Disassembly @ GitHub
Ah, I stand corrected. Haven't gotten to the CD player portion of the BIOS code yet.