PDA

View Full Version : Sega Saturn's Expansion Port... and The one Add-On that should've been made!!!!!!!!



QuickSciFi
12-02-2010, 11:12 PM
...remove archaic memory card...

...or the 4 in 1 Action Replay...

...or that memory storage/gameshark...

...or whatever pretty thing is sticking out of your Saturn's top.


NOW think

Mega Power Base Converter 32!!!

That's right folks:

It will play (and/or have a port for):
1. Sega Master System Games (even the Hu-Card ones)
2. Sega Game Gear Games (through a port adjacent to the Hu-Card one)
3. Sega Genesis Games.
4. Sega CD Games (Via the Saturn's own disk tray, but through the MPBC32's own hardware)
5. Sega 32X Games.
6. Sega Saturn Games of course!

and of course... Lets not forget, it:
1. Will remove any region lock in any of said playable system games (including the Saturn).
2. Will have an insurmountable capacity for memory storage .
3. Will allow you to travel freely to the next dimension and kick Walternate's butt.

Did I miss anything?

Metal_Sonic
12-02-2010, 11:25 PM
Yea, it doesn't give handjobs.

TrekkiesUnite118
12-02-2010, 11:36 PM
It would probably be easier to add the necessary hardware through the MPEG card slot, as from what I've heard it has a bit more freedom in what it can add to the system.

Joe Redifer
12-03-2010, 12:48 AM
If it doesn't play Wii games, then I'm not buying it.

j_factor
12-03-2010, 01:28 AM
No Pico compatibility?

QuickSciFi
12-03-2010, 02:44 AM
Lmao. Hahaha. Come on guys. I need to see some inspired images. N E 1?

TrekkiesUnite118
12-03-2010, 03:44 AM
http://i102.photobucket.com/albums/m98/TrekkiesUnite118/saturn-16bit-card.jpg

There, happy?

TmEE
12-03-2010, 05:22 AM
The cartslot gives more stuff to have fun with than the MPEG connector. There's even video signals on the carstlot ^^

chinitosoccer
12-03-2010, 06:30 AM
I remember reading somewhere that the 3DO M2 project was about to be adopted by Sega and implemented as an add-on for the Saturn as an expansion video card to be connected to the expansion port on the back of the console.

synapse
12-03-2010, 06:47 AM
The cartslot gives more stuff to have fun with than the MPEG connector. There's even video signals on the carstlot ^^

Agreed.

Joe Redifer
12-03-2010, 11:27 AM
They need something to plug in to the cart slot which also loops around back and simultaneously plugs into the MPEG slot as well as that other little port on the back just for fun.

mrbigreddog
12-03-2010, 11:58 AM
Better?

http://img207.imageshack.us/img207/9421/74253328.jpg

Cornholio857
12-03-2010, 12:03 PM
Better?

http://img207.imageshack.us/img207/9421/74253328.jpg

After seeing that, what's funny is that the Saturn and 32X have similar styling cues.

And yes, better. ;)

Lastcallhall
12-03-2010, 01:27 PM
Woah. It's the tower of Jawsumness!

sheath
12-03-2010, 02:15 PM
That is awesome! I still just wish that some 3D games used the RAM expansion.

TrekkiesUnite118
12-03-2010, 03:09 PM
The cartslot gives more stuff to have fun with than the MPEG connector. There's even video signals on the carstlot ^^

Doesn't the MPEG connector though give full access to expand the video hardware of the system? You could put the Genesis, Sega CD, and 32X hardware into that and then you would just need an adapter for cartridges and possibly Sega CD stuff could boot on it's own with just that adapter card installed. This would result in a smaller more streamlined cartridge adapter that wouldn't be as ugly as a 32X mushroom.

mick_aka
12-03-2010, 04:51 PM
A Mega Drive on an chip that plugs into the VCD slot, damn that would rock my world.

QuickSciFi
12-03-2010, 05:20 PM
Better?

http://img207.imageshack.us/img207/9421/74253328.jpg

Darn it brother, that was Beautiful. Thanks for adopting the name. :D


They need something to plug in to the cart slot which also loops around back and simultaneously plugs into the MPEG slot as well as that other little port on the back just for fun.

That's certainly acceptable. The 32X had its own a/v cable going for it.

cowboyscowboys
12-03-2010, 05:24 PM
That is awesome! I still just wish that some 3D games used the RAM expansion.

Final Fight Revenge?

Zoltor
12-03-2010, 05:34 PM
In tuth, that Saturn didnt need all the stuff people are listing here, if it was BC with gen/MD, and Sega CD games, it would be perfect as far as hardware goes.


However what it really needed, was for developers to actually release the games outside of Japan, and for Sega not to bail before the Saturn can even begin to catch on.

kool kitty89
12-03-2010, 10:57 PM
The cartslot gives more stuff to have fun with than the MPEG connector. There's even video signals on the carstlot ^^
Isn't the MPEG slot on a 32-bit bus though rather than a 16-bit bus of the cart slot? (I think both are slow compared to the SDRAM bus, not sure of the actual speed though -if it's slower than DRAM that's a pretty big bottleneck)


That is awesome! I still just wish that some 3D games used the RAM expansion.
It's slow RAM though, so more limited for some things. I'm not sure if the Saturn's VDPs have DMA that allows direct use of CPU RAM or cart RAM as graphics sources for textures (ie pull straight from that ram and map it to the framebuffer) or if it only has fast updating to VRAM like the PSX. (paging added data into video RAM)

If it can pull straight from main/expanded RAM, that would definitely explain why some saturn games (expanded or not) have considerably more animation/detail than the PSX versions. (otherwise the PSX would have the advantage of faster main RAM to page from -much faster than the DRAM bank somewhat faster than SDRAM)




As to the topic, cool and all, but that would have been exorbitantly expensive and much larger than a 32x, let alone if you wanted MCD support. They definitely could have designed a system to efficiently evolve from the MD+MCD hardware and be fully compatible, but the Saturn is nothing like that at all and would need tacked-on compatibility. (technically they could have done it far more efficiently than the MD did for the SMS and actually made use of and built upon most of the old hardware efficiently)
We've gone through that before though, especially here:
http://www.sega-16.com/forum/showthread.php?t=8497&page=3 (especially chilly willys posts)
There's more options than that too, and lots of possible trade offs of features used, but again, Sega wasn't pushing for that with the Saturn.

gamevet
12-04-2010, 12:49 AM
Does anyone know what the rumored hardware upgrade for Virtua Fighter 3 was going to plug into?

TrekkiesUnite118
12-04-2010, 03:42 AM
Does anyone know what the rumored hardware upgrade for Virtua Fighter 3 was going to plug into?

That hardware wasn't for Virtua Fighter 3. Sega of Japan never even knew it was being developed. It was instead something Sega of Europe was doing. It was going to be used for Tomb Raider 2 if I remember correctly. It was probably going to go into the VCD card slot as that gives you direct access to the graphics system.

TmEE
12-04-2010, 04:01 AM
Doesn't the MPEG connector though give full access to expand the video hardware of the system? You could put the Genesis, Sega CD, and 32X hardware into that and then you would just need an adapter for cartridges and possibly Sega CD stuff could boot on it's own with just that adapter card installed. This would result in a smaller more streamlined cartridge adapter that wouldn't be as ugly as a 32X mushroom.

Cartslot has analog video signals available for simple over/underlaying, but MPEG slot is pure digital stuff requiring software to pass data to video and sound HW...


Isn't the MPEG slot on a 32-bit bus though rather than a 16-bit bus of the cart slot? (I think both are slow compared to the SDRAM bus, not sure of the actual speed though -if it's slower than DRAM that's a pretty big bottleneck)

MPEG slot has one bus on it IIRC, but cartslot has both buses and shitload of control strobes and other fun things

OldSchool
12-04-2010, 04:06 AM
...remove archaic memory card...

...or the 4 in 1 Action Replay...

...or that memory storage/gameshark...

...or whatever pretty thing is sticking out of your Saturn's top.


NOW think

Mega Power Base Converter 32!!!

That's right folks:

It will play (and/or have a port for):
1. Sega Master System Games (even the Hu-Card ones)
2. Sega Game Gear Games (through a port adjacent to the Hu-Card one)
3. Sega Genesis Games.
4. Sega CD Games (Via the Saturn's own disk tray, but through the MPBC32's own hardware)
5. Sega 32X Games.
6. Sega Saturn Games of course!

and of course... Lets not forget, it:
1. Will remove any region lock in any of said playable system games (including the Saturn).
2. Will have an insurmountable capacity for memory storage .
3. Will allow you to travel freely to the next dimension and kick Walternate's butt.

Did I miss anything?

How much is something like this worth I wonder... if it were to exist that is. I bet some of you guys would part ways with a testicle or two to get your grubby hands on something like this eh. :cool:

mick_aka
12-04-2010, 06:14 AM
Does anyone know what the rumored hardware upgrade for Virtua Fighter 3 was going to plug into?

There are grainy photos taken at Core that used to be on the sega-saturn.com message board, but I don't really want to give a load of details without being able to post the pictures to back them up, I fear they have long been lost.

It used both cart and VCD slot.

kool kitty89
12-05-2010, 09:08 PM
Does anyone know what the rumored hardware upgrade for Virtua Fighter 3 was going to plug into?

That hardware wasn't for Virtua Fighter 3. Sega of Japan never even knew it was being developed. It was instead something Sega of Europe was doing. It was going to be used for Tomb Raider 2 if I remember correctly. It was probably going to go into the VCD card slot as that gives you direct access to the graphics system.
I think the rumors claimed it would be a cart slot add-on, and that might make more sense given the dual bus access Tiido mentioned.

Howwever, I've only seen vague info in general on it: some rumors/claims included use of an SH3 and NVidia's NV2 chipset (the successor to the quad based NV1 which I believe got some Saturn specific support for DirectX renderers in some Sega PC games -and had Saturn controller ports included on Diamond's EDGE 3D card using the chipset). But it was abandoned, as was the NV2 chipset in general.

I believe some rumors were labeling it the "64X" tying in to the naming of the 32x add-on.

I doubt that, even if SoA/SoE were working on it specifically, that SoJ didn't know about it, or rather that at least SoJ upper management didn't know about it. (as with the Katana and Black Belt projects being known to upper management but kept secret from the media and competing engineering teams)



I highly doubt there was ever added hardware planned for Tomb Raider 2, the Saturn would have been fine for that. (I think Team Andromeda even posted an article recently where CORE programmers claimed that the Saturn version was progressing ahead of the PSX version at one point -though there's always generalizations made in such magazine interviews)
The main reason Tomb Raider 2 was canned was that Sony bought exclusivity of the game for console releases. (there were claims of the "Saturn not being capable" at the time, but the reality of Sony's involvement later surfaced)


Of the info that is out there, it's come up a few times on the forums before, most centering around these:
http://www.sega-16.com/forum/showthread.php?t=5789
http://www.sega-16.com/feature_page.php?id=323&title=Interview:%20Toshiyasu%20Morita




Cartslot has analog video signals available for simple over/underlaying, but MPEG slot is pure digital stuff requiring software to pass data to video and sound HW...



MPEG slot has one bus on it IIRC, but cartslot has both buses and shitload of control strobes and other fun things
What about the bus widths and clock speeds for the cart and MPEG slots?

And there's only 2 buses on the Saturn? (I thought there was the main bus, the SH1/CD-ROM buffer bus, the audio bus, and 2 VDP buses -or 3 VDP buses if the framebuffers used a separate bus than VDP2 RAM or just separate banks on a shared bus)

mrbigreddog
12-05-2010, 10:15 PM
How much is something like this worth I wonder... if it were to exist that is. I bet some of you guys would part ways with a testicle or two to get your grubby hands on something like this eh. :cool:

Well not 2 testicles... But maybe just 1, and that 1 would have to have a fake implant put back in... But it would be worth all the pain for sure!:bang::t::love:

TrekkiesUnite118
12-05-2010, 10:19 PM
I think the rumors claimed it would be a cart slot add-on, and that might make more sense given the dual bus access Tiido mentioned.

Howwever, I've only seen vague info in general on it: some rumors/claims included use of an SH3 and NVidia's NV2 chipset (the successor to the quad based NV1 which I believe got some Saturn specific support for DirectX renderers in some Sega PC games -and had Saturn controller ports included on Diamond's EDGE 3D card using the chipset). But it was abandoned, as was the NV2 chipset in general.

I believe some rumors were labeling it the "64X" tying in to the naming of the 32x add-on.

I doubt that, even if SoA/SoE were working on it specifically, that SoJ didn't know about it, or rather that at least SoJ upper management didn't know about it. (as with the Katana and Black Belt projects being known to upper management but kept secret from the media and competing engineering teams)



I highly doubt there was ever added hardware planned for Tomb Raider 2, the Saturn would have been fine for that. (I think Team Andromeda even posted an article recently where CORE programmers claimed that the Saturn version was progressing ahead of the PSX version at one point -though there's always generalizations made in such magazine interviews)
The main reason Tomb Raider 2 was canned was that Sony bought exclusivity of the game for console releases. (there were claims of the "Saturn not being capable" at the time, but the reality of Sony's involvement later surfaced)


Of the info that is out there, it's come up a few times on the forums before, most centering around these:
http://www.sega-16.com/forum/showthread.php?t=5789
http://www.sega-16.com/feature_page.php?id=323&title=Interview:%20Toshiyasu%20Morita




What about the bus widths and clock speeds for the cart and MPEG slots?

And there's only 2 buses on the Saturn? (I thought there was the main bus, the SH1/CD-ROM buffer bus, the audio bus, and 2 VDP buses -or 3 VDP buses if the framebuffers used a separate bus than VDP2 RAM or just separate banks on a shared bus)

Interviews with Yu Suzuki and other AM2 members from that time have confirmed that they and other members of SoJ knew absolutely nothing about the Eclipse add-on. Their port of Virtua Fighter 3 ran entirely on stock hardware. There is a member of SegaSaturn.co.uk who is currently working on a journalism project of Saturn prototypes and has spoken with members of some of these development teams and as a result could go on for pages about Saturn Virtua Fighter 3.

kool kitty89
12-05-2010, 11:39 PM
Interviews with Yu Suzuki and other AM2 members from that time have confirmed that they and other members of SoJ knew absolutely nothing about the Eclipse add-on. Their port of Virtua Fighter 3 ran entirely on stock hardware. There is a member of SegaSaturn.co.uk who is currently working on a journalism project of Saturn prototypes and has spoken with members of some of these development teams and as a result could go on for pages about Saturn Virtua Fighter 3.
Umm, what did I just say?
I said that it very well may have been the case for engineers, programmers, and lower managment to be kept out of the loop (which is what was done with Katana and Black Belt early on iirc), and it could have been only upper management (or Nakayma alone) who knew of such.

Who knows how much SoJ software teams knew of the Mars/32x project back in early 1994? (some engineering staff ended up consulting on the project, so at least they knew, but even that may not have been widespread)


I also didn't claim that it was intended for VF3, if anything it was intended for nothing at all other than hardware expansion and software would come after the fact as usually is the case.

In any case, it would have been generaly impractical given the already high cost of Saturn manufacturing... same for the M2 though, a fresh start with a new system with or without compatibility would be the better option. (3DO made substantial provisions to facilitate software compatibility without hardware compatibility by forcing developers to conform to standard API/OS calls and 3DO themselves compiling and encrypting all the games) In either case, there's actually the potential for evolution of the hardware into relatively clean, powerful, and cost-effective machines with high consolidation and added hardware capabilities.

Chilly Willy
12-06-2010, 12:02 AM
I don't think I've ever seen more than a hand-waving description of the MPEG expansion port. Since it was transferring decoded video and sound at VCD rates, it was probably a single 32 bit reasonably fast bus. Just data - no analog video and other stuff... the MPEG card decoded the data stream which was then just copied into the Saturn vram and sound ram.

The cart port has been fairly well documented. It's a 16 bit bus with speeds about the same as roms of the time. You could adjust the speed a certain amount, but it wasn't particularly fast... the AR carts usually did like 15 clock cycle accesses to their ram. The cart is split into two regions with their own select lines - one meant for control registers, and the other for rom or ram. That's how the Saturn RAM carts work: the control section allows you to ID the cart and set the ram access cycle rate; the other section allows you to read/write the ram. The control section is smaller than the ram/rom section (naturally).

If the rom section has a proper header in it, you can boot from the rom. There is a Saturn homebrew game that uses that so that you can run the game on any stock Saturn.

kool kitty89
12-06-2010, 01:55 AM
I don't think I've ever seen more than a hand-waving description of the MPEG expansion port. Since it was transferring decoded video and sound at VCD rates, it was probably a single 32 bit reasonably fast bus. Just data - no analog video and other stuff... the MPEG card decoded the data stream which was then just copied into the Saturn vram and sound ram.
For 24-bit color output, you'd need to use VDP2 directly, right?
So wouldn't you need a bit of added hardware (or software) to convert to VDP2 cell format, or did VDP2 allow linear bitmaps?

Or can you directly write 32-bit pixels to the VDP1 framebuffer and have VDP2 read that out as 24-bit RGB? (I know VDP1 can't output 24-bit itself -other than 256 color indexed or 16-bit indexed using CRAM -or is that only for VDP2?)



The cart port has been fairly well documented. It's a 16 bit bus with speeds about the same as roms of the time. You could adjust the speed a certain amount, but it wasn't particularly fast... the AR carts usually did like 15 clock cycle accesses to their ram. The cart is split into two regions with their own select lines - one meant for control registers, and the other for rom or ram. That's how the Saturn RAM carts work: the control section allows you to ID the cart and set the ram access cycle rate; the other section allows you to read/write the ram. The control section is smaller than the ram/rom section (naturally).

If the rom section has a proper header in it, you can boot from the rom. There is a Saturn homebrew game that uses that so that you can run the game on any stock Saturn.
The bus speed restrictions apply to both ROM and RAM then?

What was the higher limit for the bus speeds used? (15 cycle waits for the SH2s sounds like it wouldn't be much different from the Genesis cart slot in speed, actually that would be oddly slow at ~500 ns, if that's 15 ~28.6 MHz cycles)

j_factor
12-06-2010, 12:13 PM
If the rom section has a proper header in it, you can boot from the rom. There is a Saturn homebrew game that uses that so that you can run the game on any stock Saturn.

What game is this?

Chilly Willy
12-06-2010, 04:43 PM
For 24-bit color output, you'd need to use VDP2 directly, right?
So wouldn't you need a bit of added hardware (or software) to convert to VDP2 cell format, or did VDP2 allow linear bitmaps?

Or can you directly write 32-bit pixels to the VDP1 framebuffer and have VDP2 read that out as 24-bit RGB? (I know VDP1 can't output 24-bit itself -other than 256 color indexed or 16-bit indexed using CRAM -or is that only for VDP2?)

I think the MPEG module puts the data in tile format, like the SVP puts the data in tile format for VR. Even if it didn't, it's easy enough to change the format on the fly, it just makes you use more CPU power than you would have otherwise.




The bus speed restrictions apply to both ROM and RAM then?

Depends on the cart. The DRAM carts have their own timing.



What was the higher limit for the bus speeds used? (15 cycle waits for the SH2s sounds like it wouldn't be much different from the Genesis cart slot in speed, actually that would be oddly slow at ~500 ns, if that's 15 ~28.6 MHz cycles)

The official ram carts use timing that makes it 1/4 the speed of the work ram in the Saturn. You can use burst read mode on the ram (filling a cache line in the cpu), and you can use the SH2 or SCU DMA to read the ram. You can't use burst writing from the CPU, and can only use SH2 DMA for writing.

@j_factor - the game is Police Officer Smith: http://www.policeofficersmith.de/

kool kitty89
12-06-2010, 07:24 PM
Depends on the cart. The DRAM carts have their own timing.
So it wouldn't be limited by the cart slot other than the 16-bit bus?

Would the same sort of thing technically apply to the Genesis cart slot? (though I guess that's exactly what the MCD uses already, a fully asynchronous interface with independent onboard clock and RAM running at a different speed -unlike the 32x oriented around the MD clock speed and DRAM framebuffers at almost 1/2 the rated speed compared to the full-speed MCD program/word RAM -if I'm not mistaken)



The official ram carts use timing that makes it 1/4 the speed of the work ram in the Saturn. You can use burst read mode on the ram (filling a cache line in the cpu), and you can use the SH2 or SCU DMA to read the ram. You can't use burst writing from the CPU, and can only use SH2 DMA for writing.
So 1/4 the speed of SDRAM (1/2 the speed of DRAM) or 1/4 the speed of Saturn DRAM?

Chilly Willy
12-07-2010, 02:21 AM
So it wouldn't be limited by the cart slot other than the 16-bit bus?

Yes, it would be more the device than the bus limiting the speed.



Would the same sort of thing technically apply to the Genesis cart slot? (though I guess that's exactly what the MCD uses already, a fully asynchronous interface with independent onboard clock and RAM running at a different speed -unlike the 32x oriented around the MD clock speed and DRAM framebuffers at almost 1/2 the rated speed compared to the full-speed MCD program/word RAM -if I'm not mistaken)

No, the Genesis cart uses the "standard" 68000 bus cycle with no wait states for the cart. You would have to generate your own /DTACK signal to insert wait states for slower devices, and there's no way to be faster.

The 32X is different - the SH2 can be programmed for each region (the cart is one region, the hardware another, and the SDRAM yet another). The bus is 2 cycles + whatever you set the wait states for the region . So you can access the 32X cart faster or slower by changing a register in the SH2. That's assuming there's no collision between SH2s or with the MD 68000, of course.



So 1/4 the speed of SDRAM (1/2 the speed of DRAM) or 1/4 the speed of Saturn DRAM?

The docs say "Work RAM" which I believe was the slower DRAM, not the SDRAM. I could be mistaken... I'd have to go back and check the Saturn architecture manual to make sure I've got the names of the various blocks right.

kool kitty89
12-07-2010, 03:03 AM
The 32X is different - the SH2 can be programmed for each region (the cart is one region, the hardware another, and the SDRAM yet another). The bus is 2 cycles + whatever you set the wait states for the region . So you can access the 32X cart faster or slower by changing a register in the SH2. That's assuming there's no collision between SH2s or with the MD 68000, of course.
So carts accessed by the SH2s aren't limited to the 68k bus speed? (is the SRAM/PSRAM of modern flash carts locked at the 68k bus speed, or can that be faster for the SH2s as well?)
And by 68k bus speed do you mean the 68k clock speed, or including the 4 cycle access times of the 68k?


The docs say "Work RAM" which I believe was the slower DRAM, not the SDRAM. I could be mistaken... I'd have to go back and check the Saturn architecture manual to make sure I've got the names of the various blocks right.
If that's the case it would mean the cart RAM would be 1/8 the SH2 clock speed and thus the same bandwidth as the Amiga's DRAM. ;) (280 ns random access DRAM on a 16-bit bus -the DRAM used as "150 ns" rated referring to the CAS timing, but without page mode usage, you were stuck only with full random accesses at much slower speed)

TmEE
12-07-2010, 04:24 AM
MPEG connector has a 16bit bus on it, and Cartslot has MPEG connector bus + A bus of the Saturn, both 16 bit. Only 32bit bus is the SH2 bus (called C bus), the rest is 16bits wide. MPEG bus goes to VDP2 directly.
A but connects SCU, cartslot and CD drive. B bus connects VDP1, VDP2 and sound part. A, B and C buses end up in the SCU. Audio is all digitally mixed together so no CPU power is needed for that, and I believe video coming from the MPEG bus is directly overlayed by VDP2 (?)

Chilly Willy
12-07-2010, 03:20 PM
So carts accessed by the SH2s aren't limited to the 68k bus speed? (is the SRAM/PSRAM of modern flash carts locked at the 68k bus speed, or can that be faster for the SH2s as well?)

An old Genesis cart might rely on 68000 timing - for example, having an access time that is just barely fast enough to work on the 68000. However, to work with the 32X, the cart has to be fast enough to work with the 32X default timing, which is faster than the 68000 timing. So if a flash carts works with the 32X, it can't be locked at 68000 speeds. Honestly, I'm sure that all they do is output the data as soon as possible when selected, and hold the output until they are no longer selected. As long as the access time from the selection asserted is fast enough, it works for anything. The 68000 just starts looking for the data later than the 32X, and holds the cart selected longer as well.

One of these days, I'll do some timing tests on the the various flash carts with the 32X to see where they top out at. I'm sure most of them can be accessed faster than they are.


And by 68k bus speed do you mean the 68k clock speed, or including the 4 cycle access times of the 68k?

Yes. That's part of the reason there are limits to overclocking the Genesis - if you get too fast, the standard 4 cycle bus access becomes too fast for the carts to reliably be read. That wouldn't happen with 32X compatible flash carts since they are made for faster accessing... which would be interesting as another test.



If that's the case it would mean the cart RAM would be 1/8 the SH2 clock speed and thus the same bandwidth as the Amiga's DRAM. ;) (280 ns random access DRAM on a 16-bit bus -the DRAM used as "150 ns" rated referring to the CAS timing, but without page mode usage, you were stuck only with full random accesses at much slower speed)

Which would make sense at the time given they'd be using as cheap a memory chip as was available to keep the price down.

Da_Shocker
12-07-2010, 04:17 PM
Since it was mentioned I have a few questions about the 4MB ram cart.

-How much would it have helped with a port of Quake.
-Was it really needed for Final Fight Revenge which looks more like a 1st gen Saturn game not a late gen game.
-Why was the loading time so bad on D&D? Was it because the game had characters and scenes compare to the Vs. games? Thus load the backgrounds and characters and load during the Round 1 scene.
-Why didn't that game support 4 players?
-How would CPS3 games turned out?

Oh yeah the rumored Saturn upggrade was suppose to us some variation of the Power VR PCX2 chipset.

http://upload.wikimedia.org/wikipedia/commons/6/68/VideoLogic_Apocalypse_3Dx.jpg

TrekkiesUnite118
12-07-2010, 06:25 PM
I think D&D collection was just unoptimized. Wasn't it released around when Capcom was shifting most of their focus to the Dreamcast? Street Fighter Alpha 3 shows some signs of this too. The loading isn't as optimized as the other RAM cart fighters.

If I remember correctly Capcom did have a few last CPS2 games planned for the Saturn like Marvel vs Capcom that if Dreamcast didn't come out as soon as it did they were going to release. Considering how similar Saturn and CPS3 are in specs aside from RAM it wouldn't surprise me if some CPS3 games were planned but not until after they were done with CPS2 stuff.

kool kitty89
12-07-2010, 07:07 PM
MPEG connector has a 16bit bus on it, and Cartslot has MPEG connector bus + A bus of the Saturn, both 16 bit. Only 32bit bus is the SH2 bus (called C bus), the rest is 16bits wide. MPEG bus goes to VDP2 directly.
A but connects SCU, cartslot and CD drive. B bus connects VDP1, VDP2 and sound part. A, B and C buses end up in the SCU. Audio is all digitally mixed together so no CPU power is needed for that, and I believe video coming from the MPEG bus is directly overlayed by VDP2 (?)
Huh? The SH2 bus is the only 32-bit bus inside the Saturn? (the VDPs and SH1 are all 16-bit?)

That would make the bandwidth a fair bit less competitive with the PSX (or others in general)... though it would also make multi-bus expansion more realistic. (ie Sega could have used significantly less memory on the initial Saturn but provided expansion)



An old Genesis cart might rely on 68000 timing - for example, having an access time that is just barely fast enough to work on the 68000. However, to work with the 32X, the cart has to be fast enough to work with the 32X default timing, which is faster than the 68000 timing. So if a flash carts works with the 32X, it can't be locked at 68000 speeds. Honestly, I'm sure that all they do is output the data as soon as possible when selected, and hold the output until they are no longer selected. As long as the access time from the selection asserted is fast enough, it works for anything. The 68000 just starts looking for the data later than the 32X, and holds the cart selected longer as well.

One of these days, I'll do some timing tests on the the various flash carts with the 32X to see where they top out at. I'm sure most of them can be accessed faster than they are.
So, technically speaking, the 32x could have had RAM/ROM accessed through the cart slot as fast as the SDRAM?



Yes. That's part of the reason there are limits to overclocking the Genesis - if you get too fast, the standard 4 cycle bus access becomes too fast for the carts to reliably be read. That wouldn't happen with 32X compatible flash carts since they are made for faster accessing... which would be interesting as another test.
You'd hit the PSRAM speeds too, but for some really slow ROM you'd hit the limit there first. (and with PSRAM the speed varies by model too, probably part of the reason why late model 1s overclock better than earlier ones -went from 150 ns to 120 ns to 100 ns- though by the time you get to the VA7 model or model 2s, they have the new VDP ASIC that's really timing sensitive and doesn't like much more than 10 MHz on an asynchronous overclock)


Which would make sense at the time given they'd be using as cheap a memory chip as was available to keep the price down.
Yeah, but even low-end fast page mode DRAM should have been far faster than the Amiga's asynchronous DRAM... unless using a simpler DRAM controller that didn't support page mode accessing was used or perhaps also power consumption concerns forcing lower clock rates. (with fast page mode, cheap RAM should have been 1/3 or 1/2 the SDRAM speed -like 32x framebuffers, but without fast page mode possible, the speed drops dramatically down to full random accesses, but even then it should have been 1/6 to 1/5 the SH2 speed, not 1/8)




One add-on for the Saturn that really might have made a difference could have been some sort of floating point coprocessor.
RAM gives you more animation and more/higher res/higher depth textures (uncompressed), but won't help with actual system performance otherwise, especially for 3D... an FPU OTOH would have made working with quads much easier and increased overall geometry performance and thus polygon rates (within the fill-rate limits of the VDPs of course, though avoiding things like folding quads as Quake did, would double fill rate as well as you eliminate the overdraw and you also have more efficient RAM usage as you don't waste on prewarped textures). And that also leaves more CPU resource and the SCU DSP free for other tasks including decompression which would thus stretch RAM further without even having to add more memory.

Chilly Willy
12-07-2010, 08:31 PM
Huh? The SH2 bus is the only 32-bit bus inside the Saturn? (the VDPs and SH1 are all 16-bit?)

That would make the bandwidth a fair bit less competitive with the PSX (or others in general)... though it would also make multi-bus expansion more realistic. (ie Sega could have used significantly less memory on the initial Saturn but provided expansion)

I think that's the primary difference between the hi work ram (the SDRAM) and the low work ram (the DRAM). I'd love to see schematics of the Saturn. That would answer quite a few questions, especially about the MPEG card port.




So, technically speaking, the 32x could have had RAM/ROM accessed through the cart slot as fast as the SDRAM?

Yes. You couldn't do burst (I think that requires a few extra control lines), but you could do high speed SRAM/ROM. It would improve some things, like leaving sprites or wall textures in rom. Hmm - I should try that with Wolf32X: in the init, set the rom region faster and see how it affects the game.



One add-on for the Saturn that really might have made a difference could have been some sort of floating point coprocessor.
RAM gives you more animation and more/higher res/higher depth textures (uncompressed), but won't help with actual system performance otherwise, especially for 3D... an FPU OTOH would have made working with quads much easier and increased overall geometry performance and thus polygon rates (within the fill-rate limits of the VDPs of course, though avoiding things like folding quads as Quake did, would double fill rate as well as you eliminate the overdraw and you also have more efficient RAM usage as you don't waste on prewarped textures). And that also leaves more CPU resource and the SCU DSP free for other tasks including decompression which would thus stretch RAM further without even having to add more memory.

By the time it mattered, SEGA was looking to ditch the Saturn for the Dreamcast. Maybe they could have had the FPU as part of the MPEG card. It might have helped spur sales if it not only decoded MPEG, but also doubled the polygon rate.



Since it was mentioned I have a few questions about the 4MB ram cart.

-How much would it have helped with a port of Quake.

A lot. Quake ran on the N64 in 4MB, and the NDS homebrew Quake port uses 4MB. I've thought of porting QuakeDS to the Saturn (with the 4MB ARP of course).



-Was it really needed for Final Fight Revenge which looks more like a 1st gen Saturn game not a late gen game.

It's not what it looks like that matters, it's how much space it all takes. The extra ram in the Saturn was good for storing extra characters and/or extra frames of animation for the characters. The stock Saturn had more ram, and it came in handy on 2D games. With the extra ram, you could have all the characters and animations as the original.

kool kitty89
12-07-2010, 09:41 PM
I think that's the primary difference between the hi work ram (the SDRAM) and the low work ram (the DRAM). I'd love to see schematics of the Saturn. That would answer quite a few questions, especially about the MPEG card port.
Hmm, I'd thought the main difference with the slow DRAM block was it being composed of slower/cheaper FPM DRAM (like the Sega CD, Jaguar, and 3DO -save for 3do VRAM- and 32x framebuffers) and that it was thus 1/2 the speed but full 32-bits wide. (if it's 1/2 speed that would be 70 ns FPM DRAM, but if they used the same 80 ns FMP DRAM as the MCD, that would imply it was clocked slower -1/3 the SH2 speed if it had to be a direct integer division of 28.6 MHz so in that case it would be running slower than the MCD RAM's 12.5 MHz)


Yes. You couldn't do burst (I think that requires a few extra control lines), but you could do high speed SRAM/ROM. It would improve some things, like leaving sprites or wall textures in rom. Hmm - I should try that with Wolf32X: in the init, set the rom region faster and see how it affects the game.
Burst as in what burst EDO DRAM could do, or would that also include page mode of FMP DRAM being unusable?



By the time it mattered, SEGA was looking to ditch the Saturn for the Dreamcast. Maybe they could have had the FPU as part of the MPEG card. It might have helped spur sales if it not only decoded MPEG, but also doubled the polygon rate.
Yeah, but that would have been more expensive and the MPEG card was never a big seller especially given the lack of VCD popularity. (the Saturn didn't need the MPEG card for better streaming audio/video anyway as it could do pretty well with optimized custom codecs taking advantage of the onboard resources, probably not PSX quality let alone full VCD MPEG-1, but far far better than Cinepak with the SH2s, DSP, and 68k working together, or perhaps even a custom codec catering to the VDP2 tile format -not sure how far they could push it compared to MJPEG/H.261 but supposedly some games already used software MPEG-1 of some sort though perhaps it was actually H.261)

In that respect though and especially given the Saturn's cost (for Sega to produce and what was passed on to consumers or lost to Sega if selling below cost) it might have been smart to cut more things out on the initial release and plan for incremental upgrades (or a single definitive upgrade) later on, especially with a more comprehensive expansion port than the cart slot. (ie 32-bit buses along with the natively 16-bit ones)



It's not what it looks like that matters, it's how much space it all takes. The extra ram in the Saturn was good for storing extra characters and/or extra frames of animation for the characters. The stock Saturn had more ram, and it came in handy on 2D games. With the extra ram, you could have all the characters and animations as the original.
Do you know if it was common practice to store some graphics compressed in RAM and decompress on the fly with the SH2(s)/DSP? (for 2D games you'd hardly need that resource, hell you could probably offload the game engine onto the 68k)

Da_Shocker
12-07-2010, 09:55 PM
It's not what it looks like that matters, it's how much space it all takes. The extra ram in the Saturn was good for storing extra characters and/or extra frames of animation for the characters. The stock Saturn had more ram, and it came in handy on 2D games. With the extra ram, you could have all the characters and animations as the original.

I take it you haven't played Final Fight Revenge (still need youtube help)

<object width="480" height="385"><param name="movie" value="http://www.youtube.com/v/RDqmmBq6XMY?fs=1&amp;hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/RDqmmBq6XMY?fs=1&amp;hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object>

TrekkiesUnite118
12-07-2010, 09:56 PM
The VCD card sold pretty well in Japan from what I've heard. A few games even used it.

As for FMV quality, it's not as cut and dry as what codec was use but how well it was encoded. Good Cinepak encoding will look better than bad TrueMotion encoding.

Here's a good example:

Lunar 2: (Cinepak):
PK2sT8223xI

Symphony of the Night (True Motion):
nyUoT94FG5w

Chilly Willy
12-08-2010, 12:43 AM
Hmm, I'd thought the main difference with the slow DRAM block was it being composed of slower/cheaper FPM DRAM (like the Sega CD, Jaguar, and 3DO -save for 3do VRAM- and 32x framebuffers) and that it was thus 1/2 the speed but full 32-bits wide. (if it's 1/2 speed that would be 70 ns FPM DRAM, but if they used the same 80 ns FMP DRAM as the MCD, that would imply it was clocked slower -1/3 the SH2 speed if it had to be a direct integer division of 28.6 MHz so in that case it would be running slower than the MCD RAM's 12.5 MHz)

Maybe it's both slower AND 16 bit. :D



Burst as in what burst EDO DRAM could do, or would that also include page mode of FMP DRAM being unusable?

Burst as in SH2 cache line burst. The SH2 reads 8 words (a total of 16 bytes, or one cache line) in 12 cycles. The SDRAM in the 32X is hard wired for burst read only, so even when you read the SDRAM uncached, it STILL reads 8 words in 12 cycles, then tosses out the 7 unused words, so it reads 1 word in 12 cycles. Needless to say, try to watch how you use uncached SDRAM accesses. It's one of the things I need to address in an update to Wolf32X. For details on an SH2 burst bus access, consult the SH2 hardware manual. :cool:



Yeah, but that would have been more expensive and the MPEG card was never a big seller especially given the lack of VCD popularity. (the Saturn didn't need the MPEG card for better streaming audio/video anyway as it could do pretty well with optimized custom codecs taking advantage of the onboard resources, probably not PSX quality let alone full VCD MPEG-1, but far far better than Cinepak with the SH2s, DSP, and 68k working together, or perhaps even a custom codec catering to the VDP2 tile format -not sure how far they could push it compared to MJPEG/H.261 but supposedly some games already used software MPEG-1 of some sort though perhaps it was actually H.261)

They should have made the MPEG card handle SVCD... basically MPEG2 at MPEG1 data rates. You can get great results from SVCD... about halfway between VCD and DVD quality with a good encoder. The main thing SVCD requires is a larger stream buffer since it use variable bitrate compression; so it would have probably also needed the ram expansion as well.



Do you know if it was common practice to store some graphics compressed in RAM and decompress on the fly with the SH2(s)/DSP? (for 2D games you'd hardly need that resource, hell you could probably offload the game engine onto the 68k)

No idea. There's little info on games of that era - while I've seen Jaguar game source, I haven't seen any 32X or Saturn game code released. While Doom for the Jaguar has 32X defines in it, the 32X specific code is missing. Otherwise, we'd have already seen updates to 32X Doom.

TmEE
12-08-2010, 02:40 AM
http://www.fileden.com/files/2008/4/21/1876835//SaturnVA12.png
:chewie:

kool kitty89
12-08-2010, 04:38 AM
They should have made the MPEG card handle SVCD... basically MPEG2 at MPEG1 data rates. You can get great results from SVCD... about halfway between VCD and DVD quality with a good encoder. The main thing SVCD requires is a larger stream buffer since it use variable bitrate compression; so it would have probably also needed the ram expansion as well.
Well that and the fact that SVCD (or the overall Chinese SVCD standard) didn't come into play until the Dreamcast was already on the table... unless you want to get into other hypotheticals.
The first (and arguably the best) of the SCVD family of formats was CVD (China Video Disc) released in July of 1998 using a lower resolution than SVCD but with the advantages of being DVD compatible resolution wise (no foldover problems) and having less artifacting due to the lower compression ratio. (and for composite video especially, 352x480i was well suited given you had enough blur/artifacting to make higher res less useful)

And both CVD and SVCD offered variable bitrates up to 2x CD-ROM. (roughly 342 kB/s in mode 2)

The fact remains that VCD formats still weren't popular in Japan either with DVD rising too fast and a lower end alternative not being especially attractive, especially with the limits of CD-ROM, and the fact that SVCD formats were specifically built on a Chinese standard.
However, maybe Sega could have taken advantage of that with GDROM and the Dreamcast and perhaps even licensed the GD-ROM format to SVCD manufacturers while the standard was still being created as well as integrating VCD/CVD/SVCD playback on the Dreamcast out of the box... as it is the Dreamcast should have been pretty close to being capable of that using software decoding, but I think the powerVR chipset already may have had additional acceleration for multimedia stuff. (and Dreamcast FMV definitely looks more like DVD quality stuff) It's actually a bit odd that the DC didn't at least support VCD (if not SVCD/CVD -regardless of GD-ROM) given that should have added no significant cost and plenty of potential benefits. (win win for the most part)

Use of GDROM really would have helped address a major weakness with CVD/SVCD though: short duration at decent quality. (technically DDCD-ROM would have done that too, but I don't think Sony ever licensed that format, or at least not broadly -it would have been a conflict of interest for DVD) On average composite+stereo TV set-ups of the late 90s, CVD at mid/higher bitrates (between 1 and 2x CD-ROM) probably would have looked and sounded reasonably close to DVDs.





Oh, and nice post Tiido, but I don't see any mention of the bus widths on that schematic. (and I assume the OCU is the SH1, which means the MPEG port is using the SH1 bus directly and would thus not be useful for Main or Video RAM expansion)
And why does it list FM as 8 channels when the 32 oscillators can be combined in any fashion?

TmEE
12-08-2010, 04:41 AM
Bus widths are all marked on it... D0-D15 etc. :P

And about FM channels no idea, just so that devs would not think its too complex....

TrekkiesUnite118
12-08-2010, 02:42 PM
Last I checked Video CDs were somewhat popular in japan, but not as much as formats like LaserDisc. DVD didn't take off in Japan though until the PS2 launched. The PS2 is what made DVD take off in Japan.

Chilly Willy
12-08-2010, 02:59 PM
Bus widths are all marked on it... D0-D15 etc. :P

And about FM channels no idea, just so that devs would not think its too complex....

Nice! A block diagram with some info. So the only thing that's 32 bit is the high work ram (SDRAM). Everything else is 16 bit.

kool kitty89
12-08-2010, 03:00 PM
Last I checked Video CDs were somewhat popular in japan, but not as much as formats like LaserDisc. DVD didn't take off in Japan though until the PS2 launched. The PS2 is what made DVD take off in Japan.
I thought it was the opposite... that DVD played a role in driving the PS2's success. (I've seen anecdotes about japan having the most extreme cases of early PS2 adopters buying them purely for DVD playing capabilities)
If you're correct, that could have meant Sega had an opening with the DC almost 2 years ahead of Sony to offer an alternative standard. (not only entering earlier, but offering a cheaper alternative to DVD and the PS2 later on)

One point on VCD vs Laserdisc though would be that LD was still universally better quality. CVD technically could have had more reasonable advantages and universal superiority over VHS at least. (let alone in the case of a hypothetical GD-ROM agreement)

SVCD definitely came too late for the Saturn as it was though, unless things had gone differently. (had it done better earlier on and not bothered with the MPEG add-on, a unified MPEG-2/CVD add-on in late 1998 might have made sense with the DC pushed further back, but in the context of the time, the DC natively supporting VCD/CVD/SVCD would have been far more realistic and significant, especially if they used GD-ROM and standardized that with Chinese CVD/SVCD player manufacturers)


With the historical Saturn's expansion ports, the MPEG port still wouldn't be good for a general purpose expansion unit for both video and coprocessing given the limited connectivity (only to the SH1 bus it looks like), so a cart add-on would probably have been better for such. (especially a nice, consolidated RAM+coprocessing+flash save memory module compatible with the existing expansion carts, or more likely in place of them if Sega specifically promoted such and avoided conflicts with 3rd party add-ons)
Again, it would have made more sense to strip down the Saturn as such to reduce cost early on and then offer the expansion when more cost effective along with late models integrating it. (Sega had more problems than cost effective hardware, but every bit helped and that was still a significant issue to compete against Sony's price points -let alone undercutting them) There'sother features and hardware included in the Saturn that wouldn't even need to be re-added later on as it's simply wasteful from the start, so that would make it even more extreme in cost reduction.




Bus widths are all marked on it... D0-D15 etc. :P

And about FM channels no idea, just so that devs would not think its too complex....
Huh, wow, so the DRAM IS slow and 16-bit (I wonder just how slow... if it's the same 512k 16-bit 80 ns FPM DRAM of the MCD, that would imply 1/3 the SH2 clock and 1/6 the SDRAM data rate, so about as bad as 32x frambuffers relative to SH2 speed, though if they bumped it to ~65/70 ns -which should have been pretty cheap even in '94- it could have been 1/2 speed and 1/4 bandwidth)

Given both SDRAM and DRAM are listed as "work RAM" (high and low), it's not definitive whether the cart RAM used 1/4 SDRAM or DRAM speeds. Given the later release dates for the RAM carts, I still think it would make more sense for it to be 1/4 SDRAM speed... and if "1/4 speed" actually meant 1/4 bandwidth, that would mean similar speed as onboard DRAM)
All those separate 16-bit buses and mixes of RAM really point to how the system could have been optimized if actually oriented around an highly buffered (and cached) unified system with fewer, higher bandwidth buses and consolidated RAM. (as it is, it's closer to what the 3DO did than the N64/PSX/Jaguar by the look of it, but with more buses and faster memory -though I think even the 3DO had a phrase buffer to at least do 32-bit reads/writes with the GPU and use full 50 MB/s main/VRAM bus bandwidth... though they seem to have wasted the system with the VRAM approach and using 1 MB as a glorified framebuffer rather than using plain DRAM and a hardware framebuffer set-up like the 32x/MCD at more minimalistic sizes, or maybe more like Saturn with 256k buffers and in either case with actual texture memory rather than eating up main bus time)


Heh, that means the Saturn VDPs are operating with 16 bit words and the overall system is mostly using 16-bit memory. Heh, so it's 16-bit in the same way the PCE is or the same way the Jag is 64-bit (or Xbox is 128 bit), then again the PS2 has a ton of 16-bit data paths in it... silly marketing, "bitness" is worthless without context anyway. ;)

TrekkiesUnite118
12-08-2010, 04:46 PM
Here's a Dreamcast History Video explaining DVD's not really becoming mainstream until the PS2:

e27kjhZXQqE

DVDs were there, but they weren't mainstream. PS2 came along and was the cheapest DVD player on the Market, that made DVD really take off in Japan and also helped sell the PS2. People weren't buying the PS2 to play it's games, they were buying it to watch DVDs.

As for the MPEG slot, I think something might be wrong with what TmEE posted. The official development documents from Sega show that the slot interfaces directly with the Video and Sound subsystems.

Chilly Willy
12-08-2010, 05:03 PM
As for the MPEG slot, I think something might be wrong with what TmEE posted. The official development documents from Sega show that the slot interfaces directly with the Video and Sound subsystems.

Uh - that block diagram DOES show the MPEG port interfacing directly with the video and sound subsystems. :D

TrekkiesUnite118
12-08-2010, 05:12 PM
Uh - that block diagram DOES show the MPEG port interfacing directly with the video and sound subsystems. :D

Oh woops, I missed that line there.

For what it's worth though here is the block diagram from the development manual:

http://i102.photobucket.com/albums/m98/TrekkiesUnite118/SaturnDiagram.png

Chilly Willy
12-08-2010, 07:48 PM
Oh woops, I missed that line there.

For what it's worth though here is the block diagram from the development manual:

http://i102.photobucket.com/albums/m98/TrekkiesUnite118/SaturnDiagram.png

Funny, that block diagram isn't correct (but it's easier to read) - it shows 1.5MB of 32 bit work ram when the Saturn actually has 1MB of 32 bit work ram (called high work ram), and 1MB of 16 bit work ram (called low work ram). The names for the two banks of ram come from their address in the memory map; the high work ram is higher up in address than the low work ram.

It's hard to tell what kind of connection the video and audio connections are from the MPEG module. I thought it was digital, but I wonder if it's actually analog.

kool kitty89
12-08-2010, 08:04 PM
Uh - that block diagram DOES show the MPEG port interfacing directly with the video and sound subsystems. :D

It interfaces with bus B directly (for VDP2 access presumably), but the sound is indirect but the looks of it. (it connects to the SH1 -OCU- bus which then connects to the Audio subsystem via the audio multiplex IC)


Oh woops, I missed that line there.

For what it's worth though here is the block diagram from the development manual:

http://i102.photobucket.com/albums/m98/TrekkiesUnite118/SaturnDiagram.png

You don't want to use that document, it's an early revision with several flaws...
http://koti.kapsi.fi/~antime/sega/docs.html That would be the Sega of America Introduction to Saturn Game Development listed on that site.

The Saturn Overview Manual (temporary version 1) would be the one to look at.
http://koti.kapsi.fi/~antime/sega/files/ST-103-R1-040194.pdf Though that's still a bit vague compared to the propr schematic posted by Tiido.


The most obvious thing wrong with the above diagram is the 1.5 MB of RAM listed for the SH2s.





Here's a Dreamcast History Video explaining DVD's not really becoming mainstream until the PS2:

e27kjhZXQqE

DVDs were there, but they weren't mainstream. PS2 came along and was the cheapest DVD player on the Market, that made DVD really take off in Japan and also helped sell the PS2. People weren't buying the PS2 to play it's games, they were buying it to watch DVDs.
Firstly, I wouldn't take Steve Kent at face value, he's much more of a journalist than a historian and his books reflect that with great quotes and compiled information, but poor fact checking and thus inconsistent reliability in the factuality of the compiled resourced and interview claims. So I definitely wouldn't take those statements at face value alone.
All the what-if statements about DC having DVD don't make sense as Sega was already selling the DC at a loss, and there's no way they could compete on the level of Sony's vertical integration, let alone launching a DVD system 2 years earlier. (Sony owned much of the IP for the DVD format, had in-hose manufacturing, and released the hardware 2 years later while still selling at a significant loss on top of all that)

The statement about selling 4-5 million worldwide also doesn't make sense as they sold a hell of a lot more than that by the end of 2000... onless they meant 4-5 million in 2000 alone. Pushign the DC with spedial deals and such was probably the opposite of what they should have been doing. They couldn't artificially increase sales as such and there was inevitably going to be a hump to get over with the PS2's launch hype before that dissipated (for the US at least where the long term market was definitively viable), and going conservative to minimize losses and stay on the market as such would have made much more sense. (and making provisions for a possible phase out of the DC -if it came to that- in favor of pure 3rd party to make the transition as smooth as possible would definitely have been wise -start pushing PC multiplatform titles hard alongside the DC, carefully managing the DC to maintain interest but minimize risk and optimize their ability to phase it out with minimal backlash from shareholders and their userbase, etc)

Edit: Sega really should have already been doing that during the Saturn years (pushing PC harder that is) given it would have solidified a market regardless of their hardware success and allowed an additional outlet for arcade and console ports to generate much needed revenue. Sega of America had been pushing for that it seems, and even conflicted over whether to how much they should focus on PC software development and SoJ did some PC support as well, but it was still somewhat limited with key games being omitted. (and with SoA, you had software development being cut out in general as SoJ cut down on spending and then Stolar reorganized SoA in '97)


The question is whether a DVD alternative would have had any real place on the market in Japan, or the west for that matter. Again, GD-ROM would have made that more realistic than plain CDs too. (and drives would cost the same, just drive management/firmware would be enhanced to support the GD-ROM format and disc manufacturing might be slightly more expensive due to the higher precision necessary -but still far less than that needed for DVD and rather like DDCD-ROM)

DVD was already significant in Japan and the US by 1998 and new PC games of the time were already getting some DVD-ROM releases with DVD-ROM drives starting to become more common on PCs and several common graphics cards supporting MPEG-2 acceleration (or full MPEG2 decoding in some cases). In our case we had a PCI RAGE Pro card from ATI in 1998 and DVD-ROM drive, but technically speaking DVD video was supposed to need AGP for full support and ATI actually abandoned official drivers for the PCI card... but my dad hacked together some beta drivers and it worked fine for most DVDs, and thus we had our first DVD player with composite line out to our Trinitron. ;) (it did run into trouble for DVDs approaching the peak bitrates and there would be some stutter or artifacting then, but there aren't too many DVDs that really push that -at the peak bitrate you only get just under 60 minutes of video on a 4.7 GB DVD, so most use lower rates, especially before dual layer stuff -for a lot of compiled TV shows and such you even have fairly common cases dropping to the minimum 350 kB/s -which incidentally is the max for CVD/SVCD at 2x CD-ROM)
But perhaps it was a case where new tech actually caught on faster in the west (especially the US) than in Japan. (opposed to Lasersic or such which was close to mainstream in Japan but extremely niche by comparison in the US)



But anyway, there's no question that the PS2 helped sell DVD as well as DVD helping to sell PS2s. ;) But the question would be if the same could have applied to the DC... and actual DVD would have obviously cost them big time (especially with Sony's in-house advantage of owning patents/licensing as well as manufacturing capabilities) on top of the early release, but VCD was a given and CVD/SVCD should have been realistic (at the lower peak bitrates you'd never run into the problems with bottlenecks as with the PCI RAGE anecdote above -come to think of it, the PCI RAGE may have had official SVCD support). The Dreamcast's ARM7 in the sound system is more than capable of MP2 decoding and should be fine for MP3, so that may have come into play in such hypotetical negotiations with the Chinese SVCD standardization. (SVCD and CVD used MP2 exclusively iirc) Though that may not have meshed for the price point of standalone CVD/SVCD players planned for the new standard.

If Sega had licensed the GDROM format, that could have had negative implications for piracy, especially catering to a format popular in China... in hindsight that really didn't matter as Sega left open more significant exploits in the DC hardware anyway that would have required tightened security on later models. (which they did add shortly before halting production)


On the DC topic, another significant thing (especially given Sega's tight financial situation) definitely would have been to not push the modem like they did. In hindsight it really wasn't critical and it ate into Sega's funds with all the pack-in and rebate deals. Sure, make it an attractive feature, but not an integral one: ie don't offer it pack in standard but only with special bundles or available separately, possibly with a more modest Seganet sign-on bonus of a free modem+keyboard+software rather than a full Dreamcast rebate, or not bother with SegaNet at all and cut out that added investment that they never got back (use 3rd party ISPs only). That would also allow a cleaner switch for supporting broadband network adapters later on. (many users who never bothered with dial up might jump straight to broadband instead and Sega wouldn't have been giving away modems across the board only to have them become obsolete)
So less cost overhead for Sega, less losses, sooner transition to selling hardware at a profit, and more funds to invest elsewhere or conserve in general to help stabilize the financial problems. (not keeping enough in reserve was something that plagued Sega from the early 90s onward at the very least -going all out with the Genesis did generally pay off, but not much else did when following that high-risk model -the Dreamcast did in the US in the short term but they couldn't sustain it and it didn't work in JP/EU)

sheath
12-08-2010, 08:19 PM
http://www.fileden.com/files/2008/4/21/1876835//SaturnVA12.png
:chewie:

Which chip in there is the SH-1?

TrekkiesUnite118
12-08-2010, 08:21 PM
DVD was there in 1998, but I wouldn't call it significant, especially here in the US. Some people I knew who were always early adopters of new technology had DVD players in 1998, but most people I knew didn't really start to adopt the format until atleast 2000, 2001. In fact VHS rentals and sales were still outnumbering DVD rentals and Sales well into 2003 in the US.

I really don't care about any lower end alternatives to DVD or anything like that. I am simply pointing out that VCDs were somewhat popular in Japan, if they weren't why would Sega have bothered to make that card? I'm simply pointing out that just becuase DVD came out in 1996 in Japan and was there in 1998 doesn't mean it was extremely popular right away. It really didn't begin to take off as a new format until around 2000 with the PS2. That's simply a fact really.

kool kitty89
12-08-2010, 09:03 PM
Which chip in there is the SH-1?
It has to be the OCU (IC38) as that's the only one directly connected to the CD-ROM buffer RAM. (the small chip on the diagram labeled CN4 should be the CD-ROM interface chip)




DVD was there in 1998, but I wouldn't call it significant, especially here in the US. Some people I knew who were always early adopters of new technology had DVD players in 1998, but most people I knew didn't really start to adopt the format until atleast 2000, 2001. In fact VHS rentals and sales were still outnumbering DVD rentals and Sales well into 2003 in the US.
Yeah, we only got it so early at home because of our PC facilitating it (though technically it didn't as it required a bit of software hacking to do DVD video with the RAGE Pro via PCI) and it was many years before we actually got a DVD player. (I don't think until ~2004 when our Trinitron died and we got a flat Sanyo CRT with component and anamorphic video modes and with DVD players being available for under $100 by that point -we had a GameCube that generation, so no console DVD video support)

But one thing I was pointing out was that PC software was already getting notable releases on DVD by 1998 (all of which still getting CD-ROM releases too, but that continued up to about 5 years ago), so in that respect it was as significant of a format in 1998 as CD-ROM was on the PC by 1994. (or 1997 was like 1993 in the sense that's when you first saw notable PC games using the format and multimedia heavy titles in both cases -including some notable graphic adventures- while you had a tiny amount of support in 1992 with some multimedia games -especially some educational stuff in Win3.1x)
Unlike CD-ROM (but like BD), it took far longer for DVD exclusives to actually appear given the much stronger competition CD-ROM gave over DVD compared to floppy disk over CD-ROM. (3-6 CDs for an identical game vs 12 floppy disks for a heavily cut down game in the handful of cases just before floppy based multimedia was dropped in general -other cases cut down the disk version far more or added less content to the CD-ROM versions in general)


I really don't care about any lower end alternatives to DVD or anything like that. I am simply pointing out that VCDs were somewhat popular in Japan, if they weren't why would Sega have bothered to make that card? I'm simply pointing out that just because DVD came out in 1996 in Japan and was there in 1998 doesn't mean it was extremely popular right away. It really didn't begin to take off as a new format until around 2000 with the PS2. That's simply a fact really.
Simple: market speculation, just like the 3DO did as a multimedia platform, and Phillips did when they originally introduced VCD on the CD-i, but that didn't pan out and the format didn't truly popularize until the licenses got really cheap and it became attractive as a lower-cost format in countries like China. It was notable, but not really any more so than laserdisc in the west and less than LD in Japan. (not sure if more or less than SVHS in the west)



And going back to your previous comment about Cinepak on the Saturn: there definitely should have been much better compression possible and again, from what I've read there WERE better codecs used than poor cinepak... though maybe that would be inclusive of some of the later "cinepak" codecs which went well beyond the early versions. (but I've seen specific mentions of MPEG-1 software decoding, though again it may actually have been H.261 which would be more realistic -so would motion JPEG)
And I'm also not positive that the Saturn's "cinepak" (or perhaps multiple codecs being called cinepak with some being direct derivatives of the Apple format) were really Cinepak either, but possibly a format more evolved from the "Cinepak for Sega" seen on the MCD using the 8x8 tile format of VDP2 (opposed to the MD VDP) with its much more capable color indexing abilities and CPU/DSP resource to perform additional lossless compression on the tile/pattern data, tile graphics data might be feasible to use some lossy compression on though- used to assemble the final frames (and audio of course -usually ADPCM handled by the 68k) and most likely using large groups of frame data compressed as single blocks to facilitate higher compression ratios and more variable frame sizes at more consistent framerates and data rates. (actually, the use of 8x8 pattern blocks would make that more like JPEG compression in that respect)

And youtube videos are not really a good example as they tend to filter out artifacts and obscure the native artifacts with recompression artifacts.
Edit: and Anime is one of the things that heavily caters to interaframe compression due to the generally low framerate of animation -that also makde things like Road Avenger and Keio Flying Squadron not look so bad at uncompressed at low framerates -often under 8 FPS on the MCD, though much better was managed once lossless and lossy schmemes were employed. (and the heavy use of static backgrounds and panning also catered well to use in realtime cutscenes or some hybrid curscene engines on the MCD or PCECD like Popful Mail or Lunar 2 -that would apply to Saturn as well, but I'm not sure if those techniques were used rather than pure fame by frame video)

sheath
12-08-2010, 09:12 PM
It has to be the OCU (IC38) as that's the only one directly connected to the CD-ROM buffer RAM. (the small chip on the diagram labeled CN4 should be the CD-ROM interface chip)

OCU IC37? IC38 is labeled Buffer RAM.

I was just thinking, with the way we've been discussing the SH-1 having no example code, and possibly no directly programmable capabilities, that maybe it actually wasn't an SH-1. It's a random thought, but maybe marketing thought throwing another impressive sounding chip into the specs looked better. There are enough SoA press releases promoting the Saturn having seven processors, mirroring Nintendo's anti-Blast Processing magazine campaign.

Then again, I don't recognize the 68EC000 in the sound area either.

kool kitty89
12-08-2010, 09:31 PM
OCU IC37? IC38 is labeled Buffer RAM.

I was just thinking, with the way we've been discussing the SH-1 having no example code, and possibly no directly programmable capabilities, that maybe it actually wasn't an SH-1. It's a random thought, but maybe marketing thought throwing another impressive sounding chip into the specs looked better. There are enough SoA press releases promoting the Saturn having seven processors, mirroring Nintendo's anti-Blast Processing magazine campaign.

Then again, I don't recognize the 68EC000 in the sound area either.
Yes, typo on my part... and yeah that is odd on the 68k.
As to the marketing: there were campaigns promoting the 7 processors in the system? (I only know of the "power of 4 processors" adds apparently referring to the dual CPUs+Dual VDPs) In that sense though, the Playstation has 4 processors not counting DMA management and the decompression ASICs. (CPU+GTE+GPU+AudioDSP -I don't think there's a dedicate Sound CPU like in the SNES)

I'm pretty sure the SH1 has been confirmed in official documentation and hardware tinkerers looking at the chips themselves. (and I think it may be the very same member of the SH1 MCU family as listed in EDGE as the Saturn's CPU in the early -and otherwise vague- specs published in late 1993 -the SH7032 which is a ROM-less SH1 with 8 kB onboard RAM -not cache, just a scratchpad used as work RAM)

sheath
12-08-2010, 09:40 PM
Yes, typo on my part... and yeah that is odd on the 68k.
As to the marketing: there were campaigns promoting the 7 processors in the system? (I only know of the "power of 4 processors" adds apparently referring to the dual CPUs+Dual VDPs) In that sense though, the Playstation has 4 processors not counting DMA management and the decompression ASICs. (CPU+GTE+GPU+AudioDSP -I don't think there's a dedicate Sound CPU like in the SNES)

I'm pretty sure the SH1 has been confirmed in official documentation and hardware tinkerers looking at the chips themselves. (and I think it may be the very same member of the SH1 MCU family as listed in EDGE as the Saturn's CPU in the early -and otherwise vague- specs published in late 1993 -the SH7032 which is a ROM-less SH1 with 8 kB onboard RAM -not cache, just a scratchpad used as work RAM)

Yeah, it was just an off the wall thought. I'm still very surprised that the SH-1 is in every Saturn and nobody knows what it does.

There were numerous press releases about the Saturn having, correction, eight processors (http://www.sega-16.com/forum/showthread.php?p=124975&highlight=Saturn+processors+Kalinske#post124975) in 1995. This used to lead me to believe that the Saturn's design was more centered around answering all complaints versus the SNES while being a "next gen" 3D console. Nintendo's advertising consistently promoted more chips being better than fewer chips at least through 1993.

By the way, I love that Kalinske shills the Saturn as a long term console to justify the early programming challenge. Sound familiar?

TrekkiesUnite118
12-08-2010, 10:22 PM
Isn't the SH-1 used to control the CD-ROM drive?

kool kitty89
12-09-2010, 01:38 AM
Yeah, it was just an off the wall thought. I'm still very surprised that the SH-1 is in every Saturn and nobody knows what it does.

There were numerous press releases about the Saturn having, correction, eight processors (http://www.sega-16.com/forum/showthread.php?p=124975&highlight=Saturn+processors+Kalinske#post124975) in 1995. This used to lead me to believe that the Saturn's design was more centered around answering all complaints versus the SNES while being a "next gen" 3D console. Nintendo's advertising consistently promoted more chips being better than fewer chips at least through 1993.

By the way, I love that Kalinske shills the Saturn as a long term console to justify the early programming challenge. Sound familiar?

Well, technically, the Saturn has 9 processors (including the 4-bit MCU used for I/O), or more depending on how loosely you define "processor." ;)

The Genesis has at least 4 processors in it, or more if you get picky on things like the I/O logic or PSG being a "processor." (so you could have the YM2612+PSG+VDP+68k+Z80+I/O logic but then the SNES could stretch things further with 2 PPUs+CPU+I/O+multiplier coprocessor+DSP+SPC700)
The Playstation would have the CPU+GTE+decompression logic+video decoding logic+GPU+DSP+I/O logic. (and that's all lumping I/O systems into one chunk even if they might have multiple I/O systems) The Jaguar would have the DSP+IO logic+GPU+blitter+OPL+68k.

It really gets silly if you look at things that way... though in the Saturn's case there's even some odd inflation to the specs from the perspective of the average techie as not only are there often unused features like the SCU's DSP (let alone the audio system) or the less than 2x performance of master+slave SH2 configuration, but the SH1 seeming like it's a useful coprocessor when it's just a glorified CD-ROM manager and a waste in the configuration used. (really odd given that, even if it was monopolized while loading data or such, it should have had full faculties available when the CD-ROM was idle or streaming CD-DA)



Isn't the SH-1 used to control the CD-ROM drive?
Not to control the CD-ROM drive (the CD-ROM chipset does that), but to manage the CD-ROM drive data transfer and such somewhat like the 68000 in the MCD... and it's a big waste as even a 68000 would be overkill in that role, but at least far less wasteful.
That's part of why some speculate (on top of rumors coming from engineers of the time) that the SH1 was originally to be the main CPU and have dual duties like the MCD's 68k, but later got pushed out in favor of the SH2s, but kept managing the CD-ROM due to time constrains for re-engineering the interface. (and perhaps assuming that it would be useful as a coprocessor when not managing CD duties)

However, it ended up only being a waste and never used for more than a glorified (expensive) simple MCU AFIK, with no tools, documentation, or sample code to allow developers to make use of it.

TmEE
12-09-2010, 02:13 AM
This schematic is for VA12 Saturn, which has some stuff integrated such as the SCSP+68K into same package.

The SH-1 does what Kool Kitty said, and it also single handedly manages copy protection. The chip seems to be ROM version with internal ROM (or the ROM is embedded into SCU or something) and you cannot run your own code on it, unless there's a hidden debug function which would be sweet.

sheath
12-09-2010, 09:08 AM
Hmm, copy protection. Saturn copy protection required a mod chip to circumvent (or was there a swap trick too?). Was the SH-1 less well documented than a 68000 at the time, and could they have been similar at cost? That might explain its inclusion, especially since it is likely that SoJ had some sort of bulk deal from Hitachi. Folks around here frequently argue that these system's could have simply, with little overhead, put all of the CD-ROM controls on the CPU(s). I think this would have affected optimal load times, but have no argument for thinking that way aside from the Sega CD and the Saturn having faster load times than contemporaries.

It just seems odd to me to have the SCU/DSP in there but poorly documented and the SH-1 in there but locked for hardware use only. Granted, a Saturn that reached from 1994-2004 would have likely seen more of its hardware tapped. Ah that would have been sweet.

TmEE
12-09-2010, 09:59 AM
The SH1 will read the CD, if its a game CD it will look for the security ring, if its not there, the SH1 will not allow it to be booted.

Chilly Willy
12-09-2010, 11:46 AM
If SEGA really wanted to save money on the Saturn, they should have taken the ASIC from the CDX (together with the 68000), removed the graphics process, added the sound DSP, and bumped the CD from 1X to 4X. Why did they design a whole new CD subsystem? They made a lot of errors when making the Saturn, but the CD issue seems the most clear.

kool kitty89
12-10-2010, 02:07 AM
This schematic is for VA12 Saturn, which has some stuff integrated such as the SCSP+68K into same package.

The SH-1 does what Kool Kitty said, and it also single handedly manages copy protection. The chip seems to be ROM version with internal ROM (or the ROM is embedded into SCU or something) and you cannot run your own code on it, unless there's a hidden debug function which would be sweet.
OK so NOT the SH7032 mentioned in EDGE in 1993. (which has no ROM and an 8 kB scratchpad)

Hmm, shouldn't it have been at least able to run code from the SDRAM buffer?






If SEGA really wanted to save money on the Saturn, they should have taken the ASIC from the CDX (together with the 68000), removed the graphics process, added the sound DSP, and bumped the CD from 1X to 4X. Why did they design a whole new CD subsystem? They made a lot of errors when making the Saturn, but the CD issue seems the most clear.
Given how the Audio DSP was pretty much unused on the Saturn, adding it probably wouldn't have been smart... (and it didn't support decompression, the one feature it really would have been used for) but adding the 32 DMA channels would be good and the synth capabilities. (though not often used eithe and not absolutely necessary as such, they were at least used more than the DSP from what I understand)
So more like taking the SCSP ASIC and MCD graphics/interfacing ASIC and merging them while omitting the DSP and blitter. (perhaps even allow the SCU DSP to be multipurpose and have DMA to the audio bus, unless it's not well suited for audio processing -or decompression at least, as that's the most needed feature and it definitely sounds like the SCU DSP is more flexible... and if it wasn't being used for geometry, it might as well be put to good use)
For that matter it might have been cheaper for Sega to license Yamaha's off the shelf OPL4 rather than invest in the SCSP at all, or use an embedded implementation of the 28 channel PCM chips being used on the Model 1 and Model 2 prior to the switch to the SCSP. (one interesting feature of the OPL4 is that it supports 12-bit PCM as well as 8 and 16-bit, and of course it has the OPL3 FM bock onboard too -which may have actually been more realistic for many developers to use than the advanced SCSP FM feature... far simpler but that's not bad all around and full simultaneous use of those 36 FM operators with all 24 PCM channels -with the normal limitations of the OPL3 of course, and composer/programmer skill to push its capabilities)

Did later versions of the MCD ASIC integrated the Ricoh chip, or did that remain on a separate IC until the end?

Chilly Willy
12-10-2010, 02:27 PM
OK so NOT the SH7032 mentioned in EDGE in 1993. (which has no ROM and an 8 kB scratchpad)

If the rom was in the SCU, then it could be the SH7032.



Hmm, shouldn't it have been at least able to run code from the SDRAM buffer?

It could run routines from ram - it's whether SEGA provided functions to run routines from ram that remains the question. When they dedicated the SH1 to just handling the CD, they probably removed any ability to run your own code. There really wouldn't be a need for it when you have the ability to use the 68000 and both SH2s.


Did later versions of the MCD ASIC integrated the Ricoh chip, or did that remain on a separate IC until the end?

No idea. You can look at the mobo yourself. I don't see it.

http://upload.wikimedia.org/wikipedia/commons/f/f2/Multi_Mega_mobo.jpg

TmEE
12-10-2010, 02:39 PM
The SH1 is a SH7097, and it should be able to run at 20MHz, at least on the mobos I found

And the ricoh chip is never integrated... the CDX is a MD2+MCD2 in a miniature package...

Chilly Willy
12-10-2010, 04:32 PM
Seriously, what I might have done in SEGA's place would be to start with the CDX, beef up the graphics functions in the the CD ASIC to a full VDP1 level, bump up the speed of the MD side 68000 to match the CD side (12.5 MHz), add one SH2 to act as a coprocessor to the MD 68000 (clocked at twice the 68000 speed), make a few minor updates to the VDP in the MD ASIC (like we talked about in another thread... increase the number of palettes and increase access speed to the vram among other things), and replace the Ricoh sound chip with something a little better (maybe a newer Yamaha chip like Kitty mentioned).

You'd have backwards compatibility, and you'd leverage existing technology to make the next level less expensive. They didn't need the power of VDP2 (the 2D chip), and one faster 68000 + one SH2 would have worked just as well (or better) than two SH2s. The only part that needed BIG improvements was the graphics processor in the CD part, along with better audio.

sheath
12-10-2010, 05:37 PM
Chilly Willy,

What are you offering the above alternative to? Looking at the Saturn's limited library, it appears to have provided reasonable mid-late 90s PC capabilities and Model 2 turned out fine as well.
What you are describing still sounds like a low level assembly based system that relatively few developers would have squeezed the power out of.

A ~$200 Saturn as you describe in 1995 may well have been something Sony would have taken a huge loss to compete against. How do you think your Saturn and the PS1 would have stacked up?

dbtmellis
12-10-2010, 05:40 PM
can the CD door still open with that 32x look-a-like attached?

Chilly Willy
12-10-2010, 06:17 PM
Chilly Willy,

What are you offering the above alternative to? Looking at the Saturn's limited library, it appears to have provided reasonable mid-late 90s PC capabilities and Model 2 turned out fine as well.

What you are describing still sounds like a low level assembly based system that relatively few developers would have squeezed the power out of.

Much of the Saturn software was assembly as well. All of SEGA's libraries for the 32X and Saturn were assembly. In any case, the 68000 based compilers were far more developed and debugged than SH compilers at that time as the 68000 was popular in personal computers and workstations.

My proposed Saturn is only barely less powerful than what SEGA gave us, being only less powerful in 2D capabilities. It would also have levered the knowledge developers already had with the SEGA CD.



A ~$200 Saturn as you describe in 1995 may well have been something Sony would have taken a huge loss to compete against. How do you think your Saturn and the PS1 would have stacked up?

Actually, what I described would still probably have been over $300 - don't forget that the CDX launched at about $400.

It would have eliminated the need for the 32X, and would have capitalized on existing games and programming knowledge, meaning Saturn games would have come out quicker and more frequently. Between no 32X and a larger game library, it might have actually faired pretty well against the PSX.

kool kitty89
12-10-2010, 11:31 PM
It could run routines from ram - it's whether SEGA provided functions to run routines from ram that remains the question. When they dedicated the SH1 to just handling the CD, they probably removed any ability to run your own code. There really wouldn't be a need for it when you have the ability to use the 68000 and both SH2s.
Well... when it was free of CD-ROM duties, it would be useful as a general coprocessor. It was on its own bus, so it didn't have some of the bus sharing limits of the SH2s and regardless of the model it had a 1 kB scratchpad at the very least (SH1s had 1, 4, and 8 kB versions with 0, 16, 32, or 64 kB of ROM on-chip).

I can't seem to find any specific info on the SH7097 though... Or anything in the SH709x range for that matter.




Seriously, what I might have done in SEGA's place would be to start with the CDX, beef up the graphics functions in the the CD ASIC to a full VDP1 level, bump up the speed of the MD side 68000 to match the CD side (12.5 MHz), add one SH2 to act as a coprocessor to the MD 68000 (clocked at twice the 68000 speed), make a few minor updates to the VDP in the MD ASIC (like we talked about in another thread... increase the number of palettes and increase access speed to the vram among other things), and replace the Ricoh sound chip with something a little better (maybe a newer Yamaha chip like Kitty mentioned).
Yeah, and one interesting possibility is if the pixel combining/RAMDAC chip also added alpha blending capabilities (even simple averaging like the SNES and Saturn VDP1 -but preferably in 24-bit RGB). That would be particularly interesting for shading effects: have 1 256 color 3D layer and then a translucent overlay used for 16/256 shades for shading/lighting effects. (that might be easier to engineer and better looking than hardware dithering in 256 colors or plain flat shaded/posterized 256 color)

If they added a DSP coprocessor, the one used in the SCU would probably be a lot better than a 25 MHz SSP-1601 as I suggested in that older discussion.

And as for using old tech, they probably wouldn't be using the exact same chips for the new machine (not all of them anyway), with the newer VDPs missing the necessary external buses and integrating other stuff that wouldn't need to be doubled, but working with mostly pre-existing hardware should have cut R&D time and costs for sure and (initially at least) they could probably use much of the very same hardware. The dual VDPs, RAMDAC/pixel combining/alpha blending logic would probably be on a new ASIC (and only including the MD-DAC+SMS+PSG+YM2612+CRAM+I/O blocks once, with the 2nd VDP block being just the digital portion of the VDP itself, or even omitting the SMS VDP logic entirely if they felt the need for SMS compatibility was unnecessary -which it already was by the MD2 given the rarity of PBC-IIs in Europe -and virtual absence elsewhere), maybe integrating the beefed up MCD blitter or leaving that on a separate IC with other interface logic integrated as with the MCD ASIC.

And with compatibility you'd need to keep all the MD+MCD audio hardware too, so you might as well make better use of it. (and rather than pushing for the OPL4, let alone something as elaborate as the SCSP, you could double the Ricoh chip, or add a few simple 16-bit DMA channels -the latter would probably be better to allow higher quality streaming audio in general with added stuff via software mixing: maybe even just a pair of 16 bit linear DACs with DMA -so like the 32x but with better DACs- and variable output sample rate, but a bank of DMA channels with a good range of hardware sample rates, volume, and 8/16-bit support would be nice too -maybe something like the Atari Falcon has with 8 16-bit DMA channels, and that actually went up to ~50 kHz, but it didn't cater to the common 48/44.1/32 kHz/22.05 kHz rates exactly) If they could get a good deal on the OPL4 (especially licensed and embedded), then it would certainly be a nice option on top of the old hardware. ;) (you'd have the PSG, YM2612, Ricoh chip -probably with more RAM- and the OPL3 FM block of the OPL4 plus 24 DMA PCM channels sampled to 22 or 44.1 kHz at 8/12/16-bit resolution -with a bit of added logic to allow DRAM interfacing given it only supports SRAM/ROM natively)

But given the low-cost emphasis and existing compatible hardware included, probably stick with a simple stereo DAC controlled by one of the other CPUs and /or DSP depending what had DMA to the audio bus. (maybe interleave accesses of both the Ricoh chip and the simple 16-bit DMA audio -simple ST/Amiga like interleaving should have been feasible, or perhaps make the DMA audio read directly from one of the 68k buses instead -then allowing either 68k, the DSP, or SH2 to mix to the DMA channels and keep the ricoh RAM purely 8-bit -a slow 128 or 512 kB 8-bit DRAM chip which should have only been a small 24-pin narrow DIP, and a bit of added logic to the Ricoh interface in the ASIC to allow DRAM to be used rather than SRAM/PSRAM)

And I already mentioned the previous discussion on page 2 of this thread ;)


We've gone through that before though, especially here:
http://www.sega-16.com/forum/showthread.php?t=8497&page=3 (especially chilly willys posts)



You'd have backwards compatibility, and you'd leverage existing technology to make the next level less expensive. They didn't need the power of VDP2 (the 2D chip), and one faster 68000 + one SH2 would have worked just as well (or better) than two SH2s. The only part that needed BIG improvements was the graphics processor in the CD part, along with better audio.
Cost advantage, R&D advantage, etc to allow faster production run-up, lower price point, and more time+fund investment in software development, advertising, producing good development tools, etc.
If they left out the warped rasterization logic of VDP1 and focused on providing external resource to aid in rasterization would have saved some time and increased flexibility and made the hardware only quads a non-issue. (via fast CPUs and/or DSPs -one SH2 and the DSP from the SCU would be nice -especially if it could be clocked up to 16.7 or 25 MHz)
As it is, the DSP in the Saturn+SH2s probably could have addressed triangle rasterization fairly well (perhaps even with less resource than software floating point math -and obviously avoding overdraw with folded quads), but Sega probably wasn't supplying a ready-made example of using the DSP for that... but in such a case with the hypothetical console, that would have been a primary feature to support with the DSP. ;)

And you've got the 68ks to help out too even if the SH2+DSP were maxed out rendering and related tasks (scene management, z-sorting, physics, lighting, etc), especially while the CD was idle or streaming CD-DA and you had full use of both 68ks. (and the Z80 for what that's worth, maybe again used as an audio controller, maybe clocked faster in Saturn mode if they really wanted to make use of it -maybe even 12.5 MHz given the 50 MHz- and a better bank switching scheme)


Since there's no VDP2 and they're working on existing hardware anyway, maybe they could have put more focus on the VDP1/blitter instead. Regardless of adding hardware rasterization, they could have added buffering for higher bandwidth and peak fill rate (and certainly keep the color look up capabilities of the Saturn VDP1), but buffering in particular would be very useful in maximizing operation in slower RAM and avoiding the need for SDRAM and still being faster than the Saturn's VDP1 for some things. (using 32-bit word RAM and texture memory, or perhaps DMA to the SH2 bus for 32-bit accesses as well as slower 16-bit access to the 68k buses, have phrase buffers to allow multiple lower depth pixels to be read and written at higher bandwidth and if possible add line buffers to allow prolonged reads and writes at full fast page bandwidth and probably double the internal clock rate to 25 MHz -really useful with shared memory to minimize page breaks and bus usage and is what the Jaguar does at 64-bits for most graphics operations -except texture mapping unfortunately) That's the best you could get without a proper cache, and that would be pushing it for the premise, but line buffers would minimize the hurt it would put on bus sharing with the 68ks and SH2. (if you used all 80 ns DRAM to minimize cost and use existing stockpiles, that would mean 50 MB/s for pulling textures from SH2 memory and for writing to word RAM and 25 MB/s for using the 16-bit 68k buses)

If you used SDRAM or EDO DRAM (probably the latter due to cost -probably avoided it on the Saturn to speed development due to SDRAM being easy to interface) for SH2 memory, that would be 100 MB/s for reads from SH2 memory. (if the ASIC was running at 25 MHz at least... if it was 12.5 MHz but with the added buffering, 25 MHz RAM would be useless...) And that's not considering potential to add 64-bit memory and buffer for that. (but since you've got an existing multi-bus architecture, that would be impractical due to the traces/board space it would requite -making a few things 32-bit and the rest 16/8-bit would make more sense)

Doing any warping effects (without full rasterization logic) would still take added overhead as any such case, but you'd have much faster texture mapping and more efficient bus sharing (without needing more buses/banks/RAM) and better 2D performance for scaling/rotation in general on top of the plain MD VDP sprites/tiles. (so supplanting the lack of VDP2 a bit more for some things -especially large, scaled background effects, competing better with the PSX GPU in 2D mode)




Chilly Willy,

What are you offering the above alternative to? Looking at the Saturn's limited library, it appears to have provided reasonable mid-late 90s PC capabilities and Model 2 turned out fine as well.
What you are describing still sounds like a low level assembly based system that relatively few developers would have squeezed the power out of.
None of that is to make it more powerful, but more cost effective and backwards compatible (while still optimizing cost). In actuality it would be a bit less powerful but far more cost effective and (depending on the actual feature set -a wide range of possibility in the hypothetical example) the differences wouldn't necessarily be that evident. (it definitely would be missing the VDP2 capabilities though)


A ~$200 Saturn as you describe in 1995 may well have been something Sony would have taken a huge loss to compete against. How do you think your Saturn and the PS1 would have stacked up?
Yeah, and that IS one thing Sega had over Nintendo from the launch of the SNES up to 1994 when both dropped to $100. (supposedly they were both $100 suggested retail by spring of '94, but it probably took longer for that price to be reflected at the actual retail level)

And while a fully evolutionary console would have been a very attractive option (both for compatibility, or even avoiding compatibility and only choosing select components to build onto with a bit more flexibility -and still cutting R&D costs/time and easing production/development), but even so the Saturn itself could have been cost cut to a more minimalistic configuration.

Aside from the Jupiter, they could have done a similar stripped-down configuration with the existing Saturn architecture (but no compatibility and added R&D costs). Cut down the CD-ROM sub system cut down RAM all around, and perhaps drop one of the SH2s. Using a derivative of the MCD CD-ROM interface with the 68k dual purpose for audio and CD-ROM would be nice, but from a late 1993 perspective they'd probably had the SH1 based interface locked-in, so other options would be faster. (maybe keep the slave SH2 but drop the SH1 and have the slave SH2 dual duty as coprocessor and CD-ROM manager, and cut down the CD-ROM buffer size in any case, maybe using a 128k DRAM chip -cheaper than SRAM/PSRAM and already in use by the MCD/Virtua Racing -and later 32x)
Drop the DRAM on the main bus and perhaps drop main SH2 memory to 512 kB 32-bit (2 256k chips rather than 2 512k chips), keep video RAM the same.
Hmm audio... definitely cut down the audio subsystem, no dedicated DSP, probably no synth, just DMA channels and maybe ADPCM decoding logic and drop the 68k.
Hmm, or maybe go REALLY simple and have something only a little better than the 32x (say stereo 16-bit high quality DACs -not PWM- with variable sample rate up to 48 kHz or 44.1 kHz) and then use the slave CPU to drive DMA audio and perhaps allow the SCU DSP to access audio as well. (to save cost, maybe either allow the CD-ROM buffer to double as audio RAM -and thus probably bump it to 512 kB DRAM, or bump up main RAM to 1 MB again and share that with audio, sharing slow DRAM with the CDROM would probably be the cheaper option)

So perhaps something around 2.5 MB total memory, so a major cut over the 4.5 MB the Saturn used, though probably 2 MB of that would still be fast/expensive SDRAM down from 3 MB SDRAM +1.5 MB DRAM of the real Saturn. In any such case, they could have addressed the limited initial memory with a bit more provision for RAM expansion including full 32-bit main SDRAM expansion and 16-bit SDRAM for the video bus as well (with expansion signals to facilitate that with minimal external logic on the add-on card). Basically allowing 16/32-bit SDRAM modules to be plugged straight in for expansion of the main bus and bus B (which both of the VDPs are connected to) while leaving bus A for the MPEG port alone. (bus A is the CDROM bus -or in this context, possibly a dual purpose audio+CD-ROM bus)

Perhaps even a coprocessor add-on... maybe (to simplify marketing) make a single, unified RAM+coprocessor add-on. But probably more likely plain RAM expansion. (and SDRAM is easier to interface, so that would facilitate things)

kool kitty89
12-10-2010, 11:41 PM
Actually, what I described would still probably have been over $300 - don't forget that the CDX launched at about $400.

It would have eliminated the need for the 32X, and would have capitalized on existing games and programming knowledge, meaning Saturn games would have come out quicker and more frequently. Between no 32X and a larger game library, it might have actually faired pretty well against the PSX.
You could cut costs a lot more to manage a lower cost though... and it would especially be nice to cut certain areas that would be easier to expand later on at reasonable cost, bu would be expensive early on. (like RAM)

Also remember that the CDX was hardly low-cost optimized and likely not sold at cost. It was $350 in early 1994 while the Genesis 2 and CD 2 had dropped to $100 and $150 by that fall, and a cost optimized duo unit should have been more like $200 by fall of 1994 in that context. (so $300 for a new system in spring of 1995 to the Saturn's $400 might have been rather feasible, maybe down to $250 rather than $300 in the Fall -or avoid the spring launch in the US entirely)

IblisSlayer
04-13-2014, 07:57 PM
I know that this is a super old post, but I was wondering if making the add on for Saturn would be possible still. I have the other consoles that I would take apart to mod into an ddon to plug into the expansion port and the VCD port.

Guntz
04-13-2014, 10:55 PM
You do realize this was a joke thread, right?

IblisSlayer
04-16-2014, 09:23 PM
Perhaps, but can still be doable. For example, the Genesis had half the required component to run master system games, so the Power Base Converter was added to add in those missing channels. The Saturn as well takes some hardware from the genesis, so an adapter (and possibly and boot disc if needed) can be used to run the Genesis. Sega CD is a possibility that is almost certain, though I believe 32X may be out of the picture due to the hardware.

Guntz
04-16-2014, 11:06 PM
Wrong, the Genesis has everything needed to run SMS games. All the PBC does is re-route the 64 pin cartridge slot to the smaller SMS cart slot.

The Saturn is a little too complicated to simply let the 68000 run Genesis code, you'd also have to basically emulate the VDP, YM2612 and PSG since none of those are represented on Saturn.

Segadream
04-17-2014, 04:37 PM
You know what's worse than finding a expansion port on the bottom of your favorite childhood console?
finding out that said expansion came out and was awesome and you didn't hear about it or play any of those rad games cause you live in _______ (insert country here) and not japan, then You wish you were living in japan and then : Fukushima Daiichi, still wanted to live there anyhow.:p