Saturn CD Block ROM dumped

My vote would definitely be for USB host so that we can use hard drives. People can buy an externally powered HDD if need be.

 

I'm a fan of stealth mods so if push came to shove my preference is for SD over hard drives, ideally it would support both. 32GB is a ton of games.

 

Congrats jhl on the dump! If you need any info or help trying to make sense of any of the code let me know. There's also some basic info on the Yabause wiki too.

 

This.

 

Especially since this is a better solution than the one the Chinese guys seem to be using. Since they were booting from the cart slot, they would have to use software hooks to intercept the CD drive commands - and might not have been able to implement CD-Audio at all.

In theory, this method should be able to simulate everything perfectly, since it's sitting behind the (presumed immutable) interface that the Saturn uses to talk to the CD. Of course, it will take up the slot for the MPEG card, but you could always simulate that too, if you had the patience...

 

Without an external power adapter there's not really anywhere to get those extra 2A from - you'd be overloading the Saturn PSU by 100% if you went internal.

The other major downfall of USB host mode is software maintainability. In my experience, USB Mass Storage stacks have to take account of a huge variety of dodgy implementations on devices. Just look at the Linux UMS subsystem. I'd really rather my limited time be spent on accurate emulation and useful features than in just getting a finicky drive to talk to the board.

If the design includes a PC-driven mode (which I currently intend to do), then you can tuck a Linux SBC and externally powered drive under your Saturn -- or even rip out the CD drive and put in HD + SBC + PSU internally (which would be my preferred method). I'm aiming to place the USB connector so that the cable can be routed internally.

 

Just out of curiosity, did you find anything in the SH-1 code that sheds any light on how the system disc works?

 

x

 

Absolutely. Disc authentication lives in Task 7 in the multitasking system, which is shared with the ISO filesystem access code. It's a spaghetti monster.


System discs are defined simply by finding SEGASYSTEM at the appropriate place in the disc header. The disc author is stored for later comparison, so a system disc that has SEGA TP will only work with SEGA TP discs, for example. The disc must be authenticated for the mechanism to enable the bypass. Everything else on the system disc is only there to show the message on the screen!
Interestingly, there is also provision for a 'super system disc', which also bypasses the author check. A super system disc has to have exactly 30 tracks, and some weird subcode stuff in the TOC region. This was presumably to make sure nobody could burn them on a dev CDR (since you'd need to burn them in raw96 DAO mode, which was not well supported at the time). They need to be authenticated just like a regular disc.

The code also confirms that both scrambled ring data (the logo) and the track wobble data from the CD mechanism are used for authentication. It's interesting that the crappy modchip data passes the check, the code looks relatively complex. Evidently it's not as secure as the designers thought it was.

As an amusing aside, there's also a provision to load (encrypted) SH-1 code from an authenticated Saturn disc. Presumably this was for bugfixes via CDR during development. If my notes are correct, then at 0xF8 and 0xFC in the header are two dwords holding the FAD and the length in bytes of such a region, active if nonzero. I'd be interested to see if any such discs have been spotted in the wild, and what they were used for.

 

Also, there's no way (at least no designed way) to inject SH-1 code from the SH-2.

CDB MPEG commands (90-AF) are forwarded to code loaded from the card, except for 93 (init MPEG), AE (get LSI), AF (set LSI).

The only commands present in CDB105 but not documented on the Yabause wiki are:

FF - get some debug statistics (on the DRAM sector pool, as I recall)
55, 56 - calls into Task 4 (the selector handling task)

 

That was exactly the conclusion I came to when I disassembled it - the code on the disc didn't actually do anything and it had to be internal to the CD controller. Nice to know the real deal now

 

Very interesting! By the way, I noticed some time back you could also bypass the ring detection by removing the "SEGA SEGASATURN" string at the beginning of the disc and using a custom bootloader to load said custom disc. My theory always was that the ring check was only done based on that string. Which is why vcd's and audio cd's would work fine without the need of a ring check. Any thoughts?

By the way, do you have any additional info on the provision to load SH-1 code? Like encryption format, etc.? I'm kind of tempted to mess around with it From what I've seen I never saw any games or discs meant for public consumption using those two offsets. It may have been used internally though. Kind of like the ability to run code from the cartridge, which I also think was never intended to be used outside of dev, system check carts, etc.

Sounds about right. It was designed to be a closed system after all. Though I always wondered if there was possibly a hidden way by manipulating the selectors and buffer connections. But it was pretty much a crap shoot with so little info and the SH-1 code not being accessible. I remember noticing 55, 56, and FF sometime back but I wasn't sure if they were mirrored commands or what. IIRC 0xFF by itself normally returns 0xFF in the CR registers.

By the way, what exactly do the the set/get LSI commands do? I could never find much info on them.

 

Correct. The disc must begin with a Mode1 sector starting with SEGA SEGASATURN. It also looks in the last session on a multisession disc (so '90s!)

They're for talking directly to one or both of the MPEG ASICs selected on MVCS/MACS; they each have a little register space mapped in there.

 

Wow. That's a beautiful hack.

 

hehe. Yeah, I'm somewhat surprised they left multisession support in the CD block at all. The bios won't even allow multi-session games to boot.

Ah ok. I figured get/set lsi had some function like that, but I wasn't sure what kind of registers or data was being accessed.

 

I've got a rev 0.5 Japanese model, so I'm pretty sure I'd have a CDB104. As for the CDB106, no idea, but I've got a mix of model 1 and 2 systems from the US, Europe, and Japan, maybe one of them has it.

 

x

 

Aren't these the last info we needed before Being able to selfboot a disc?

I'm not a tech guy bit it sounded like that.