Discuss alternate realities here!

[A Black Falcon]

none of the poll options, but this:

Sega releases no 32X at all, instead they push the Mega CD with more games (less FMV)
and wait for 1.5 years after PS launch to bring out their Saturn, which is even more powerful
than it has been in reality, handles 3D graphics better and such.

Just like Sony defeated the Dreamcast, by simply waiting and advertising the PS2, while
the "enemy" was sitting on a slowly aging console.

FATALITY. Sega wins. Flawless victory : P

Yeah, that's the option I would choose too. No 32X at all, more focus on the Genesis and Sega CD in the interim, more actual good first party games on the Sega CD, and a later (one year later, probably, I'd say mid 1996 most likely) and more powerful Saturn. Sounds perfect.

[kool kitty89]

to simplify, the 32 bit market was wide open until sony published final fantasy vii in 1997. the playstation had a slight-to-moderate sales edge among hobbiests and technophiles, but the 16 bit market was still fairly strong in the mainstream with the snes.

this was segas failure, the market was fragmented and ripe for the taking, and the best title sega could come up with was nights... an effeminate clown flying through childrens' dreamworlds... not exactly a world beater, not exactly a game with attitude worthy of the sega scream.

you can play hardware shuffle all you want, but the results wouldnt be much different. sega wouldve faded from the picture. but if you were plop the final fantasy vii exclusive onto the saturn, that is your ultimate alternate reality.

So basically Sony bought the market with FFVII then? (Square published in in Japan of course, but I'd bet Sony had something to do with it being a PSX exclusive, and they advertised it a ton -and published it in the US)
It was after Square left Nintendo's side that several other key nintendo-oriented developers also left for Sony, many releasing killer apps. (like Metal Gear Solid)
But even before FFVII, you already had Sony buying off exclusives by 1996 with Tomb Raider II, and with the Saturn's decline in popularity came other issues, like some multiplatform games that WERE released in Japan still didn't get translated, even some of the Saturn specific ones. Of course what Stolar did didn't help. (the not out future thing more than anything else)

You can argue Nights, though given the fall out in marketing you can't know how it would do. (it was a big hit in Japan, but that doesn't necessarily it would translate to the western markets) The Panzer Dragoon series was some of Sega's best stuff at the time: cinematic, action-packed, graphically impressive, etc.
The lack of a new Phantasy Star game was a bit odd though, as was a lack of a new Sonic of any kind from SoJ or a Japanese 3rd party. (R was all there was other than bonus/compilation stuff)

Hmm, I wonder if the Genesis 2 spacer for the 32X could have done a better job of making the Genesis 2 and 32X look better. I also wonder if all of the opinions about the 32X being "ugly" are based on it standing so far off of the Genesis 2.

On the Genesis 1 it looks like a black mushroom cloud coming out of the top of the circular case design. It's fitting in an unorthodox way. On the Genesis 2 it looks like a mushroom, or a device with a neck cast, it's just too tall.

I bet if the spacer plastic helped mold the 32X better to the Genesis 2 case (Genesis 1 had no spacer) then the conflicted "aesthetics" of it all would be on the "hater" fringe only.

I think the 32x looks fine on the model 2 personally, better than the model 1 in several respects even.

Um, yeah, wiki isn't a source. It especially can't tell me what my set is capable of.

That wasn't a source, I was just trying to point you to a better explanation of how interlacing works.
And when a PC device manager says "29 Hz" for an interlaced display, it really means 59 Hz, again that would eb the effective full screen refresh rate too, but interlaced displays update 2x per frame, with even lines then odd lines, 1080i uses 2 540 line fields while 480i uses 2 240 line fields with 60 fields per second (or 59.94 for NTSC).
If it was 30 fields per second, that would be extremely flickery and only be an effective 15 frames per second, and no display uses that... none uses 30 Hz progressive either due to the flicker problem. (there was a high-res TV standard attempted in Brittan early on iirc that did that and was abandoned due to flicker)

I don't know, I haven't seen that stated before either way. It has always been somewhat of a mystery in gaming circles. The term you are using for it exemplifies this. You might as well be calling it "chip".

Well blitter would be the most appropriate term, as that's pretty much what it is, but Graphics Coprocessor ASIC or Gate Array is what it's often referred to. It's not really a VDP as it can't directly output video, then again neither can the VDP1 of the Saturn... maybe GPU might apply as that is often used to refer to a processor that doesn't necessarily contain video generation hardware. The term VDP is just a generic term coined by Texas Instruments for their TMS9918 video controller, the true common term for such is VDC (video display controller). Others used other terms like Nintendo's PPU, or Motorola's VDG (video display generator). I think Atari was the first one to use the term GPU on a console with the Jaguar. (in that case referring to a fairly general purpose RISC coprocessor optimized for graphics operations -namely transform and lighting effects, though it can perform some general CPU duties, it's rather poor at them compared to other tasks)

ASIC often implies additional hardware integrated on a single chip, though that's not really an exclusive thing for the term. The SVP is an ASIC, as is the VDP in the Genesis, and of course, the even more consolidated VDP ASICs used on later models.

I thought that is what I said. Listen, I'm talking about Sega targeting their arcade hardware capabilities and focusing on converting games. That is opposed to Sega designing hardware as "better" NES, or a better PC-Engine, or a better SNES.

All I was saying was that the NES and PC Engine are just as optimized for arcade games as Sega's consoles, and much more than that in some areas.
But in terms of Sega's console designs, I'd bet that the console competition was always a factor as well as arcade conversions.

You'd have to be crazy to think NEC wasn't the main reason for Sega and Nintendo pushing for CD-ROM based game platforms. (hell, NEC's push probably even had some influence on the FM Towns having CD-ROM standard and proliferating the media in general in Japan)

Hmm, yeah, I haven't paid much attention to that era.

OK, but hopefully now you realize that the Z80 in the SMS is not directly related with Sega using that in the arcade, but with the SG-1000, which was a direct Colecovision clone with 2 kB main RAM to the CV's 1. (it was so similar that a combo clone console with both SG-1000 and CV game support via 2 cart slots -it's even closer to the CV than the MSX which uses a different sound/IO chip -and I think different memory map as well)

It was an extremely common CPU used all over for consoles and home computers from the late 70s through the 1980s, just like the 6502.

And also note, Sega's earliest microprocessor based arcade systems used 8080 CPUs, which makes sense to transition to Z80 from that. (Z80 is more or less an evolution of the 8080)

Wow, you really do just think one way. The Dreamcast is almost certainly focused on consumerizing a 3D system with Model 3 capabilities. It happens to be better than Model 3 in numerous ways, doesn't render anything the same, etc. The Playstation 2 is more of an answer to the PS1 and N64 than the Dreamcast ever was, and it shows in the games. Think about the games, not the way the games are made.

I'm talking about the dreamcast's technical design, not the software library. You could take any console of that genration and apply the DC's game library to similar effect. (no different than had Sega used the 3DFX chipset instead of PowerVR)

The DC is just an advanced, high-performance, low-cost 3D oriented microcomputer with a custom optical media format. It's as much optimized for porting model 3 games as the GC, Xbox, or even PS2. That and they focused on a high-level friendly architecture with corresponding tools exceeding even those of the PlayStation by a good margin, and that's certainly something they learned the hard way with the Saturn. (ironically Sony did the opposite with with PS2)

Not according to any screenshot I have ever taken. I will agree with the framerate assertion though.

Just because you're using a 256 color palette, doesn't mean you're going to display all 256 colors simultaneously, especially with how low-res the mode 7 tile is (and more so by cartridge space to some extent).

Likewise you also don't have VGA games hitting 256 colors that often, or 32x games for that matter.
But the really important thing is that it's not limited like a 4 bit per pixel display to 16 colors (or 15 colors depending how you use it). And any pixel on any 8x8 tile used to build the mode 7 plane can be one of any 256 colors.

Yeah, I couldn't find nearly as much dirt on the PCE, it seems very elegantly designed.

It's still got a bandwidth limit, but not the Vblank only limit, Tomaitheous would be the one to know. (PCE programming is his specialty)

In regard to the Sega CD updating full screen, are you considering that the full screen might not need updating? If the scaled ground is only 1/4th of the screen and the other objects only take up another 3rd, wouldn't that save bandwidth as well?

Yes, it depends what sort of game you do and how you handle it. With BC racers the game window is probably rendered by the blitter, not using the VDP to move anything at all. (they might have used it for part of the scrolling BG, but that seems awkward given how they did it, and especially given the BG scrolls in a choppy manner similar to the rest of the screen)

If you render to sprite tiles for some things and/or keep things to only certain parts of the screen, that would help for sure, but you would have to stay within those limits and manage things carefully. (soulstar renders a fair amount of stuff to sprite tiles)
You still have that fixed bandwidth limit at the full 224 lines of active video and always VRAM space limit though. (and double buffering really puts a hurt on VRAM space -and the less added VRAM available)
And if you're going to use normal sprites and BG as well, you have to leave enough bandwidth to update those tiles and animation as well.
So clipping the screen is a very attractive option. (without any added clipping you only have enough bandwidth to update ~230 8x8 tiles in 320 wide mode or 186 tiles in 256 wide mode)

If you were careful and set it up in an optimized manner (ASIC rendered BG section in a small enough area to update in 1 vblank frame, sprite tiles in another single update, and probably at least another frame for general tile updates), but even then you wouldn't get more than 20 FPS, more likely 15, and doing that would mean you'd only have a very small region rendered as a single block (ie for a warped ground layer) with the rest being flat scaled or perhaps scaled and rotated animation on sprite tiles. (and you'd be limited in the number of sprites you could update too)
In this case, for a full width span of the ground layer (be it 256 or 320 wide mode), you'd be limited to only 5 tiles high (40 pixels vs the 64 pixels in BC Racers and closer to 176 pixels in many mode 7 games -it uses about that much in F-Zero).
Or you could split it into 2 updates, but that looks a bit off. (it's not super noticeable if it's split straight down the middle and done in 2 consecutive frame -especially on a CRT SDTV due to the long persistence phosphor, but it's not ideal and would still only get you 88 lines) But more importantly, you'd likely drop to 12 FPS.
In all of those cases, it would eliminate the need for double buffering. (the latter one could be done double buffer to remove the tearing, but that 2 frame update technique with the seam at the very middle of the frame seems to work very well on an actual TV -on an emulator you see a bit of flicker/tearing due to the faster response time of CRT VGA monitors or LCD displays than high persistence phosphor screens meant for interlaced displays -to minimize flicker, so the flicker from such updating would not be much more noticeable than the flicker from interlacing, but only if you limit it to 2 consecutive updates, no longer)

Clipping the screen isn't so bad though, and well worth it in many cases. You wouldn't have to clip it as extreme as I mentioned to get some consistent 20-30 FPS stuff if the game was really optimized, but you're still limited. Clipping to 200 or 192 lines really helps a ton (192 lines is what VR used and also what many SMS games use -SFII doesn't clip it quite that much). At 192 lines, you could probably approximate F-Zero at 20 FPS in NTSC, probably with scaled sprites/objects too, especially if you had them on the same layer rather than on hardware sprites. (in PAL you could probably do it at 224 lines at 25 FPS)
If you clipped to 184 lines you could almost certainly do it 30 FPS NTSC and render to sprite tiles and have enough room for reasonable tile updates for the scrolling BG as well. (which would only be a small strip anyway)

I think you might be right about BC racers, that screen is clipped enough that it should be able to run much faster than it does.

I can't think of anything that looks anything like Mode 7 no. I can think of tons of games that simulated road, roadside objects and other cars with scaling sprites/objects though. Rad Mobile being a prime example. No home system prior to the 32-bitters could even hope to simulate this, and the effect was far more impressive besides.

Huh, that's an interest way to do it, I've seen that with other things (namely galaxy force), but I hadn't seen a racing game that used scaled sprites/objects composited as a road. Usually such games just used plain old linescroll with lots of scaled sprites for the cars/objects: like F1 Exhaust Note or Super Lap on the System 32. (and linescroll limits the perspective used) The technique used for Rad Mobile gives a feel much more like a warped textured ground layer like mode 7 with the dynamic perspective of the world moving around you in perspective. (albeit it looks sprite-y) That's how they'd have to do it if the blitter/ASIC had been optimized for what the arcade boards do, or what Atari's Object processor did, straight zooming. (and in the case of those games, having more limited animation wouldn't be that much different than what you can do with warped perspective, the texture resolution would be just as limited, but you'd just use the composite method rather than the mode-7 like texture effect)

On the topic of F-1 Exhaust Note and Super Lap, both use linescroll for the road with a 3rd person perspective and tons of layered scaling for the scenery. Compared with F-1 Beyond the Limit it's obviously faster and more colorful, and BTL is also 1st person, but in BTL you have real perspective, and while some things are composited/layered objects, you have a ton that's not. Not only do you have the warped ground layer, but you also have texture mapped polygon models for the stands and some of the buildings. (Batman Returns, Batman and Robin, and Joe Montana NFL also use texture mapped polygons in several areas)

Right, with Batman Returns, Soul Star and Battlecorps though, this is certainly not a problem. With F1 Beyond the Limit, BC Racers and Batman & Robin it is.

Actually, I think it might be some of the former that are more limited by DMA (especially batman returns and battlecorps) given that the latter 2 might max out the ASIC bandwidth and thus not be limited by the VDP. (VRAM space is always limiting, but I remember reading that Batman and Robin pretty much maxes out the ASIC's resources and that's the primary factor, while BC racers is so clipped that the DMA bandwidth shouldn't be a problem)

For Sonic CD though, the bandwidth is definitely the limiting factor, and they really should have clipped it, it could have looked a lot nicer. (not only higher framerate, but scaling sprites/objects, and probably a longer draw distance for the ground -though that would also depend on how much of the screen they wanted to fill with the sky)

Stop knocking my second favorite Sonic bonus rounds would ya! I never found the grounds particularly low framerate though. Have you looked at Super Mario Kart on real hardware recently?

Yeah, it's still decent nonetheless, I just don't think the trade-offs for keeping it full-screen were worth it. 15 FPS is OK, but the fact that the sprites are just choppy animation is probably the biggest issue. Plus the fact that it could easily run at 25 FPS in PAL as it is had the PAL version been modified to take advantage of the added bandwidth. (clipping it to 200 lines for NTSC should have really addressed that a lot)
Hell, running it in 288x200 probably would have been nice, high res mode and still about the same amount of space on-screen as 256x224 (in terms of VRAM usage), with the higher bandwidth of 320 wide mode and the clipping, it could probably be 30 FPS for NTSC. (clipping horizontally doesn't add bandwidth but helps save VRAM use and makes for a smaller area to update -also note that clipping to 288 pixels wide isn't so bad, for example: Shadow Squadron runs in 288x224)

I never notices Mario Kart's mode 7 to be particularly slow and I've played it recently, maybe I should pay closer attention. (obviously the sprite animation is choppy, but the ground didn't seem like 15 FPS) Again, the lack of sprite scaling is the real downside to Sonic CD.

It's apparently 20 at 320 or 16 at 256. I haven't figured out what that really means though. It just sounds like simple math based on the 8 pixel wide tiles to me. Of course more than twenty 16 pixel wide sprites can't appear on the same line of only 320 pixels. Why would Streets of Rage max out at "only" ten characters on screen then? I haven't seen any discussion on that topic actually.

I'm not sure that's true, but I know several of the guys on here know for sure. There's 2 limits: 1 is sprites per line, the other is sprite pixels per line and you can't break either of them. (you get drop out, so it's not like you can have 20 32x32 sprites per line, but I think you could have 20 16 pixel wide sprites per line -height doesn't matter)

I'll have to check that out again, I know I never gave either game a chance back in the day. Checking out Galaxy Force II on Genesis again really made a difference for my appreciation of it.

The control in GFII feels really sluggish to me, especially in the vertical, otherwise the music is good and I can stand the flicker.

It must have been development costs really. Sega was already relatively bad/disinterested in wooing third parties to any of their systems. To add a 3-5x development cost to prioritizing Sega CD hardware would not have worked.

Other than the transition for programmers to get used to the different limitations and areas for optimization of CDs vs carts, there shouldn't be much cost difference for direct multiplatform releases.

Granted, you had the potential for some higher production value stuff, but that wasn't necessary for a huge portion of the library, just an arrange synthesized soundtrack (and/or using the onboard sound -depending on the length of some tracks or if the CD needs to load data on the fly), and maybe a more detailed opening sequence with better animation (or actual FMV depending on the case).

But otherwise, it could just have been like the PCE CD, and they could save costs in a ton of areas: namely related to production/distribution and revisions of software. (discs are cheap, little is lots when you have to dump a batch, changing supply output rate is smooth and easy, changing production for new revisions is also inexpensive, etc -vs the limits and costs of ROM production)
Having many of the more common games at lower price on CD-ROM than cart would have been a major selling point, or had the potential to be. (enough to make the system pay for itself if you're talking $30-50 for new games vs $50-90 or $100 in a few cases)

I enjoy the conversation, I just can't use conjecture. Sources with names and dates just matter more than forum posts or nameless wikis for that matter.

But we've been through the whole technical side with some people who really have some idea of the costs involved, that's the point...

There just isn't any historical hardware outside of the NEO GEO or TG16 to compare to. If we knew of specific markups for either system we would have more to go on. In a speculative Sega CD redesign with more features real world cost is everything.

Finding the contemporary prices for the PCE CD in Japan would be a good start.
But RAM prices for sure were no the main issue. The PCE CD in 1988 could reasonably have had 256 kB of DRAM instead of 128 kB split between ADPCM and program RAM... hell, in hindsight it almost definitely would have been more useful to have 256 kB of program RAM than the ADPCM channel, and probably cheaper too. (remember the RAM amount isn't the measure of cost alone, but factors like the speed used, the type of RAM, the number of buses, the bus width, number of chips, number of pins per chip, etc -in this case you're talking about cutting 2 separate banks of DRAM down to one consolidated bank on a single 8-bit bus but 256 kB instead of 2x 64 kB -and 256 kB of DRAM in 1988 cost about $28 on the mass market -with NEC's vertical integration, probably less than that)
And again, they could have later added the ADPCM expansion via a hucard. (probably along with a BIOS upgrade, or maybe along with more RAM -like in 1991, instead of upgrading to 256 kB, it upgraded to 512 kB and added ADPCM)


Going back to the original discussion, I really like the bare-bones Sega CD idea best, especially by late 1989 in Japan, if possible. (1990 would still have been OK though) 256 kB DRAM would have been fine for the time (maybe more if audio was shared), no ASIC, probably the same sound chip (sega was using it by '89 as was the Fm Towns) though they could go cheaper with a simple DMA sound chip, preferably stereo. (something like the STE had would be fine) They could have dumped the 68000 for a simple MCU to manage the CD-ROM drive, but keeping the cache would have been important. (that was one nice feature over the PCE CD, and it almost certainly helped speed up load times and smooth things out in general)
FMV would probably be about the same quality with that too.

And then later have a separate upgrade via the cart slot, earlier than the 32x and more like the Sega CD's enhancements, adding a flexible blitter oriented around scaling and rotation (maybe a little faster than the one in the MCD), added RAM (at least for the blitter to render in), possibly a general purpose coprocessor (added CPU or DSP perhaps -depending on the time it was released, maybe a 68000 or maybe an SH1 and perhaps 512 kB to 1 MB of work RAM -depending on time of release), and rather than just the blitter, couple it with a simple bitmap display controller for an 8bpp 256 color indexed display (preferably 15-bit RGB, but 12-bit would probably be OK), and sound expansion, especially if the CD hadn't used the ricoh chip. (probably use the ricoh chip then, or maybe DMA sound again depending how you want to delegate resources)

If you pushed at out in 1992, probably 2x128 kB for the word RAM/framebuffers (like 32x and MCD had), 512 kB of work RAM and a 16 MHz 68k (maybe stick to 12.5 MHz), the low-cost ARM60 was out by then, but still probably not the price range sega wanted, and even the SH1 was out by late 1992 but that would almost certainly have cost more unless Sega got a super good deal from hitachi. (the ARM60 was a tiny low-cost RISC CPU, no cache, no on-chip RAM at all for that matter, 100 pin package, 12.5 MHz rated speed, moderate performance -probably similar to a 33 MHz 386, etc -probably the one part of the 3DO they really went cheap on)

If they waited until 1993 they probably could have reasonably gone with the SH1 by that point and probably 1 MB as well. (RAM prices were pretty stagnant but other costs would be coming down) That or maybe add a faster 68k and another coprocessor (ie the SVP, or the DSP core used in it rather) probably have that, the blitter, and bitmap controller all consolidated in a single ASIC but that point, probably the audio hardware too. (you could probably even cut cost and drop the added 68k altogether, but it depends on the case -the SH1 would have the most flexibility in several areas but would be as cost effective in others -you actually could push an SH2 at that point too, but it would probably be rather expensive -the cache is nice though, especially if you stuck with slow/cheap RAM as was likely, maybe that would be fine if it was a late 1993 JP release and a 1994 US release)

Of course, any such add-on could be used for cart games as well as CD, and the RAM expansion could come in handy in either case. (storing most/all data compressed in ROM or more program memory in general for the CD)

In the case of a more advanced 1993 unit (or even pushing into 1994 -more likely for a US release anyway), that would offer some pretty decent 3D as well as some nice 2D enhancements, so much so that an integrated counterpart could probably act as a decent early 5th gen console (especially with the SH2). Of course, that would mean a successor to that much sooner than the DC. (probably by 1996 in Japan depending how strong competition was)


And in any scenario with the CD, having cart games with CD expansions would be neat too.
And also, in any case, a duo unit would have been significant too. (probably about a year after the CD was initially released, maybe 2 if it had a late 1989 launch)

[N.Saibot]

Yeah, that's the option I would choose too. No 32X at all, more focus on the Genesis and Sega CD in the interim, more actual good first party games on the Sega CD, and a later (one year later, probably, I'd say mid 1996 most likely) and more powerful Saturn. Sounds perfect.

We both should work as highest executives at Sega. Let's detail this plan out and go to
them, maybe they want to take us. Together we will bring the old glory back to the House Of
The Hedgehog!

[kool kitty89]

Yeah, that's the option I would choose too. No 32X at all, more focus on the Genesis and Sega CD in the interim, more actual good first party games on the Sega CD, and a later (one year later, probably, I'd say mid 1996 most likely) and more powerful Saturn. Sounds perfect.

Yeah, except as it was FMV wasn't that huge a chunk of the library, the marketing just focused a bit too much on it. (pushing multimedia was fine, and even the more gimicky stuff was still popular for a while, but better use of multimedia stuff interspersed with gameplay or better used integrated in-game)

In particular, they could reevaluate some earlier games that could still be marketable (and may not have gotten much press originally) and others that are more worn out or already heavily sold, and re-release some select titles.

On top of that, the Duo console, preferably by 1993 and dropping in price in '94.

And for all the cart stuff you still had a lot of potential for on-cart enhancement too. (from graphics to audio to RAM, or even things to save cost like a decompression ASIC to allow all data to be compressed and streamed in realtime -like some late SNES games- cutting ROM needed by a significant margin)

As to 1996, maybe, but that would be a hurt on Japan, and even if you focused primarily on the western markets, you'd still need to keep Japan in mind for support of several key Japanese 3rd parties.

Still, they might have been able to afford another 6 months or a bit more on the Saturn in Japan (especially if Virtua Fighter II was a launch title). They wouldn't have to abandon the Saturn hardware either.
Say by late 1993 (when they supposedly started the final redesign of the Saturn historically -not fully confirmed afik) that instead of a more short term redesign for a fall 1994 release, they made the enhancements more substantial and aimed at a mid/late 1995 release for Japan and a year later in the US.

I'm thinking perhaps instead of so many dedicated buses/banks, consolidate things a lot more, maybe even down to a single 64-bit bus even and a single 4 MB unified block of SDRAM and all the processors buffered to take advantage of that -66 MHz 64-bit DRAM would be in the same bandwidth range as the N64, and all the SDRAM used in the Saturn was rated for at least that speed, though most wasn'tclocked nearly that fast as the processors couldn't use it -ie 64-bit DMA, you might get away with 32-bit shared bus at that speed. (probably still have the separate CD-ROM cache though, but managed by a cheaper MCU/CPU rather than the overkill SH1 and maybe not a full 512 kB for that, though it would be nice -the PSX only had 32 kB for the CD-ROM buffer) Have a 66 MHz SH3 as the main CPU -should be fairly reasonable by then (and 66 MHz was the lower-end model, there was a 100 MHz model at the time too), and especially with the cost savings in other areas and less board space used, still Hitachi given the good relationship Sega apparently had and correspondingly good pricing for such. Probably drop the audio DSP too, just the SCSP sharing main memory if possible. (and any decompression or other effects handled by the CPU)
The VDP architecture would likely be built onto VDP2 for the video generation and 2D capabilities (the BG layers -also usable in a mode-7 like manner and used for the floor in many saturn games), but integrated with that would be a coprocessor similar to VDP1 but perhaps adding hardware triangle rasterization and transparency for warped polygons (fix the bug), maybe some other features like a texture cache, maybe a hardware Z-buffer, or maybe bilinear texture filtering or perspective correct rendering. (probably a texture cache would be most useful if anything of the latter group, much of the rest could be addressed by the added CPU grunt) Probably rely on the CPU to plot the points for 3D as well. (so no 68k, no SH1, simple embedded MCU controlling the CD-ROM/cache, fewer chips in general, unified system bus with high bandwidth and system buffered to take advantage of it, maybe bump it up to a 3x or 4x CD-ROM drive depending on other cost issues, and provisions for RAM expansion)

[chameleon]

its impressive the amount of technical details you know. I am learning a lot from you

anyway, my timeline could be this:

1993: SegaCD. there are countries where the model1 didnt appear and they went right to the model2. the market was not ready for SegaCD in January 1992 in many places (outside japan). a 1993 model should have a more polished hardware (like the changes you sugested), more ram, faster scaling, faster CPU. and/or cheaper

It should be easier to program, with good dev tools

games like virtua racing or doom could be possible just with a bit improved segaCD

1995: Sega Jupiter. No 32X release. Jupiter should be based on a Dreamcast style hardware (with the hardware available on the time). A SH3 at 66MHz + 3D video could be great.

2000: Sega Dreamcast: with DVD and improved PowerVR/3DFX. I could propose some other changes, like remove the modem, the control pads should be like the saturn ones but with two analogs + vibration (dual shock were introduced in 1997/1998), and no memory card slot on the control pads.

[sheath]

I think the 32x looks fine on the model 2 personally, better than the model 1 in several respects even.

Yeah, it is more symmetrical on the Genesis 2. I just think it doesn't look so tall and large in comparison to the Genesis 1. It's still centered on the ring design that was always offset anyway. I hate it when people say something I think is cool looks ugly either way, it's just impossible for me to see things their way.

We ought to have a poll on whether yellowing SNESs, the 32X, or the Playstation 1 is the most ugly.

That wasn't a source, I was just trying to point you to a better explanation of how interlacing works.
And when a PC device manager says "29 Hz" for an interlaced display, it really means 59 Hz, again that would eb the effective full screen refresh rate too, but interlaced displays update 2x per frame, with even lines then odd lines, 1080i uses 2 540 line fields while 480i uses 2 240 line fields with 60 fields per second (or 59.94 for NTSC).
If it was 30 fields per second, that would be extremely flickery and only be an effective 15 frames per second, and no display uses that... none uses 30 Hz progressive either due to the flicker problem. (there was a high-res TV standard attempted in Brittan early on iirc that did that and was abandoned due to flicker)

Ah, I see what you're saying, and I got mixed up. My HTPC's display output is 1080i, as that's the only high resolution my set supports. Then I have the desktop and in game resolution set to 1280x800 29Hz. I knew that about interlacing, I just didn't put the relationships together correctly.

Well blitter would be the most appropriate term, as that's pretty much what it is, but Graphics Coprocessor ASIC or Gate Array is what it's often referred to. ...

ASIC often implies additional hardware integrated on a single chip, though that's not really an exclusive thing for the term. The SVP is an ASIC, as is the VDP in the Genesis, and of course, the even more consolidated VDP ASICs used on later models.

That later definition of ASIC is what I think of when I see it. I haven't seen the term Gate Array before. I decided to stick to Graphics Coprocessor, because that's what it is.

All I was saying was that the NES and PC Engine are just as optimized for arcade games as Sega's consoles, and much more than that in some areas.
But in terms of Sega's console designs, I'd bet that the console competition was always a factor as well as arcade conversions.

You'd have to be crazy to think NEC wasn't the main reason for Sega and Nintendo pushing for CD-ROM based game platforms. (hell, NEC's push probably even had some influence on the FM Towns having CD-ROM standard and proliferating the media in general in Japan)

NEC definitely was the reason Sega had the Mega CD created, that same interview with Takami said just that. However, the focus on Turbo CD ended with making it load faster and less often. The focus on the extra hardware began and ended with Sega's arcade systems according to the interview. Again, the Sega CD's capabilities have more dissimilarities with Mode 7 than there are similarities. You are observing this yourself in your framerate observations.

OK, but hopefully now you realize that the Z80 in the SMS is not directly related with Sega using that in the arcade, but with the SG-1000, which was a direct Colecovision clone with 2 kB main RAM to the CV's 1. (it was so similar that a combo clone console with both SG-1000 and CV game support via 2 cart slots -it's even closer to the CV than the MSX which uses a different sound/IO chip -and I think different memory map as well)

It was an extremely common CPU used all over for consoles and home computers from the late 70s through the 1980s, just like the 6502.

And also note, Sega's earliest microprocessor based arcade systems used 8080 CPUs, which makes sense to transition to Z80 from that. (Z80 is more or less an evolution of the 8080)

I know the Z80 was extremely common, but it is no coincidence that Sega used it almost exclusively in the pre-Space Harrier arcade hardware released before and after the SMS.

I'm talking about the dreamcast's technical design, not the software library. You could take any console of that genration and apply the DC's game library to similar effect. (no different than had Sega used the 3DFX chipset instead of PowerVR)

The DC is just an advanced, high-performance, low-cost 3D oriented microcomputer with a custom optical media format. It's as much optimized for porting model 3 games as the GC, Xbox, or even PS2. That and they focused on a high-level friendly architecture with corresponding tools exceeding even those of the PlayStation by a good margin, and that's certainly something they learned the hard way with the Saturn. (ironically Sony did the opposite with with PS2)

Sony also focused almost exclusively on making the PS2 jam as many polygons on screen as possible. This was obviously not Sega's focus, they instead focused on the texture mapping and GPU effects that enhanced the look of games. I'd have to dig up a bunch of old press releases and interviews, but Sega was targeting Model 3 for the Dreamcast's performance capabilities. Sega even made a big deal out of how much less expensive Naomi was compared to Model 3, and that it was at least as powerful.

Just because you're using a 256 color palette, doesn't mean you're going to display all 256 colors simultaneously, especially with how low-res the mode 7 tile is (and more so by cartridge space to some extent).

Likewise you also don't have VGA games hitting 256 colors that often, or 32x games for that matter.
But the really important thing is that it's not limited like a 4 bit per pixel display to 16 colors (or 15 colors depending how you use it). And any pixel on any 8x8 tile used to build the mode 7 plane can be one of any 256 colors.

Yes, that is true. 256 colors is better than 64, more is better. However, SNES games are still not displaying four times the colors, they are displaying two to three times the colors. When people look at a SNES game and say "Oh, more colors!" they're not envisioning the color palette, they're looking at the display. Then they turn around and look at the specs, typically caused by bad editorialist impressions, and say "Oh, SNES has 4x the colors, that's 'better'".

Whereas I was shocked that a great looking game like Revenge of Shinobi was averaging less than 45 colors, or Super Castlevania IV only 96, I wouldn't even guess that in emulation. The color differences between these two systems is a huge exaggeration in actual software, especially on a regular television.

If you were careful and set it up in an optimized manner (ASIC rendered BG section in a small enough area to update in 1 vblank frame, sprite tiles in another single update, and probably at least another frame for general tile updates), but even then you wouldn't get more than 20 FPS, more likely 15, and doing that would mean you'd only have a very small region rendered as a single block (ie for a warped ground layer) with the rest being flat scaled or perhaps scaled and rotated animation on sprite tiles. (and you'd be limited in the number of sprites you could update too)

Batman Returns is 20FPS, I would have thought it was 30FPS.

I think you might be right about BC racers, that screen is clipped enough that it should be able to run much faster than it does.

The developer said that they asked him to use the Battlecorp engine but cram as many scaling sprites into it as possible. So, assuming he meant "sprites" and not "objects using a BG" it is a fairly unique engine from what you are describing.

Huh, that's an interest way to do it, I've seen that with other things (namely galaxy force), but I hadn't seen a racing game that used scaled sprites/objects composited as a road. Usually such games just used plain old linescroll with lots of scaled sprites for the cars/objects: like F1 Exhaust Note or Super Lap on the System 32. (and linescroll limits the perspective used) The technique used for Rad Mobile gives a feel much more like a warped textured ground layer like mode 7 with the dynamic perspective of the world moving around you in perspective. (albeit it looks sprite-y) That's how they'd have to do it if the blitter/ASIC had been optimized for what the arcade boards do, or what Atari's Object processor did, straight zooming. (and in the case of those games, having more limited animation wouldn't be that much different than what you can do with warped perspective, the texture resolution would be just as limited, but you'd just use the composite method rather than the mode-7 like texture effect)

Power Drift is another one, also I think there were some motorcycle games that did it. I would have rather had a System 32 home console than even a Saturn or PS1. That is, I would have rather seen an entire generation of games focused on System 32's capabilities.

On the topic of F-1 Exhaust Note and Super Lap, both use linescroll for the road with a 3rd person perspective and tons of layered scaling for the scenery. Compared with F-1 Beyond the Limit it's obviously faster and more colorful, and BTL is also 1st person, but in BTL you have real perspective, and while some things are composited/layered objects, you have a ton that's not. Not only do you have the warped ground layer, but you also have texture mapped polygon models for the stands and some of the buildings. (Batman Returns, Batman and Robin, and Joe Montana NFL also use texture mapped polygons in several areas)

Slipstream seems to look a lot like something the Sega CD could do. It's more of a texture mapped look. I always thought F1 Beyond the Limit was unnecessarily low framerate though.

I never notices Mario Kart's mode 7 to be particularly slow and I've played it recently, maybe I should pay closer attention. (obviously the sprite animation is choppy, but the ground didn't seem like 15 FPS) Again, the lack of sprite scaling is the real downside to Sonic CD.

It's either 20 or 30, but I'm fairly certain it slows down into the teens on turns. Mario Kart isn't a solid framerate, that much is certain.

I'm not sure that's true, but I know several of the guys on here know for sure. There's 2 limits: 1 is sprites per line, the other is sprite pixels per line and you can't break either of them. (you get drop out, so it's not like you can have 20 32x32 sprites per line, but I think you could have 20 16 pixel wide sprites per line -height doesn't matter)

I know that the TG16 treats 8 pixel wide sprites as 16 wide, so while it should be limited to 16 per scanline it seems to really be limited to 8. I didn't find that kind of limit with the Genesis.

The control in GFII feels really sluggish to me, especially in the vertical, otherwise the music is good and I can stand the flicker.

It plays the same as the Saturn version on a real controller. I'm more impressed with how smooth the animated sprite scaling is. It blows any of Sega's other arcade adaptations out of the water in that department. It seems to run afoul of sprite limitations compared to the arcade game though. The capital ships that you blow apart in the first level might as well have been cut, they just don't even come close to the way they look in GF Arcade (or Saturn).

Other than the transition for programmers to get used to the different limitations and areas for optimization of CDs vs carts, there shouldn't be much cost difference for direct multiplatform releases.

Sure, the cost would be the same as a port unless they add multimedia or special effect scenes. The 4-5x development cost isn't based solely on CD-Audio and voice actors being added, apparently they needed more people in the general development team too. One article compares the development team for Phantasy Star III and claims the average CD-ROM team needed to be double or more that size.

But otherwise, it could just have been like the PCE CD, and they could save costs in a ton of areas: namely related to production/distribution and revisions of software. (discs are cheap, little is lots when you have to dump a batch, changing supply output rate is smooth and easy, changing production for new revisions is also inexpensive, etc -vs the limits and costs of ROM production)
Having many of the more common games at lower price on CD-ROM than cart would have been a major selling point, or had the potential to be. (enough to make the system pay for itself if you're talking $30-50 for new games vs $50-90 or $100 in a few cases)

I rarely paid full price on games even back then. I think for the most part Sega CD games were set at or lower the cheapest Genesis carts though.

Finding the contemporary prices for the PCE CD in Japan would be a good start.
But RAM prices for sure were no the main issue. The PCE CD in 1988 could reasonably have had 256 kB of DRAM instead of 128 kB split between ADPCM and program RAM... hell, in hindsight it almost definitely would have been more useful to have 256 kB of program RAM than the ADPCM channel, and probably cheaper too. (remember the RAM amount isn't the measure of cost alone, but factors like the speed used, the type of RAM, the number of buses, the bus width, number of chips, number of pins per chip, etc -in this case you're talking about cutting 2 separate banks of DRAM down to one consolidated bank on a single 8-bit bus but 256 kB instead of 2x 64 kB -and 256 kB of DRAM in 1988 cost about $28 on the mass market -with NEC's vertical integration, probably less than that)

It would be really helpful if I could see a scan of something from back then showing that price.

Going back to the original discussion, I really like the bare-bones Sega CD idea best, especially by late 1989 in Japan, if possible. (1990 would still have been OK though) 256 kB DRAM would have been fine for the time (maybe more if audio was shared), no ASIC, probably the same sound chip (sega was using it by '89 as was the Fm Towns) though ... FMV would probably be about the same quality with that too.

I think it would have been fine like that too. In fact, I really like the cart loaded processor and expandable RAM idea, though that's all bad for developer support unless it sells into the mass market.

And then later have a separate upgrade via the cart slot, ... a flexible blitter oriented around scaling and rotation ... added RAM ... possibly a general purpose coprocessor ... and rather than just the blitter, couple it with a simple bitmap display controller for an 8bpp 256 color indexed display ... and sound expansion, especially if the CD hadn't used the ricoh chip. ...

Some of that would at least need its own video output, I'm not sure that would be better than just releasing the 32X. That's actually why I like the 32X, because it killed so many birds with one stone. Something that only brought Genesis owners Mode 7-ish graphics and theoretical 256 color graphics just would not have mattered as much. US gamers were graphics whores but they knew nothing about optimal displays.

That's why I like the idea of delaying the Saturn in the States so much. All 32X needed was better marketing really, and the Neptune by 1995. The case redesign was mostly being silly. Though I would like to see some concepts other than the original design.

If you pushed at out in 1992, probably 2x128 kB for the word RAM/framebuffers (like 32x and MCD had), 512 kB of work RAM and a 16 MHz 68k (maybe stick to 12.5 MHz), the low-cost ARM60 was out by then...

Ooh, I can hear the developers whining now "working with two different CPUs is soooOoOoo hard."

If they waited until 1993 they probably could have reasonably gone with the SH1 by that point and probably 1 MB as well. ... That or maybe add a faster 68k and another coprocessor ... the blitter, and bitmap controller all consolidated ...

...

In the case of a more advanced 1993 unit (or even pushing into 1994 -more likely for a US release anyway), that would offer some pretty decent 3D as well as some nice 2D enhancements, so much so that an integrated counterpart could probably act as a decent early 5th gen console (especially with the SH2). Of course, that would mean a successor to that much sooner than the DC. (probably by 1996 in Japan depending how strong competition was)

I could definitely see a scenario where Sega started emphasizing the Sega CD in 1993 and enhanced it with carts through 1998. Sega just needed to *not* release the upgrades too often and needed to handle the upgrades with adequate promotion/fan service. The "true" 32/64-bit consoles would have had an even harder time pulling the masses away from the Genesis-"Super" CD and SNES. Release the Dreamcast as normal ("normal" DVD was apparently impractical, see Xbox and GC besides) in 98-99 and I can definitely see Sega still being in hardware.

[Defolto]

Interesting thread.

[kool kitty89]

its impressive the amount of technical details you know. I am learning a lot from you

Thanks, but I should point out that I'm not really a tech expert or anything, I've just absorbed a lot of knowledge from discussions with those who really know the hardware/software of such things on a detailed level as well as various articles online and the hard technical documentation. But my level of understanding is still limited to a fairly general sense and I'm only getting started in programming in general, not anything close to working on any of these consoles. And not just from being in active discussions either, but reading through past discussions, many of which I linked to on the first page of this thread.
Plus, not just Sega-16 either, a lot of this was tempered by other discussions on Atariage. (especially some details regarding certain cost and complexity trade-offs when engineering such hardware -especially in the context of discussing why the Jaguar was designed the way it was or why the Panther was impractical)

And one things that I should point out is the RAM prices here: http://phe.rockefeller.edu/LogletLab/DRAM/
http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm

And not that's for average worldwide mass market prices, so it would apply mainly to the cheaper/lower end DRAM of the respective times (as that would make up the vast majority sold). And also that the figures are in kBit or Mbit, not kByte/Mbyte, and 1 byte is 8 bits. (and all the prices are not per chip, but per 1 Mbit -128 kB- of RAM across the board)

1993: SegaCD. there are countries where the model1 didnt appear and they went right to the model2. the market was not ready for SegaCD in January 1992 in many places (outside japan). a 1993 model should have a more polished hardware (like the changes you sugested), more ram, faster scaling, faster CPU. and/or cheaper

If they released it as it was in Japan, it shouldn't have been any different for the US release though.
And as it was, without changing release dates or the Sega CD base hardware, there's a number of other things that could have been handled better: software support in some certain areas perhaps, but especially broader marketing that still pushed the popular multimedia angle but also promoted the broader spectrum of games and other advantages of the platform. Plus a low-cost duo console for the western markets by 1993: given the price of the Genesis and Model 2 CD in 1993 ($130+$230) an integrated cost-optimized CD unit sold at similar margins probably could have been $300, and possibly down to $200 by late 1994.

The Sega CD did have some unfortunate bottlenecks, but even so, it still wasn't pushed that much in several areas anyway, and the DMA issue was reasonably addressed by clipping the display a fair bit. (plus the limits of VRAM space made clipping more attractive anyway) No ports of Scaling Sega arcade games, no Sega produced direct competition to some of the mode 7 games on the SNES, and not even the common (if gimmicky/overused) scaling/rotation effects in common use as it had been on the SNES or in the Arcade in several cases as well. (albeit rotation was animated in the arcade, not in hardware)

The ASIC's rendering technique facilitated texture mapping as well, and a few games used some texture mapped polygons in places. (batman and robin, batman returns, F-1, Joe Montana NFL) It would have been really interesting if Stellar fire had been texture mapped.

It should be easier to program, with good dev tools

games like virtua racing or doom could be possible just with a bit improved segaCD

Yeah, but personally, I think Sega actually might have done better with a simpler Sega CD released earlier (ie late '89 or '90) to better establish them in the Japanese market. Plus it would have been a bit cheaper overall by the time the OTL CD was released. Many games and pretty much all FMV would likely not look much worse at all either, but no scaling stuff and with less onboard RAM, more limited animation and/or more frequent loads for certain games.
Plus release a lower-cost duo console, of course. (cheaper than the CD or Genesis costs added together)

But in that case, it really would make the 32x (or similar) much more attractive as well for 1992/93 in Japan (93/94 in the US). That, or skip straight to a whole new console altogether, possibly with backwards compatibility. (and a simple CD and no other add-on would greatly facilitate that at lower cost and greater flexibility) Of course, the 2nd add-on could have been so comprehensive that you might even just integrate it and the CD as a decent early 5th gen console for 1993. The option to upgrade or buy the full new system and have compatibility either way would be nice for sure, though a full standalone new system (be it all new or evolutions and enhancements of older hardware) could be far more flexible though... well unless Sega has given the Genesis the sort of expansion interfaces as Hudson had the PCE -which ironically were never really taken advantage of. (it was enough that the PCFX could have been an add-on )

I mentioned that a few times already, though mixed into some very long posts. (see the last group of paragraphs in post 47)

1995: Sega Jupiter. No 32X release. Jupiter should be based on a Dreamcast style hardware (with the hardware available on the time). A SH3 at 66MHz + 3D video could be great.

Maybe, though I think a lack of CD would be a big problem... A mid 1995 release in Japan could probably still be very competitive even with Sony's head start (especially if certain Saturn killer apps were launch titles -like VFII). And a strong mid 1996 launch in the US with a strong launch library and competitive price point really could have made it for them. (mid/late 1996 was the start of the deciding period in the western market, 1997 solidified that)

But even with the historical Saturn, things could have been done a lot better: the biggest problem for 1995 was undoubtedly the terribly botched May launch: they frustrated and confused retailers and 3rd parties who hadn't been aware in the shift in release dates, forced developers to rush software to completion, had a weak initial release lineup, and gave Sony the opening to steal their thunder with the $299 announcement. (it made a mess of the 32x as well) Had they stuck to September, they almost certianly could have outshined Sony that fall, or come very close: Sega had the name on the market, by September the Saturn had a hefty array of software (and several games would have been less rushed if not for the early launch), Sega matched Sony's price point by then as well, the 32x would have been on the market almost a full year by then, so less of a general shock, and 3rd parties and retailers wouldn't have been hurt by Sega leaving them out of the loop.

In the context of the 32x and Saturn launching in 1995 in general, I think "Jupiter" directly based on the Saturn as it was probably would have made much more sense in the long run than the 32x, but it may have had a slower start in late '94 due to the higher price point and lack of direct compatibility with the Genesis. (probably no less than $250, granted that was the Jaguar's price and less than the 32x+Genesis cost at the time -maybe closer to $300)
OTOH, witht he 32x as it was, the Neptune really should have paralleled it if they really intended it to be on the mass market, even in the short term. (and that probably could have been managed at $200 for the time -lower cost from integration/consolidation, etc -and also should have been possible to include virtua racing/PBC/etc compatibility for genesis compatibility mode)

2000: Sega Dreamcast: with DVD and improved PowerVR/3DFX. I could propose some other changes, like remove the modem, the control pads should be like the saturn ones but with two analogs + vibration (dual shock were introduced in 1997/1998), and no memory card slot on the control pads.

The Dreamcast itself was fine, but I'd be cautious about DVD as it would be a really hard push to manage that and a competitive price point with Sony (assuming they pushed the PS2 in the same manner as historically). Sony had the advantage of owning the patent/licensing rights to several parts of the DVD drive itself as well as the DVD video format (plus they were already marketing DVD video players, so the licensing overhead for the rest was already taken care of).

By 2001 probably, but honestly I don't think GD-ROM was that huge of a problem, especially if they could have bumped up the capacity a little later as happened with CDs (unless they were already pushing the wall for density -I'd think that 1.4-1.6 GB might be reasonable though).

However some things to address would definitely be the stock memory card size: should have been 512 kB minimum for sure... LCD screen was nice for in-game use, but the mini-game/battery functionality probably could have been cut) probably built-in rumble too. Having 6 face buttons really should have been kept and the d-pad could have been better. (dual analog would be important for FPSs, but that's definitely more of a hindsight thing... and with 6 face buttons, you could at least relegate 4 of those as a pseudo d-pad in leu of an 2nd stick and still have 2 buttons plus the triggers and d-pad for added options -like the N64, or like it should have done -I don't think many FPS actually offered C-buttons for aiming) Actually, as it was, you could probably rig up a FPS to use all 4 face buttons for aiming (as one of the control options) and use R to fire, L maybe for ducking/crouching, and the d-pad for weapon toggling and added options. (plus a pause menu)

But they definitely needed to scrutinize a bit more over security given the significant exploits leading to the piracy threat, though that was mainly an issue given all the other problems Sega already had. (Sega's shaky reputation from 1995-1998 in the west along with that piracy threat really hurt the DC, then the PS2 hype of course, and finally Sega pulling the plug rather than at least trying to ride it out in North America -the one market where the DC had seen significant popularity -it wouldn't have been until after the PS2 hype settled down as well as that from the GC and Xbox ~2002, that it would have been clear whether the DC could actually have continued to compete or even pull ahead of the GC/Xbox in North America -obviously Xbox in Japan, but not likely GC given the oddly weak popularity of the DC early on, not sure about Europe)



Sega's main problems weren't really hardware, though there were certianly areas where things could have gone better there. But even with releasing everything they did, even with the overemphasis on multimedia on the CD, or launch of the 32x in 1994, the big problems came from 1995-1998 in the west.
Again, you had the horrible mess of the May launch, then you had the marketing budget cut in mid 1996, just before the big Nights campaign was to launch in August, then you had Kalinske leave (as well as Rosen from the board of directors) and Stolar come in in 1997... and while I could see some reason in some things done in order to keep to a strict budget, other things didn't make sense, like pushing NetLink as much as he did rather than putting emphasis on bringing out as much of the better software as possible (and the lack of funding was also odd given the tons of money that was being poured into the Dreamcast or before that the hardware design of the Katana/black belt prototypes -granted that was tied to SoJ as well). But the "Saturn is Not Our Future" Statement at E3 1997 was the worst of all, and the one that's truly baffling.
They should have been trying as hard as possible to at least establish a dedicate niche for the Saturn and to sell off the stockpiled hardware at minimal loss while keeping the existing userbase satisfied and minimizing losses further with software sales.
Hell, they shouldn't even have started promoting DC in the west until mid 1998 at the earliest, they needed to fill the gap in the mean time. (ironic that the 32x was intended to fill such a gap years earlier when it wasn't needed anywhere near as much as something was needed after what happened with the Saturn in 1997 )

[sheath]

And one things that I should point out is the RAM prices here: http://phe.rockefeller.edu/LogletLab/DRAM/
http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm

Awesome! Look at page 13. The dollar price per mbit in 1990 was ~$10-$20. If I am reading this right, that means the 64kbit chips cost $10 to manufacture fairly solidly. Everything else plunged below $10/Mbit in 1990 including the 256KB variety.

That should mean that by 1991 the 6 mbit in the Sega CD cost $42-50 on its own. Add another $10 for the 64K PCM RAM, and whatever else for the 16KB CD Cache, 8KB Back-up RAM and 128KB ROM and you have close to a fourth or fifth of the Sega CD's system cost in RAM alone.

I'm not aware how the RAM totals are achieved, I'm just assuming that they'd buy the largest chip possible to save space and apparently money too. I'm also assuming it was all DRAM, or that other types of RAM were similar in cost.

-edit-

Also, the Y Board game G-LOC from 1990 features a flat background scrolled and tilted. It is very similar to standard Mode 7. The Genesis game simulates this with what looks like less than ten frames of repeated animation (see level 3 especially). After Burner III on Sega CD seems to stick to the flat color ground/sky with animated sprite zooming like After Burner on the Genesis/TG16 did. The cockpit to chase animation is much smoother on the Sega CD game, but the controls are more action oriented than G-LOC's are.

[kool kitty89]

Edit:

Awesome! Look at page 13. The dollar price per mbit in 1990 was ~$10-$20. If I am reading this right, that means the 64kbit chips cost $10 to manufacture fairly solidly. Everything else plunged below $10/Mbit in 1990 including the 256KB variety.

That should mean that by 1991 the 6 mbit in the Sega CD cost $42-50 on its own. Add another $10 for the 64K PCM RAM, and whatever else for the 16KB CD Cache, 8KB Back-up RAM and 128KB ROM and you have close to a fourth or fifth of the Sega CD's system cost in RAM alone.

I'm not aware how the RAM totals are achieved, I'm just assuming that they'd buy the largest chip possible to save space and apparently money too. I'm also assuming it was all DRAM, or that other types of RAM were similar in cost.

No consoles at that time would be using 64 kbit stuff, the NES used 1 Mbit of DRAM for main RAM, the CD used 2 1MB chips and 1 4 MB chip, the Genesis used PSRAM not DRAM but used 2 256 kBit chips and another 2 VRAM chips of that capacity plus a 64 kBit SRAM chip. (PCE also used a 64 kBit SRAM chip) I believe the PCE CD used 2 256 kBit DRAMs for program RAM and 2 more for ADPCM RAM. The SVP and 32x used the same 1 Mbit chips as the MCD though only 1 in the SVP cart. The Jaguar uses 4 4mbit chips similar to the MCD's but slightly faster (75 ns timing rather than 80 ns -13.3 MHz vs 12.5 MHz) The 3DO used 4x 4Mbit 8-bit DRAM chips for main RAM I think (80 ns like the MCD) but 1 MB of expensive VRAM for the video chipset, the 32x also used a 2Mbit SDRAM chip for main memory. (that size isn't one of the more common ones for RAM, it's normally multiples of 4, but you do get in-between values at times, the Genesis later used a 512 kBit PSRAM chip for instance, it depends on the case, and they're usually less common -somethimes demand is too low to even bother)

Edit: note I meant no 64 kBit DRAM stuff, not no 64 kBit chips at all. The 64 kBit SRAM chips were obviously used. (there's at least one of those in the CD too, for saves, maybe more depending if the CD-ROM cache was used SRAM or PSRAM -either way it's probably 64 kbit chips there too, not a single 128 kbit chip)

That later definition of ASIC is what I think of when I see it. I haven't seen the term Gate Array before. I decided to stick to Graphics Coprocessor, because that's what it is.

Chilly Willy used to always call it the "CD Gate Array" though he stopped that a while back I think. That term is about as ambiguous as ASIC though.

NEC definitely was the reason Sega had the Mega CD created, that same interview with Takami said just that. However, the focus on Turbo CD ended with making it load faster and less often. The focus on the extra hardware began and ended with Sega's arcade systems according to the interview. Again, the Sega CD's capabilities have more dissimilarities with Mode 7 than there are similarities. You are observing this yourself in your framerate observations.

Yes, the load times were shorted to some extent by the CD-ROM cache used (though they were also much longer due to the much larger amount of RAM used vs the tiny amount in the original CD-ROM^2), and the fewer number of loads than the CD/SuperCD/Duo was due to the larger amount of program RAM. (512 kB vs 64 or 256 -you could also cram additional data into word RAM, but the 512 kB block was the dedicated chunk for program memory from what I understand)

As for mode 7, yes and no. It's closer to mode 7 than it is to any Arcade scaling hardware, but it's also closer to texture mapping on other systems. (in the Jaguar, Texture mapping was actually intended primarily for rotated sprites and simple warped planes, not for full textured polygons -it was assumed in '89/90 when the Jaguar's core chipset was being laid down that smooth shading was much more important for polygonal 3D)
The framerate issue comes from having to render to VRAM as tile animation vs Mode 7 doing that internally and directly outputting to the screen, not animating to VRAM (mode 7 texture data is in VRAM, not tile animation to the normal BR layers). But yes, it's far more flexible than mode 7 and more like a primitive GPU with texture mapping support (more like the scaling and rotation effects available on the GBA I think).

So it's neither like mode 7 nor any arcade hardware of the time either. In some respects it's more like a primitive precursor to the Saturn's VDP1 as Chilly Willy described a while back. (the difference is it's slower and only rasterizes flat rectangualr objects that can be rotated, no warping like VDP1 -texture mapping polygons is handled line by line, so faster than software rendering alone but a lot more overhead than proper hardware texture mapping and rasterization of polygons, and of course VDP1 can render in highcolor and gouraud shade as well -and has the video output by VDP2 rather than the Genesis VDP, obviously -I can only imagine how limited VDP1 would have been trying to render to the Genesis VDP like the ASIC did )

I know the Z80 was extremely common, but it is no coincidence that Sega used it almost exclusively in the pre-Space Harrier arcade hardware released before and after the SMS.

Yeah, they started with the 8080, moved up to Z80 and stuck with it until 68k, it makes perfect sense. (focusing on one CPU architecture rather than jumping around) Some other Arcade companines stuck with the Z80 as well, others preferred the 6502 or 6800, some the 6809/6309 or a mix of the latter 3. (those architectures are related -the 6502 is sort of a cost-optimized evolution of the 6800 while the 6809/6309 was an advancement over the 6800, they're different in several areas, but it also makes sense to cross-develop for them to a degree)
Atari Inc's (and Atari Games') Arcade hardware was mainly 6502 based though, and when they shifted to 68000, the 6502 was often included as the sound CPU. (albeit that was necessary for using POKEY as well I believe, given how it was interfaced -both for some sound and for the timers often alongside a YM2151)

Sony also focused almost exclusively on making the PS2 jam as many polygons on screen as possible. This was obviously not Sega's focus, they instead focused on the texture mapping and GPU effects that enhanced the look of games.

That sounds just like the N64. Actually the PSX as well in some respects for the time, it had a huge emphasis on fast texture mapping as well as polygon pushing and highcolor gouraud shading, especially for 1994, but the N64 definitely pushed more for added effects and hardware support with the perspective correct rendering, bilinear filering, mipmapping, Z-buffering, etc over high polygon count -with the standard SGI microcode Nintendo pushed at least. (actually the Jaguar really pushed more for that as well, but again, in 1990 Flare thought smooth shading and Z-buffering were key features to focus on, goign so far as using a custom palette "CRY" colorspace for shading 256 intensity levels of a fixed 256 color palette output as 24-bit RGB -smoother than anything short of truecolor shading- rather than focusing on highcolor RGB rendering, polygon rasterization, or texture mapping -rasterization had to be done in software by the GPU while texture mapping was done in hardware but very slow compared to shading and Z-buffering -let alone texture mapping on the PSX or Saturn) Interestingly the Jaguar II being developed in 1995 (for a planned 1996 release) had many of the same design points of the N64, adding hardware triangle rasterization, a texture cache, bilinear texture filtering, fast texture mapping, z-buffering of course, and RGB shading support. (and generally much more capable system resources, caching for a general purpose custom CPU with good C support and a number of other changes, but that's another topic)

But generally yeah, the DC seemed to take the best points of the PSX and N64 and expand upon those. All the added effects in the N64 on top of pushing lots of polygons, focus on triangle based rendering, and critically: having a strong emphasis on clean hardware with excellent high-level tools going beyond that of the PSX. (and oddly Sony totally screwed up there with the PS2 for whatever reason)

Yes, that is true. 256 colors is better than 64, more is better. However, SNES games are still not displaying four times the colors, they are displaying two to three times the colors. When people look at a SNES game and say "Oh, more colors!" they're not envisioning the color palette, they're looking at the display. Then they turn around and look at the specs, typically caused by bad editorialist impressions, and say "Oh, SNES has 4x the colors, that's 'better'".

Oh, but it's way more than that, and it's not 256 cs 64, but 256 vs 15 or 16 colors for ASIC rendering on a BG layer.
It's all about the flexibility of the palette used and in this context, you genuine 8bpp tiles with any of the 256 colors able to be mapped to any tile, so you have full use of the palette vs only 15 or 16 colors with the ASIC, or for plain scaling on sprite tiles, you could use any of the 4 15 color palettes per tile, not just 1. (you could optimize on a tile by tile basis for the BG, but you'd get blocky artifacts with color clash like you see in a lot of FMV due to such color optimization -it looks a little like some compression artifacts- plus doing that would add a lot of overhead to rendering and generally not be practical at all) I believe BC Racers is using only 16 colors other than the sprite overlay on the status bar,

Though for in-game SNES stuff, it's all 15/16 colors per tile or sprite like the PCE or Genesis, same for mode 7 games outside of the mode 7 layer itself. All BG/tiles and sprites are up to 15 colors plus transparent (for the far BG, you get 16 colors with the solid window layer color shone through transparent pixels). The differences comes from 2 areas: 1 many more palettes: the SNES had 8 palettes dedicated to spites and 8 for BG, while the PCE has 16 and 16 vs the 4 shared palettes of the Genesis, so you can chose any one of those palettes to apply to any corresponding sprite or BG, and you often end up with far fewer colors than the max due to redundant/common palette entries, then you have the nice 15-bit RGB palette of the SNES vs the 9-bit RGB of the PCE/MD. That's also why the on-screen colors of the Neo Geo are still limited to the low hundreds in many cases in spite of there being 256 15 color palettes available.
With true 256 colors per tile, or for a bitmap display (like VGA or 32x and some Saturn games) it's FAR more flexible than the 15/16 color limit, and if you have multiple 256 color palettes (as with the Saturn) you have even greater possibilities for flexibility on a tile by tile basis (technically the PSX does that too by using 256 color indexed textures output to a highcolor display -I think VDP1 is limited to a fixed 256 color display in highres mode, VDP2 works on tiles though)
The SNES has a couple 256 color/tile modes (actually 241 colors per tile), namely mode 3 is the most useful there, but that wasn't used for any 2D games AFIK, just Doom, Dirt Trax, and Sturnt Racer (note the lack of dithering on flat shaded polygons compared to Star Fox and Vortex), and Wolf3D used mode 7 to render to rather than one of those. (in a 112x96 screen scaled 2x) I can only guess that the lack of mode 3 being used is due to ROM space limits and especially VRAM space, though maybe there's some late games I don't know about. (especially some of the SA-1 games or others using compression ASICs -VRAM would still be a big issue though) Technically, it's about the same as mode 2 with one of the 16-color layers replaced by a 256 color tile layer. (sprites and the 2nd BG are still 16 colors/tile though)

That's also the main difference in Master System vs NES graphics: the NES is limited to 3/4 colors per tile with 8 palettes available (3 colors plus transparent plus solid window layer color for a max of 25 colors on-screen, likely less due to redundant colors, and 3 colors per tile... actually normally you're limited to only one palette per 16x16 block of 8x8 background tiles, though some mappers allow palettes on an 8x8 tile basis) with the YCbCr palette which is actually very large id the added chroma/luma control is used allowing some 440+ unique colors/shades, though few used/needed that (the color/tile limit made it less useful in many cases) -the general palette is more useful than the SMS's 6-bit RGB as well, generally speaking. There's also the common mid-screen palette-swapping trick too, and the added shades/colors could have been more useful there too for water effects and such, but I don't know if many NES games did that for whatever reason. (it was very common on Atari 2600 and A8 games, particularly due to the larger palettes facilitating nice gradients)
The SMS has 15 colors per tile/sprite plus the common BG/window color: there's one single 15 color set available for sprites while that palettes and another can be used for the BG, so up to 15 colors for all sprites and 31 colors in the BG indexed from 6-bit RGB -expanded to 12-bit RGB on the GG though you probably didn't get the full advantages of that from LCD screens of the time -or the 15-bit RGB of the GBC for that matter, or the GBA even -outside of the DS/Micro/SP Plus/GB Player. (the master palette is probably more significant in the Genesis over the SMS colors in some respects than the added subpalettes, though both are important -technically speaking, the System E had as many colors on-screen as the Genesis, granted it had the same 6-bit RGB and sprite palette limits as the SMS)

Whereas I was shocked that a great looking game like Revenge of Shinobi was averaging less than 45 colors, or Super Castlevania IV only 96, I wouldn't even guess that in emulation. The color differences between these two systems is a huge exaggeration in actual software, especially on a regular television.

Yeah, but on-screen color isn't the issue, it's per tile color, the number of palettes, and the master palette used that really matter. You have WAY more compromises to make with the MD's limited set of 4 palettes, either using a lot of dithering or posterization, or limiting yourself to a very narrow set of colors with a lot of common enteries. (total likely 30 or fewer colors without shadow or HL) And palette swapping is also quite limited, but will inflate the on-screen colors substantially.
Colors on-screen is not the issue, it's how they're able to be used in the PCE and SNES over the MD, and in the SNES's case, the much broader array of colors that can be selected from.
Hell, you could have many cases where having only 32 colors like the Amiga, but used anywhere on-screen, would be better than the SNES or PCE's large number of palettes, let alone the halfbrite mode with 64 colors/shades. (and sme for a plain 256 color display vs 16 color tiles with huge number of subpalettes like the Neo Geo or even later 2D arcade boards -really late ones finally switched to 256 color palettes like the ST-V and I think the CPS-3)

Batman Returns is 20FPS, I would have thought it was 30FPS.

That one's probably being limited by the DMA bandwidth given the large screen size and lack of clipping, and from what I can see in fusion (using frame advance) it seems to be 15 FPS, not 20. (1 update per 4 frames, at least when there's the buildings on screen)

The developer said that they asked him to use the Battlecorp engine but cram as many scaling sprites into it as possible. So, assuming he meant "sprites" and not "objects using a BG" it is a fairly unique engine from what you are describing.

Battlecorps works the same way iirc. "sprites" is a common term generally misued, especially when dumbing things down to the general public, most "sprites" in amiga games aren't hardware sprites but blitter objects, and there are no sprites at all in Any ST, Apple II, ZX Spectrum, CPC (non plus), PC, etc, all software or hardware blitter objects.

Slipstream seems to look a lot like something the Sega CD could do. It's more of a texture mapped look. I always thought F1 Beyond the Limit was unnecessarily low framerate though.

AFIK the slipstream had no hardware texturemapping and I haven't seen anything on it that really looked like texture mapping honestly, other than the really low-res texture in the terrain demo that had, at least lookign at screenshots and the games seen here:
http://www.youtube.com/watch?v=nYpebHK4cEo
From what I understand the multisystem was composed of a general purpose blitter (more like the ST blitter in some respects than the amiga's, but far faster than either and with 256 color bitmap suppport and 16 color bitmap modes as well -faster for 256 colors, or at least working a byte at a time -so probably an unpacked 16-color 8bpp mode would work fast too), a general purpose custom RISC DSP intended for audio processing and for 3D or other graphics stuff as well (might help with texture mapping or ray casting too -it might even be directly related to the RISC/DSP core in the Super FX and was engineered by the same person: Ben Cheese and clocked at a similar speed -10.74 MHz for SFX1 vs 12 MHz in the Slipstream/Flare 1) as well as a fast ALU coprocessor and of course a general purpose CPU for game logic and such (originally a Z80, but Konix pushed for an 8088 -possibly in part simply for marketing to be able to call it "16-bit" like the SNES and avoid the stigma of the TG-16's 8-bit CPU). It was intended to have bus sharing like the amiga, with the custom chips popping inbetween the slow CPU accesses without slowing the CPU down, or halting the CPU entirely for full bandwidth use. (by the time it was nearing release though, that sort of bus sharing was getting less attractive, and something more like the Lynx did probably would be preferable -full serial buss access, no parallel sharing, but processors taking advantage of fast page-mode accessing to DRAM, thus being faster than random access interleaving a la Amiga, of course, any system using the 6502 or similar CPUs would be impractical for Amiga type sharing as the CPU has very fast and efficient bus accessing unlike the Z80, 68k, or x86 CPUs, so the 7800, A8, 5200, etc also had to do that in many cases -though you had a few cases where you had a slow 6502 and relatively fast RAM allowing interleaving -I think the Apple II did that, but that was long before fast page DRAM was cheap/common anyway)
It's rather ironic that the Flare team hadn't continued work with Sinclair staff after the merger with Amstrad, especially given Amstrad's foray into the console market with the rather weak GX-4000 a little later, or the CPC Plus for that matter. (the Flare 1 chipset, or former loki design would have been amazing if shifted for the CPC as such and/or in place of the GX-4000)
Also a bit odd that Atari didn't use that in place of the Panther prior to the Jaguar in 1990 given the Panther being abandoned, partnership with Flare, and the fact that Flare still owned the IP of all the Flare 1/Slipstream hardware. (Konix could only afford to sign-on for licensing with royalties, not by the chipset outright -hence the later use in some set-top boxes and such)
For that matter, it might have been useful in the ST line as well, especially as the TT or Falcon were still quite a bit away when Brennan started consulting over the Panther. (the STE had not yet even been released)
OTOH, the Lynx chipset might have had merit to be expanded as a full home console as well. (more RAM and TV output to allow higher res modes, probably a faster CPU and added sound hardware -not sure if the blitter was powerful enough to be reasonably be used for such a large screen though, or if it could have been useful for a 256 color display for that matter -if it was flexible enough, it could have been fine though, albeit higher res stuff was always going to be more intensive -regardless the Slipstream would undoubtedly be much more capable, even with am 8088, let alone if Atari upgraded to a 68k -depending if Flare had made provisions for such an architecture: going from Z80 to x86 wasn't that huge of a deal, both little endian instruction sets vs big endian of 68k -that's actually one big difference from the 6502 and 6800/6809/6309 as the former is little endian and the latter is big endian -the Jaguar specifically supported a wide range of architectures especially aiming at x86 and 68k and that ended up allowing the CoJag to use a MIPS R3000 rather easily)

I'm getting into too mugh detail off-topic again though.

It's either 20 or 30, but I'm fairly certain it slows down into the teens on turns. Mario Kart isn't a solid framerate, that much is certain.

Yeah, I'm not sure how that could be measured outsie of a very high speed capture device perhaps, or a good VHS deck with frame by frame advancing. (none of the SNES emulators seem to have frame advance either, and I'd only really trust ZSNES to have even a reasonable likely hood of properly simulating that -Fusion seems to as well most of the time, but VHS/SVHS on real hardware, or maybe a capture card that records 60 FPS for SDTV and doesn't force interlacing/deinterlacing might work -a good VCR would probably be best: count the number of frames it takes for the screen to consistently update under certain conditions and then use that number to divide 60 Hz: ie 4 frames=15 FPS 3 frames= 20 FPS etc)
Any mode 7 game using warping, not just flat scaling/rotation effects as with SMW or such, uses added CPU resource and/or an on-cart coprocessor to handle the additional perspective effect. (iirc an interrupt on every scanline of mode 7 video -it's somewhat similar to some scanline interrupt effects done for non-mode-7 stuff like Axelay or the cylindrical room in SCV4: linescroll is also done with a scanline interrupt)

I know that the TG16 treats 8 pixel wide sprites as 16 wide, so while it should be limited to 16 per scanline it seems to really be limited to 8. I didn't find that kind of limit with the Genesis.

I'm not sure what you're talking about there... there's normally 2 limitations for such consoles: 1 for the totally pixel count per line, and another for individual sprites used per line (plus a total number of sprites on-screen as well), and again, you can't exceed either of those, so if you use small sprites, you'd never hit the pixel limit before the sprite count limit.
I'm not sure on the PCE specifically, but tomaitheous would know for sure.

I know the SNES has a higher sprite number per scanline, though not really a higher pixel count per line iirc. (Tomaitheous explained all of this before but i forget now)

Sure, the cost would be the same as a port unless they add multimedia or special effect scenes. The 4-5x development cost isn't based solely on CD-Audio and voice actors being added, apparently they needed more people in the general development team too. One article compares the development team for Phantasy Star III and claims the average CD-ROM team needed to be double or more that size.

That's odd, you should only have a large team for added content, and even without added content you have the huge advantages of much cheaper media/production making distribution easier and profit margins much higher while prices being lower than carts. CD-Audio should cost no more (if not less) than a capable sound engineer and composer working with the onboard hwardware. Of course, if you add in additional cost for more extravagant tracks with vocals, real instrumentals/musicians/orchestras used, that's another matter, but using high-end MIDI/synthesizer/sampler equipment seems to be par for the course for most CD games of the time, and much of it sounded amazing. (there's a lot you can do with a broad array of synthesis hardware)
It almost certainly would have been a lot easier on a lot of STI/SoA teams/associates working with the synthesis/midi equipment of their choosing rather than having to translate that to GEMS. (the fact that it was mainly sound engineers/composers more atuned to MIDI is almost certainly the reason GEMS was used so often -SMPS and other engines are a lot more programming intensive)

Longer animated intros and such would likely matter, and high quality optimized compositions using hardware synth likely would have been more work, though others actually seem to have taken it easier when using the PCM chip too, just stickign with that alone, little or no FM, and just an 8-channel stereo MOD player basically, with samples fitting into the 64 kB block of wave RAM. (that's what it sounds like psygnosis did for NovaStorm and Microcosm, and I must say it's more pleasant than what Sewer Shark did with FM, albiet not on par with the amazing stuff done in games like Silpheed or even Sonic CD's past tracks in some cases -wing commander was all hardware synth as well save for the intro, same for many others like Popful Mail)

I rarely paid full price on games even back then. I think for the most part Sega CD games were set at or lower the cheapest Genesis carts though

OK so they did do that as it was. Again, that's where a LOT of common pors/multiplatform releases could come in for CD users (let alone combo/compilations). Even with no enhancements you had the edge with value, and any such cases of little to no-enhancement should have seen the biggest price difference from the Genesis versions. (and the most minimal enhancement would be things like CD-DA and re-done sound effects using the PCM chip)
Intentionally developing games in parallel for both platforms would likely be faster/easier than converting games to CD after the fact. (the main issue is segmenting the game into 512 kB loads and working with the different interface -through word RAM- -the easiest cases were games that were only 512 kB to begin with -and that's the cases where compilations would be more attractive too).

The only added cost/complexity of using the CD to do the same games as carts was loading into RAM efficiently: but even then it was a trade-off vs working within cost restrictions or ROM and optimizing to save space there. (of course, Sega's developers would have been more accustomed to doing the latter, but that's where pushing for an early transition would have come in handy) Of course, developing for computers using floppy disks was pretty much identical to that too, having to work within RAM limits and loading, though you also had the small capacities of floppy disks (or using HDDs on PCs -not on some others though) and such developers should have transitioned rather easily to CD-ROM as well, and indeed did so for PC games, and NOT just pushing multimedia stuff more than Floppies in some cases either, though generally taking advantage of that as well given how much they'd already been trying to push that with floppy stuff as it was. (Psygnosis, EA, Origin, Lucas Arts, Sierra, etc)

It would be really helpful if I could see a scan of something from back then showing that price.

The RAM price, sure:
http://phe.rockefeller.edu/LogletLab/DRAM/
http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm
Mass market prices of course, and averages, but that would apply most closely to the cheaper mass market DRAM (which is what was used), in fact it might have even been a little lower than that for Sega too depending on the deals they got, and much more so with NEC's vertical integration. (the prices in the mid/late 80s would also be much lower than that in Japan/Asia due to inflated prices in the US at the time -due to taxes on imports in attempt to stem the price dumping from overseas threatening to collapse the domestic DRAM market, though that didn't stop it)
That source was actually originally brought up on Atariage to correct some assumptions about RAM prices dropping in the early/mid 90s and others regarding RAM pricing. (someone mentioned Digikey prices that didn't correspond at all -too low and dropping way too fast, maybe they were reading Mbit as Mbyte by accident)

I think it would have been fine like that too. In fact, I really like the cart loaded processor and expandable RAM idea, though that's all bad for developer support unless it sells into the mass market.

Yeah if Sega had eaten the R&D costs for such and offered it to developers at cost, that could have helped too. Plus there's a lot of simpler and cheaper stuff possible than the SVP, like various audio expansions among other things. You could have 3rd parties doing their own enhancements too, which did happened in several cases with the SNES too. (again, probably audio expansions might be the most common)
Beyond PCM stuff, you could have other added sound chips on-cart too, and a second YM2612 in particular probably would have been attractive for Sega. (in terms of PCM though, you could have a simple DMA sound chip to something more advanced or an implementation of the Ricoh chip -in particular it would be very significant if they could have implemented an ASIC with the ricoh chip -or simpler custom chip- and an embedded ROM with default samples for music and sharing cart ROM for any additional samples -voices/sfx and such, that or maybe embedded RAM instead and make the samples fully programmable)

Some of that would at least need its own video output, I'm not sure that would be better than just releasing the 32X. That's actually why I like the 32X, because it killed so many birds with one stone. Something that only brought Genesis owners Mode 7-ish graphics and theoretical 256 color graphics just would not have mattered as much. US gamers were graphics whores but they knew nothing about optimal displays.

That's exactly what I'm suggesting, something like the 32x in some respects, but not quite the same. (a bit earlier, more optimized and not rushed like the 32x with a more comprehensive interface to the Genesis and more independent clock speeds like the Sega CD did, and more hardware support rather than just slapping a bunch of CPU grunt into it)
If the 32x had had a blitter built into the VDP like the Sega CD had or even something like the SVP rather than the 2nd SH2, it would have been cheaper and much more capable in several areas. (2D hardware support and texture mapping about as fast as the 32x could flat shade polygons)
Then things like more RAM, audio, etc. (i'm thinking and optimized system communicating through and rendering into word RAM like the Sega CD and at full speed, not clocked down to the genesis speed like the 32x framebuffers, cheap DRAM used for main memory, but 2 512 kB 16-bit DRAM chips instead of 1 in the CD for 1 MB on a 32-bit bus which would make it about as fast as the 16-bit SDRAM in the 32x, a VDP with some actual hardware acceleration, either like the ASIC and/or the DSP used in the SVP, preferably all embedded within the VDP to save cost and board space and then the added CPU, possibly an SH1 or fast 68k depending on the timing, though you could even leave that out entirely -especially if it wasn't going to end up becoming a mainstay 5th gen console, but definitely if it was to serve into 1996/97 on the mass market before a replacement came and an SH2 in that case morst likely as well -more variables than that too)

The main reason the 32x wasn't like that was almost certainly due to lack of time, and possibly lack of access to some SoJ hardware (SVP, CD Blitter, etc), and cost compromises to save on board space. (DRAM was cheap but the chips and added traces still take up space on the board -hence compromises like a single SH1 or SH2 to save on board space -the fast 68k in the case of a 1992 version, and no SVP then either) As it is, if the only compromise made to the 1994 32x was to drop the 2nd SH2 and integrate both the SSP-1601 DSP and especially a slightly modified version of the coprocessor in the Sega CD, that would have been huge (and especially bumping the framebuffers and SH2 up to full speed rather than sticking to genesis clock rates, or rather maybe not full 28.6 MHz for the Sh2, but focused around 25 MHz perhaps given that's what the SSP-1601 was rated at -plus theDRAM they were already using in the CD/32x was rated for 12.5 MHz and the ASIC in the CD ran at 12.5 MHz iirc), and that would make it cheaper to manufacture but require more R&D time. (and again, with the board space saved, it really made sense to switch to 1 MB of DRAM over the SDRAM... hell you could even argue that over dropping the slave SH2 alone)

And since the Sega CD was so simple in that case, there's no wasted redundant hardware like with the MCD+32x, and generally a much more attractive piece of hardware. But that's also true for the historical 32x: it would have looked much better alongside a bare bone CD unit and also been much more practical to integrate with the MD+CD in that respect too. (I could see it at perhaps $300 in late 1994, but with the 32x's RAM that would really limit things, hence the 1 MB DRAM 32x alternative would be considerably more practical)

That's why I like the idea of delaying the Saturn in the States so much. All 32X needed was better marketing really, and the Neptune by 1995. The case redesign was mostly being silly. Though I would like to see some concepts other than the original design.

The 32x was a very simple and very rushed piece of hardware though, had it had a lot more R&D time/resources, it could have been far more capable at similar cost.
That's a big reason why I wonder what SoJ's Mars design was like too, they had the potential to have had that as a long-term project vs the 4-5 months the 32x was designed in. (initiated during the winter CES in January of 1994 and presented at the Summer CES that June)

Ooh, I can hear the developers whining now "working with two different CPUs is soooOoOoo hard."

I wasn't suggesting dual CPUs, but the 68k OR ARM60 OR SH1. (actually in 1992, an 8 or 12 MHz ARM2 would likely be preferable to a 68k and cheaper than the low-cost ARM60 -Acorn/ARM LTD had released a low-cost CMOS version of the ARM2 in 1991 iirc) Or possibly an SH1 if the price could be managed favorable by late 1992 and it was available in quantity.
For 1993, the SH1 would definitely be a nice option, or maybe even the SH2 if available by then in quantity. (production started in late 1993 vs mid/late 1992 for the SH1 and 1994 for the SH3)

I could definitely see a scenario where Sega started emphasizing the Sega CD in 1993 and enhanced it with carts through 1998. Sega just needed to *not* release the upgrades too often and needed to handle the upgrades with adequate promotion/fan service. The "true" 32/64-bit consoles would have had an even harder time pulling the masses away from the Genesis-"Super" CD and SNES. Release the Dreamcast as normal ("normal" DVD was apparently impractical, see Xbox and GC besides) in 98-99 and I can definitely see Sega still being in hardware.

It all depends on the context, especially a 32x-like console that becomes the full nextgen platform in integrated CD+MD form (being replaced by '97).

As to enhanced carts, I wasn't mainly talking about CD games, but that could work too. (especially in the context of a simple CD and no other add-ons)

[Chilly Willy]

Chilly Willy used to always call it the "CD Gate Array" though he stopped that a while back I think. That term is about as ambiguous as ASIC though.

SEGA calls it the "CD Gate Array", or sometimes just "Gate Array". It's easy enough to just call it the ASIC as people will know what you mean. It's a fully custom chip designed by SEGA (not an off-the-shelf part of any sort).

ASIC stands Application Specific Integrated Circuit. It's just a big old mess of gates in an array (hence, gate array) that can be connected in a manner you choose to make the circuits you want. They're like roms - programmable once at the factory, then set for life. Back in the old days, that was all you had for large circuits. They are still around today, and are cheap in bulk quantities. If you want small quantities or something that can be changed later, you go with a Complex Programmable Logic Device (CPLD) for smaller circuits, or a Field Programmable Gate Array (FPGA) for larger circuits.

The Gate Array is not the display processor of the SCD... the display processor is a small part of the Gate Array. It also handles all the memory interface, MD interface, sound chip and ram interface, etc. The graphics functions are possibly the single largest part of it, so people just refer to it when they mean the part of the ASIC that actually performs the graphics functions because it doesn't take as long to type.

[kool kitty89]

SEGA calls it the "CD Gate Array", or sometimes just "Gate Array". It's easy enough to just call it the ASIC as people will know what you mean. It's a fully custom chip designed by SEGA (not an off-the-shelf part of any sort).

ASIC stands Application Specific Integrated Circuit. It's just a big old mess of gates in an array (hence, gate array) that can be connected in a manner you choose to make the circuits you want. They're like roms - programmable once at the factory, then set for life. Back in the old days, that was all you had for large circuits. They are still around today, and are cheap in bulk quantities. If you want small quantities or something that can be changed later, you go with a Complex Programmable Logic Device (CPLD) for smaller circuits, or a Field Programmable Gate Array (FPGA) for larger circuits.

The Gate Array is not the display processor of the SCD... the display processor is a small part of the Gate Array. It also handles all the memory interface, MD interface, sound chip and ram interface, etc. The graphics functions are possibly the single largest part of it, so people just refer to it when they mean the part of the ASIC that actually performs the graphics functions because it doesn't take as long to type.

Yes, I know what ASIC stands for, and ASIC and Gate Array are more or less equally ambiguous for describing a consolidated processor/logic chip, though in this case SOC might be more applicable. (and all systems on a chip could also be referred to as ASICs, but the former is a bit more descriptive)

ASIC would also fit as a description of the VDP in the Genesis would also fit, more so with the later revisions with further degrees of consolidation. (the VDP ASIC in the VA4 would really be a system on a chip too with the Z80, 68k, Z80 RAM, YM2612, I/O hardware, RAM controlling/refresh circuitry, PSG, and VDP integrated)

[gamegenie]

A. Sega Saturn released with full 32X support for it's cartridge port.

[Jorge Nuno]

A. Sega Saturn released with full 32X support for it's cartridge port.

In other words, a pumped-up Megadrive + CD + 32x...

Thats 2 x 68000 + 2 x SuperH2 + 1 z80, 2VDPs, a bunch of memory chips for each CPU/VDP, a mix of sound hardware, same architecture, and you still have to add more stuff. or else it would just be the regular MD32xCD system.

[Chilly Willy]

Yes, I know what ASIC stands for, and ASIC and Gate Array are more or less equally ambiguous for describing a consolidated processor/logic chip, though in this case SOC might be more applicable. (and all systems on a chip could also be referred to as ASICs, but the former is a bit more descriptive)

ASIC would also fit as a description of the VDP in the Genesis would also fit, more so with the later revisions with further degrees of consolidation. (the VDP ASIC in the VA4 would really be a system on a chip too with the Z80, 68k, Z80 RAM, YM2612, I/O hardware, RAM controlling/refresh circuitry, PSG, and VDP integrated)

Yes, the last few ASICs from SEGA would be considered SoCs... generally called GoaC by many (Genesis on a Chip). Earlier ones probably wouldn't as they lacked the 68000. For example, the CDX is two big ASICs and two 68000s, plus a few minor chips and the ram. One of the ASICs could be argued as being a SoC as it has the Z80 in it, but the other can't as it has no processor in it at all. As the Z80 isn't the main processor, I wouldn't consider either a SoC, just plain ASICs.