Sega Saturn hacking

[eatcomics]

I thought this board would enjoy this video:



Basically trying to replace the sega saturn CD reader with a USB port. Which is neat.

[dandymcgee]

Awesome video!

Couldn't figure out the youtube tags, sue me.

Just put the video id in the tags. If you mouse over the "youtube" button, it will tell you that.

[eatcomics]

Awesome video!

Couldn't figure out the youtube tags, sue me.

Just put the video id in the tags. If you mouse over the "youtube" button, it will tell you that.

Well that's fair Thanks

[Arce]

That's awesome! Thanks for sharing. I hope the project comes to fruition; "hotswapping" discs is such a pain in the ass. I would love to replace the CD with a harddrive that houses my game library. I'm surprised that he hasn't mentioned rigging one of his custom adapters to raspberry pi to enable wifi/cloud game streaming.

I'll have to keep my eyes open for updates

[Falco Girgis]

Well fuck me sideways.

This is the kind of shit they're doing with the Dreamcast right now, as there's been a renewed interest in it and the homebrew scene with Kickstarters like Pier Solar and Elysian Shadows... But you never see this kind of shit happen EVER with the Saturn.

Not just because its homebrew scene isn't as large, but because it's supposedly an absolute BITCH to develop for. The hardware was so notoriously complex that developers all flocked from the Saturn to the N64 and PSOne during that era. Sega's (retarded) R&D team essentially built the ultimate 2D platform with the Saturn, then, after hearing rumors of the upcoming PSOne's specs and focus on 3D graphics just months before its release, the hardware team had to scramble to get their shit up to par.

What did they do? Basically duct-taped a second SH2 processor into it (Yeah, in 1994, the fucking Saturn was dual-core) and tried to half-assedly add better 3D support to the console. What we wound up with was an INSANELY powerful 2D console (could absolutely take a shit on the PSOne with sprites) that sucked at 3D and was ridiculously hard to develop for. Most Saturn games apparently only used a single processor, because multiprocessor programming was so new for game development back in the day. Virtua Fighter apparently allocated the rendering and physics for each of the two fighters to each of the two SH2 CPUs.

Another interesting thing... If you find a Saturn for cheap in a garage sale or something, BUY IT. All you need to play burned games is a fucking piece of tape. I shit you not. Open the bitch up then tape the latch down that detects when the CDRom drive is open. Then turn it on with a legitimate game. You'll hear the laser move to the outer edge and read for a few seconds. It's reading the proprietary copyright shit on the outside of the disc. Then IMMEDIATELY, as you hear the laser move from the outside to the inside, swap the legit disc with ANY burned game and boom, you can play any Saturn homebrew or anything of the sort. Also you can duplicate Saturn games with a simple CD burner...

You have no idea how many times Peter, Marcel, and I used to walk to the local game store, buy a Saturn game, run home, pirate the bitch, then bring it back a few hours later and claim "it doesn't work!"

[Falco Girgis]

As for the programmable sound coprocessor...

I am not familiar with the Saturn's chip, but the Dreamcast has a very similar ARM audio coprocessor... which has an extremely unfortunate bottleneck. I have never personally developed for it, but I've read plenty of posts from Randy Linden (the guy who created Bleemcast, a full-speed PSOne emulator for the Dreamcast, which actually makes PSOne games run and look better than they did on the PS2) on DCEmulation.org lamenting its capabilities...

It sounds nice and awesome for special effects, there's a C compiler for it in the Dreamcast toolchain, the clock speed is high enough, there is enough SRAM, and the BUS is fast enough... but the processor has no fucking cache. This means every goddamn memory read and write and even every instruction fetch is having to go to the RAM bus (read: it's very goddamn slow), which SEVERELY castrates the performance of the coprocessor. To the point of it almost being nearly worthless is what I heard.

As the Dreamcast came after the Saturn and supposedly was the product of learning from a lot of these design mistakes, I would be very surprised if the Saturn's SPU didn't also suffer from this kind of shortcoming...

...But then again, it's not an ARM, and it's apparently a different manufacturer for the chip... So maybe I'm wrong?

Edit: Here's a dude actually trying to use the Dreamcast's ARM SPU as a general-purpose coprocessor. Pretty interesting as an academic exercise, but don't know if it would be practical for real, in-game applications:

[dandymcgee]

It sounds nice and awesome for special effects, there's a C compiler for it in the Dreamcast toolchain, the clock speed is high enough, there is enough SRAM, and the BUS is fast enough... but the processor has no fucking cache.

Ouch.

[short]

It sounds nice and awesome for special effects, there's a C compiler for it in the Dreamcast toolchain, the clock speed is high enough, there is enough SRAM, and the BUS is fast enough... but the processor has no fucking cache.

Ouch.

Wow, never programmed in an environment like that before. Cool!

[Light-Dark]

Edit: Here's a dude actually trying to use the Dreamcast's ARM SPU as a general-purpose coprocessor. Pretty interesting as an academic exercise, but don't know if it would be practical for real, in-game applications:

I always love seeing one of Dave's videos in my subscription feed; he's always doing cool shit with the DC.

Glad the Saturn scene is making strides though. A lot more progress than the N64 scene (we're still writing programs largely in MIPS assembly )

[Falco Girgis]

I always love seeing one of Dave's videos in my subscription feed; he's always doing cool shit with the DC.

I just stumbled upon him, and we've been talking a shitload. At this point in development, I haven't been able to sit down and sink a lot of R&D time into getting the more advanced lighting effects in ES running on the Dreamcast, but he has dynamic shadows and even bloom lighting demos... All of my plans for porting some of that stuff have been purely theoretical until this point, so it's really cool seeing someone who has actually done it. I was pretty convinced bloom just wasn't going to happen in hell on the DC.

Glad the Saturn scene is making strides though. A lot more progress than the N64 scene (we're still writing programs largely in MIPS assembly )

Seriously? Why is that? I would have assumed it would have been a lot more mature than the Saturn scene, because it's arhitecturally far simpler and more powerful... Why the need for assembly? Unless... There's no compiler for it? Was that MIPS processor proprietary? Yeah, you would be totally fucked then...

Dreamcast and I'm assuming Saturn have been blessed in the fact that the SuperH 2 and 4s are pretty populate microprocessors and at least the SH4 is still widely used and supported today, so there are plenty of tech documents floating around out there, and of course GCC supports it... That's why the Dreamcast, which was released in 2009, has no problem with C++11 and some of C++14...