As a developer nowadays, I get the sense that I would have simultaneously loved and hated working on the Saturn 🙂 Simultaneous Multi-Thinking, if you will.
Can you clarify on how hard or easy it was to develop for the saturn? I am curious about homebrewing a game. A question I have is: Do you need a machine made by SEGA, do I have to buy a expensive physical kit? How about the dreamcast?
Ciara Garrity it depends what you want to make; a fast 3D game with lots of special effects takes a great deal of knowledge in both C and Hitachi assembler. But getting started and making simpler games isn’t difficult, and you don’t need any custom hardware if you use an emulator or mod chip. I used to use a dev environment called Saturn Orbit but idk if it’s still around.
The way I understand it, it was a super crunchy setup to work with. It's a matter of "how much did you enjoy haskell back in college?" If the answer is anything other than "oh god no," then you'd probably enjoy it.
Mate, the way you did the visualisation deserves a fucking award, showing a window of what each chip does on the chip. Brilliant, I have never seen that before, if done before someone show me where.
And to think that's not even the most absurd system Sega ever produced. A Sega Genesis with both the CD and 32x add-ons formed a system with: A 68000 at 7.67MHz, a 68000 at 12.5 MHz, a Z80 at 3.57MHz, and two SH-2s at 23.01MHz, then for sound you have a YM2612 with 6 FM channels (or 5 and 1 PCM channel), a PSG with 3 channels of square waves and 1 noise channel, a QSound chip with 2 PWM channels, an RF5C164 with 8 PCM channels, and two channels of CDDA, and then for graphics you have... I'm not even going to try to describe the CD32x graphics hardware, but it's 3 completely different chips being over or underlayed.
Can you utilize all that hardware at once? Or is some of it locked out most of the time? I know the z80 and 68k can't work together at once but what about all the other stuff
All these years I never stopped to consider what a Frankenstein's monster all of those pieces of hardware are together under the hood. Really it's a shame things turned out like they did, I would have really loved to see a CD, 32X, or CD32X game that utilized all that hardware to it's fullest... maybe helmed by Hideo Kojima fresh off the Sega CD port of Snatcher that was so amazing.
@@jlewwis1995 The z80 operates as a sound controller and not really a coprocessor. Yes you can use them all at once. They would generate the background, overlay and other 2d stuff with the 68000 and its graphics hardware on the genesis while more fancy graphics were generated with the SH-2 processors on the 32x. There wasn't a lot of communication between the CPUs and the images were combined via the video signal so no shared frame buffer or anything like that.
More please! I find the Saturn fascinating, it had such stark differences in game graphics quality. I believe that one must be a wizard developer (team) to make great looking 3d games like Powersslave, panzer Pragoon zwei, etc using this architecture. The Saturn, was part of my teenage gaming years, hope to get more coding secrets content for it. Great work!
It's also about how much time you are willing to spend making a game. Time = money. Are you going to sell enough copies to make that extra time spent on polish worthwhile?
You should check out PowerSlave, whose SlaveDriver engine was reused for the Saturn ports of Duke Nukem 3D and Quake. Ezra Dreisbach, the lead architect of the SlaveDriver Engine, was one of the few people who used the Saturn to its full effect, despite him criticizing the Saturn’s architecture.
I know for a fact that there were at least 2 in europe. The launch units had small elipse buttons, but these were replaced with round ones on later units.
Even a short lifespan is a lifespan. But the Saturn har games released for it from 1994 - 2000, the majority of which came out from 94-98, so it had a pretty typical console life. There were around 1000 total games, and it outsold the N64 in Japan.
Man, I don't envy you for your assembly code... Ouch, I remember the nightmare 68000 assembly was, let alone the SCU interaction... Thanks for these videos
I had no idea that the Saturn had twin CPUs. The 32X/Mars also has twin SH-2s as far as I'm aware. I only knew that because of 32X test programs that people have come across. They make reference to the Master/Slave SH chips.
A significant difference is that unlike on the Saturn, graphics on the 32X are all software rendered (not counting the underlying Megadrive graphics layer)
The 32X had dual SH-2s specifically because the Saturn did. Somebody at Sega had the harebrained scheme that they could use the 32X as a "bridge" to the next generation to make developing Saturn games easier.
This is the most diplomatic and tactful description of the Sega Saturn's patchwork architecture I've ever seen. A more pragmatic take would be "a confused, schizophrenic design resulting from haphazardly converting a system originally designed exclusively for 2D games into a 3D system in order to compete with the PS1, which blindsided Sega while they were still focused on one-upping the SNES". Given Traveler's Tales' penchant for doing crazy stunts with limited hardware, it's no wonder Mr. Burton has such fond memories of the console, but most third-party developers hated it, which was one of the reasons the Saturn flopped.
Have I seen all of these episodes before? Yes. Am I watching them all again as they're uploaded on the new channel? Absolutely. They're just too good not to 👍
These are really awesome videos, both the explanation and the graphical representations really paint a picture of what's going on. I'd definitely want to see a video on how you programmed the DSP too
It would be interesting to go a little deeper and break open some of the steps that were a little handwavy. Like, "finally all the layers were combined", what does that mean? The pixels for each layer were sitting in memory and the scan-out could read from multiple buffers at the same time, compositing final pixels as they were sent to display? If so, how were transparent pixels in the layers indicated? If not, was there a composition step boiling the layers down to one framebuffer? If so, what chip performed that? Etc.... Love the videos and your presenting style by the way.
I agree. Software people make it sound more complicated than it seems to a HW person. The tasks and pipeline were clear. The VDP2 did all of the video output. VDP1 did the rendering. SCU does the setup/transform of the polygons/geometry. Master CPU did control the memory transfers and main loop. Slave CPU does the processing heavy but conditional/sequential math. All games were frame driven, not asynchronous real time. Depending on the TV standard 50 or 60 frames were computed. A frame update mid picture would usually cause a black line.
Non Sega creators are left relentless and uncertain when it comes to creating games for the Saturn. It’s not because they aren’t skilled, but rather how complex and challenging it is to code this kind of game on a system like this
@1:36, looking at that thing and looking at a modern mainboard. XD. Back then a hundred different chips with different languages and different buses. Today a cpu and a chipset and MAYBE some ram sticks if not soldered on. The dying of the various chips and buses began in 2006, when AMD started putting the dram memory controller into their cpus. Subsequently intel started eradicating various other chips like ata and sata controllers and usb hc's from their boards and moved them into the boards chipset. Nowadays looking at a schematic, you have the cpu and chipset, all ios extend from those two like a tree root, no other controller or chip involved.
1:10 - Saturn was promoted back then as having access to an internet based system where you could play original genesis games. I still believe I have my old Game Pros which talk about Sega Net, so I bet that chip was there in the case they could run genesis roms via the online server (that failed horribly).
Sega programmer tasked to make seemingly impossible graphics on complex hardware: ok, I am gonna just develop my own 3D engine and use every trick I know about the hardware to get it to run. The real blast processing was not the hardware, but the brain power of Sega Devs.
Because people will keep Burning down buildings, Looting stores and Murdering people if you don't. Who am I kidding? They will keep doing that whatever you do. NEVER NEGOTIATE WITH TERRORISTS.
Dude, I know that doing this sort of thing was commonplace for you and your team, but this sounds like the most complicated sort of programming ever. You must have been so thoroughly familiar with the hardware. How long was the documentation for that beast of a console?
I have Sonic R for the PC. The environment and various time/weather changes looked so good while the soundtrack was perfect for the game. Sonic R has a strange spot in my heart separate from the other games. Running around in the rain looking for balloons was oddly satisfying.
IIRC, the Saturn was designed to be the best 2D console of all time. The the Playstation arrived. In their panic, Sega did the standard arcade solution to make the Saturn 3D: add more hardware! They took the graphics processor and doubled it. This explains the unusual polygon style of the Saturn: quadrangles of solid (immobile) texture. They were sprites with distortion. The resulting system was considered difficult to program for (obviously), and Sega's dev tools weren't very optimizing on this hardware (less obviously). As a result, developers gravitated to the Playstation, which was easy to develop for, on, and with Sony approval. On an unrelated note, I have a copy of PC Sonic R, as released by Express. Know anything about the porting of Sonic R to the PC?
@Lassi Kinnunen more like optimized memory access, if textures were accessed as quads, the whole process can be parallelize better. Currently gpus access their memory in 4x4 blocks laid out as a linear arrays of characters. Actually, the only advantage of triangles is their texture coordinates flexibility, but textures are still accessed as quads
The Saturn was a 2D Powerhouse that could run circles around the PlayStation in sprite-based games, as any Capcom fighter fan can tell you. But, in 3D games the tables were turned and the PlayStation, if not more powerful at 3D, was at least easier to program 3D games in. The idea that the Saturn was basically a 2D system that was being forced to do 3D would help explain that, except that Sega themselves also played a part in kicking off the 3D revolution with Virtua Fighter. They had to know going in that a home version of Virtua Fighter would be expected on their next gen console. So, it seems weird that they would make a console with only 2D in mind and then only add 3D capabilities at the last minute to compete with Sony... Does anybody know if Sega's Model 1-2 arcade hardware (that they used for 3D arcade games at the time) used quads or triangles? If their arcade hardware used quads then it makes sense that Sega's programmers would be used to quads and didn't realize that 3rd party developers would prefer working with triangles. That would probably be a better explanation.
@@TetsuDeinonychus The problem was that the Saturn could only run circles around the PlayStation in sprite-based games if the developers knew how to take advantage of the difficult hardware... which many didn't. There are direct comparisons of games that run much worse on the Saturn than their Playstation counterparts, like Symphony of the Night. Not because the Saturn was incapable of doing a 2D sprite game as well as the Playstation, but because the developers were incapable of doing so.
Wow, I LOVED this one!!! Man, the way computer stuff work is just SO interesting! Highly looking forward to more vids pertaining to console hardware!!!
In this application it sounds like there would be little to no inter process communication needed. So it would be a snap. The SH-2 are VLIW and use trace scheduling afaik....
This is deliberately dividing the problem into independent parts to minimise synchronization, locking, and race conditions. Though I am sure that would be a problem at the end of processing for each frame.
@@darren8453 That is very possible. But with the kind of intricacy and detail he went into programing the matrix dsp for this game, it sounds like he went to great care to make sure everything was timed just right. That video will be probably coming up soon. It is really something quite amazing.
I thought maybe that was just a Saturn naming convention but took me a moment to realize what was going on. The whole "slave" renaming because it's racist is ridiculous, but "servant" isn't a bad substitute.
Yeah seriously. I was a kid around this console generation, and a lot of how they work seemed like magic back then. An explanation on how the magic works would be glorious.
I am wondering did the x68k chip play any role in this game? If not, why not? Since it was still relatively a capable (not powerful) chip that could contribute some to the game, like drawing hud, mixing, etc
So the VDPs werent actual GPUs in the sense that we'd think of them now, they just draw the screen output? They just display whatever objects are given to them more or less? Just trying to understand how this machine worked.
From what I understand, the CPUs give information like vertex coordinates, lighting and textures to use, and the VDPs do the actual rendering, somebody correct me if I'm wrong
I wonder if Saturn lost the console war because programmers said "I cant be arsed to code for this, I will just do N64 and PSX ports, they're both running 64 bit MIPS, that should be straightforward enough"? :p
definitely a contributing factor, but the damage was done long before with the mega cd, certainly 32x 6 months prior, and then that early 'surprise' launch that pi**ed off most retailers, and publishers before the 'war' even started.
No, they lost because SOA released the Saturn 6 months early, making magazines covering the September launch date look like idiots, and angering retailers who were not given Saturns for the early launch. Consequently, many retailers didn't carry the Saturn at all, so many gamers never saw a Saturn in their stores to buy if they wanted one. And most of the gaming press took a hostile stance against Sega for the next two generations because they were lied to about the launch of the Saturn. That and SOJ's boneheaded decision to produce far fewer Saturns than consumers demanded are what did the Saturn in. They did that because they lost money on each console sold, and they were so obsessed with staying in the black that they would rather produce half as many units if that meant staying profitable that fiscal year. What that did was send a signal to developers that the Saturn would have a small user base by design, because even if more customers wanted a Saturn than a PlayStation, they couldn't get one. So of course developers focused on the PlayStation because they could sell more games on it, because Sony didn't put a ceiling on how many consoles they wanted to sell. The launch and the under-production are what did the Saturn in. Any other issue was minor and could have been overcome, including its difficulty to develop for and the failure of the 32X. Also, the PlayStation ran a 32-bit MIPS, and the N64 was even harder to develop for.
It's always struck me looking at the specs that the Saturn should have been at least 1 1/2 to twice as fast as the PS1 hardware wise. It seems to me that the only thing it lacked were proper developer tools that would have allowed the less-than-stellar programers (sadly, not all programmers are as good as the Author 😋) to have properly used the hardware available. This same problem, speaking of coding for what amounted to an SMP system would come up a few years later when PCs moved to multi-core chips, etc.
This just isn't true. For pure textured polygon pushing, the PS1's custom GPU was EONS more powerful, feature rich, & flexible than both the Saturn's VDP's combined. "3D" on the Saturn had be achieved at all with really clever sprite manipulation (hence why it uses quads as the primitive vs the standard triangles. They're really just individual 2D sprites with some clever use of scaling & rotation), as the hardware was almost entirely designed from the ground up for 2D graphics. (Whereas the PS1's video processor was pretty much the exact opposite, with 3D being by FAR the primary focus). The Saturn as a whole was extremely powerful in a raw calculations per second kind of metric, but when it came to running 3D games it tended to fall flat on its face.
@@Cooe. In terms of GPU drawing the Saturn could have done what the PSX did if only it allowed textured triangles with Gouraud shading, the Saturn was almost there but not quite with its quirky rectangle sprites. Sony had to bolt on a "Geometry transformation engine"(GTE) CPU-based co-processor to calculate 2D coordinates for the GPU from 3d vectors, a lot of Playstation's 3d capability was done by software on the CPU, unlike GPUs of today.
@@SerBallister That's a whole lot of "whataboutism" if I've ever heard any. The PS1's design was as explicitly 3D focused as could be ANY console design at the time it was done (developed over ≈ 1991-1994). Sony was breaking new ground in so many areas for a mass consumer product (aka not a >$10,000 SGI workstation; with the GTE in particular helping to push things forward) that of COURSE they'd be missing some things we'd later traditionally associate with explicitly 3D focused rendering hardware. I'm sure if Sony had had the benefits of hindsight, endemic affine texture warping & such wouldn't have been a thing ofc, but that doesn't mean the PS1's hardware design wasn't focused around polygonal 3D first & foremost (again, unlike the Saturn's). And ofc after both, Nintendo would then take the "it's a 3D hardware design for a 3D polygonal gaming era" to the inevitable extreme. This as the N64 design done w/ SGI was basically the exact opposite of the Saturn's. The N64 was built almost exclusively for textured polygonal 3D & as such was absolutely STUPID powerful at polygon pushing for 1996 (at launch, the N64 & its SGI developed "Reality Engine" kicked the ever-living ASS out of even the highest end gaming PC's w/ their quaint little 3dfx Voodoo 1's as far as RAW 3D textured poly pushing power was concerned), but was absolutely dogshit at high-res 2D rendering. Hence why the N64 library is full of expansive 3D platformers & action games instead of the Saturn's fighting games, JRPG's, & assorted Japanese obscurities. PlayStation otoh neatly split the difference between the other 2 consoles in design focus/prowess, even if 3D was definitely still Sony's prime priority. The Saturn otoh was a next-gen 2D system that Sega desperately tried to jury-rig for the "3D era" at the last minute by expensively just throwing a bunch more already existing silicon at the problem (aka, "if we're gonna do 3D by sprite manipulation, then its gonna need at LEAST another pricey VDP to not COMPLETELY choke & die", & so on).
@@Cooe. I think you misunderstood, I was talking about the GPU as a discrete chip ("... in terms of GPU drawing"), on both systems they aren't that far apart in ability, the ps1's GPU is a 2d triangle drawing GPU with no concept of 3D, which for me puts it closer to the Saturn than one might think. The PS1 as a system had 1 additional piece supporting hardware located outside of the GPU for 3d acceleration. Everything else the PS1 had like table based Z-sorting and that janky tesselation it did was done entirely in software on the CPU. It's interesting because it wasn't a truly integrated hardware 3D pipeline, unlike every machine that came after it starting with the N64.
@@SerBallister Again, this is absolutely fucking nonsense. The Saturn's VDP's & Sony's co-designed with Toshiba GPU have next to nothing in common outside sharing basic sprite manipulation capabilities like rotation & scaling.... The Toshiba chip was EXPLICITLY designed from the jump as a dual-purpose 3D & 2D graphics processor, with triangles as the fundamental primitive for polygons & a largely normal 3D rendering pipeline (even if it's missing PLENTY of steps we'd consider necessary in more modern 3D rendering hardware. Literally the only 3D hardware on the planet at the time of the PS1's development with widespread use which had a Z-buffer w/ culling capabilities & all the other good stuff you mentioned were >$10,000 SGI workstations [& these capabilities wouldn't end up in a console until the SGI developed N64 ofc]). The Saturn's VDP was designed from the ground up EXCLUSIVELY as a 2D sprite pushing MONSTER, until late, LATE into the Saturn's development when Sega realized they'd need to figure out how to make their already finalized hardware (as far as the chip designs themselves; aka there was gonna be no "redesigning the VDP for native 3D") work with polygonal 3D.... Which they did by literally throwing another VDP at the problem & brute forcing the "3D" with sheer sprite pushing/manipulating power & really clever use of what was BLATANTLY a 2D graphics engine/pipeline.
I'd love to see a video series on how assembler relates to C, C++ etc. I primarily code in C++ and C#, so when I look at C code you're written, it's a little more complex than the code I write, but I can see what you're doing in a given snippet. When you show assembly, I'm just lost. Best I can do in assembly (and only x86 assembly at that) is perform operations on arbitrary numbers with mov and add/sub/div/mul commands etc. Anything above that? No chance. I could maybe write you a basic calculator, but that's about it lol I guess a big question I would have is did hardware manufacturers back then give you datasheets on how to send commands to the various components and red input etc? Or did they just hand you the dev kit and just expect you to figure it out? I ask because I've done a bit of work with PS4 development with a dev kit at the university I teach at, and they provide a COLOSSAL amount of documentation on the internals and how to use the various abstraction layers built into it so you can write code to run on it. Of course, you wouldn't write code in assembly for a PS4 or you'd still be working on one game 50 years from now, but in theory you *could*. I'm just curious how, say, the C++ instructions I write for it convert into assembly, even at a basic level to give me an idea. We have a separate lecturer who teaches the low level stuff like assembly, and I teach the more creative stuff like game design and high level scripting, but I'd love to get an insight into how our two disciplines relate.
The compiler takes care of interpreting the higher level language (C) and also noting directives to the compiler to inline/inject assembly directly into the binary before creating the final output binary. If the ASM code and C code are targeting different CPUs / machine languages, the tool chain may cross compile (or use specific definitions) for each chip.
The renaming of "slave" has come up recently because some people claim that it has a racist connotation. I think that's ridiculous, but I wouldn't mind if servant became the new term.
What I don't understand is this kind of thinking behind the Saturn archeticture was not even prevalant circa 1986/1987 when the Genesis project was taking shape...you never hear of any developer complaining how bad a system that was to work for yet for the Saturn somehow Sega just did the complete opposite at a time when it wasn't about just Nintendo any more, but the new kids on the block as well: Sony..
My gosh this was overly complicated, yet Sega Saturn was heavily underappreciated, along with Sonic R. By itself it looks like grandfather off multi-CPU processing, with manually assigned processing instructions. Wild! While PC world statred to get dual-core processors around 2000's.
I really think they should have delayed release and added a better 3d based chipset.... with the backwards compatibility possible with the 6800 and extra ram expansions that can be used in the cartridge port it could have been great...
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
I would love to see a video about that crazy parallelism on the DSP
It exists as 'Coding for the World's Trickiest Chip,' so that should be uploaded soon, but we are still waiting on the sequel to that video.
And if you can't wait: ruclips.net/video/n8plen8cLro/видео.html
Seconded!
Me three
Me as well!!
As a developer nowadays, I get the sense that I would have simultaneously loved and hated working on the Saturn 🙂
Simultaneous Multi-Thinking, if you will.
Can you clarify on how hard or easy it was to develop for the saturn? I am curious about homebrewing a game. A question I have is: Do you need a machine made by SEGA, do I have to buy a expensive physical kit? How about the dreamcast?
Ciara Garrity it depends what you want to make; a fast 3D game with lots of special effects takes a great deal of knowledge in both C and Hitachi assembler. But getting started and making simpler games isn’t difficult, and you don’t need any custom hardware if you use an emulator or mod chip. I used to use a dev environment called Saturn Orbit but idk if it’s still around.
@@caseycu oh goody! Ill try to find it. Thank you!
The way I understand it, it was a super crunchy setup to work with. It's a matter of "how much did you enjoy haskell back in college?"
If the answer is anything other than "oh god no," then you'd probably enjoy it.
Mate, the way you did the visualisation deserves a fucking award, showing a window of what each chip does on the chip. Brilliant, I have never seen that before, if done before someone show me where.
And to think that's not even the most absurd system Sega ever produced. A Sega Genesis with both the CD and 32x add-ons formed a system with: A 68000 at 7.67MHz, a 68000 at 12.5 MHz, a Z80 at 3.57MHz, and two SH-2s at 23.01MHz, then for sound you have a YM2612 with 6 FM channels (or 5 and 1 PCM channel), a PSG with 3 channels of square waves and 1 noise channel, a QSound chip with 2 PWM channels, an RF5C164 with 8 PCM channels, and two channels of CDDA, and then for graphics you have... I'm not even going to try to describe the CD32x graphics hardware, but it's 3 completely different chips being over or underlayed.
Can you utilize all that hardware at once? Or is some of it locked out most of the time? I know the z80 and 68k can't work together at once but what about all the other stuff
With all that power, could it do FF7 at the appropriate resolutions?
Now THAT is Blast Processing!!!
All these years I never stopped to consider what a Frankenstein's monster all of those pieces of hardware are together under the hood. Really it's a shame things turned out like they did, I would have really loved to see a CD, 32X, or CD32X game that utilized all that hardware to it's fullest... maybe helmed by Hideo Kojima fresh off the Sega CD port of Snatcher that was so amazing.
@@jlewwis1995 The z80 operates as a sound controller and not really a coprocessor. Yes you can use them all at once. They would generate the background, overlay and other 2d stuff with the 68000 and its graphics hardware on the genesis while more fancy graphics were generated with the SH-2 processors on the 32x. There wasn't a lot of communication between the CPUs and the images were combined via the video signal so no shared frame buffer or anything like that.
More please! I find the Saturn fascinating, it had such stark differences in game graphics quality. I believe that one must be a wizard developer (team) to make great looking 3d games like Powersslave, panzer Pragoon zwei, etc using this architecture.
The Saturn, was part of my teenage gaming years, hope to get more coding secrets content for it. Great work!
to think a company ported quake 1 in near entirety to the saturn is unbelievable.
It's also about how much time you are willing to spend making a game. Time = money. Are you going to sell enough copies to make that extra time spent on polish worthwhile?
The Sega Saturn did sound like a bloody "knightmare" to code for.
I think it sounds very interesting to pull cool stuff with Saturn 😁
@@melficexd It's interesting after you pulled this off, but a nightmare to come up with and code.
I think you and I are the only ones that got the joke. I remember knightmare.
Sounds like you could easily get yourself into a Pickle.
Such good games on it though!
I think I'm starting to see why Yuji Naka just gave up and ran his game loops on the 68k
He did? Is there a story here?
You should check out PowerSlave, whose SlaveDriver engine was reused for the Saturn ports of Duke Nukem 3D and Quake.
Ezra Dreisbach, the lead architect of the SlaveDriver Engine, was one of the few people who used the Saturn to its full effect, despite him criticizing the Saturn’s architecture.
3:23 Extreme Danger Dungeoneers! (Nice reference to Knightmare!)
Used to love that show, despite being creeped out every time by the life force draining animation...
There were many revisions made through its life.
Me: Wait. The Saturn had a lifespan?
Mostly for Japan I imagine.
I know for a fact that there were at least 2 in europe.
The launch units had small elipse buttons, but these were replaced with round ones on later units.
@@NemXX2 I had one with round buttons in Brazil, no disc access LED in the panel.
Even a short lifespan is a lifespan. But the Saturn har games released for it from 1994 - 2000, the majority of which came out from 94-98, so it had a pretty typical console life. There were around 1000 total games, and it outsold the N64 in Japan.
You already know we want to see the DSP code explained again; why would you ask?
I notice that Tails is named "Tales" in the code.
because Traveler's Tales, I presume?
Funny
yeah he actually did confirm that Tails is called Tales because you know though i can't remember which video it was
Man, I don't envy you for your assembly code... Ouch, I remember the nightmare 68000 assembly was, let alone the SCU interaction...
Thanks for these videos
I had no idea that the Saturn had twin CPUs. The 32X/Mars also has twin SH-2s as far as I'm aware. I only knew that because of 32X test programs that people have come across. They make reference to the Master/Slave SH chips.
Or ya know, you can open one up and see "SH2" stamped right on the chips
A significant difference is that unlike on the Saturn, graphics on the 32X are all software rendered (not counting the underlying Megadrive graphics layer)
Thought sh1 chips
The 32X had dual SH-2s specifically because the Saturn did. Somebody at Sega had the harebrained scheme that they could use the 32X as a "bridge" to the next generation to make developing Saturn games easier.
@@geniedumal2974 I thought inside was a Mars sh1 chip
This is the most diplomatic and tactful description of the Sega Saturn's patchwork architecture I've ever seen. A more pragmatic take would be "a confused, schizophrenic design resulting from haphazardly converting a system originally designed exclusively for 2D games into a 3D system in order to compete with the PS1, which blindsided Sega while they were still focused on one-upping the SNES". Given Traveler's Tales' penchant for doing crazy stunts with limited hardware, it's no wonder Mr. Burton has such fond memories of the console, but most third-party developers hated it, which was one of the reasons the Saturn flopped.
Sega: Welcome to the Next Level!
Competitors: Dude, you should be on the next _game._
this is the man who programed magnets into the walls
Im still at 8th Grade but I aspire to be a programmer. I really love YOUR VIDEOS
Have I seen all of these episodes before? Yes. Am I watching them all again as they're uploaded on the new channel? Absolutely. They're just too good not to 👍
Why is there a new channel?
fun fact: "sram" is "im sh!tting" in polish
These are really awesome videos, both the explanation and the graphical representations really paint a picture of what's going on. I'd definitely want to see a video on how you programmed the DSP too
"I loved coding on the Saturn"
- Coding Secrets
It would be interesting to go a little deeper and break open some of the steps that were a little handwavy. Like, "finally all the layers were combined", what does that mean? The pixels for each layer were sitting in memory and the scan-out could read from multiple buffers at the same time, compositing final pixels as they were sent to display? If so, how were transparent pixels in the layers indicated? If not, was there a composition step boiling the layers down to one framebuffer? If so, what chip performed that? Etc....
Love the videos and your presenting style by the way.
I agree.
Software people make it sound more complicated than it seems to a HW person. The tasks and pipeline were clear. The VDP2 did all of the video output. VDP1 did the rendering. SCU does the setup/transform of the polygons/geometry. Master CPU did control the memory transfers and main loop. Slave CPU does the processing heavy but conditional/sequential math.
All games were frame driven, not asynchronous real time. Depending on the TV standard 50 or 60 frames were computed. A frame update mid picture would usually cause a black line.
Sonic r was my childhood, thankyou
Non Sega creators are left relentless and uncertain when it comes to creating games for the Saturn. It’s not because they aren’t skilled, but rather how complex and challenging it is to code this kind of game on a system like this
@1:36, looking at that thing and looking at a modern mainboard. XD.
Back then a hundred different chips with different languages and different buses. Today a cpu and a chipset and MAYBE some ram sticks if not soldered on. The dying of the various chips and buses began in 2006, when AMD started putting the dram memory controller into their cpus. Subsequently intel started eradicating various other chips like ata and sata controllers and usb hc's from their boards and moved them into the boards chipset. Nowadays looking at a schematic, you have the cpu and chipset, all ios extend from those two like a tree root, no other controller or chip involved.
Well, it is faster, cheaper, and smaller to combine chips if you can.
Servent CPU? Isn't it typically referred to as the slave ?
1:10 - Saturn was promoted back then as having access to an internet based system where you could play original genesis games. I still believe I have my old Game Pros which talk about Sega Net, so I bet that chip was there in the case they could run genesis roms via the online server (that failed horribly).
Sega programmer tasked to make seemingly impossible graphics on complex hardware: ok, I am gonna just develop my own 3D engine and use every trick I know about the hardware to get it to run.
The real blast processing was not the hardware, but the brain power of Sega Devs.
wow. I'd love an in-depth version of this entire video actually!
Master and servant - I didnt realise this was a “PC” mainboard 😂
It's a shame when technically minded people feel the need to change standard terminology because of political correctness.
Eh "to-may-to", "to-mah-to"
@@TetsuDeinonychus
It's actually tomatl from the Nahuatl language, aka Aztec.
You do a great job on these videos btw
I love how you break this down.
What is a servant cpu and how is it different than a slave cpu?
One is post-BLM and one is pre-BLM.
"To-may-to, To-mah-to"
Because people will keep Burning down buildings, Looting stores and Murdering people if you don't.
Who am I kidding? They will keep doing that whatever you do. NEVER NEGOTIATE WITH TERRORISTS.
From the thumbnail I thought you were going to say that each one of Sonic's limbs was controlled by a separate cpu.
A technology advanced enough is indistinguishable from magic to the average person. Computers are freaking magical.
Dude, I know that doing this sort of thing was commonplace for you and your team, but this sounds like the most complicated sort of programming ever. You must have been so thoroughly familiar with the hardware. How long was the documentation for that beast of a console?
@ReviewRevue true
Thousands of pages. You can find it all online.
I have Sonic R for the PC. The environment and various time/weather changes looked so good while the soundtrack was perfect for the game. Sonic R has a strange spot in my heart separate from the other games. Running around in the rain looking for balloons was oddly satisfying.
the one frame shot of 'Knightmare'
I remember submitting subtitles for this back on GameHut. But it seems Jon never integrated them. :(
@mPky1 Because Jon's making a channel expressly for coding stuff, like he did with his aeronautical content, and he's exporting stuff over.
i played the crap out of sonic r on pc as a kid. its crazy getting to see the technical aspects of it so many years later.
This is awesome. Amazing video
4:05 Yes please, would love to know how that worked. The Saturn is fascinating architecture wise :)
IIRC, the Saturn was designed to be the best 2D console of all time.
The the Playstation arrived.
In their panic, Sega did the standard arcade solution to make the Saturn 3D: add more hardware! They took the graphics processor and doubled it.
This explains the unusual polygon style of the Saturn: quadrangles of solid (immobile) texture. They were sprites with distortion.
The resulting system was considered difficult to program for (obviously), and Sega's dev tools weren't very optimizing on this hardware (less obviously).
As a result, developers gravitated to the Playstation, which was easy to develop for, on, and with Sony approval.
On an unrelated note, I have a copy of PC Sonic R, as released by Express. Know anything about the porting of Sonic R to the PC?
The panic was to add the second SH-2 and the matrix DSP. VDP1 and 2 were always in the recipe.
@Lassi Kinnunen more like optimized memory access, if textures were accessed as quads, the whole process can be parallelize better. Currently gpus access their memory in 4x4 blocks laid out as a linear arrays of characters.
Actually, the only advantage of triangles is their texture coordinates flexibility, but textures are still accessed as quads
3DO already did quads in almost the same way BTW
The Saturn was a 2D Powerhouse that could run circles around the PlayStation in sprite-based games, as any Capcom fighter fan can tell you. But, in 3D games the tables were turned and the PlayStation, if not more powerful at 3D, was at least easier to program 3D games in.
The idea that the Saturn was basically a 2D system that was being forced to do 3D would help explain that, except that Sega themselves also played a part in kicking off the 3D revolution with Virtua Fighter. They had to know going in that a home version of Virtua Fighter would be expected on their next gen console. So, it seems weird that they would make a console with only 2D in mind and then only add 3D capabilities at the last minute to compete with Sony...
Does anybody know if Sega's Model 1-2 arcade hardware (that they used for 3D arcade games at the time) used quads or triangles? If their arcade hardware used quads then it makes sense that Sega's programmers would be used to quads and didn't realize that 3rd party developers would prefer working with triangles. That would probably be a better explanation.
@@TetsuDeinonychus The problem was that the Saturn could only run circles around the PlayStation in sprite-based games if the developers knew how to take advantage of the difficult hardware... which many didn't. There are direct comparisons of games that run much worse on the Saturn than their Playstation counterparts, like Symphony of the Night. Not because the Saturn was incapable of doing a 2D sprite game as well as the Playstation, but because the developers were incapable of doing so.
I'd love to learn more about the DSP.
Absolutely loved Sonic R!
Wow, I LOVED this one!!! Man, the way computer stuff work is just SO interesting! Highly looking forward to more vids pertaining to console hardware!!!
"But sir, we can't program that in!"
"yes"
I read this in C-3PO's voice: "But sIR!"
I'd be all in favor on a video about that special assembly code.
Guess what? He already made the video: ruclips.net/video/CPaNNiB2H-s/видео.html . Have fun!
@@BuysDB Woo-hoo!
Somehow "Servant CPU" just doesn't sound right..
Yes, it was always "slave", but apparently that's no PC anymore...
Servant CPU sounds too close to "server" for me, and they're programming the Saturn to play games, not store and fetch web pages.
On the old hdd's (IDE OR PATA) you had a master and a slave hdd ^^let me guess you think that's even worse right ;P
@@ragexg Master and slave are, in my humble opinion, the proper terms that shall be used, PC culture should not be applicable everywhere.
main cpu and sub cpu?
4:02 No..
I hereby leave a comment to let you know I want to see a video on how exactly this code works.
Now that's a lot of chips!
Love these videos, I mess around in Unity and this seems like another world. I LOVED sonic R!
These videos about your work on the Saturn and how it functioned are completely fascinating. Extremely underrated console.
Would love to see a video teaching some of that assembly programing for the Genesis or Saturn! Even a hello world of sorts
I believe GameHut had some basic tutorials for coding on Genesis.
You can find that on Game Hut.
I want to see how you handle multiprocessing like that. Are they prone to raceconditions, or is this more in tune with MIMD architecture?
In this application it sounds like there would be little to no inter process communication needed. So it would be a snap. The SH-2 are VLIW and use trace scheduling afaik....
@@wishusknight3009 VLIW, ok. Thanks.
This is deliberately dividing the problem into independent parts to minimise synchronization, locking, and race conditions. Though I am sure that would be a problem at the end of processing for each frame.
@@darren8453 That is very possible. But with the kind of intricacy and detail he went into programing the matrix dsp for this game, it sounds like he went to great care to make sure everything was timed just right. That video will be probably coming up soon. It is really something quite amazing.
So cool! Thanks for the breakdown.
I like how he explained all that in only five minutes
"SEGA's Insanity"
No, YOUR insanity.
*in key to the song* Virtuaaal Insanity!
"Servant CPU"? Good grief.
?
Master and servant/slave are actually common computer terms, but yeah kinda awkward...
Not allowed to say slave anymore :p
"Servant" is not common terminology
I thought maybe that was just a Saturn naming convention but took me a moment to realize what was going on. The whole "slave" renaming because it's racist is ridiculous, but "servant" isn't a bad substitute.
i REALLY want to see that dsp video
Yeah seriously. I was a kid around this console generation, and a lot of how they work seemed like magic back then.
An explanation on how the magic works would be glorious.
I definitely would be interested in a video showing a more advanced look at how the code works.
Who handled the PC version of Sonic R and were the limitations any different on PC than it was on the Saturn?
The ironic thing is, that Sonic R could've been repurposed from a racing game to what sonic Xtreme was supposed to be.
If only Traveler's Tales were hired to help tame the beast that was Sonic X-Treme. Ah well, maybe in some other universe.
Servant CPU? Come on.
I heard a minor delay before he said it. Odds are he got demonetised and had to change it to get the video out.
Thank you so much I love this!
"Multichip Madness" is what I call it when I order 2x large fries with my McDonald's instead of just one.
we need more
Soo interesting that tecno mages existed at some point in time.
the stuff Travelers Tales did here with Sonic R is the reason I believe the Saturn far exceeded the original Playstation in capability.
Absolutely do want to see how the scu chip coding worked.
I am wondering did the x68k chip play any role in this game? If not, why not? Since it was still relatively a capable (not powerful) chip that could contribute some to the game, like drawing hud, mixing, etc
So the VDPs werent actual GPUs in the sense that we'd think of them now, they just draw the screen output? They just display whatever objects are given to them more or less? Just trying to understand how this machine worked.
From what I understand, the CPUs give information like vertex coordinates, lighting and textures to use, and the VDPs do the actual rendering, somebody correct me if I'm wrong
Can you show us how the Sega Saturn programming software looks like?
Meanwhile, the PS1 had just a CPU and a GPU and it was much more popular than Saturn.
The PS1 also had a better install base for 3D games than the Saturn.
I wonder if Saturn lost the console war because programmers said "I cant be arsed to code for this, I will just do N64 and PSX ports, they're both running 64 bit MIPS, that should be straightforward enough"? :p
definitely a contributing factor, but the damage was done long before with the mega cd, certainly 32x 6 months prior, and then that early 'surprise' launch that pi**ed off most retailers, and publishers before the 'war' even started.
@@BuzzaB77 I would concur, especially as the PS2 is allegedly as complex to code for, but had the PSX success to build upon.
No, they lost because SOA released the Saturn 6 months early, making magazines covering the September launch date look like idiots, and angering retailers who were not given Saturns for the early launch. Consequently, many retailers didn't carry the Saturn at all, so many gamers never saw a Saturn in their stores to buy if they wanted one. And most of the gaming press took a hostile stance against Sega for the next two generations because they were lied to about the launch of the Saturn. That and SOJ's boneheaded decision to produce far fewer Saturns than consumers demanded are what did the Saturn in. They did that because they lost money on each console sold, and they were so obsessed with staying in the black that they would rather produce half as many units if that meant staying profitable that fiscal year. What that did was send a signal to developers that the Saturn would have a small user base by design, because even if more customers wanted a Saturn than a PlayStation, they couldn't get one. So of course developers focused on the PlayStation because they could sell more games on it, because Sony didn't put a ceiling on how many consoles they wanted to sell. The launch and the under-production are what did the Saturn in. Any other issue was minor and could have been overcome, including its difficulty to develop for and the failure of the 32X.
Also, the PlayStation ran a 32-bit MIPS, and the N64 was even harder to develop for.
@@BuzzaB77 The Sega CD did not damage Sega going into the Saturn, but I concur with your other points.
@@geniedumal2974 Sega made such great games and consoles but was such a dysfunctional shit-show behind the scenes, and always made baffling decisions.
Brings back memories
A nightmare you say? Ooh, nasty.
3.58 in sounded like boris johnson wrote that little sentence.
@2:34 that "height hack" comment tho :)
I understand a fraction of what you’re talking about but I’m fascinated nonetheless
Go forward. Nightmare!
I wonder how the transparent level was made.
Master and Servant? Was someone a Depeche Mode fan?
Interesting stuff, I wonder if this guy ever worked on non-Sega gaming systems such as the PlayStation 3.
It's always struck me looking at the specs that the Saturn should have been at least 1 1/2 to twice as fast as the PS1 hardware wise. It seems to me that the only thing it lacked were proper developer tools that would have allowed the less-than-stellar programers (sadly, not all programmers are as good as the Author 😋) to have properly used the hardware available. This same problem, speaking of coding for what amounted to an SMP system would come up a few years later when PCs moved to multi-core chips, etc.
This just isn't true. For pure textured polygon pushing, the PS1's custom GPU was EONS more powerful, feature rich, & flexible than both the Saturn's VDP's combined. "3D" on the Saturn had be achieved at all with really clever sprite manipulation (hence why it uses quads as the primitive vs the standard triangles. They're really just individual 2D sprites with some clever use of scaling & rotation), as the hardware was almost entirely designed from the ground up for 2D graphics. (Whereas the PS1's video processor was pretty much the exact opposite, with 3D being by FAR the primary focus). The Saturn as a whole was extremely powerful in a raw calculations per second kind of metric, but when it came to running 3D games it tended to fall flat on its face.
@@Cooe. In terms of GPU drawing the Saturn could have done what the PSX did if only it allowed textured triangles with Gouraud shading, the Saturn was almost there but not quite with its quirky rectangle sprites. Sony had to bolt on a "Geometry transformation engine"(GTE) CPU-based co-processor to calculate 2D coordinates for the GPU from 3d vectors, a lot of Playstation's 3d capability was done by software on the CPU, unlike GPUs of today.
@@SerBallister That's a whole lot of "whataboutism" if I've ever heard any. The PS1's design was as explicitly 3D focused as could be ANY console design at the time it was done (developed over ≈ 1991-1994).
Sony was breaking new ground in so many areas for a mass consumer product (aka not a >$10,000 SGI workstation; with the GTE in particular helping to push things forward) that of COURSE they'd be missing some things we'd later traditionally associate with explicitly 3D focused rendering hardware. I'm sure if Sony had had the benefits of hindsight, endemic affine texture warping & such wouldn't have been a thing ofc, but that doesn't mean the PS1's hardware design wasn't focused around polygonal 3D first & foremost (again, unlike the Saturn's).
And ofc after both, Nintendo would then take the "it's a 3D hardware design for a 3D polygonal gaming era" to the inevitable extreme. This as the N64 design done w/ SGI was basically the exact opposite of the Saturn's.
The N64 was built almost exclusively for textured polygonal 3D & as such was absolutely STUPID powerful at polygon pushing for 1996 (at launch, the N64 & its SGI developed "Reality Engine" kicked the ever-living ASS out of even the highest end gaming PC's w/ their quaint little 3dfx Voodoo 1's as far as RAW 3D textured poly pushing power was concerned), but was absolutely dogshit at high-res 2D rendering.
Hence why the N64 library is full of expansive 3D platformers & action games instead of the Saturn's fighting games, JRPG's, & assorted Japanese obscurities. PlayStation otoh neatly split the difference between the other 2 consoles in design focus/prowess, even if 3D was definitely still Sony's prime priority. The Saturn otoh was a next-gen 2D system that Sega desperately tried to jury-rig for the "3D era" at the last minute by expensively just throwing a bunch more already existing silicon at the problem (aka, "if we're gonna do 3D by sprite manipulation, then its gonna need at LEAST another pricey VDP to not COMPLETELY choke & die", & so on).
@@Cooe. I think you misunderstood, I was talking about the GPU as a discrete chip ("... in terms of GPU drawing"), on both systems they aren't that far apart in ability, the ps1's GPU is a 2d triangle drawing GPU with no concept of 3D, which for me puts it closer to the Saturn than one might think.
The PS1 as a system had 1 additional piece supporting hardware located outside of the GPU for 3d acceleration.
Everything else the PS1 had like table based Z-sorting and that janky tesselation it did was done entirely in software on the CPU.
It's interesting because it wasn't a truly integrated hardware 3D pipeline, unlike every machine that came after it starting with the N64.
@@SerBallister Again, this is absolutely fucking nonsense. The Saturn's VDP's & Sony's co-designed with Toshiba GPU have next to nothing in common outside sharing basic sprite manipulation capabilities like rotation & scaling.... The Toshiba chip was EXPLICITLY designed from the jump as a dual-purpose 3D & 2D graphics processor, with triangles as the fundamental primitive for polygons & a largely normal 3D rendering pipeline (even if it's missing PLENTY of steps we'd consider necessary in more modern 3D rendering hardware. Literally the only 3D hardware on the planet at the time of the PS1's development with widespread use which had a Z-buffer w/ culling capabilities & all the other good stuff you mentioned were >$10,000 SGI workstations [& these capabilities wouldn't end up in a console until the SGI developed N64 ofc]).
The Saturn's VDP was designed from the ground up EXCLUSIVELY as a 2D sprite pushing MONSTER, until late, LATE into the Saturn's development when Sega realized they'd need to figure out how to make their already finalized hardware (as far as the chip designs themselves; aka there was gonna be no "redesigning the VDP for native 3D") work with polygonal 3D.... Which they did by literally throwing another VDP at the problem & brute forcing the "3D" with sheer sprite pushing/manipulating power & really clever use of what was BLATANTLY a 2D graphics engine/pipeline.
I'd love to see a video series on how assembler relates to C, C++ etc. I primarily code in C++ and C#, so when I look at C code you're written, it's a little more complex than the code I write, but I can see what you're doing in a given snippet. When you show assembly, I'm just lost. Best I can do in assembly (and only x86 assembly at that) is perform operations on arbitrary numbers with mov and add/sub/div/mul commands etc. Anything above that? No chance. I could maybe write you a basic calculator, but that's about it lol
I guess a big question I would have is did hardware manufacturers back then give you datasheets on how to send commands to the various components and red input etc? Or did they just hand you the dev kit and just expect you to figure it out? I ask because I've done a bit of work with PS4 development with a dev kit at the university I teach at, and they provide a COLOSSAL amount of documentation on the internals and how to use the various abstraction layers built into it so you can write code to run on it. Of course, you wouldn't write code in assembly for a PS4 or you'd still be working on one game 50 years from now, but in theory you *could*. I'm just curious how, say, the C++ instructions I write for it convert into assembly, even at a basic level to give me an idea.
We have a separate lecturer who teaches the low level stuff like assembly, and I teach the more creative stuff like game design and high level scripting, but I'd love to get an insight into how our two disciplines relate.
Download flat assembler by Thomasz Grysztar and his programming guide, flat assembler comes with some example programs to help as well.
Was that called the "servant CPU" at the time, or was it "slave"? Real question.
Slave, you can see it in code.
Political correctness requires people to censor everything at this point.
I work at a software company and we're renaming everything
Ohhh~ politically correct everything is TIGHT!
No? You don’t think it’s a good idea?
Nah, it’s actually VERY stupid
Oops!
Oopsi!
It's slave.
>political correctness
Well, well, well, are YOU a politician? I am not.
Guess we are excempt.
I mean i didnt like sonic r because i couldnt control it at all but its very interesting to learn how you made it
0:48 Are you sure it was SRAM and not ROM - you said SRAM keeps data after its powered down. That is true of ROM, not SRAM.
How is it possible to write and compile a program in two languages (assembly and C)?
The compiler takes care of interpreting the higher level language (C) and also noting directives to the compiler to inline/inject assembly directly into the binary before creating the final output binary.
If the ASM code and C code are targeting different CPUs / machine languages, the tool chain may cross compile (or use specific definitions) for each chip.
I love these videos ❤
Fascinating stuff. The Saturn architecture looks super complicated. Would love to see more.
How would you have developed Sonic R on the PS1?
Maybe a video like this comparing how it would have been done on the psx?
I feel like I've never heard someone refer to a slave cpu as a "servant cpu". Doesn't really roll off the tongue.
Sound better than slave
The renaming of "slave" has come up recently because some people claim that it has a racist connotation. I think that's ridiculous, but I wouldn't mind if servant became the new term.
@@sswpp8908 Yes, servant sounds good. I don't care much but sounds more "voluntary" than Slave.
Gotta be politicially correct these days lol.
@@lucassantossj a slave cpu isn't really voluntary though
What I don't understand is this kind of thinking behind the Saturn archeticture was not even prevalant circa 1986/1987 when the Genesis project was taking shape...you never hear of any developer complaining how bad a system that was to work for yet for the Saturn somehow Sega just did the complete opposite at a time when it wasn't about just Nintendo any more, but the new kids on the block as well: Sony..
My gosh this was overly complicated, yet Sega Saturn was heavily underappreciated, along with Sonic R.
By itself it looks like grandfather off multi-CPU processing, with manually assigned processing instructions. Wild! While PC world statred to get dual-core processors around 2000's.
I really think they should have delayed release and added a better 3d based chipset.... with the backwards compatibility possible with the 6800 and extra ram expansions that can be used in the cartridge port it could have been great...
Do you know about the 32X? Was it even worse to program for?