Saturn Boot Process

[Mask of Destiny]

I took a look at the disc standards doc and I have a few questions.

From what I gather, the AIP is only executed after the security ring check, is this correct? What address does this get loaded to?

What exactly is the 1st read file? I understand that it gets loaded while the Saturn logo is doing it's thing, but how is this file identified, I didn't see an entry in IP.BIN for it?

 

[antime]

The IP is loaded to 0x6002000, so the address of the AIP is 0x6002000 + sizeof(boot code). The exact address depends on how many area codes you have. The first read file is the first file listed in the root directory of the filesystem.

 

[RockinB]

Hey MOD,

just want to say that it's great that you got yourself a Saturn and try something out.

A new coder cable or something to upload test binaries is a very good idea. The method with the CommsLink and Action Replay requires a lot of hardware, the Saturn cartridge slot is rapidly dying and modern PCs don't have any ISA slot....

So there is really much use for your idea. You could use the serial port on the back or the controller port.

Good luck! :cheers

 

[Mask of Destiny]

I'd imagine the serial port is +5V and not a 12V port like on a PC so I'd need to use one of the MAX converter chips. Controller port is simpler and probably faster too. Using my crappy protocol with the Sega CD I was able to get ISDN speeds, I'd imagine between the new protocol I want to use and the speed of the SH-2 I can increase the speed by quite a bit. Only disadvantage is that it's more processor intensive than the serial solution so it may be less ideal for streaming data after the initial load. There isn't any way to get custom code running on the SMPC is there?

I think I'm going to dig around in the Saturn boot ROM a bit and see if there are any exploitable bugs that would allow me to run code before the ring check. The transfer program is quite small, so I should have no problems fitting it within the first 16 sectors.

 

[cgfm2]

Originally posted by Mask of Destiny@Mon, 2005-08-15 @ 07:49 AM

I'd imagine the serial port is +5V and not a 12V port like on a PC so I'd need to use one of the MAX converter chips.

Correct. On the serial connector you get the SCI pins for both SH-2's and a MIDI serial channel used by the SCSP (that you can directly program using the 68000).

There is/was a Japanese website that had unofficial schematics for the Saturn which were mostly complete. I think the author's nickname was 'babax' if that helps with a Google search. If you need this stuff and the site isn't around anymore I believe I saved all the images at one time.

Controller port is simpler and probably faster too. Using my crappy protocol with the Sega CD I was able to get ISDN speeds, I'd imagine between the new protocol I want to use and the speed of the SH-2 I can increase the speed by quite a bit. Only disadvantage is that it's more processor intensive than the serial solution so it may be less ideal for streaming data after the initial load. There isn't any way to get custom code running on the SMPC is there?

Did you use a serial connection for the Genesis? If so, isn't that limited to 4800bps by hardare (or was this a software driven protocol instead of using the built-in serial hardware?)

The SMPC is a mask programmed microcontroller, so there's no way to change the code.

I think I'm going to dig around in the Saturn boot ROM a bit and see if there are any exploitable bugs that would allow me to run code before the ring check. The transfer program is quite small, so I should have no problems fitting it within the first 16 sectors.

Unless I'm wrong, you'd still need a modchip (or swap trick) for the Saturn to even read anything off the disc and go through the boot process. Then again this is not my area of expertise.

 

[Mask of Destiny]

Originally posted by cgfm2+Mon, 2005-08-15 @ 08:07 PM--><div class='quotetop'>QUOTE(cgfm2 @ Mon, 2005-08-15 @ 08:07 PM)</div><div class='quotemain'>Did you use a serial connection for the Genesis? If so, isn't that limited to 4800bps by hardare (or was this a software driven protocol instead of using the built-in serial hardware?)[/b]

It's a 4 bit parallel protocol with 2 bits for handshaking. I think I gave you source for it a while back. After I got it working I realized that my handshaking was quite innefficient so if I should be able to get a decent speedup with a rewrite. It needs it anyway to fix some initial sync issues.

Originally posted by cgfm2@

The SMPC is a mask programmed microcontroller, so there's no way to change the code.

Figured as much. Oh well.

<!--QuoteBegin-cgfm2

Unless I'm wrong, you'd still need a modchip (or swap trick) for the Saturn to even read anything off the disc and go through the boot process. Then again this is not my area of expertise.

[/quote]

From what I've gathered, the first 16 sectors are accessible before the security ring check. The software in the boot ROM loads the IP.BIN from these sectors and checks it for validity before doing the security ring authorization. So if I can find an exploitable bug in that initial code, I can at least get small programs running. My transfer software is quite small and would fit easily in the first 16 sectors giving me access to a lot more data off of the attached PC.

It's not a good solution for an end-product (apart from little demos anyway), but it will speed up development.

 

[CyberWarriorX]

From what I've gathered, the first 16 sectors are accessible before the security ring check.

Yes they certainly are. All other sectors are inaccessible until a disc is authenticated, no matter what you do. The thing to note here is that all you need is "a disc". It can even be an audio cd if you so choose. An interesting thing I learned about the cd block is that the only time the ring is ever checked is if a saturn disc(original or not) is in. Regular data, audio, and mixed mode discs automatically pass authentication(the cd block will also return a value depending on what kind of disc is detected). One has to wonder what the cd block checks so that it's able to tell the difference between a regular data disc and a saturn disc.

The software in the boot ROM loads the IP.BIN from these sectors and checks it for validity before doing the security ring authorization. So if I can find an exploitable bug in that initial code, I can at least get small programs running. My transfer software is quite small and would fit easily in the first 16 sectors giving me access to a lot more data off of the attached PC.

I already checked the ip checking code myself for any exploitable flaws, and I certainly didn't see any(kudos to sega on that one). That being said, anything mapped to 0x22000000 can get away with just a simple ip check(that's the exploit the AR carts use).

Cyber Warrior X

 

[Mask of Destiny]

Originally posted by CyberWarriorX@Tue, 2005-08-16 @ 01:02 AM

The thing to note here is that all you need is "a disc". It can even be an audio cd if you so choose. An interesting thing I learned about the cd block is that the only time the ring is ever checked is if a saturn disc(original or not) is in. Regular data, audio, and mixed mode discs automatically pass authentication(the cd block will also return a value depending on what kind of disc is detected).

Interesting.

One has to wonder what the cd block checks so that it's able to tell the difference between a regular data disc and a saturn disc.

My guess would be it checks for "SEGA SEGASATURN" at the beginning of the first sector. Should be easy enough to test if you have a PAR.

I already checked the ip checking code myself for any exploitable flaws, and I certainly didn't see any(kudos to sega on that one). That being said, anything mapped to 0x22000000 can get away with just a simple ip check(that's the exploit the AR carts use).

I might take a whack at it anyway, I need to brush up on my SuperH assembly. However, since you've taken a look at it, do you mind revealing the approximate offset where the code lives in ROM? Also, do you know if the security and area codes are checked by a byte by byte comparison or some sort of checksum (this wouldn't seem to be particularly helpful for the task at hand, but I would like to be able to eliminate as much Sega IP from any homebrew I do as possible)?

 

[CyberWarriorX]

I might take a whack at it anyway, I need to brush up on my SuperH assembly. However, since you've taken a look at it, do you mind revealing the approximate offset where the code lives in ROM? Also, do you know if the security and area codes are checked by a byte by byte comparison or some sort of checksum (this wouldn't seem to be particularly helpful for the task at hand, but I would like to be able to eliminate as much Sega IP from any homebrew I do as possible)?

It was about 0x00001A4A on the rom I used. The comparisons were more along the lines of a long-word by long-word check, but yeah, it certainly makes sure it matches.

Cyber Warrior X