Playstation and Saturn (32-bit) memory tech

atomic837

Newcomer
I know that these systems have been analyzed to a great extent, and I've digested quite a bit of information about them in the last few years. One of the aspects that intrigues me greatly is how much the limited memory played into that generation of gaming. Most games were products of their limited memory space, and some were severely compromised because of it (later Playstation Capcom fighters). Both the PS1, Saturn, and 3DO had the same amount of main DRAM, but they differed somewhat is in the additional RAM pools for graphics, sound, and CD-buffer.

The PS1 had 1MB of VRAM used as the frame butter, CLUT space, and textures. It also had 512KB of Sound RAM with a decent compression solution (I've heard anywhere from 2:1 to 4:1). The Saturn had multiple discrete pools of VRAM, split up between the VDP processors which had its advantages and disadvantages. It also had 640KB of sound RAM, but no baked-in compression that I'm aware of. Additionally, there was 512KB of CD buffer RAM. The Saturn was also the only 32-bit system to dabble with ROM/RAM expansion cartridges (1MB and 4MB). The 3DO, as far I understand, had 1MB of VRAM for frame buffer/textures, but nothing else.

To start things off, three things I've always been confused as to how textures are stored in the Playstation's memory space. I've dabbled in various VRAM viewer utilities using PS1 emulators to get a better understanding of it. Obviously, the current frame's graphical assets must reside in VRAM, and I have witnessed how sprite data is often transferred to/from main RAM to the VRAM's workspace. What I'm not clear is this: do all textures/sprites have to be redundantly loaded/sitting in main DRAM or can some of those assets get loaded directly in VRAM and sit there exclusively? In other words, do all textures/sprites need to have a redundant memory space in DRAM even if they are actively loaded in VRAM? That would seem to be a waste of resources if it is, but I'm not clear if the CPU needs to keep tabs of those assets at all times.

Second, how do the Saturn's RAM expansion cartridges work? In the case of Capcom fighting games, I'm guessing that the cartridges hold vast amounts of sprite/character data that are streamed to the 2MB of system DRAM as needed, and then those are streamed to the Saturn's VRAM in real-time. Seems like that would be expensive constantly DMAing memory back and forth across the various pools of RAM, but the result seemed to work fine. Anyone have any insight on this?

Lastly, the 3DO seems to be limited to its 2MB main DRAM and 1MB VRAM. Does this mean that all sound data/samples had to share main DRAM space? While unsurprising give the age, that must have really been a tight squeeze getting an entire next-gen level game to fit inside.
 
I believe the sega saturn had 2MB of ram for general purpose. That ram is split between 1MB of Sdram and 1MB of Dram. Both Cpus could access this. But there was also a DMA controller that can access all 3 ram main busses without using the cpus.

I believe the VDP1 has 2 256KB frame buffer chips and the sound stuff had its own 512KB of ram.


I believe and I am not a 100% sure but I believe that the DMA controller could access the expansion slot and thus that is how you would gain access to the aditional 1-4MB of ram provided
 
Thanks for the replies above.

Does anyone have a good answer for my other question, "... do all textures/sprites have to be redundantly loaded/sitting in main DRAM or can some of those assets load directly from the disc into VRAM and sit there exclusively? In other words, do all textures/sprites need to have a redundant memory space in DRAM even if they are actively loaded in VRAM?"
 
Thanks for the replies above.

Does anyone have a good answer for my other question, "... do all textures/sprites have to be redundantly loaded/sitting in main DRAM or can some of those assets load directly from the disc into VRAM and sit there exclusively? In other words, do all textures/sprites need to have a redundant memory space in DRAM even if they are actively loaded in VRAM?"

Looking around, I found a lot of Saturn developer docs hosted here:

https://segaretro.org/Saturn_official_documentation

The Saturn Overview Manual Vol 1 (https://segaretro.org/images/8/84/ST-103-R1-040194.pdf) has an interesting block diagram on page 7.

7.PNG

It indicates that the System Control Unit (SCU) can transfer data directly from the cartridge to VDP1 or VDP2. This would make sense, as there were a number of games that used ROM or RAM carts to store extra graphics data.

From page 8: "SCU (System Control Unit)
The SCU controls all buses (A-bus, B-bus, CPU-bus) and functions as a co-processor of the main CPU. Because the DMA controller is loaded internally, character data can be transferred to V-RAM when the main CPU is operating.
"

8.PNG

The block diagram from page 7 indicates that the CD ROM subsystem is on the same bus as the cartridge port. The MPEG decompression add on unit is also shown as being part of the CD-ROM subsystem, and that would have , I think, sent decompressed sound and video straight to VDP2 and the sound block directly also via the SCU.

Therefore, I think it's quite possible that the CD ROM could have loaded textures into the CD ROM subsystem's 512KB of ram (where I think the MPEG add on unit may also have put video / audio), and from there transferred textures / sprites directly into VDP1 via the SCU. If any game would have done this, I think it might have been something like Panzer Dragoon Zwei, which would stream bosses (and their synth music and texture data) in during gameplay.

It would certainly have been possible to do it from main ram too, of course. And for games where CD ROM lag was too great, swapping data between vram <--> main ram would probably have been necessary. I believe 2D fighters did this.

Not got any more time to look into this currently, but my guess at answering your question would be .... maybe? Under some circumstances??

You (or someone else!) might have more luck with the plethora of docs at Segaretro than me!
 
That's a great observation. I've always been a bit perplexed at the rather large 512KB CD-Rom buffer in the Saturn (versus the Playstation's 32KB). That buffer might be the key in economically streaming in art/program data from the disc while the SCU frantically shuffles data into and out of the various RAM pools (to include the cartridge upgrades). A large enough workspace that can maintain a real-time stream of assets flowing through the system was probably a boon for the more advanced 2D fighters.
 
Looking around, I found a lot of Saturn developer docs hosted here:

https://segaretro.org/Saturn_official_documentation

The Saturn Overview Manual Vol 1 (https://segaretro.org/images/8/84/ST-103-R1-040194.pdf) has an interesting block diagram on page 7.

View attachment 6534

It indicates that the System Control Unit (SCU) can transfer data directly from the cartridge to VDP1 or VDP2. This would make sense, as there were a number of games that used ROM or RAM carts to store extra graphics data.

From page 8: "SCU (System Control Unit)
The SCU controls all buses (A-bus, B-bus, CPU-bus) and functions as a co-processor of the main CPU. Because the DMA controller is loaded internally, character data can be transferred to V-RAM when the main CPU is operating.
"

View attachment 6535

The block diagram from page 7 indicates that the CD ROM subsystem is on the same bus as the cartridge port. The MPEG decompression add on unit is also shown as being part of the CD-ROM subsystem, and that would have , I think, sent decompressed sound and video straight to VDP2 and the sound block directly also via the SCU.

Therefore, I think it's quite possible that the CD ROM could have loaded textures into the CD ROM subsystem's 512KB of ram (where I think the MPEG add on unit may also have put video / audio), and from there transferred textures / sprites directly into VDP1 via the SCU. If any game would have done this, I think it might have been something like Panzer Dragoon Zwei, which would stream bosses (and their synth music and texture data) in during gameplay.

It would certainly have been possible to do it from main ram too, of course. And for games where CD ROM lag was too great, swapping data between vram <--> main ram would probably have been necessary. I believe 2D fighters did this.

Not got any more time to look into this currently, but my guess at answering your question would be .... maybe? Under some circumstances??

You (or someone else!) might have more luck with the plethora of docs at Segaretro than me!

Love the info dump. The system came out when I was just starting highschool and the internet was not what it is now. So I just went from memory of old magazines. Glad to see I was kinda correct lol.
 
Looking around, I found a lot of Saturn developer docs hosted here:

https://segaretro.org/Saturn_official_documentation

The Saturn Overview Manual Vol 1 (https://segaretro.org/images/8/84/ST-103-R1-040194.pdf) has an interesting block diagram on page 7.

View attachment 6534

It indicates that the System Control Unit (SCU) can transfer data directly from the cartridge to VDP1 or VDP2. This would make sense, as there were a number of games that used ROM or RAM carts to store extra graphics data.

From page 8: "SCU (System Control Unit)
The SCU controls all buses (A-bus, B-bus, CPU-bus) and functions as a co-processor of the main CPU. Because the DMA controller is loaded internally, character data can be transferred to V-RAM when the main CPU is operating.
"

View attachment 6535

The block diagram from page 7 indicates that the CD ROM subsystem is on the same bus as the cartridge port. The MPEG decompression add on unit is also shown as being part of the CD-ROM subsystem, and that would have , I think, sent decompressed sound and video straight to VDP2 and the sound block directly also via the SCU.

Therefore, I think it's quite possible that the CD ROM could have loaded textures into the CD ROM subsystem's 512KB of ram (where I think the MPEG add on unit may also have put video / audio), and from there transferred textures / sprites directly into VDP1 via the SCU. If any game would have done this, I think it might have been something like Panzer Dragoon Zwei, which would stream bosses (and their synth music and texture data) in during gameplay.

It would certainly have been possible to do it from main ram too, of course. And for games where CD ROM lag was too great, swapping data between vram <--> main ram would probably have been necessary. I believe 2D fighters did this.

Not got any more time to look into this currently, but my guess at answering your question would be .... maybe? Under some circumstances??

You (or someone else!) might have more luck with the plethora of docs at Segaretro than me!
I ve said this a few times before, but with the resources, knowledge and skills we have now, I wonder what the Saturn could have output if developers had those back then to take fully advantage and in more creative ways the hardware.
It is an interesting layout which on one hand it had its complexities, but probably also provided solutions and approaches that were interesting and impossible on available hardware back then.
Lack of motivation to support a dying hardware, when 3D was new to almost every developer and there was no standardization in game design, surely must have held the hardware back tremendously.

We see some interesting homebrew projects but none approach the visuals some developers could output from games like Panzer Dragoon Saga, Sonic R, Sonic Jam (3d world) or Quake.
I am pretty sure there is a lot of headroom.
 
I ve said this a few times before, but with the resources, knowledge and skills we have now, I wonder what the Saturn could have output if developers had those back then to take fully advantage and in more creative ways the hardware.
It is an interesting layout which on one hand it had its complexities, but probably also provided solutions and approaches that were interesting and impossible on available hardware back then.
Lack of motivation to support a dying hardware, when 3D was new to almost every developer and there was no standardization in game design, surely must have held the hardware back tremendously.

We see some interesting homebrew projects but none approach the visuals some developers could output from games like Panzer Dragoon Saga, Sonic R, Sonic Jam (3d world) or Quake.
I am pretty sure there is a lot of headroom.
I've always wondered what a Resident Evil style game could be on Saturn with the right development. Maybe not RE in gameplay, but something with polygon characters and prerendered backdrops. If VDP2 is used for most of the screen, you could have high resolution characters with quality lighting. Maybe something along the lines of Alone in the Dark: The New Nightmare. Actually, not sure if that would work because I don't know if you could pull of the lighting in the background using VDP2.
 
I've always wondered what a Resident Evil style game could be on Saturn with the right development. Maybe not RE in gameplay, but something with polygon characters and prerendered backdrops. If VDP2 is used for most of the screen, you could have high resolution characters with quality lighting. Maybe something along the lines of Alone in the Dark: The New Nightmare. Actually, not sure if that would work because I don't know if you could pull of the lighting in the background using VDP2.
Deep Fear is a Saturn exclusive RE clone that was actually competent for what it was. It probably didn't leverage the system's resources in the way you mention though.
 
I love Deep Fear, warts and all. In fact, I have an "I have this strange feeling" notification sound on my phone. And while the game is great in many ways, it still doesn't run in Saturn's high resolution mode, nor does it use any advanced effects.
 
Deep Fear is a Saturn exclusive RE clone that was actually competent for what it was. It probably didn't leverage the system's resources in the way you mention though.
I never thought Deep Fear as a competent game. It was inferior in every way even compared to Resident Evil 1. To me it looked like a rushed project with fewer resources than what Resi 1 ever got.
 
I never thought Deep Fear as a competent game. It was inferior in every way even compared to Resident Evil 1. To me it looked like a rushed project with fewer resources than what Resi 1 ever got.
It's fine. It's an RE clone with memorable voice acting and a unique setting, but I don't think it's very impressive from a tech perspective.
 
I bought deep fear when I had a Sega Saturn, and yes the voice acting was memorable in the "master of unlocking" kind of way.
 
On a personal note, I was very disappointed when I found out Cold Fear was an unrelated game. But that was good and was technically impressive for it's time. The rain right at the start shows off some cool effects.
 
Back
Top