Emulate A Sega Saturn


rohezal

Advanced Member
Joined
Oct 18, 2009
Messages
1,712
Hi guys I have read that the sega saturn can't be emulated. My question is why? The Saturn was (at least wikipedia says so) weaker then PS 1 (25 against 30 MIPS, 1 instead of 2 MB RAM, 512 KB instead 1024 KB Video RAM). Is it because the Saturn had 2 CPUs? I'm just asking out of courisity (and because the forum search results on the first site were about Grandia 2 and Controllers^^).
 
It's prolly just that.. less documentation.
Sega Saturn I believe was notoriously a pain to program for, and is overly complex.

EDIT: Nights would be nice tho. :p


OO, and Panzer dragoon!
 
WTF this thing has 2xGPU and 2 CPUs and everything had it own ram... emulate that is much work. Optimise that is very very very hard work. Rofl, the Saturn guys had the best copy protection. Build a fukcing complex system that is hard to emulate^^

* Two Hitachi SuperH-2 7604 32-bit RISC processors at 28.63 MHz (25 MIPS)—each has 4 kB on-chip cache, of which 2 kB can alternatively be used as directly addressable Scratchpad RAM
* SH-1 32-bit RISC processor (controlling the CD-ROM)
* Custom VDP 1 32-bit video display processor (running at 7.1590 MHz on NTSC Systems, 6.7116 MHz for PAL Systems)
* Custom VDP 2 32-bit video display processor (running at 7.1590 MHz on NTSC Systems, 6.7116 MHz for PAL Systems)
* Custom System Control Unit (SCU) with DSP for geometry processing and DMA controller (running at 14.3 MHz)
* Motorola 68EC000 sound controller (running at 11.3 MHz / 1.5 MIPS)
* Yamaha FH1 DSP sound processor, "Saturn Custom Sound Processor" (SCSP), running at 22.6 MHz
* Hitachi 4-bit MCU, "System Manager & Peripheral Control" (SMPC)

Memory

* 1 MB SDRAM as work RAM for both SH-2 CPUs (faster)
* 1 MB DRAM as work RAM for both SH-2 CPUs (slower)
* 512K VDP1 SDRAM for 3D graphics (Texture data for polygon/sprites and drawing command lists)
* 2x 256K VDP1 SDRAM for 3D graphcis (Two framebuffers for double-buffered polygon/sprite rendering)
* 512K VDP2 SDRAM for 2D graphics (Texture data for the background layers and display lists)
* 4 KB VDP2 SRAM for color palette data and rotation coefficient data (local, on-chip SRAM)
* 512 KB DRAM for sound. (Multiplexed as sound CPU work RAM, SCSP DSP RAM, and SCSP wavetable RAM)
* 512 KB DRAM as work RAM for the CD-ROM subsystem's SH-1 CPU
* 32 KB SRAM with battery back-up for data retention.
* 512 KB Mask ROM for the SH-2 BIOS
 
rabidpoobear said:
In before "Confirmed: Exophase is working on a Saturn emulator"

I'm not working on a Saturn emulator, but I have vague empirical reasons to believe that it could be realistic on at least substantially weaker hardware than current Saturn emulators require. The big mystery to me is exactly why SSF has the requirements it does despite using recompilers, but without source availability that's not something I can look into.

Yabause got both SH2 and 68k recompilers for the PSP port some months ago. I always wondered how they performed, and if work was being done towards getting recompilers for other platforms. Unfortunately, I've never heard of anyone successfully running anything with it. Whether that's due to the recompilers not being mature enough or due to the inability of anyone to properly compile it (I don't think a corresponding PSP binary was every distributed) is unknown to me. But at least someone who's skilled enough to write a recompiler - and a pretty good looking one from what I've seen of the source code - thinks that it's worth doing for a target as weak as PSP. Take from that what you will.

(by the way, none of the Yabause stuff I just mentioned is my empirical evidence... I'm not at liberty to reveal that part)
 
Last edited by a moderator:
Exophase: The Pandora is all about Open Source!
Share your "empirical evidence" be OPEN SOURCE! ;) :lol:
 
Well the pandora can at 800-900 MHZ at max and have 256 MB RAM (how big is the bus? 32 Bit, 64Bit or 128 Bit? Single or dual channel?), right? The SFF uses SSE2 (128 Bit processing unit that handle 4x32bit or 2x64 in one step) for optimisation maybe we can the same with the NEON (its a 128bit unit for the same reason if wikipedia do not misinformed me^^).

The SSF needs 256 MB Singel Channel Ram (recommended: 2x256 MB dualchannel) and a SSE2 CPU (Pentium 4 recommended). Don't know hard it needs the pentium 4 for its MHZ (like 2000 mhz) but the pentium 3 (600 - 1x00 MHZ) has only SSE 1 which is quite slower (128bit internal split to 2x64bit passed to normal units. So 2 cycles (or units) for 2x64Bit).

I think were at the lower edge but a guy had ran the emulator (or was it something similar called like "satourly") with a 1533 AMD CPU (AMD XP 1800+) and 256 MB RAM had written a guide to tweak it to run quite normal (with some moderate worse graphic). And the AMD 1800+ doesn't even support SSE2 (it supports only SSE1)(http://en.wikipedia.org/wiki/List_of_AMD_Athlon_XP_microprocessors). I just lost the link...

I think a very skilled coder with lots of low level knowledge and very good near hardware skills can do it with lots of time...
 
rohezal said:
Well the pandora can at 800-900 MHZ at max and have 256 MB RAM (how big is the bus? 32 Bit, 64Bit or 128 Bit? Single or dual channel?), right?

166MHz DDR, 32bit, single channel. This delivers a theoretical maximum of ~1333MB/sec bandwidth. Tests on OMAP3530 have shown that it's difficult to achieve even more than half of that, but I think that these tests were reading from and writing to areas that were L2 cachable, where the L2 cache miss penalty impacts the maximum memory bandwidth by adding over a dozen cycles per L2 cacheline. So it might be possible to get better performance by partitioning the address space into non-cached areas.

Now, what any of that has to do with Saturn emulation is another story, but it could be useful for optimizing bandwidth for emulators in general, for certain tasks that overwhelm the L2 cache like streaming data and large render areas.

rohezal said:
The SFF uses SSE2 (128 Bit processing unit that handle 4x32bit or 2x64 in one step) for optimisation maybe we can the same with the NEON (its a 128bit unit for the same reason if wikipedia do not misinformed me^^).

SSF probably uses SSE2 for integer purposes since Saturn has no floating point, of course I could be wrong. NEON does have that as well.

I think using SSF's requirements as a model is just too ambiguous. We don't know what its relative efficiency is, or if it suffers from any major bottlenecks.
 
Last edited by a moderator:
rohezal said:
Asked about single channel but exo edited faster^^

Yeah, I update the post since then and sneaked that in there too. As a rule of thumb you shouldn't respond to me until several minutes after I post because I'm too damn scatterbrained to get a post right the first time through ;D
 
Last edited by a moderator:
Anyhow... With you "secret" knowledge, does it seem like there is any chance of a Sega Saturn emu ever happening.
 
kingoddball said:
Anyhow... With you "secret" knowledge, does it seem like there is any chance of a Sega Saturn emu ever happening.

I said all there is I have to say.
 
Last edited by a moderator:
Kloplop321 said:
Saturn doesn't take much... The dreamcast is another story though.

I think you got that the wrong way around.

Dreamcast is generally believed to be easier to emulate than Saturn. It may be more powerful but it's a lot less complex in design.

Saturn Emulation would be awesome. NiGTHS, Daytona CCE and Sega Rally all on the move? Yes please!
 
Last edited by a moderator:
Exophase said:
rabidpoobear said:
In before "Confirmed: Exophase is working on a Saturn emulator"

I'm not working on a Saturn emulator, but I have vague empirical reasons to believe that it could be realistic on at least substantially weaker hardware than current Saturn emulators require. The big mystery to me is exactly why SSF has the requirements it does despite using recompilers, but without source availability that's not something I can look into.

SSF uses software rendering. That might be the reason for the high CPU requirements ;) The plus side (or negative side, depending on which way you look at it) is it looks extremely accurate.
 
Last edited by a moderator:
Back
Top