Finally made a working modchip

[Pinchy]

Well I finally made a working modchip for the saturn.


It has been buggin me for ever and I started the project way back a few months after hacking up a 21pin modchip in another thread and worked off and on it since then.


Took a long time just to understand the protocol for commands and data between the saturn and CD. But I think I have most all of it figured out.


The whole process basically boils down to a few sequences.

When theres a request to seek out to some LBA thats in the security ring you have to disable the commands to the cd drive which in the original mods case was just replacing the parity byte with the wrong value which makes the cd ignore the command.


The authenticate process usually issues 4 seek commands to various parts of the ring and you have to supply it with a same repsonse (status) data that the cd drive would give.


After that it will issue a few read commands to various parts of the ring. And this is the hard part since you have to supply some 'fake' ring data. I tried originally to implement it all in a fpga but I ran into a stumbling block in trying to convert LBA to MSF which requires several divisions and multiplies. So I now have a board with a 8051 (cypress fx2) and FPGA where all the MSF calculations is done on the 8051.


The majority of the mode2 ring data is really not critical. Subcode doesnt matter and much of the payload doesnt matter. Its the MSF that has to be correct when its being sent along with the correct MSF in the status data in the command interface.


I still dont see where there would be any problem in burning a cdr with the ring data. you just need some software that will burn the correct data and TOC. I believe subcode would play a factor in this since the ring has the characteristics of LEADOUT and the status data is generated from this subcode info. Im sure the track number 'AA' which indicates leadout would make a difference. I will try to do some more testing to see what all it really looks for in the status data.



heres some tech info:


http://www.crazynation.org/SEGA/Saturn/cd_tech.htm


and some command log for reference:

http://www.crazynation.org/SEGA/Saturn/files/command_log.txt


project files:

http://www.crazynation.org/SEGA/Saturn/files/MODCHIP.ZIP


other:

http://www.crazynation.org/SEGA/Saturn/files/


I tried before to implement a CD emulator that would just use the PC as the virtual cd and have all the commands and data sent back and forth but it didnt work out to good. I could send the TOC data and respond to seek commands but It never did like the sector data I sent it. Didnt realize till now that the global 8mhz clock is synchronized to the 2mhz clock that is used for sector data. It must drive some state machine that decodes the incoming sector data, and since I was transmitting in bursts from the usb there would be empty spaces with the 8mhz clock running even though I would freeze the cd sector signals state.



What I still dont exactly know is how the commercial saturn modchips are implemented. I think the 'gal' on the board is some sort of FIFO that is pushed bytes from the uc and sends them in the correct serial format. But I dont know how large the fifo would be since the hardest part of all this is quickly calculating the MSF and getting back to filling the fifo and the status data to the command interface. Its quite a lot to keep going and I have most of it implemented in the fpga which takes a lot of resources. and it still takes a good while to do on the 8051 and sometimes the authenticate process will still fail or take a long time. I notice when it does this that it seems to miss properly updating the MSF along with the status data MSF values, and the saturn will keep issuing read commands at a lower LBA to it finally accepts it.


-cheers

 

[vbt]

Really nice you did it :thumbs-up: I'm wondering how look your modchip 🙂 .

I'll stay tuned here to read the result of your test with CD burning in case you make some 🙂

Your work is quite impressive, how many time did you spend on this project ?

 

[mal]

That's awesome news. :thumbs-up:

 

[Pinchy]

Really nice you did it :thumbs-up: I'm wondering how look your modchip 🙂 .


Your work is quite impressive, how many time did you spend on this project ?

This board was orignally meant to be the cd emulator:

http://www.crazynation.org/SEGA/Saturn/files/


http://www.crazynation.org/SEGA/Saturn/files/CD_EMU1.JPG

and

http://www.crazynation.org/SEGA/Saturn/files/CD_EMU2.JPG


theres some schematics here:

http://www.crazynation.org/SEGA/Saturn/files/CD_EMU.pdf


Ive done some more poking around and seems that even on the response (status) data you can leave a lot of the bytes out.


The saturn doesnt seem to be able to read the subcode from the sector data lines. You can fill it in with any value and it doesnt make any difference. It seems to rely solely on the status data to get whatever is in the subcode. Thats how it reads the TOC. It issues the 03 command and the cd drive feeds the tracks back in the various fields in the status data.


the ring data is in MODE 2 format:

12 bytes sync 00 ff .... ff 00

4 bytes header M S F MODE

8 bytes subheader

2342 bytes user data

4 bytes EDC


I removed the MODE byte , 8 bytes subheader and 4 bytes EDC and it doesnt make any difference.


The user data that contains 0x59 , 0xA8 does matter, you cant leave it out. I havent tried just sending all 0x59 or 0xa8 yet.


the status response for a seek command (0x02) involves:

status[0]=0xB6;

status[1]=0x44;

status[2]=0;//0xF1;

status[3]=*((BYTE*)&lba+1);

status[4]=*((BYTE*)&lba+2);

status[5]=*((BYTE*)&lba+3);

status[6]=0;//9;

status[7]=0;//9;

status[8]=0;//9;

status[9]=0;//9;

status[10]=0;


you can leave most all out and it works.


for the status response data to a read command (0x06):

status[0]=0x36;

status[1]=0; //0x01;

status[2]=0; //0xAA;

status[3]=0; //0x01;

status[4]=*((BYTE*)&msf+1);

status[5]=*((BYTE*)&msf+2);

status[6]=*((BYTE*)&msf+3);

status[7]=0; //6;

status[8]=*((BYTE*)&msf+1);

status[9]=*((BYTE*)&msf+2);

status[10]=*((BYTE*)&msf+3);


you can leave most all of it too. I was suprised to see that you can leave out the Qsubcode ,TRACK (0xAA which is leadout), and index field and have it still work.


Seeing this im pretty sure the only reason why my attempts to burn ring like data didnt result in it passing is that the TOC is what messes up the authenticate process. Since when you burn with regualr software it has the info that some data track is out where the ring should be and it shouldnt. the saturn docs specify that the disc cant contain data past like 60min mark.

 

[Pinchy]

Im beginning to think that its not really the TOC that is preventing a CDR from booting. I havent tried yet but I bet you could burn a disc with user data tacked on way out to the end of the disc and use a modchip and have it still boot. I made some discs like that but didnt even bother to check against the modchip. That would rule out the theory of the TOC containing info that tracks exist on the disc where the security data should be interfering with the authenticate process.


I think the problem is the response data to the seek commands (0x02)that are issued at the beginning of the process. I notice that it behaves the same was as the tests discs I made when you dont provide the 0x44 in the response.

status[0]=0xB6;

status[1]=0x44;


if you just send 00 for the second status byte (which is the first byte of the subcode data for that sector (4 bits CONTROL|4bits Mode) the saturn would issue a command to seek back to 'home' on the disc.


in the ecma docs for CD the 0x4 control represents "user data is digital and shall not be copied" 0x6 btw means that it can be copied.


The 0x4 for the q-mode is unusual since I dont see it specified in the docs.This mode number basically tells you what the format of the rest of Q subcode data in this sector will be in. you have mode 1 which is user data and lead out, mode 2 is for information/catalog data, 3 is for audio data but no mention of 4.



I notice that the seek commands that are issued at the beginning of the authenticate process are to MSF's between 57min and 66min which is actaully before the 0xa8 0x59 ring data starts. This must be a 'special' lead IN area (a lead in to the actaul security ring) that has this special Q-mode of 4.


So now the quesiton is can we burn some sectors in the area with this special q-mode subcode?

 

[dibz]

This is very cool, nice to see something interesting on the boards here. 😉

 

[Quakester2000]

So now the quesiton is can we burn some sectors in the area with this special q-mode subcode?

Ask over in http://www.cdfreaks.com they have some of the most well informed people on their forums. I think you would use sommat like CDRWIN as you can do a lot with cue files but im not the person to ask get over to their forums and ask in the software forums about which software will do it or one of the other.

Forum link is http://club.cdfreaks.com

As for subcode info heres some info from the cdrfaq.org

There are eight subcode channels (P,Q,R,S,T,U,V,W). The exact method of encoding is discussed in section (2-43), but it's really only important to note the data is distributed uniformly across the entire CD, and each channel can hold a total of about 4MB.

The P subcode channel identifies the start of a track, but is usually ignored in favor of the Q channel.

The Q subcode channel includes useful information, which can be read and written on many recorders. The user data area contains three types of subcode-Q data: position information, media catalog number (MCN), and ISRC code. Other forms are found in the lead-in, and are used to enable multisession and describe the disc TOC (table of contents).

The position information is used by audio CD players to display the current time, and has track/index information. This can be controlled when doing Disc-At-Once recording.

The ISRC (International Standard Recording Code) is used by the recording industry. It states the country of origin, owner, year of issue, and serial number of tracks, and may be different for each track. It's optional; many CDs don't use this. The media catalog number is similar, but is constant per disc. Note these are different from the UPC codes.

See http://www.ee.washington.edu/conselec/CE/reports/Group.1/matt_page_individual/subcode.html for some details on P and Q.

The R-W subcode channels are used for text and graphics in certain applications, such as CD+G (CD w/graphics, supported by SegaCD among others). A new use has been devised by Philips, called ITTS. It enables properly equipped players to display text and graphics on Red Book audio discs. The most recent result of this technology is "CD-Text", which provides a way to embed disc and track data on a standard audio CD.

 

[ExCyber]

Im beginning to think that its not really the TOC that is preventing a CDR from booting.

I was also never really convinced this was the case; the main difficulty posed by the area being outside the TOC was in dumping the signature. I knew there are some ways around this (used in e.g. GD-ROM ripping among other pursuits), but I was never well-versed enough in the snags to suggest a particular procedure; the closest I got was using a Dreamcast with a taped lid switch and an overburned boot disc to try to dump it, but the CD library kept spewing errors back at me.

 

[Pinchy]

@quakester2k

Dude, dont frell this thread up like you did with the "sega cp..." over at clubcdfreaks. Dont post all that useless info. doesnt do anybody any good. and dont cross paste, just link it. kthnx

/endrant



Well I made some more discoveries. It seem that I suspected right. The contents of the TOC does NOT make a difference. I did make another test disc where I padded it out with some cooked up ring data sectors with the 0xa8 0x59 image data the same format was the modchip, (padded all the way to 80min). I watched the status/command sequence and it does fail on the first "seek" commands to this pre-ring area. And it doesnt have anything to do with the "type 4" q-mode subcode. That 2nd byte of the status has to just be non-zero for it to pass.


But the reason this "test cd" fails the seek commands is because of the 7-11 bytes in the status:

B6 44 9F 03 F4 35 09 00 08 08 00 21 00

that 00 byte after 09 seems to cause it to fail. If 09,00,08,08 are all changed to zero then it passes, or if that single zero byte is changed to 09 then it passes. It some sort of flag in the subcode I would imagine. Thats the thing that confuses me is that the format of this status data is NOT the same as the format that you see when seeking and reading in the "normal game data" area. In there the status is just the straight Q subcode accross the board presumably to let the saturn know information on the current sector being sent.


heres another example of failed seek:

02 03 FE 51 00 00 00 00 00 00 02 A9 00 <-seek command

B6 44 DC 03 FE 51 09 00 09 09 00 BD 00 <-cd response

The cd seeked and is at it but the '00' after the '09' killed it.


[edit]Actaully I did some more tests with a real saturn cd and got these as passed seek:

02 03 F4 35 00 00 00 00 00 00 02 CF 00

B6 44 E8 03 F4 35 09 00 09 09 00 D6 00

--

02 03 FE 51 00 00 00 00 00 00 02 A9 00

B6 44 E7 03 FE 51 09 00 09 09 00 B1 00

--

02 04 E2 BB 00 00 00 00 00 00 02 5A 00

B6 48 5A 04 E2 BB 0A 0A 09 09 00 E0 00

--

02 04 D4 D1 00 00 00 00 00 00 02 52 00

B6 48 5A 04 D4 D1 09 09 0A 0A 00 D8 00

--

So theres more to it than meets the eye, just have to see what exactly is in the area of the CD.

Note that the saturn does NOT care whats being transmitted on the sector data bus for these seek commands. Its the confirmation in the status that counts.

[/end edit]


Apparently theres a 'subcode engine' in the cd mcu that extracts subcode from the sector data thats about to be sent and compiles it on the status line. I can actaully sync the the sync header in the fpga and mask whatever bits in a sector that I want. I managed to mask all the subcode in

the outgoing sectors and the game will run fine, so the sector decoder in the saturn cant handle the subcode afaict.


I did manage to make what I call a partially bootable CD. Since I had the ring data on the disc I just patched the seek commands and it would boot. It takes a lot of work out of the modchip since you dont have to inject sector data.


So the problem now is what exactly is the deal with this 'pre-ring' data it should be around 57-67 minutes. I dont even remember trying to read this area. There has to be something different about. It possible that its just plain lead-out data and this is what give the correct bytes in the status, since after all this data that it is reading that makes it fail is actaully mode2 sectors that I cooked up.


I did finally take the time to read the sega cd patents and pretty confirmed what I suspected about the logo being drawn with sector data. It tell you just as plain as day how its done. I cant believe people are still arguing about what all is in security ring, like special holograms and such.

 

[ExCyber]

So the problem now is what exactly is the deal with this 'pre-ring' data it should be around 57-67 minutes. I dont even remember trying to read this area. There has to be something different about. It possible that its just plain lead-out data and this is what give the correct bytes in the status, since after all this data that it is reading that makes it fail is actaully mode2 sectors that I cooked up.

Yeah, my understanding is that lead-out is done with so-called "Mode 0" sectors, but I'm not sure what the exact layout rules are for these; it might be in ECMA-130 though. I think the reverse of your problem may have been happening when I tried to probe around with the Dreamcast (i.e. it expected "normal" subcodes and got "Mode 0" ones).

I did finally take the time to read the sega cd patents and pretty confirmed what I suspected about the logo being drawn with sector data. It tell you just as plain as day how its done. I cant believe people are still arguing about what all is in security ring, like special holograms and such.

But it is holographic! And PSX protection is in the disc color, and the Gamecube protection is that it spins the discs backwards!

 

[Quakester2000]

But it is holographic! And PSX protection is in the disc color, and the Gamecube protection is that it spins the discs backwards!

Anywas as for reading the Outer track on the sega saturn it can be done with some drives, with cdrwin you can specifiy sectors from say 270000 - 300000 and it will try to read them back and data will get dumped. But some drives will not let you do this i have been able to do this with my BenQ and so have other people. Reading past what the TOC specifies can only be done with certain drives. So the data can be read back no problems its just writing it back.

 

[dibz]

Quakester2000, ExCyber was being sarcastic. The protection has absolutely nothing to do with the disc color -- it was a joke.

 

[Pinchy]

@quakester2k

There you go again dude. dibz pointed it out allready but cyber makes a joke, you go and post some d@mn LIES and link to some misinformation. Then to top it all off you start talking about dumping data in the security area that has allready been discussed to no end on this forum and cdfreaks. (for those reading this, all you do is just take any old cd drive apart and do your bog standard swap trick). So stop being a kook i say!

--------------------------------------------


Well I figured out what was causing my modchip to take so long to authenticate and sometimes fail. I failed to calculate the parity correctly in my 'fake' status data. Seems for loops can still get the best of me. Its funny in the fact that despite me leaving out 1 byte in the parity calculation that it would still pass after the saturn requesting a different LBA over and over that it would eventually land on the right value so that the parity would happen to work out anyway.


Ill have to admit now this thing is absolutely rock solid! CD boots up every time and immediately unlike before.


Ive updated ,cleaned up a little, and commented on the source code in the zip files if anyone wants to have a looksee:

main project page:

http://www.crazynation.org/SEGA/Saturn/cd_tech.htm

http://www.crazynation.org/SEGA/Saturn/files/

MODCHIP.ZIP

the firmware file modchip.c contains the brunt of the calculation work and status data generator.


cd_emu.vhdl is the fpga code that watches the cd commands like a hawk and lets the fx2 sniff in on the action and jump in when need be.


Also put the sega cd patent there with eye friendly gif's

SEGA_CD_PATENT.ZIP for those interested.


Theres some schematics cd_emu.pdf that is how im setup but you really dont need to all that. I dont think you can fit it on any cpld. You could redesign it so that you just have a couple of fifos instead and let the mcu handle all the data pushing which is what I think the commercial mods do, but you would have to write a lot more code and it would probably be really time critical.


The way im setup now is that I still have to leave the fx2 connected to USB and if I power up I have to connect with the "saturn_fx2_tool" that just loads the firmware since the fx2 is ram based. You could hook a eeprom up to it, but maybe later Ill try to use a PIC instead.



After battling that parity bug, it forced me to learn more nuances of the cd interface like where the sector is in relation to the command/status transaction(transact). The "sync header" occurs about 1000us after the last byte of the transact or 3600us after the start of it. transacts are spaced about 6600us apart when the disc is active.


When the saturn requests a certain LBA the cd will start reading at LBA-4 and continue until its told to stop. But all of this is really not hard rules as such. It appears you can start your sector data anywhere in relation to the transact. I have mine set to the last byte of the transact. And if you start reading at too high a LBA then the saturn will after a few sectors issue another request at one less LBA until it gets the data it wants.


So to reiterate the method of tricking the saturn is this:

saturn requests a read 0x02 to the pre-ring area (which im pretty sure is just plain LEAD-out) which is usually a MSF of 56-66 MIN but of course the request will be in LBA and you provide the response in a non standard status response which is :

status[0]=0xB6;

status[1]=0x44;

status[2]=0xF1;

status[3]=LBA high;

status[4]=LBA mid;

status[5]=LBA low;

status[6]=9;

status[7]=9;

status[8]=9;

status[9]=9;

status[10]=0;


You also have to make sure you patch the parity byte before the parity byte of the transac is sent or else the cd is going to seek out there and make problems.


The saturn will usually issue a couple of more random

seek commands then it issues some reads 0x06

you give the 'normal style' status data like:

status[0]=0x36;

status[1]=0x01;

status[2]=0xAA;

status[3]=0x01;

status[4]=MIN;

status[5]=SEC;

status[6]=FRM;

status[7]=4;

status[8]=MIN

status[9]=SEC;

status[10]=FRM;


You also need to update the sector data your sending with the correct MSF as well.

bytes 1-7 arent even required afaict for actaul passing.

the 'correct' format of the bytes, if you havent seen it before, its mentioned in ecma130. It just the Q subcode of the sector. the 0xAA represents a lead out track. the first MSF is actaully the MSF relative to the start of that track, so you will see on a real saturn numbers like 11 mins and for the last MSF which is absolute you will see like 72Mins etc etc. SO the saturn want to see absolute MSF times.


Im still puzzled by the format of the status data when it seeks to this lead out area. Its unlike any other. It responds with LBA which is required and some other bits that dont seem to make sense. you can change most to zero and have it work but then you start playing with the bytes it will refuse the seek response with no apparent pattern to the bytes.

 

[ExCyber]

I have some idea as to how the commercial chips might work, but I found I couldn't describe it very clearly, which means I'm probably not thinking about it clearly. To make matters worse, it seems that none of the HQ modchip pics are around anymore, so I don't have much to sanity-check against.

 

[Quakester2000]

Have you had any developments recently.

 

[Drenholm]

I'll have to try this swap trick with my old drive.

I'm guessing that we're now at a point where reading the data is no major mystery or challenge, but making use of it is the real trouble? From my very brief skim over this topic, I gather that the subchannels, and maybe even an area before the graphic, could also play a part - which could prove more difficult to read.

This is assuming that, as I say, reading the main data is easy enough; have good matching comparisons been made between rips from different users and discs? I seem to recall Kortex saying a while back that he read consistent data from several titles.

I'd also appreciate any further information or expertise on this. I remain forever interested in this subject and hope that further breakthroughs occur! =)

 

[rHessmann]

Hi guys, sorry to bump this.

I'd really like to build this, very interesting project.
But unfortunately, crazynation went offline, and so went the firmware code.

Anyone managed to hold a copy on disk?

 

[antime]

There you go.

 

[timofonic]

Hello.

MODCHIP.ZIP lacks schematics and many other interesting information. Fortunately, I found most content is mirrored here.

https://web.archive.org/web/20111012135550/http://www.crazynation.org/SEGA/

I hope to be able to decipher this and make a schematic+PCB in KiCad someday.

Are there new DIY electronics Sega Saturn developments?

 

[ArcTuba]

Hello.

MODCHIP.ZIP lacks schematics and many other interesting information. Fortunately, I found most content is mirrored here.

https://web.archive.org/web/20111012135550/http://www.crazynation.org/SEGA/

I hope to be able to decipher this and make a schematic+PCB in KiCad someday.

Are there new DIY electronics Sega Saturn developments?

It might be cheaper to buy a board from eBay with a Spartan/FX chip setup instead of designing a custom PCB. You can always change the pinout in the VHDL to match since a pin assignment file isn't provided anyway. It might involve more troubleshooting, but should save you in the long run. I think I may try a board with a Spartan6 if I ever have the time and money.

...although a custom circuit board would be very helpful for the connectors and inverter chip. As well as to keep it as small as possible.