/-------------------------\ | 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: eidolon@psp.net eidolon@uni-mannheim.de christian.schiller@ba-mannheim.de cschille@mail.de.ibm.com 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 *** ----------------------------------------------------------------------