Questions about Sega Saturn
- Thread starter Liandry
- Start date
That's a crazy system, and it sounds crap. Why did they go this route? What were the (hoped for) benefits?
So many thanks for all this information! I wil read it some times and try to understand.
Ha-ha-ha! Welcome to reality!
Interesting question. Since the source bitmap is a rectangle, it was probably easier to start scanning it in an ordered fashion rather than start from the target buffer and calculate the source pixel.
It's interesting to note that the Mega CD ASIC was capable of affine line rendering and used a backward texturing approach (it drew a raster line pixel by pixel, fetching the source texel accordingly) so Sega certainly knew the tricks.
It only rendered line by line though, so it was less flexible than the VDP1 and a lot more CPU overhead was involved.
If I'm not mistaken, this 'forward approach' was also used by the 3DO and by the iNFamous NV1. I don't know about the Jaguar
BTW: I don't think this link was posted http://koti.kapsi.fi/~antime/sega/docs.html The VDP1 & VDP2 manuals are a must to understand how 3D graphics were created on the Saturn
In addition to the SH760x datasheet which was linked to earlier in this thread, you can try search for an Hitachi application note, dated 11/96, which is called 'Hitachi SH series memory interfacing'. Basically the lower 128MB of the address space are divided into 4x32MB zones, which could be connected to ROM, BurstROM, SRAM, DRAM, SDRAM or PSRAM. Dynamic bus sizing is also possible (i.e 8 bit to ROM, 32 bit to RAM). All the necessary signals to handle the different types of memory were provided by the SH2 itself.
As mentioned, but I thought I might expand a little, VDP chips don't count as processors as such. Saturn had a sound system though consisting of Motorola 68k CPU and a custom 32-channel Yamaha FM/PCM audio processor with an integrated DSP, with its own separate RAM and DAC chips...
There was also - curiously - an additional Hitachi SH-1 CPU in the Saturn, seemingly dedicated exclusively for CDROM control. I've no idea if there's any way to use that chip for anything else, or what you might want to use it for...
Truly an insanely crazy complicated console, the world has seen nothing like it either before or since.Wait. Wasn't main RAM on 32-bit bus?
Also good question, why CD-ROM needed it's own CPU?
Yes, and that's he point why I started this thread. Absolutely great hardware but very confusing to understand how it works.
What's 'great' about it? A convoluted mish-mash that's not particular good at anything, Saturn smacks of a botched engineering job rather than a great console. Bad for devs, bad for the product, bad for Sega's finances. It's certainly interesting and a great case-study, and well loved by fans because of the games, but the machine itself is something of a joke AFAICS - how not to design and build a console.
Last edited:
You're right, my fault: the Saturn had 2 x 4Mbit SDRAM chips in parallel over a 32 bit bus; it was the 32x which had one single 2Mbit (that's right, it's not a typo) SDRAM chip over a 16 bit bus.
I guess Sega took a lot of inspiration from the arcade machines, where it was pretty common at the time to have multiple CPUs (also with different architectures) and dedicated ASICS.
I often wondered if the end result (the Saturn) could have been better or less expensive (or maybe a bit of both) if Sega had followed the Nintendo route with only two powerful and complex custom chips instead of a multitude of small custom, semicustom and off-the-shelves chips. Certainly Sega was aware of what Nintendo was doing as Silicon Graphics first had approached Sega of America to pitch their low cost, entertainment 3D solution.
So this is before bandwith savings from reducing fillrate became such an unquestionably more important optimization over simplifying computation at rendering. Thinking about it, that methot is not unlike doom's raycasting engine's way of drawing walls, only put on steroids to support arbitrary orientations...
I wonder how hard would it be to make the uv mapping more flexible. In theory they could, i believe, make it so it could skip pixels from or after a certain point. Say you want to draw a quad that only covers 24x24 texels, but the chip was made to only draw distorted 32x32 pixel btms, but with a texel-skip sort of feature, you could assign your quad a 32x32 pixel block that contains your desired 24x24 image and draw a slightly larger quad that skips the texela from the 25th column/line onwards. Idealy they'd have hardware acceleration for the operation that figures out the vertice position of the larger distorted quad based on the desired vertice position of the "clipped" rendered quad. Of course a system that didn't even accelerate basic 3d transforms and projection just clearly didn't give a shit about that hahaha.
IMO expansions are rarely a good idea and Sega should have known this by then. Maybe they planned on having it in the system and it got cut to save costs.
From the VDP1's point of view, yes. These aren't final buffers though, they get mixed with other layers on the VDP2 and that outputs to the display.
I think you can DMA from the buffers that CD data is read into directly to VRAM.
Nothing to do with VDP1 is stored there. It's for tiles and map data that the VDP2 renders.
Probably started with a design that was only intended for blitting a lot of scaled sprites, Afterburner or Outrun style. Then turned into this when they realized they needed to do real 3D with it.
VDP1 didn't employ rendering caches, it just interleaved different memories for simultaneous read + write. It's probably easier to have fast random access writes than random access reads (VDP1 blending, in addition to being broken, was also very slow).
There was also - curiously - an additional Hitachi SH-1 CPU in the Saturn, seemingly dedicated exclusively for CDROM control. I've no idea if there's any way to use that chip for anything else, or what you might want to use it for...
It was used for the optional MPEG stuff. I don't think you could actually run user code on it though, more like the MPEG card had an extra ROM on it, that the SH1 ROM knew how to access?
There's actually an optional feature, a total kludge really, that will make the VDP1 only process every other pixel in a line if the scale factor for that line is < 1. Of course, this isn't actually accurate.
steveOrino
Regular
I think one of the biggest technical feats on the Saturn was Virtual Fighter 2 running at 704x480 @ 60 by effectively using the VDP1/2. It used the saturn's high resolution mode for both background and polygons and at the time it really stood out compared to 3D fighters on the Playstation.
Who knows what tricks would have been found to maximize the pants-on-head hardware if the system would have survived longer but I think games like Burning Rangers show could have been possible (at better frame rates hopefully).
Its always nice to have these tech threads for older hardware since there weren't many (if any) online communities available to discuss them when they were relevant.
Who knows what tricks would have been found to maximize the pants-on-head hardware if the system would have survived longer but I think games like Burning Rangers show could have been possible (at better frame rates hopefully).
Its always nice to have these tech threads for older hardware since there weren't many (if any) online communities available to discuss them when they were relevant.
There's not enough VRAM to store 704x480 and an NTSC TV couldn't display that w/o interlacing anyway so it's really 704x240, maybe with interlacing (so more like 30 Hz?)
Using that high resolution mode meant 8-bit rendering, which meant a much more flat, static, less vibrant look with no lighting. The VDP2 layer helped a lot though.
There were PS1 fighters that used 512x240 or so with actual lighting. Soul Blade was 640 wide IIRC.
Of course Saturn's architecture was difficult, but from tech perspective this is one of it's kind system.
As I understand, correct me if I'm mistaken, data goes from VRAM to framebuffer 0 then VDP1 reads it modifies, writes to framebuffer 1 and then reads it from it and sends to VDP2? Then again do the same for next frame?
You mean data goes from CD-ROM to 512 kb CD-ROM cache and then main RAM gets it's data and VDP1 VRAM it's data? Is it the same with VDP2 VRAM and sound RAM? Or all data first goes to main RAM and then to other RAM pools?
Then where stored VDP1 framebuffer which goes to VDP2?
Absolutely agree! Thank you for posting here. And thanks everyone!
Just wanted ask about that. Is there enough space in VRAM. But you already told it.
How big actualy could be resolution for Saturn game? Is it limited with 256 kb framebuffer size?I don't think I understand what you're saying.
This is what happens during a frame:
1) VDP1 renders sprites to framebuffer A (could be referencing its VRAM for textures)
2) VDP2 combines scanlines from framebuffer B with other layers using its VRAM, puts the result on the screen
Next frame A and B are swapped.
All of these RAMs exist at least partially on the same address space, the SCU can DMA stuff between various locations directly without having to store things in main RAM.
In one of its two framebuffer RAMs.
Full recap, these are the video RAMs:
2x256KB framebuffers
512KB VDP1 VRAM, stores textures, command lists and color tables
512KB VDP2 VRAM, stores tiles and maps and some other stuff, it's like a traditional 2D console's VRAM
Just wanted ask about that. Is there enough space in VRAM. But you already told it.
The 3D part is limited to the 256KB anyway. Maybe you could have higher resolution and only show the 2D layers on the other part of it. Like 640x240 @ 16bpp, but the 3D part only takes up 640x200 and the rest is a HUD or something.
Two questions:
1) VDP1 renders only sprites to framebuffer or polygons too?
2) You mean VDP1 renders to framebuffer A, then read it and sends it to VDP2 and at the same time renders to framebuffer B then reads it and send it to VDP2 and at the same time renders to framebuffer A and so on?
If we simplify it. that means all data goes from CD-ROM cache to SCU and then it sends data to different RAM pools?
My question wasn't correct. I mean when VDP1 sends framebuffer to VDP2 where it's stored? Or it's just go to VDP2 and VDP2 combines it with backgrounds?
Yes 640x200x16bpp is 256 kb, but this isn't 4:3 aspect ratio. Did Saturn have some upscaler?
Polygons in Saturn are "distorted sprites."
VDP1 doesn't read or send anything to VDP2. VDP2 reads from the other framebuffer. You're adding these complicated steps that I don't understand.
I guess?
It doesn't have to be stored anywhere.
The 3D layer doesn't have to take up the whole screen.
The system can only output up to 240 lines per frame to an NTSC TV. By alternating between even and odd lines (interlacing) it can give the appearance (sort of) of 480 resolution at 30 FPS. That's a standard NTSC feature and how broadcast TV worked, for instance. Most of the older consoles did not use interlacing, they always sent even or always sent odd frames to give a lower resolution "progressive" (not interlaced) image. This is also why they had visible dark gaps between the scanlines. PS1/Saturn/N64 were more likely to actually use interlacing sometimes. The generation after much more so.
This is why some people say what Saturn is 2D machine and not 3D?
Ok. When VDP1 complets write to framebuffer A, where this framebuffer data goes?
So, you not sure about it?
How? VDP1 can't send framebuffer to screen, as I understand it goes to VDP2 and VDP2 combines it with his own data (background layers) and then sends final image to the screen.
It just goes through VDP2 to screen and simultaneously combines with VDP2 background layers? Sorry, this system is just... to hard to understand fast. Now I understand a little, why many people say it's hard to work with.
I was thinking about that. But didn't thought what it could be true.
How big these gaps were? If this question is correct.
