What About Saturn Emulation?

[CyruzDraxs]

I don't really expect anything either...but my offer still stands. I hope someday I'll be able to play my Saturn games without having to have access to a TV.

What's wrong with SSF? Or did you mean on something portable? Take it laptops don't count?

A laptop is okay, but it just doesn't quite feel right without proper gaming controls.

 

[Dio]

The 68k on Jaguar steals massive main bus cycles if you have it do anything but halt out entirely. It's dead weight.

Surely if the RISC processors are running from their scratchpad SRAM there will be main memory bandwidth to spare? (Although the RISC processors will obviously have to use some bandwidth to produce useful output.)
Right, but from the point of view of emulation, the 68K still has to be emulated. Although you can detect more simple idle loops like a tst / bxx, there aren't many games that actually do the correct thing and STOP and halt the CPU.

As to the actual horsepower - the RISC don't hit the external bus an awful lot from what I can see, but the OP and the Blitter certainly do. The OP is a massive bandwidth hog. But if you've got an OP-heavy game the rest of the chips might well be idle-ish anyway. It also seems unclear to me as to whether 68K cycles that only hit the ROM need to be vectored via the MMU.

I disagree - I think the SH2s on Saturn are a lot better because they don't have the kind of register/pipeline stalls that the JRISCs do. Even Atari claims that you'll only get 75% efficiency from well optimized code.

Is this the register scoreboarding bug you're talking about, or something else?
The various Jaguar bugs don't add much load (except the store bug on the DSP), they just make programming more complicated. 75% is a reasonable estimate for the best possible IPS you'll get on reasonable code. Currently in the emulator I start at 2 cycles / instruction and add various other stalls on (emulating the scoreboard would be too much baggage).

I'd generally doubt if anything of SH2 vintage - that doesn't have triport RAM like a 56001, for example - regularly achieves that much better than 0.5 IPC on real code. But SH2 is one I've not had to fiddle with to this point so I could be completely wrong.

(edit) I looked up the SH2 and it has plenty of pipelining contention as well. It looks to be less severe than the Jag, from how I read it - there doesn't appear to be a pipeline stall on ALU results reused in the next instruction. But the SH2 docs are quite clear that "To write efficient programs, it is essential to avoid contention, keep instruction execution speed up, and use instructions with fewer stages." So I reckon for emulation grunt required for an SH2 vs. a Jag RISC, you'll be talking tens of % more horsepower required, not 2X or more.

But the Saturn has a minimum of five things you'd describe as a CPU. I'd say overall, the Saturn would need around twice the cycles of a Jaguar, and it would be a hellishly complex beast.

As far as cache is concerned

Visible vs. transparent caching is more about faff than performance. There's no fundamental reason either should be faster than the other, but transparent cache is a metric shedload easier to use.

The Jaguar's second JRISC (DSP with 8KB of scratchpad) is brought up a lot as a good source of power, but the way I see it, if you want audio that greatly surpasses NES level then you're going to have to spend a good amount of space on mixer code and possibly samples (although loading them from main memory probably won't hurt that much).

I don't think this is the case. In a RISC optimised for DSP, mixing is truly trivial. The T2K mod player, for example, uses about 20% of the cycles of the DSP, and is hardly a bus or memory hog (four byte reads per loop at 15kHz, ~200K for the mods). The Atari softsynth (which does the music for the BIOS and Alien vs. Predator, amongst others) is done using the DSP's wavetable ROMs rather than loading samples from main memory. I'm not sure if it has main memory wavetables as a backup, but I know pretty much all the ROM tables are used by AvP. The NES level comment is clearly overegging the pudding - it would be very easy to emulate a Megadrive-level FM synth, for example, but with the wavetable ROMs it can do a lot more than that. I wouldn't want to run per-operator resonant filters on it mind.

But the great advantage of all pure-software synths is that you can do what you want; mods, wavetable, FM, additive, whatever. Or a bit of everything, use hybrid approaches for each instrument. Or, like in the case of Doom, use it for something else. Dedicated hardware was unnecessary as soon as cheap DSPs became viable for consoles.

 

[Zor Prime]

No one has been arguing that anything shouldn't be emulated (except Zor Prime, but that was pretty summarily dismissed).

That is not true. I did not say Saturn shouldn't be emulated. More emulation on more forms of hardware, the better.

 

[Exophase]

Visible vs. transparent caching is more about faff than performance. There's no fundamental reason either should be faster than the other, but transparent cache is a metric shedload easier to use.

That just isn't true. Think about the equivalent work necessarily to load from memory to scratchpad manually - you have to load from memory into a register and then store that register into memory. You probably won't get burst bonuses doing this, and there will probably be additional stalls involved due to contention with fetching/decoding the load/store opcodes. And caches can keep track of things that are otherwise impossible to determine statically such as cleanliness and time of use, which would be too expensive to keep track of explicitly.

Caches are much more expensive to implement than similarly sized scratchpad RAMs, so I think if it were just a matter of convenience we'd be seeing more bare metal DSPs without it.

I don't think this is the case. In a RISC optimised for DSP, mixing is truly trivial. The T2K mod player, for example, uses about 20% of the cycles of the DSP, and is hardly a bus or memory hog (four byte reads per loop at 15kHz, ~200K for the mods). The Atari softsynth (which does the music for the BIOS and Alien vs. Predator, amongst others) is done using the DSP's wavetable ROMs rather than loading samples from main memory. I'm not sure if it has main memory wavetables as a backup, but I know pretty much all the ROM tables are used by AvP. The NES level comment is clearly overegging the pudding - it would be very easy to emulate a Megadrive-level FM synth, for example, but with the wavetable ROMs it can do a lot more than that. I wouldn't want to run per-operator resonant filters on it mind.

But the great advantage of all pure-software synths is that you can do what you want; mods, wavetable, FM, additive, whatever. Or a bit of everything, use hybrid approaches for each instrument. Or, like in the case of Doom, use it for something else. Dedicated hardware was unnecessary as soon as cheap DSPs became viable for consoles.

I'll grant you that 4 channel MOD at 15KHz is better than NES level, but it's also well below SNES level, never mind Saturn or PS1 level. Yes, you could emulate Genesis level FM synth, but it'd take every last CPU cycle and all of your RAM to actually be competitive. I know this because that's what it takes to emulate FM for the emulator jEnesisDS, which uses a 33MHz ARM7 (which is much better than the DSP in the Jaguar). I'm going to hazard a guess that games with low end mod players like T2K aren't using the DSP to do other things, and for good reason (aside from that it'd be a pain to do). You don't exactly have a wealth of space to do whatever you want. But the point I was trying to make was that if you want good audio in a Jaguar game you're not going to have a bunch of power left over to utilize the DSP for other things, and that is NOT the case with the Saturn. Also, certainly, you can use the ROM wavetables in games, but don't you think that'd get old pretty fast? Then again, a lot of the Jaguar games did have pretty similar sounding music...

I think history has proven otherwise regarding DSPs vs dedicated audio, or at least for many consoles that post-dated the Jaguar, with only N64 and GBA springing to mind as counter-examples (which were rectified with Gamecube and Nintendo DS respectively). Sure, you can do whatever you want, but the industry has basically concluded that wavetable synth trumps all in the end. That basically goes for soft synths as well. So does it really matter? Unfortunately, the result of that flexibility in Jaguar's DSP was a console that could vaguely compete with SNES and Genesis in the audio department, but that was about it. On Saturn you didn't have to waste one of the SH2's for audio (or the 68k, or even the audio DSP for that matter), and that was really where the bottom line went in computational power, because you could very easily do a game with excellent non-streaming music and have all of your CPU resources available.

 

[Dio]

Visible vs. transparent caching is more about faff than performance. There's no fundamental reason either should be faster than the other, but transparent cache is a metric shedload easier to use.
That just isn't true. Think about the equivalent work necessarily to load from memory to scratchpad manually - you have to load from memory into a register and then store that register into memory.
Unless you have a DMA engine to do it for you (in the Jaguar's case - the blitter). This can move memory at bus rates and with no overheads. It's a faff, but that's all it is.

QUOTE
Caches are much more expensive to implement than similarly sized scratchpad RAMs, so I think if it were just a matter of convenience we'd be seeing more bare metal DSPs without it.

One thing that's been pretty much conclusively proved in computers in the last 20 years is that ease of use generally trumps hard-to-get-at potential. In addition, for general-purpose tasks visible caching may be completely useless. At the very least, you'd need a lot of specialised R&D in compiler research to optimise a compiler for it. Carmack's opinions on the Jaguar port show this up clearly, and he's one of the rocket scientists (ha!) who could have made it work if he'd spent the time.

Yes, you could emulate Genesis level FM synth, but it'd take every last CPU cycle and all of your RAM to actually be competitive. I know this because that's what it takes to emulate FM for the emulator jEnesisDS, which uses a 33MHz ARM7 (which is much better than the DSP in the Jaguar).

I've not used the ARM7, so I can't comment on the suitability of that architecture. I have written an emulator for the MD sound chip, though, and the fundamental ops really are rather simple and I think would be very suited to implementation on the Jaguar chip. Sinewave generation is two adds and a sine table lookup (from the onchip ROM on the Jaguar DSP); attenuation is another add and a couple of ops to handle the envelope; clamp, sum and lookup the log table. You have enough regs to run operators from 3 channels in parallel, so you're not going to get many pipeline stalls.

RAM isn't a huge issue either. You can get by with 128 entries in the log table, and only a couple of frac bits are needed at most.

I reckon 25-30 cycles per operator, which with 24 ops would leave you around 25% of your cycles free if you matched the MD YM2612's 35-ish kHz, and about 50% if you did 22kHz. Of course, it's always dangerous to predict performance based on an architecture I've not exactly written a lot of code for, but I would bet a pint on it.

QUOTE
I'm going to hazard a guess that games with low end mod players like T2K aren't using the DSP to do other things, and for good reason (aside from that it'd be a pain to do). You don't exactly have a wealth of space to do whatever you want.

Yeah, it's not. Two channels of panned variable-frequency SFX. Like I said, though, it's 80% plus idle.

QUOTE
But the point I was trying to make was that if you want good audio in a Jaguar game you're not going to have a bunch of power left over to utilize the DSP for other things

No arguments there.

QUOTE
Also, certainly, you can use the ROM wavetables in games, but don't you think that'd get old pretty fast?

Depends how imaginative your sound guys are and if they are going to build their own patches. So, you're probably right there .

QUOTE
I think history has proven otherwise regarding DSPs vs dedicated audio, or at least for many consoles that post-dated the Jaguar, with only N64 and GBA springing to mind as counter-examples

I'm surprised about this statement. My understanding was that as well as the N64 at least the Xbox, PS3 and 360 were primarily softsynths, and I'd be really astonished if anyone did anything else now you can just stream MP3 for music.

QUOTE
So does it really matter? Unfortunately, the result of that flexibility in Jaguar's DSP was a console that could vaguely compete with SNES and Genesis in the audio department, but that was about it. On Saturn you didn't have to waste one of the SH2's for audio (or the 68k, or even the audio DSP for that matter), and that was really where the bottom line went in computational power, because you could very easily do a game with excellent non-streaming music and have all of your CPU resources available.

Not really sure about the conclusion in the end. Really all I get out of it is that both the Jaguar and the Saturn basically failed, and the audio capabilities weren't a factor in either failure.

 

[paddy]

cassini ,source code v.1, originaly girigiri, was completely reverse coded and the source has been cleaned

http://www.zophar.net/saturn/cassini.html


cassini is a very fast saturn emulator ,has some graphics and sound bugs ,but with the source
these things may get sorted out.

this source might be messy ,but i know theres a v2 of the source, tho i cant find it
yet, i may have it backed up tho.

 

[darkstorm classic]

cassini ,source code v.1, originaly girigiri, was completely reverse coded and the source has been cleaned

http://www.zophar.net/saturn/cassini.html


cassini is a very fast saturn emulator ,has some graphics and sound bugs ,but with the source
these things may get sorted out.

this source might be messy ,but i know theres a v2 of the source, tho i cant find it
yet, i may have it backed up tho.



The source code was *never* released. Some idiotic script kiddies just took the hacked version of girigiri and put a pathetic gui on top, then lied and said they'd got source code. There was a v2,3 and 4, and guess what? Not a single one of them had *any* core changes, only gui. There are only 4 real saturn emu's(since giri giri is owned by sega), SSF, Yababuse, Satourne and Saturnin.