It had 8 times the RAM of the Genesis, a faster 68k CPU, and then there's the storage capacity which compared to carts at the time it was mind-blowing, yet FMVs were bad (though some 3rd parties in Japan were able to improve it) and games like Silpheed which originally ran on 8bit Zilog computers with real-time 3D graphics had a prerendered background on the SCD. Could Doom have been ported to the SCD? color problems aside, did it have the power to run games like that?
The Sega CD assists the main CPU as a coprocessor, it doesn't upgrade it. The fast 68K only has 256 KiB of memory to work with itself, and that's to hold the program it's running and the data it's crunching. The 512 KiB goes to the main CPU, and while yeah this is a big RAM upgrade, RAM isn't really a bottleneck in cartridge games. 512 KiB was basically the minimum required to hold an immersive level of game assets, and allow easy porting of early 4M titles. The Sega CD also has some kind of graphics acceleration for tile packing, similar to the Super FX chip, but it doesn't seem to be programmable or mapped to the fast 68K so it's not as versatile. Since the Super FX is a fast RISC, I'm pretty sure it can do more work than the Sega CD, and the SA1 is probably about on par. Is the Sega CD powerful? Yes. Was it utilized well? Not really. Was it ahead of its competition? For a couple years. Probably the most noticeable upgrade was its sound.
Actually, it was a single bank of 512KB fast page DRAM, you could use either with the main CPU at the Mega Drive (You would have to give up on the CD drive if you did so as the registers are only accessible for the SUB CPU) or let the SUB CPU run and keep using the 64KB of RAM the MD has inside. There were also a pair of 64KBx16 bit dual port DRAM chips which were "flippable" by a toggle bit and were meant to be used to exchange data from one CPU to the other without the MD CPU having to stop the main CPU. Sadly for the designers of games using it, you can't divide the 512KB RAM in two without stopping the SUB CPU... Also, there were a pair of 16 bit port register for the two CPUs messaging/signaling/semaphores. Silpheed used DMA extensively with the 2 dual port DRAM chips to transfer the background animations for the MD VDP. Because it had a lot of " 'but's " and "pehaps" it was a very complex system to code for, the BIOS helps you with almost nothing but just redirect low level calls on the CD data decoder or blink leds, open the tray, the game code has to do everything, even handle the ISO9660 filesystem, making programming for it a nightmare (or dream if you are a down to metal, challenge loving type of guy) ...
Sometimes I wonder who the fuck did Sega hired to engineer its hardware, is like they kept making shit as convoluted as possible so programmers would kill themselves Anyways since we're on it, how did the 68000 on the SCD compared to the Samsung/SVP chip on VirtuaRacing?
or you could do what SEGA did with sonic CD and told game developers during the megaCD prototype stage was code for the megadrive but assume unlimited storage also the buts and perhaps and maybes is why the megaCD wasn't standalone and also the Saturn's complexity is also why megaCD was never stand alone it was always meant to be a compliment much like the neoCD
I don't think so. It depends of games developers. For example, Game Arts' games like Lunar 2, Urusei, Popful Mail takes good advantage of SCD hardware. It's good technical demo for tiles based cut-scenes with very good sampled audio synchro (not cheap like CDA tracks...) and mixed FM+PCM for BGM. Dune is also a good example of technicaly well-balanced game and Sonic CD for his full PCM sequenced audio tracks (past BGM). However, the best remains the 32x CD games who use 256 colors at decent frame rate for only x1 CD. Fahrenheit is the perfect example. I think the SCD lacks support from games devellopers. But at time, it was a powerfull machine with lazy developer who don't want / can't works on metal. :wink-new:
That's why I love the MEGA-CD. It's a nice and beautiful design that is pretty badly misunderstood. It was made the way it is to be a good match to whatever was already on the MEGA DRIVE.
not sure if anyone has mentioned these titles yet but I loved the Mega CD and still buy games for it today, I recently got Soul Star and Battlecorps to name a few, both of which offer excellent scrolling sprite graphics and nice textures, I know the FMV's were dire but the Mega CD was not worlds away from the performance of the Jaguar for me, though I never saw exactly what it could handle with Polygons. Does anyone know any good Polygon games on the Mega CD? I have games like Wolfchild, Jaguar XJ220, Thunderhawk and a few others etc but can't remember if any had true Polygonal graphics
yeah I've got both of those games and I agree the scaling in those is pretty awesome, though I'm surprised to hear that the Mega CD didn't have Polygon technology... the 32x did right? I mean Metal Head and Star Wars are both Polygonal games right? so I'm just surprised that the CD didn't, I think even the Mega Drive could do some Polygons, though very few, correct me if I'm wrong lol, I'm sure I saw some polygons in a mega drive game, hell, even Phantasy Star for Master System used polygons didn't it? or am I just completely barking up the wrong tree here? lol probably am
Despite every single "official" ad saying the 32X has hardware graphics acceleration, it doesn't. It's a plain frame buffer that uses software routines by the SH2 or 68000 to draw everything. Ditto for the sound - there's no hardware QSound support as implied... it's a plain PWM stereo out that requires the SH2 (or 68000) to handle all in software. In some ways, that's better - you're only limited by how good your code is, and having the second SH2 means that one chip can handle things like the audio while the other handles the game code. Back on topic - while the SCD doesn't have hardware that handles polygons explicitly, someone pointed out a demo where scaling/rotating quads (which IS what the SCD ASIC can do) was used to handle polygons. I mean to try porting that demo to the SCD when I get a chance.
sounds awesome, and pretty interesting, though a lot of the technical stuff there was slightly lost on me but I understand the gyst (though I have no idea what PWM, SH2, 68000 or SCD ASIC is/are lol) but yeah I guess I'm just baffled that the SCD didn't actually produce polygons, I guess looking back the 20 plus games are a good give away, I guess I just always thought they had intended to make polygonal games for it but it failed before they could try
How the ASIC works (for scaling and rotation) is that you specify a starting point in the destination bitmap, the width in pixels, and the height in lines. Then for each line, the ASIC fetches data from the "trace table." Said info consists of a starting point in the texture (called the stamp map), and an X and Y step. For each pixel in the output line, it fetches from the stamp map, then adds the delta X and delta Y to the fetch address. The deltas are a fixed point number, so fractional steps can be done. Use a step smaller than 1 to magnify the image, or greater than 1 to shrink the image. Use the proper starting point and delta X/Y to rotate. Using a fixed delta to advance along a line for output is known as affine mapping. So the ASIC is technically capable of affine mapping of a quad if you setup the output and trace table correctly. By the time anyone was really ready to try doing that on the SCD, Sega had already sent out word to kill all development except on the Saturn. So all we have is mainly plain scaling and rotation of sprites.
