Coding for the World's Trickiest Chip - SEGA's Saturn DSP (CODING SECRETS) 

Saturn homebrew dev here. The leaked English coding docs for the Sega Saturn are known to be full of errors as they were rushed through translation or something.

This reminds me of a quote Jon made in 1997: "while the PlayStation was easier to get started on ... you quickly reach [its] limits, whereas the Saturn's "complicated" hardware had the ability to improve the speed and look of a game when all used together correctly." Judging from the mastery of the DSP, it seems so. I mean, having an entire 68K all to yourself just to produce sound alone is pretty incredible.

I burst out laughing when he said "This is where it gets more complicated". I got lost 3 minutes before that.

Very well explained indeed. As an oldtimer PSX and Saturn programmer too, I can appreciate how challenging it is to explain plainly the very concept of simultaneous operation in the different units of a DSP. Something interesting is that the DSP multiplier unit actually performs the multiplication operation between X and Y every cycle, and the instructions are used to tell the unit at any point in time whether one is interested in the result or not... At any rate, the TMS C6000 DSPs are tricky beasts too, as different operations take a different amount of time to complete (like many other pieces of hardware), but the system does not "wait" for an operation to complete before moving forward (pipelining), and one has to (when programming in assembly) take that delay into account to avoid using a result at the wrong time ;)

Very interesting. Thanks for presenting that in a somewhat understandable manner. I was able to follow but of course that doesn't mean my mind fully grasps it. Congrats on learning the Saturn so well. I had heard that Sega kept a lot of the more complex coding abilities for themselves so that their games looked better than 3rd party games. I don't know how true that is, but it's what I read in magazines back in the day when 3rd parties were complaining about programming and Sega not exactly being helpful in their documentation or programming tools.

The visual representations really help in making the code easier to understand. Thanks Jon!

As somebody who has only barely dabbled in the fundamentals of coding, seeing a breakdown of hardware on such a technical level like this is both fascinating and humbling. It captivates me with how much mastery of the material you and other programmers needed to have at the time for such a dizzying machine while also being awe-inspiring to the point where I want to try and learn even more about this. Thank you, Jon!

Oooh, programming that DSP sounds like a fun challenge.

Impressive chip but good god I can't imagine dealing with this

This system is so powerful, it could steal the SOUND CHIP to aid in 3D graphics.

I only understood about 40%, but when I first started watching your videos I barely understood 5%... Your videos have helped me learn a lot

There's something fascinating when you watch a video about stuff you can't even grasp.

SEGA and Yu Suzuki and the AM2 team were so elite with programming back then. SEGA built the best arcade experiences back then and tried to bring those experiences home. Sadly they built hardware that was so complex for programmers that only the very best could use it to its full potential.

Oh neat, I didn't realize there was a VLIW core in the Saturn. It seems Sega included every possible kind of CPU they could, 2 RISC (SH-2), 1 CISC (68K), and the VLIW DSP core. Truly crazy hardware design. Thanks for sharing!

The main problem with the DSP was the amount of time it took to load the matrix and set up the DMA for transforming the points. For transforming a small number of points, it was faster just to do it in the main CPU. At least that's what I found when porting Assault Rigs from PlayStation to Saturn and trying to get it to run at a reasonable frame rate (which kind of failed on the busier levels!).

After watching the video, now I know that I'll never have the expertise to make a simple game, even though I'm a developer myself... Coding games in the 80's and 90's were the real deal, with all those people (especially you Jon) digging into those pieces of hardware to get the maximum performance. EDIT: I started programming at age 20, I got my first computer the year before and I was determined to become a good developer; I loved playing games and I was very interested in learning C language to understand the source codes I downloaded from the Internet (about 2000-2001) including some Net Yaroze games I enjoyed playing. I was very proud of myself when I completed a playable version of Tetris in my first year of C learning, but then I started working on a consulting firm and time passed... and now I feel that I have wasted all this time. So when I see this kind of video, I can't help but thinking that I could have learnt those things instead of letting time go. It's too late now to revert those bad decisions....

Early 3D modeling is very fascinating. Now it seems much easier, back then, probably most coding was done manually.

Nowadays we have our fancy compilers do all that multi-threading nonsense for us. Really makes you appreciate it.

I enjoy assembly programming, but I don't get to do it very often, so this video was very enjoyable.

Wish this video existed about 2 months ago :( My students had to cover this topic (use of Matrices in 3D computer graphics) for an assessment task. I'll probably use this video as an example of application of the technique next year. Cheers :)

That's fascinating, I've never seen that form of paralellization. This kind of code really requires comments for every line to be maintained though, lol.

FUN FACT. a game on Saturn called MDK was named after the memory of the DSP chip as it was a continual game where the accumulated numbers changed the visuals on screen. Each level just kept going and going until a time clock ended. Each level was coded with a single start “code” and the Saturn itself filled in the level, much in the same way a procedural game is made

I can't wait for the follow up video. What I like most about the saturn is it gives developers so many obscure options to get the results they want. You're made to manage exactly what part of any processor is handling a specific segment of code while another part of that same chip is processing two entirely different things. They don't make hardware like it, a highly specialized hyper paralleled system that evolves 2D game play to the next level and pushes 3D in a way the inter-mingles with what it can do in 2D. Antiquated and advanced, simultaneously! That's why I love learning about it. It's so highly specialized that it earns its own understanding.

This was fascinating, it would be great to see more in-depth videos like this just to understand more about how the Saturn hardware works.

I might know of one piece of silicon that might be harder to code for: The iAPX432. I think I might be the only one here thinking "DAMN! THAT CHIP IS AWESOME!".

Nice implementation of a VLIW processor. Maybe they could've implemented Tomasulo's algorithm to simplify programming but still get a good performance. Anyone has any idea why they didn't use it? The algorithm was developed in 67, so it was already around by the time of the Saturn.

Would LOVE a video on the DSP and the issue with the dev docs! Thank you so much for this!

I just took a class on Assembly and computer organization. The fact that this makes sense to me makes me so happy! 🤓

VLIW in action, pretty much. Mad respect to the team for dealing with all that.

I cannot thank you enough for this type of information. Thank you for explaining it in a way where someone with no coding knowledge can somewhat understand.

Your works have inspired me to become the senior 3D/VR artist that I am today. I just wanted to thank you. Seeing the face of the man behind so many of my favorite games back in the ‘90/‘00 was amazing, knowing that you are a nice person (all the efforts and the charity you are doing) was once again inspiring. Kudos my distant and long unknown mentor, kudos.

I would call this process "manual hyperthreading" since you have to program it yourself. Pretty interesting concept for something made in the mid-90s

This is the hardware of my nightmares.

Sega Saturn is the console i think of when i think of gaming it captured me in 96, just awesome. its the gift that keeps on giving.

Wow great stuff Jon keep it coming, you explained the DSP so well. I’ve not touched Assembly Code since second year at Uni, it was great fun playing around with it.

Awesome quick overview! I love the more technical videos you put out

Gosh, this is just a masterpiece! I wonder if modern games have something like that, even not exactly like that, but still just beautiful and complex. Also, i just love how you title everything "Impossible %THING%"

Loving the new logo, Jon! The Sega Saturn really is an enigma when it comes to programming.

Hi Mr. Burton! After roughly 26 years, I've finally finished Sonic 3D Blast on Genesis. And with all emeralds! I wanted to let you know I enjoyed the game and that your videos helped me appreciate all the work that went into it. Thank you to you and the team for everything y'all did!!

Looks like this would make a great Zachtronics game, looks very similar to puzzles in TIS-100

I Like how i watch the video and still didn't understand anything and still get impressived

DSPs are very common in mobile phone base stations. I know at Ericsson they had entire achitectures built with many many of these and c code complied into VeryLongInstructionWord assembly to program them. So yeah, this is not ”acient technology”, it is used every day when you call your mother or whatever.

So I’m interested, given that you seem to know the Saturn hardware well, what you think the most accomplished, commercially released use of the hardware, and therefore the DSP, actually was. You’ve probably answered this question a million times!

I like how you show the code/diagrams while also giving an oversimplified explanation. Those who know what they're looking at can stay interested and (i think) those who don't really know can follow

Parallel programming on Assembly ? What kind of sorcery is that ???

Programming for DSPs is fun! I never touched the Saturn DSP, but in the past spent some years writing code for Texas Instruments C5000 and C6000 DSPs. They have all kind of weird hacks not usually present in regular CPUs, like guard bits in the accumulator, modulo addressing (extremely useful to implement digital filters), specific loop instructions to avoid branching (causing the pipeline to get emptied), instruction buffers inside the DSP to avoid reloading looping code each iteration, duplicated data buses... If you write C code, the compiler is unable to use many of these (especially when coding for fixed point DSPs), so you end up having to write the computation intensive code in assembly language, and you need a good grasp of the hardware details to take advantage of many of these weird details.

I don't comment often, but I absolutely loved this video. The technical aspects of programming video games truly fascinates me, and you've made it fun to watch!

That actually makes a lot of sense and is really cool when you think of the potential through put and modular usage of that pipeline

Crikey, coding that must have been a real brain twister - what can and cannot be done in parallel, which result do you need before some other calculation uses it, etc. I only hope there was a repeating pattern you could grasp. p.s. Extra thanks, considering what happened in Malibu 👍

6:49 >The Impossible DSP Will it be a video on DSP's ability to somehow stay afloat despite his bad financial skills and general ineptitude?

Currently looking into DSP coding on Saturn. Thank you so much for making my work much easier!

Either you take and precisely organize meticulous notes or you have a crystal clear memory. Either way, thank you for this incredible breakdown of a complicated process.

Using 2 broadband engine cells on the early PS3s were a pain

Ouch. That gives me a headache. Managing That level of parallel code is not a pleasant experience. (It's bad enough when you're dealing with a full symmetric multiprocessing system - but this is much like hyperthreading - except a CPU with hyperthreading manages code balancing by itself, where here you have to code it directly.) The n64 also had a bad reputation for being difficult, but looking at why that was, I don't think it's even remotely comparable. The problems on the n64 are related to high level optimisation, and some frustrating bottlenecks in the architecture that required careful workarounds. Also Nintendo absolutely refused to provide microcode documentation for the Graphics processor until quite late into the system's life, meaning you were entirely dependent on the handful of pre-written routines Nintendo provided to get any 3d acceleration at all. - easier, sure, but not conducive to getting the best out of the system. In hindsight looking at what the system contained it's not at all in the same league of complexity. You had a MIPS 4300i CPU with a floating point unit, and a Graphics chip that consisted of a DSP with fixed function 3d logic, and a second MIPS 4300i core. This core differed from the main CPU core only in terms of having a large dedicated cache memory, accessing memory differently in general, and having a vector co-processor in place of a floating point co-processor. The instruction set was obviously much the same. Leaving aside not being given any low level documentation at all, the difficulty seems to arise not from the complexity of any given part of the system, but the interaction. The Main memory is RAMBUS ram - which is very fast, but has high access latency. (meaning working with RAM efficiently is tricky), the main CPU is incapable of accessing memory independently, so it has to get the RCP (aka the graphics chip) to do it on it's behalf. The texturing unit has a 4 kilobyte 'cache'. Which is just about enough to store a single 64x64 texture at 8 bit colour depth. (only 32x32 if you have mip-mapping enabled). This wouldn't be so bad, but despite being called a 'cache' it's manually controlled by the programmer, and in standard microcode implementations isn't used very effectively. (a major factor in why so many games appeared to have such low resolution - since most developers lacked the documentation and skills to write custom micro-code; Many of the games that seemed to defy the odds later in the system's life did so by using custom microcode.) The cpu core inside the graphics chip, which does such things as geometry transformation and the like cannot run code or work with data directly from main RAM, it has to be loaded into the local cache, which isn't that large, relatively speaking, so the size of code running on this core has to be considered. The pixel fill rate is about 60 megapixels a second. Which sounds like a lot for a system from that era, but becomes a big problem when you consider the system does multi-texturing, bilinear filtering, perspective correct texturing, anti-aliasing and environment mapping, amongst other things, all of which eat up a LOT of fill rate compared to what the system has to work with. (other systems of that era didn't use such effects, and it's estimated because of this the n64 was typically doing something like 5-8 times as much work drawing a single onscreen pixel as say, a playstation was doing.) Essentially, the n64 was frequently being used to render a level of graphical effects that objectively speaking were out of it's league, and probably shouldn't have been attempted on a system with such relatively low performance. So, no individual element of the n64 was that complex, and each part individually was actually quite powerful, but the pieces don't work well together, and the system is full of performance choke points. Thus, what makes it a pain to work with is that it has very high peak performance, but lots of bottlenecks that drag it's average performance into the gutter. In other words, the system is a high level optimisation nightmare. Still, it's pretty clear that it doesn't even come close to the Saturn, and the Saturn's reputation for complexity is well earnt. Just optimising DSP code alone already looks like a nightmare comparable to optimising n64 code in it's entirety... Yeah, I do think you're right there. May just be the trickiest chip seen in a mainstream product. (Can't say trickiest EVER, because I'm sure there's some obscure supercomputer chip or something that's worse. XD)

I am an electrical engineer and digital hardware is my favorite area, so I found this especially fascinating! Even cooler is how you managed to take advantage of the insane and convoluted hardware. I think I followed a good bulk of it, though I'd probably have to watch it again to fully grasp all the math steps going on in each calculation. This was a really neat insight into how you managed to program so much to work at once, all the while having to deal with such a complicated piece of equipment. Very well done!

That was really interesting, thanks for this! I'm looking forward to 'the impossible DSP' video too.

Wait so you can read from a register and write to it on the same cycle without the data becoming inconsistent? I wonder if the "impossible" bit from the manual is related to that.

Single Instruction Multiple Data (short SIMD) stuff was never really easy. Even today compilers sometimes struggle with it. For my job i needed to learn NEON assembly for our ARM processor. It's different as only one instruction is executed which handles a whole matrix of data instead of the DSP which handles multiple instructions at the same team. But still the the amount of different instructions of NEON was so high that the current GCC was not capable of correctly compiling code for this thing. Also lot's of register magic happened as this thing got 64 Bit Registers and 128 Bit registers which weren't other registers but instead the 64 Bit ones concatenated together. Lot's of thought and documentation was needed to maintain that monster. Keep up the cool videos sir.

I love the technical explanation!! Thanks for sharing and keep up the good work.

Very interesting. Thanks for taking the time to make videos like these.

Thank you for this video. I have to say I'm surprised the Saturn requires such complex instructions, even though I know very little about computer programming. I seriously thought you guys had some sorts of tools made by Sega to help your work, but it looks like programmers had to start from scratch.

Dun-du-du-dunnnnnnnnnnnn! I got you. Try programming for the Atari Jaguar. It was infamously hard to program back in the day, which is one of the reasons it got next to no 3rd party support. Try seeing why, at the very least.

So glad to see you back at it. Good show as always.

Absolutely fantastic video can't wait for the next one!!

WOOOOOOOOOOOO!!!!!!!! This is the kind of GameHut I love most!

Thanks Jon, please do follow-up.

Love this channel! Always something interesting about programming but with the context of retro games 👌🏻

I'm a third year university student, and I'm just now learning to program in assembly code. Your videos have inspired me to take up a project programming for the SNES. The technical details for things on the channel are always amazing!

How does the DSP does the multiplication and move a new value into the input registers at the same time and maintain consistency between if the original or new value is used? I only takes one clock cycle but surely the operations can't be truly concurrent? Are they sequential between themselves?

Have you ever worked with Broadcom DSPs?

We NEED Saturn's Shenmue prototype! Let's imagine that it would've been released somewhen in 1998: Is it conceivable that it could achieve stable-ish 30 fps, considering by that time-line, they'd spend more than 4 years on it...?

Possibly your best video yet. Keep up the coding secrets!

I'm always impressed by your videos and efforts to tell us how you guys programmed games for SEGA's consoles back in the 90's. At the same time however, it makes me wonder what made the Saturn so much of a hassle for other studios to develop while there are things such as Sonic R, Tomb Raider and even early development versions of Shenmue and Sonic Adventure running on that thing.

1st 😎 Saturn was such a nice Machine and i like your Videos alot mr. Game Hut 😊

The way you visualized it made a difficult thing much easier to understand, so thank you for this great video.

Fantastic presentation! Thank you, can't wait to see the follow up!

5:50 If this is done in parallel, we have a race condition? Moving a value to the X register and at the same time trigger the multiplier sounds dangerous.

I don't care what anyone says programming in assembly is a real blast lol Anyways, I skimmed through the SCU documentation as well (because what else am I gonna do with my time?) and it seems that there is no issue with loading data from a bank to X&Y while also preforming the multiplication operation like some people seem to speculate; Sega themselves do it in some example code in the document "SCU DSP Assembler User's Manual". I have yet to find the actual "impossible" part of the code, maybe I'll keep trying to find it or I'll leave myself to be surprised in the future, we'll see.

Awesome video! And good to know you are all clear from the fires.

Awesome, the animations really help to understand the explanation

Oh I see! Actually no, no I don't. :)

This seems similar to what we called "FMA" today, but in integer only... funny to see today's generic CPUs mimicking DSPs like this in SIMD instructions to make better performance. What seems most complicated to me is all ALUs in that era are all integer only. My programming skills raised in modern days which CPUs already provided nice FPU functionality, even with robust SIMD instructions. But back then you have to use fixed point numbers which is basically just integers with an imaginary decimal. All these bit shifting, number overflowing things, make me headache just for imagine them... Programmers in this era really had hard days.

Looking at this makes me appreciate all the effort that Saturn developers put into their games, especially 3D ones, I wish I was this good at math.

Damn you and your teasers! Nice video - I love this stuff! Young'ns today don't know how good they have it.

Since you've also programmed the PS2, I'm curious as to why you feel that the Saturn DSP is harder to program than the PS2 EE.

If this was difficult to learn, imagine the Atari Jaguar coders doing 3D with so archaic and rare design with its two chipsets: "Tom & Jerry" (yeah, like the animation lol). But anyway, this is simply fascinating! I'm not a programmer but i can understand how difficult is (or was) learn the Saturn infamous hardware in general. It was more powerful than the PSX, no doubt, but it was rarely see that (Radiant Silvergun, Panzer Dragoon Saga, Sonic R, and some more, but not much examples unfortunely).

Oh the joy of parallel computing. Speaking from personal experience, it indeed is hard to get used to a multithreaded or even worse, a multicore environment especially if you are coming from a single core environment. When we started making games ourselves, everything was single core. Taking advantages of multicore, requires you to think completely different. You need to build your engine from the ground up with multicore in mind. And that’s difficult. That said, we could still offload a lot of lower priority or specialized tasks to other cores. Such as network updates, audio rendering, difficult calculations, particle engine updates (syncing with rendering is tricky), and various game systems that had a lower priority or could be updated out of sync with the main thread. For instance we had a sensory system that was complex, but could run “one frame behind” the main update loop. No one would notice. Offloading that to another core, was a massive gain. But the worst bugs arise when there is a race condition. I remember spending a week or two on an obscure audio bug on the Wii U that only occurred once every couple of thousand of samples. Reproducing the bug took hours; but always resulted in a massive crash. Nintendo obviously found the bug as well. So it was a big showstopper. After making a simulator that spawned thousands of audio samples each second inside the game, I managed to get this repro time to down to 5-10 minutes. Still not ideal, but enough to finally find the bug: some core initialization order and a critical section that was thread safe, but not if those threads ran on different cores... oh the joy... I still have nightmares of that garbled audio that was produced by running thousands of samples a second 😊

This is brilliant, finally i found someone who shows how console optimization actually works. And it's so great to see how each line of code is thought in conjunction with the hardware schemas, .because nowadays when we program, mainly in Pc we need to abstract so many things and pray for everything to work out in hardware, see how values ​​go from one place to another is somewhat comforting.

I assume that the DSP is decoding the 6 instructions simultaneously? In practice is works like a 6 stage pipeline, but in coding, you prime each stage of the pipeline, then issue instructions to perform an action for each stage, is this correct? What frequency did the DSP run at? I think you might get a kick out of the Parallax Propeller microcontroller, it has 8 individual cores with 512 longs per core. In practice, each instruction executes in 4 cycles, with shared memory instructions taking longer if you miss the access window. If written correctly, you can align code and memory accesses to ensure you hit the main memory on every access window, resulting in a true 20MIPS per core. The hub memory is 32KB with another 32KB of ROM containing a bytecode interpreter (SPIN language), SIN/COS/LOG tables, and a bitmap font. I recently got back into doing some coding on a DOS platform and writing inline asm to speed things up, programming the Propeller is a lot like coding for those old processors, but all of the goofy things like "why do I only have 5 general purpose registers when the 8051 has the first 1K as a register", and "why must I load a segment descriptor into a general purpose register first, before loading the segment register", are not present in the Propeller. All 512 longs of COG ram are registers and can be treated as instructions or data. There is no cycle penalty for byte or word memory access, and there are a quite a few non-conventional instructions. Best of all, each core (COG) has a video generator builtin, so you can easily generate high res tiled video output or low res bitmapped output, or high res low-color output (the HUB memory size is the constraint). You can do VGA or NTSC directly from the COG with just a few resistors for support components.

No wonder the Saturn failed: it was a nightmare to program!

Great job! I really look forward to the next video!

I actually understood what was going on when you explained it, but I'm pretty sure I would have had a really hard time figuring it out with just the documentation and some examples. Thanks for the really good explanation!

But can do you do it without collecting a coin

The Saturn is really powerfull. The weak point is the complexty to program in this board.

I can seem why this was difficult to code for. Strangely, though, I understood every bit of what you were saying and never got confused.

I'm not a programmer, so I couldn't make sense of a lot of what you were showing, but it was still facinating to watch. I still hope your videos benefit the Saturn homebrew community somewhat.

These are absolutely fascinating. And I thought the PS2's two vector processing units were crazy!

If it was this difficult to program, I can see why Saturn emulation has been so difficult to pull off... (that and the fact that the internal ROM of the SH-1 that controls the optical drive was only extracted fairly recently and AFAIK isn't even public or supported by any emulators yet)

Thanks forma all your clear explanation and please, keep doing that kind of video. I love the "retrotech" explanations

Really enjoyed the animation that made the pipeline immediately clear!