Initializing Sega CD in Mode 1

I'm working on a little Sega CD backup RAM cart that features a flash memory that will allow one to manage the memory on the cart. When a switch is selected, the cart will boot to that flash memory. The flash memory contains some utilities to manage the RAM and use your Sega CD's hardware.

The Sega CD has this convenient feature called Mode 1, which lets code run from a regular Mega Drive cartridge, but make use of the Sega CD's additional hardware.

To really be able to access the Sega CD hardware, one needs to initialize the hardware and load the BIOS. How would I go about doing this? The documentation isn't very specific and only lists steps to take.

The only other software that I know of that uses the Sega CD in Mode 1 is Flux, a music visualizer. I've attempted to disassemble parts of it, but without much success so I still haven't been able to find the code to do this.

Any help would be greatly appreciated!

 

The location from which it decompresses the BIOS shouldn't really matter - the BIOS is (for some odd reason) split into 3 parts, which go in the order of 3, 1, 2, if I remember. Maybe this is to prevent hacking of the BIOS - I have absolutely no idea. The BIOS is always loaded to bank 0 of the Sub-CPU program RAM while the Main CPU has the Sub-CPU's bus and the Sub-CPU has reset de-asserted.

 

Thanks for the response.

The CDX BIOS files don't seem to have a Sub-BIOS I can find whatsoever, which I find odd. I've already gotten my Sub-CPU program to load, but I can't seem to talk to my main CPU and have that do anything. Right now, it compares the first long in the Sub-CPU (w/o) to Main-CPU (r/o) memory with the ASCII string "INIT" and keeps looping until it gets that. My Sub-CPU program obviously writes that to that location, but they can't seem to work. This is my Sub-CPU code:

Code (ASM):

1.  
2. SPHeader:
3.     dc.b    'MAIN        '                          ; Module name
4.     dc.w    $0100, 0                                ; Version, type
5.     dc.l    $00000000                               ; pointer to next module
6.     dc.l    SPEnd-SPHeader                          ; Module size
7.     dc.l    $20                                     ; Module start address
8.     dc.l    $00000000                               ; Work RAM size
9.     dc.b    0                                       ; End mark
10.     even
11.    
12.     include "cdbios.inc"
13.    
14. SPInit:
15.         move.l  #"INIT", $FF8020                    ; Tell the main CPU we've initialized.
16.        
17.         moveq   #0, d0                              ; Clear d0
18.         move.w  #LEDSET, d0                         ; Function number to d0
19.         moveq   #0, d1                              ; Clear d1
20.         move.w  #$0004, d1                          ; Blink both LEDs
21.         jsr     _cdbios                 ; Jump into BIOS
22.        
23. MainLoop:
24.  
25.         bra.w   MainLoop                            ; Keep looping the main loop of death.
26.    
27. SPEnd:
28.     END
29.  

 

Is it also Kosinski compressed? It doesn't seem to have that Kosinski header, so maybe it uses some other form of compression? The Sub-BIOS is incredibly bitchy and doesn't want to run my Sub-CPU code, so I still need to figure that out, as well as from what CPU I can call into the BIOS.

(The BIOS apparently is still 'stealing' my CPU since the drive does go into standby after a while. Maybe I forgot to set some register/gate array/comms RAM?)

 

I changed the header to what you suggested, but my code still doesn't exactly seem to work. It compiles, but it just won't run, and my main CPU is stuck in an initialization loop, where it waits for the Sub-CPU to write to Comms RAM.

This is an except from my program:

Code (ASM):

1.  
2. SPHeader:
3.         dc.b   'MAIN-SUBCPU'
4.         dc.w   $0001, $0000
5.         dc.l   $00000000
6.         dc.l   $00000000
7.         dc.l   SPHeaderOffsets-SPHeader
8.         dc.l   $00000000
9.  
10. SPHeaderOffsets:
11.         dc.w   SPInit-SPHeaderOffsets
12.         dc.w   SPMain-SPHeaderOffsets
13.         dc.w   SPNull-SPHeaderOffsets
14.         dc.w   SPNull-SPHeaderOffsets
15.         dc.w   $0000
16.         even
17. ....
18.  
19. SPInit:
20.         move.w  #$002, d1                           ; Load the LED status to d1
21.         BIOS_LEDSET                                 ; Call into BIOS
22.         ....
23.  

I defined SPNull as a simple rts at the bottom of my file, as well as SPInt2. I'm hoping the fact that I just do an rts in the level 2 interrupt routine doesn't screw stuff up, since probably the sub-BIOS runs code there to back up registers, etc and calls it with a jsr. I still can't get my code to run at all (the LEDs do not change as they should) and I'm slowly running out of ideas as to why this is happening. My last guess (and probably most likely) is that the BIOS never even calls my code for some really strange reason.

Any ideas?

Edit:

Huh, odd. The dumps I have here are probably bad dumps then. Or I was just looking at the wrong file, yet again.

 

No problem - I should have probably invested some more thought into that than just replacing things randomly. Quite oddly, I still am unable to get this to work. Any ideas what could be causing this oddity of mine? I still can't get both the red and green LED to light up (which is what I call in my SPInit) routine.

Could it be, quite simply, that I'm not loading my Sub-CPU code to the right place? I'm loading it to $426000 in the Main CPU's memory map, which is $6000 in the Sub-CPU program RAM. I set everything to bank 1, and it's actually just writing it right after the Sega CD BIOS. Odd.

 

Erm, I meant bank 0. I tried loading the uncompressed program to the MCD - no difference. Maybe we should move this conversation to Skype/IRC/etc or something?

 

Right now I'm calling this right after I give the Sub-CPU back the bus and release it from reset, and after clear the comms RAM:

Code (ASM):

1.  
2.         bset    #8, $A12000                         ; Generate an interrupt
3.  

Would this be enough time to allow the Sub-BIOS to initialize? Is there some time estimate on that? I assume I could just run nop's for like 32k cycles, but meh.

 

Thanks for everyone's help - Eventually I was able to figure out my issues with the help of Chilly Willy over Google talk.