Ponut
Gear Supporter
I wanted to make this a formal write-up summary, going over the uses of the SCU-DSP & the things I've bothered to do with it, in detail. However, I'm running short on time in my life so I'll have to make it quick.
First: Should you be reading this? What is your level of understanding?
This is a question that I start with just to try and touch base with you, the reader. I am going to talk about computer science stuff: architecture, pipeline, bits, bytes, data types, memory bus width, even/odd addresses, and pointers.
If you do not have a computer science background, this post will not be useful to you. Either close the tab now, or read on with caution.
And even if you do have a computer science background, I have a further filter for you:
Do you know what these are expressing? Don't have to answer in the comments, just think about it.
If you get it, that's good. You have a level of C mastery that means you might actually be able to make use of the DSP.
I am being pedantic about this just because I want to make a point: the SCU-DSP is difficult to use.
It is so difficult that fine-tuning your program written for the SH2s in C is going to net you a far greater gain than learning the SCU-DSP.
I would even argue that even at the point where your code is logically where you want to be, messing with compiler flags is a better use of your time.
This of course assumes you just want to "GSD", as it were. If you want to learn something unique and fun in programming, by all means, go ahead.
Second: What is the SCU-DSP?
The Saturn actually has two processors referred to as "the DSP". There is the DSP inside the Saturn Control Unit / System Control Unit (SCU), and the DSP inside of the Saturn Custom Sound Processor (SCSP). These two processors are COMPLETELY DIFFERENT. They do not function even remotely the same way. It is extremely important to specify which DSP you are talking about. Today, we are talking about the SCU-DSP. The SCSP-DSP is a piece of hardware covered by a different discipline, that being a digital audio engineer.
What you see above here is a logical diagram of the SCU-DSP.
...
Yes, that's really it. That's the whole thing. I'm not kidding, it is that simple. Some of you of course are saying, "What?! SIMPLE?!"
Well, trying to fit the logical diagram of something as slow as a M68K onto a single sheet of paper is a challenge. Go look up a diagram of one; it's probably going to have to span multiple entire pages. I think a bigger note is that the manual for a 68K might be hundreds of pages whereas the SCU-DSP is a part of the SCU manual taking up 86 pages. The point of this is that while using the SCU-DSP is complicated, it is not because the processor is complicated. It just requires intricate management by the programmer to function.
The core feature highlights of the SCSP-DSP are as follows:
A 48-bit MAC unit and ALU (Accumulator) unit with the processor in total running at about 12.7 MHz.
A simplified RISC-like instruction set where one instruction is executed in one clock cycle.
1KB of program RAM, at four bytes per instructions, allowing a single program to be 256 instructions (program changing covered later).
Technically 1KB of on-chip ""RAM"". This however is not RAM, it is indexed access memory, split across four banks of 64 x 4 byte entries.
A very wide instruction bus, with the capacity for a single 4-byte instruction to execute five simultaneous actions.
A "pipeline" wherein the instruction after the current one being executed is pre-loaded and prepared for execution-in-sequence.
Due to the extremely wide instruction bus, the SCU-DSP can only be programmed for in its own assembly language.
This is not Assembly like you will see for most of any other processor, however, if you've worked with a 56K before, it's probably familiar.
Here is a primitive program example written using the SCU-DSP's Assembly, highlighted via a language plugin for notepad++ to color-code the various instruction bus of this processor.
What you will notice in this primitive (which should run in the DSP simulator), is a conditional jump. Unlike the SCSP-DSP, the SCU-DSP has a feature of critical usefulness and that is a number of logic flags and conditional instructions. Of course, you probably haven't looked at the SCU-DSP's instruction set yet, so that screenshot doesn't make sense. I am just using it to highlight that the SCU-DSP is a fully functional logical processor. In other words, this chip is more like a CPU than a DSP.
I will now insert a link to Antime's Saturn page, where you can find the SCU-DSP manual.
I have no idea where the hell I found these, but they could be on Antime's page too, but these are DOS tools.
These tools (being the dsp-simulator and the dsp-assembler) are needed tools to test and assemble DSP programs.
They must be run in DOSBox. Also, you'll need their respective manuals. (See Attached Files)
Okay, those are the basic footnotes about the SCU-DSP. I will not cover its explicit architecture as GameHut already did a video on that. I will also attach a file that is a sample program demonstrating the SCU-DSP's logical capabilities in a program that allows the DSP to divide numbers using recursive logic and a root seeking algorithm (i just googled the method, nothing special). If you intend to understand how it actually works & write code for it, bouncing back and forth between sample code and the manual whilst writing your own program is more helpful than what I could cram in here.
First: Should you be reading this? What is your level of understanding?
This is a question that I start with just to try and touch base with you, the reader. I am going to talk about computer science stuff: architecture, pipeline, bits, bytes, data types, memory bus width, even/odd addresses, and pointers.
If you do not have a computer science background, this post will not be useful to you. Either close the tab now, or read on with caution.
And even if you do have a computer science background, I have a further filter for you:
Do you know what these are expressing? Don't have to answer in the comments, just think about it.
If you get it, that's good. You have a level of C mastery that means you might actually be able to make use of the DSP.
void function(void(*thing)(void))
unsigned int notiCommand = 0x4A<<25 | ((unsigned int)dsp_noti_addr)>>3;
I am being pedantic about this just because I want to make a point: the SCU-DSP is difficult to use.
It is so difficult that fine-tuning your program written for the SH2s in C is going to net you a far greater gain than learning the SCU-DSP.
I would even argue that even at the point where your code is logically where you want to be, messing with compiler flags is a better use of your time.
This of course assumes you just want to "GSD", as it were. If you want to learn something unique and fun in programming, by all means, go ahead.
Second: What is the SCU-DSP?
The Saturn actually has two processors referred to as "the DSP". There is the DSP inside the Saturn Control Unit / System Control Unit (SCU), and the DSP inside of the Saturn Custom Sound Processor (SCSP). These two processors are COMPLETELY DIFFERENT. They do not function even remotely the same way. It is extremely important to specify which DSP you are talking about. Today, we are talking about the SCU-DSP. The SCSP-DSP is a piece of hardware covered by a different discipline, that being a digital audio engineer.
What you see above here is a logical diagram of the SCU-DSP.
...
Yes, that's really it. That's the whole thing. I'm not kidding, it is that simple. Some of you of course are saying, "What?! SIMPLE?!"
Well, trying to fit the logical diagram of something as slow as a M68K onto a single sheet of paper is a challenge. Go look up a diagram of one; it's probably going to have to span multiple entire pages. I think a bigger note is that the manual for a 68K might be hundreds of pages whereas the SCU-DSP is a part of the SCU manual taking up 86 pages. The point of this is that while using the SCU-DSP is complicated, it is not because the processor is complicated. It just requires intricate management by the programmer to function.
The core feature highlights of the SCSP-DSP are as follows:
A 48-bit MAC unit and ALU (Accumulator) unit with the processor in total running at about 12.7 MHz.
A simplified RISC-like instruction set where one instruction is executed in one clock cycle.
1KB of program RAM, at four bytes per instructions, allowing a single program to be 256 instructions (program changing covered later).
Technically 1KB of on-chip ""RAM"". This however is not RAM, it is indexed access memory, split across four banks of 64 x 4 byte entries.
A very wide instruction bus, with the capacity for a single 4-byte instruction to execute five simultaneous actions.
A "pipeline" wherein the instruction after the current one being executed is pre-loaded and prepared for execution-in-sequence.
Due to the extremely wide instruction bus, the SCU-DSP can only be programmed for in its own assembly language.
This is not Assembly like you will see for most of any other processor, however, if you've worked with a 56K before, it's probably familiar.
Here is a primitive program example written using the SCU-DSP's Assembly, highlighted via a language plugin for notepad++ to color-code the various instruction bus of this processor.
What you will notice in this primitive (which should run in the DSP simulator), is a conditional jump. Unlike the SCSP-DSP, the SCU-DSP has a feature of critical usefulness and that is a number of logic flags and conditional instructions. Of course, you probably haven't looked at the SCU-DSP's instruction set yet, so that screenshot doesn't make sense. I am just using it to highlight that the SCU-DSP is a fully functional logical processor. In other words, this chip is more like a CPU than a DSP.
I will now insert a link to Antime's Saturn page, where you can find the SCU-DSP manual.
I have no idea where the hell I found these, but they could be on Antime's page too, but these are DOS tools.
These tools (being the dsp-simulator and the dsp-assembler) are needed tools to test and assemble DSP programs.
They must be run in DOSBox. Also, you'll need their respective manuals. (See Attached Files)
Okay, those are the basic footnotes about the SCU-DSP. I will not cover its explicit architecture as GameHut already did a video on that. I will also attach a file that is a sample program demonstrating the SCU-DSP's logical capabilities in a program that allows the DSP to divide numbers using recursive logic and a root seeking algorithm (i just googled the method, nothing special). If you intend to understand how it actually works & write code for it, bouncing back and forth between sample code and the manual whilst writing your own program is more helpful than what I could cram in here.
Attachments
Last edited: