Looking for someone knowledgeable in Saturn hardware for an overclocking project

[Epicenter713]

I am currently working on a procedure to overclock the Sega Saturn for improved performance in intensive games. While I've got a procedure mostly hammered out, I would like to get the opinions/some insights from some persons who are intimately familiar with the workings of some aspects of the hardware. Any help would be greatly appreciated; please reply here or contact me via email (epicenter713@gmail.com) or AIM (Epicenter713).

Thanks for your time!

 

[Runik]

Although the idea is interesting, I doubt that it can be done ... There is a bunch of processors to overclock, and the saturn is really picky about synchronisation ...

 

[Epicenter713]

No one will ever know unless I try, it seems. Lots of people said the MD and NES couldn't be overclocked even with proof staring them in the face.

 

[Runik]

MD and NES are nowhere near the Saturn regarding the number of processors ... and like I already stated, the Saturn is really picky about synchronisation, trust me

But if you still want to try, good luck, you'll need it

 

[Epicenter713]

I'd like to know in what ways it is 'picky'. Exact components that need synchronization and of what sort. Timings? Clockrates? I would call the Saturn 'impossible' if I hadn't analyzed the PCB and determined that those numerous processors are all on separate buses and communicate with each other differently-- they don't all operate in harmony with each other so to speak. A lot of them only communicate in very specific ways over a very limited number of paths. Like the 68000, Yamaha DSP in the audio subsystem and SH-1 in the CDROM subsystem. The components that seem to be the tightest-knit are the SH-2s, SCU and VDP1/2.

 

[Runik]

Don't forget about the SMPC, it has a central role. The SCU also has a built in DSP, and the sound system also use a SCSP processor.

While trying to emulate this console, I ran into unexpected problems like the SMPC not triggering some interrupts due to a timing problem. Sometimes it was the SCSP which prevented some VDP1 sprites to be displayed.

I'm not saying that overclocking the Saturn isn't possible, just that it's a really massive task.

Good luck

 

[antime]

I'd say the SCU is the critical component as it has to interface all the buses. There's other non-obvious connections that have the possibility to be troublesome, eg. VDP2 reads the VDP1 front buffer and the CD block can talk directly to the SCSP.

Forgot to add that the video output is also tied to the system clock. When you change the horizontal resolution you do it by asking the SMPC to change the system clock frequency.

 

[Epicenter713]

Forgot to add that the video output is also tied to the system clock. When you change the horizontal resolution you do it by asking the SMPC to change the system clock frequency.

The way I see it, it's making small alterations to the system clock based on the ~14.3 MHz reference crystal, which would normally change the clock to near everything-- SH-2s, SCU, VDPs. My intention is to keep the VDPs connected to their ordinary clock path back to the system clock, so they'd be unaware that other components might be using something else entirely. That's my theory anyway-- I'd love to hear what you think of it.

I really wish someone had an idea of where those clock lines to the SCU and VDPs were though, since it'll take a lot of poking about to find them myself. Always nice to save time...