• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Why did Mega Drive/Genesis games not have special chips in them? Á la Snes

tayls129

Member
Red Zone on the Genesis didn't need any special chips and pulled out some amazing effects. I think it was a case similar to the PS3: The power was there, it just took very specialized development techniques to use it.
 

MTC100

Banned
What I don't understand with the MD's Motorola though, quoted from Wikipedia:

I've seen people custom clocking the thing up to 12,5 MHz and receiving better performance in MD games. Couldn't Sega just have done the same? Or did you have to pay per MHz back in the day? I'm sure Motorola sold faster 68000 CPU's prior to the MD too.

Not every CPU overclocks the same way, not every CPU is of the same grade/quality, you can have one CPU that overclocks to 12,5MHz and the other will fail to reach 10MHz, Sega did, what everyone does and used a safe frequency to ensure that the system will run stable -for everyone.
 

Sapiens

Member
It did not sadly, there's a reason why Shmups like Super R-Type had major slowdowns when there were too many enemies on the screen at once and the Megadrive could handle such situations with ease.

The SNES had the far superior sound processor though, designed by Sony by the way :)

-That said, I am not quite sure if there are examples of the megadrive pushing 3D Polygons like seen in Stunt Race FX that was possible on the SNES only with the extra Chip on the cart.

SFC sound chip is nice and all, but end of the day, I'm firmly in the camp of these two methods being too different to compare. The both made some cool music, but most of it sucked. You had to be higher on the bell curve to get results out of the MD though. They both have their pros and cons and both of them seemed to have more cons. They were heavily compromised system compared to what the Neo Geo was capable of, sound wise. Before the shift to all-redbook or streamed era completed in the PS2/DC/XBOX era, I really thought the Saturn had the most interesting chip music (too bad the sampled voices seemed to be inferior to the PSX). Radiant Silvergun (I THINK....) is all chip and sounds amazing.

The thing with these 3D polygon claims on the MD is that a lot of the demos you are seeing use pre-calculated math - and while you are seeing polygons being converted to tiles and shifting in realtime, it is highly scripted and it would be harder/impossible to create a open world, free roaming example close to what is shown in the elite demo - in real time that is.

The 3D polygon flight games you saw on the MD earlier in the lifespan from EA were about as good as you were going to get in flat shaded polygons in real gameplay*.

*without a chip, of course.
 

ElFly

Member
Are you ready to have your pants shat? You only ever saw sprites being shrunk in those fighting games. Things only truly zoomed out. Even when things appeared to zoom in, they only started from a smaller size and then were zoomed to their original size.

A good example of this is in Metal Slug when the soldiers are being blown towards the screen or in Mutation Nation when that one boss zooms in from the alley.

Also, not knowing too much about the Neo Geo video hardware, it is my assumption that when you see those zooming fighting games, anything that is being transformed, even the backgrounds, are actually sprite tiles. Can someone correct me if I am wrong?

as far as I understand, everything in the Neo Geo is a sprite. there ain't background layers like in the SNES o Genesis, which are big static images the console would just paste onto the screen for backgrounds. big backgrounds were done by queueing sprites one after the other, just like the big characters were also collections of smaller sprites

the zoom on the Neo Geo started from big images and took out lines from the sprite at each zoom level. there was a chip which knew which lines to take out of the sprite for each "zoom level", so it would be less "zoom" and more "shrinking" or "shaving". this special chip had all those rules hardcoded; given each character and background was composed of a lot of equally sized sprites, when zooming in and out it only had to deal with zooming a piece of data of a regular size, not arbitrary sizes

obviously this approach does not apply to rotation; afaik if something rotates in a Neo Geo game it is precalculated
 

Sapiens

Member
as far as I understand, everything in the Neo Geo is a sprite. there ain't background layers like in the SNES o Genesis, which are big static images the console would just paste onto the screen for backgrounds. big backgrounds were done by queueing sprites one into another

the zoom on the Neo Geo started from big images and took out lines from the sprite at each zoom level. there was a chip which knew which lines to take out of the sprite for each "zoom level", so it would be less "zoom" and more "shrinking" or "shaving". this special chip had all those rules hardcoded; given each character and background was composed of a lot of equally sized sprites, when zooming in and out it only had to deal with zooming a piece of data of a regular size, not arbitrary sizes

obviously this approach does not apply to rotation; afaik if something rotates in a Neo Geo game it is precalculated

Amazing.
 

s_mirage

Member
The sega cd's background and sprite scaling were not mode 7. Also, the system, unlike the snes, could do sprite scaling, but the background scaling and rotation was always inferior to what the snes could do. It ran at a lower frame rate.

Wasn't that actually due to a bottleneck between the Mega/Sega CD and the MD/Genesis's VRAM, while the system itself was more capable than it was able to display? The scaled output had to be converted into tiles, transferred to the Genesis's VRAM, and then displayed by the VDP since there was no line between the Sega CD and the DAC. A side effect of the expansion port being designed more for things like floppy drives and modems rather than a full system expansion.
 

Sapiens

Member
Wasn't that actually due to a bottleneck between the Mega/Sega CD and the MD/Genesis's VRAM, while the system itself was more capable than it was able to display? The scaled output had to be converted into tiles, transferred to the Genesis's VRAM, and then displayed by the VDP since there was no line between the Sega CD and the DAC. A side effect of the expansion port being designed more for things like floppy drives and modems rather than a full system expansion.

I think I remember reading something like that before. So, you're always bottlenecked by what the MD could do, video and ram-wise, at gameplay? And the lower frame rates on special effects were due to a delay for tile-transfer? So, was the SegaCD CPU mostly there to pre-crunch tiles for developers that wanted to use the ASIC chip - otherwise, it just sat there or was used to manage the CD drive?

What a weird system.
 
as far as I understand, everything in the Neo Geo is a sprite. there ain't background layers like in the SNES o Genesis, which are big static images the console would just paste onto the screen for backgrounds. big backgrounds were done by queueing sprites one after the other, just like the big characters were also collections of smaller sprites

the zoom on the Neo Geo started from big images and took out lines from the sprite at each zoom level. there was a chip which knew which lines to take out of the sprite for each "zoom level", so it would be less "zoom" and more "shrinking" or "shaving". this special chip had all those rules hardcoded; given each character and background was composed of a lot of equally sized sprites, when zooming in and out it only had to deal with zooming a piece of data of a regular size, not arbitrary sizes

obviously this approach does not apply to rotation; afaik if something rotates in a Neo Geo game it is precalculated
Incredible. I love learning new stuff about old consoles!
 

Sapiens

Member
Seriously?

https://www.youtube.com/watch?v=cbreFmRDN3E

you can still listen to that stuff in the year 2017. -And it's really hard to find pleasing music out of the Megadrive games.

It would be hard to change my opinion that the SFC and MD sound solutions are very different and both had compromises. Why do people always reference DKC2 when Zelda LTTP's soundtrack exists and is far superior?

Besides, there is a different war-thread for comparing the audio of these systems.
 

MTC100

Banned
Why do people always reference DKC2 when Zelda LTTP's soundtrack exists and is far superior?

Don't know it just came to mind as I've played it a lot back in the day and David Wise did a stellar job on it. No doubt Koji Kondo is even better, that guy worked wonders even with the limitations of the NES.
 

Sapiens

Member
I would say Kawasaki Superbike Challenge is leaps and bounds ahead of any of them when it comes to performance

https://www.youtube.com/watch?v=o9v-9lGNJQ4

Oh yeah, that game is pretty insane - not very fun though and it had a linear racing track movement - the flight games are more 3D and free moving and I feel are a better example of limitations. It's also a good case study for demonstrating the differences between the SNES and MD CPU. Although, I kind of bet it might have been more due to Domark being more skilled with the MD more than anything.

One more note about the shitty sound on both of these systems: I think that Gauntlet IV MD soundtrack blows away almost everything else I've heard in the 16-bit era. I just think the NeoGeo has spoiled me in terms of mixing synthesized and sampled sounds. The Neo Geo sound is just so amazing for a 16-bit.

Also, the Sf2CE voice hack (which runs on real MD hardware), closes the door on the MD being inferior in regards to voice samples. It just took an extra 20 years of hacking to get it sound right, lol...
https://www.youtube.com/watch?v=-iE5GJNkOqs
 

s_mirage

Member
I think I remember reading something like that before. So, you're always bottlenecked by what the MD could do, video and ram-wise, at gameplay? And the lower frame rates on special effects were due to a delay for tile-transfer? So, was the SegaCD CPU mostly there to pre-crunch tiles for developers that wanted to use the ASIC chip - otherwise, it just sat there or was used to manage the CD drive?

What a weird system.

I'm not really knowledgable at all about this but my understanding is that the CD's cpu could be used to run programs, prepare graphics, run the drive, etc, but it only had access to the Sega CD's RAM and chipset. It couldn't control or access anything on the Genesis side. The Genesis's CPU had to handle copying data out of the Sega CD's RAM to it's own RAM before that data could be used for output by the VDP or YM2612, and IIRC the Sega CD's CPU had to be halted while this happened.

Yeah, I really don't think the Megadrive/Genesis was designed with major expansions in mind.
 

Sapiens

Member
I'm not really knowledgable at all about this but my understanding is that the CD's cpu could be used to run programs, prepare graphics, run the drive, etc, but it only had access to the Sega CD's RAM and chipset. It couldn't control or access anything on the Genesis side. The Genesis's CPU had to handle copying data out of the Sega CD's RAM to it's own RAM before that data could be used for output by the VDP or YM2612, and IIRC the Sega CD's CPU had to be halted while this happened.

Yeah, I really don't think the Megadrive/Genesis was designed with major expansions in mind.

So, wow, if you think about it, to get sprites to scale on the SEGA CD was likely a herculean task of timing between the two systems. Probably explains why only like two or three programmers ever bothered with it.
 

lazygecko

Member
I'm not really knowledgable at all about this but my understanding is that the CD's cpu could be used to run programs, prepare graphics, run the drive, etc, but it only had access to the Sega CD's RAM and chipset. It couldn't control or access anything on the Genesis side. The Genesis's CPU had to handle copying data out of the Sega CD's RAM to it's own RAM before that data could be used for output by the VDP or YM2612, and IIRC the Sega CD's CPU had to be halted while this happened.

Yeah, I really don't think the Megadrive/Genesis was designed with major expansions in mind.

I had one of those multi game bundles of Genesis titles for Sega CD, and I remember Golden Axe strangely only supporting single player. Later I read that this was due to some bottlenecks in how the addon interacted with the vanilla hardware.

Then there's the whole way the 32X works. It almost feels like it's 2 different systems operating in parallel with eachother, since interestingly due to the separate video outputs you could see what the Genesis and 32X were displaying individually if you don't connect one of them. I would love it if someone knowledgeable made YouTube videos explaining all of this stuff in layman terms.

So, wow, if you think about it, to get sprites to scale on the SEGA CD was likely a herculean task of timing between the two systems. Probably explains why only like two or three programmers ever bothered with it.

Is this possibly why the collision detection is so godawful in the Sonic CD special stages?
 

Sapiens

Member
I had one of those multi game bundles of Genesis titles for Sega CD, and I remember Golden Axe strangely only supporting single player. Later I read that this was due to some bottlenecks in how the addon interacted with the vanilla hardware.

Then there's the whole way the 32X works. It almost feels like it's 2 different systems operating in parallel with eachother, since interestingly due to the separate video outputs you could see what the Genesis and 32X were displaying individually if you don't connect one of them. I would love it if someone knowledgeable made YouTube videos explaining all of this stuff in layman terms.



Is this possibly why the collision detection is so godawful in the Sonic CD special stages?

Maybe? I think all the sprite objects were handled by the MD while the only thing the CD was processing was the choppy background later.

Due to the fact that the sprites didn't scale and were merely swapping out different sized sprites, it was all on the MD and it probably had a lot more to do with sub-par programming and whatever technique they used to gauge depth and how much "forgiveness" they would allow on collision (which was probably very very low). Although, I imagine tight deadlines were the ultimate culprit. I really don't like Sonic CD - it just feels like a shitty Sonic 1 hack.
 

dogen

Member
Man the Genesis was just a beast with parallax stuff wasn't it? Saw someone play Sonic 2 yesterday and I never really took a moment to notice all the layers in the first level until now, it's kinda insane. Lovely piece of hardware it was.

I believe the SNES had features to make this easy too.

Oh? someone building something in Homebrew? Neat, but still would rather have someone making a nice mapperIC for homebrew with a small framebuffer. One that can rotate and scale sprites ;). Imagine an Afterburner clone with fully scalable sprites ;).

Yeah, paprium will be using a 24 channel PCM sound expansion chip.

Red Zone on the Genesis didn't need any special chips and pulled out some amazing effects. I think it was a case similar to the PS3: The power was there, it just took very specialized development techniques to use it.

I think the 68k was considered a more straightforward and easy to develop for CPU back then. Zyrinx did impressive work partially because they were used to writing demos that attempted pushed the amiga (which also had a 68k at ~7MHz) to it's limits. But other, non demoscene developers did great jobs on the genesis. Contra Hard Corps, Gunstar Heroes, Vectorman, Batman and Robin, Panorama Cotton, etc... In fact, I remember an interview with treasure talking about gunstar heroes being easy to develop on the genesis because that's what the hardware was made for.


Cool stuff. I mean you need to just compare Contra Hard Corps to Contra III and it highlights your point perfectly.

We did get Panorama Cotton on the MD which looked great and all, but it still paled in comparison to the SNES Mode7 graphics. Still though it's amazing seeing some of the stuff here that was done on software so maybe we could've had games like Mario Kart on the system.

That's sorta been done.

https://www.youtube.com/watch?v=SwW5y4rrvwk

It's lower resolution, but it's been a while. Wouldn't be surprised if he could push it a little more like he did with wolfenstein.
 

Coppanuva

Member
Seriously?

https://www.youtube.com/watch?v=cbreFmRDN3E

you can still listen to that stuff in the year 2017. -And it's really hard to find pleasing music out of the Megadrive games.

Bullshit it's hard. The genesis has a ton of games with amazing soundtracks, the fact you had to use what's probably the most-lauded soundtrack on the system to prove your point doesn't help.

Let's go, GENESIS TIME!

McDonald's Treasure Land Adventure: Some happy nice platforming tunes, perfect for the uplifting fun spirit of the game and a soundtrack I listen to daily (no joke). https://www.youtube.com/watch?v=F86pG7U6R-s

Mega Bomberman: Maybe not as nice as the TG16 version, but this soundtrack is still super listenable. https://www.youtube.com/watch?v=Hp5AWssF8Es

Rocket Knight Adventures: Nice use of bass to show urgency and really hits home far better than most SNES games. https://www.youtube.com/watch?v=244ZH1DNHlI

Michael Jackson's Moonwalker: Legit 16-bit versions of MJ tunes. The Genesis' ability to use bass is proven here. https://www.youtube.com/watch?v=hMioj8ldP8Q

Also just because you used DKC... Sonic games. https://www.youtube.com/watch?v=bHdhj7psoV0
 

Sapiens

Member
Never understood the love for the MJ songs in FM synth. They sound horrible to my ears and I cringe when they are brought up as good example of MD sound.
 
Red Zone on the Genesis didn't need any special chips and pulled out some amazing effects. I think it was a case similar to the PS3: The power was there, it just took very specialized development techniques to use it.
Not at all. The 68000 was a off the shelf CPU used in many other computer devices. PS3's Cell was only used for that console and required a lot more development to utilise in a good way.

When you think of it the SNES seems more complicated to develop for, but I guess developers put more work into the SNES version as it was the better selling console.

Oh and yes, Red Zone is an incredible game on the MD on a technical level!
 

cireza

Member
Cool stuff. I mean you need to just compare Contra Hard Corps to Contra III and it highlights your point perfectly.
Comparing games like these do show the differences well. If we talk about Konami games, you can compare Castlevania IV to Bloodlines and it points out very well the differences in hardware.

Castlevania IV has great pixel-art and colors. Nice gradients. On the music side, you get some very moody themes that create the atmosphere well. That's especially impressive when you see that it was a pretty early game, and you can't achieve the exact same thing on Genesis of course. However, the game is also pretty limited by the CPU, and some pretty "simple" stuff can cause unbelievable slowdowns. Like the guys that split in two, then in four, in the cave.

On the Genesis side, you get Bloodlines. Game uses the larger resolution (320 * 224 instead of 256 * 224). That's actually quite a lot more pixels displayed. So you have a wider point of view on the screen. Characters move a lot faster too. Also, the game is filled with "special effects" created with the console. Developers can't rely on the "SNES Modes chip" here, so they need to implement themselves, software wise, whatever effect they want. But the good point of this is that you are not limited by what a specific chip is meant to do. That's why you have all kinds of very different special effects in Bloodlines.

Because the CPU of the SNES is a bit weak, you really can't rely heavily on it, and you are sort of forced into using the "SNES Modes chip", this is why in the end, most of the special effects you see on SNES look a bit alike. You could still do some pretty great stuff (Terranigma first overworld for example, flames in Dracula X etc...), but most of the time, it feels like "Mode 7". I personally don't like the Mode effects much because I felt that it was simply everywhere (except when they actually had good ideas, like the one I have said). While a game like Gunstar Heroes throws at you a great variety of different effects.
 

lazygecko

Member
https://www.youtube.com/watch?v=SwW5y4rrvwk

It's lower resolution, but it's been a while. Wouldn't be surprised if he could push it a little more like he did with wolfenstein.

IIRC the main issue with this is that multiple track levels would consume an unreasonable amount of space, since the tracks are made out of a single giant bitmap image rather than tiles. You can conserve space by sacrificing image resolution, but as you can see in that video it's already pushing it with a rather low pixelated resolution.

Mimicing Mode7 in software on Genesis is ironically much harder to do compared to more advanced 3D tricks.

Speaking of Wolfenstein 3D, it was recently updated with even more optimizations resulting in both a bump in resolution and framerate.

http://www.mediafire.com/file/7qc5tq8z80phhfv/wolf3d_256x144_test_demo_ver.rar

ftgilsaavjwxox2zg.jpg
61mgi5152empd3yzg.jpg
 
I believe that the chip allowed for wider mode 7 areas (bigger circuits), as well as displayed some 2D elements on the circuit (pipes etc...).

Street Racer, which does not use a chip, as much smaller circuits, and nothing is displayed in 2D except for the racers themselves.

Ah, I forgot about Street Racer. The SNES did have to render two mode 7 playing fields for Super Mario Kart at all times, so I could see Nintendo using an additional chip just to extend the size of both playing fields.


I think it had more do do with the math being processed at 16-bit and the addressing being 32bit. I didn't do very well in my architecture class, so I can't go into it, but it was a hybrid of some sort?

You'd think the marketing people would be all over calling it 32bit...

I think marketing a Motorola 16bit CPU as a 32bit chip would have been a bit dumb. Especially given how common that CPU was back in the day, it was in everything from the Commodore Amiga, Atari ST, Apple Macintosh, to just about every 16bit arcade machine.

The SNES has a 16bit variation of the Ricoh CPU that is found in the original NES, it is a 16Bit CPU with a 24bit bus. They never marketed the CPU as 24bit.

SNK tried marketing their Neo-Geo AES as a 24bit machine just because it has a 16bit M68000 @12Mhz and an 8bit Z-80 CPU co-processor @ 4Mhz. The machine had higher clocked versions of the M68000 and Z-80 chips found in the Genesis.

Mode 7 for background manupulation is jargon in the same way blast processing is for a faster than competition processor.

The sega cd's background and sprite scaling were not mode 7. Also, the system, unlike the snes, could do sprite scaling, but the background scaling and rotation was always inferior to what the snes could do. It ran at a lower frame rate.

Mode 7 is a feature that is built into the video display processor. The reason why it is called "mode 7" is because it is graphics mode 7. The SNES has a bunch of different graphics modes that could be mixed together, mode 4 is something like 256 bitmap colour mode, mode 5 allows for the screen to be displayed in the SNES's high resolution mode, but can only display about 16 colours, I forget what the rest do. But really, that is where the name came from.

The Sega CD could display multiple large flat 3D playing fields at once, but it also has sprite scaling capabilities built into the hardware, unlike the SNES which could not so sprite scaling at all unless it was written through software.
 

Sapiens

Member
That special chip was called 32x which was technically superior to snes but everyone laughed at it.

so......
yeah.

That was two gimped hitachi CPUs similar to the mess that was in the Saturn and a video chip that was capable of displaying more than 6 colours.

The 32x was sega of Japan operating at their most supreme levels of dickhead.
 

Sapiens

Member
Ah, I forgot about Street Racer. The SNES did have to render two mode 7 playing fields for Super Mario Kart at all times, so I could see Nintendo using an additional chip just to extend the size of both playing fields.




I think marketing a Motorola 16bit CPU as a 32bit chip would have been a bit dumb. Especially given how common that CPU was back in the day, it was in everything from the Commodore Amiga, Atari ST, Apple Macintosh, to just about every 16bit arcade machine.

The SNES has a 16bit variation of the Ricoh CPU that is found in the original NES, it is a 16Bit CPU with a 24bit bus. They never marketed the CPU as 24bit.

SNK tried marketing their Neo-Geo AES as a 24bit machine just because it has a 16bit M68000 @12Mhz and an 8bit Z-80 CPU co-processor @ 4Mhz. The machine had higher clocked versions of the M68000 and Z-80 chips found in the Genesis.



Mode 7 is a feature that is built into the video display processor. The reason why it is called "mode 7" is because it is graphics mode 7. The SNES has a bunch of different graphics modes that could be mixed together, mode 4 is something like 256 bitmap colour mode, mode 5 allows for the screen to be displayed in the SNES's high resolution mode, but can only display about 16 colours, I forget what the rest do. But really, that is where the name came from.

The Sega CD could display multiple large flat 3D playing fields at once, but it also has sprite scaling capabilities built into the hardware, unlike the SNES which could not so sprite scaling at all unless it was written through software.


You're absolutely right - I just take offence to people labelling any type of background layer transformation to "mode 7." It is a named hardware mode yes, but it was also used in marketing. Everything else you say about the sega cd I already mentioned earlier.

My statement about marketers calling the x68k 32bit was more a criticism on 90s game marketing. I'm well aware of how old the chip was and how obviously disingenuous it would have been.
 

tayls129

Member
Not at all. The 68000 was a off the shelf CPU used in many other computer devices. PS3's Cell was only used for that console and required a lot more development to utilise in a good way.

Crap, you're right. Looked further in to this and realized I was totally off in my analogy.
 

Zee-Row

Banned
It always seemed like Genesis fighting games like Street Fighter and Mortal Kombat had more character animation than the SNES versions. Was that due to more ROM cart space or the faster Genesis processor?
 
You're absolutely right - I just take offence to people labelling any type of background layer transformation to "mode 7." It is a named hardware mode yes, but it was also used in marketing. Everything else you say about the sega cd I already mentioned earlier.

My statement about marketers calling the x68k 32bit was more a criticism on 90s game marketing. I'm well aware of how old the chip was and how obviously disingenuous it would have been.

ah yeah, the marketing on everything was ridiculous hen it came to classifying 'bits'. Even 'Mode 7' was a bit silly as a buzz word, but it is a legitimate feature built into the SNES.

And yeah, I guess the Sega CD was well covered in this thread. Technically the Sega CD add-on had the best hardware sprite scaling abilities of the 16bit generation. The only other system tat came close was the Atari Lynx. But yeah, most Sega CD games that used extensive sprite scaling were capped at 20FPS, apparently it had something to do with the trade off from the Sega CD 12MHZ 68000 to the 7Mhz 68000 in the Genesis. There was a performance penalty.

I guess the Super-FX chips could also do some neat sprite scaling as well. Here is some beta footage of the unreleased SNES port of Comanche, which used the Super FX2 chip for sprite scaling and voxel environments: https://youtu.be/Op5EkC7GbxQ?t=8311


Wow, that just looks so effortless.

Remember Hard Drivin' on Genesis?

https://www.youtube.com/watch?v=pfe2Ze_yDk4 (1990)

Kawasaki Superbike Challenge was also on the SNES as well, but the trackside detail looked barren in comparison to the Genesis game: https://www.youtube.com/watch?v=l8eaHk0IXps&t=469s
 

cireza

Member
It always seemed like Genesis fighting games like Street Fighter and Mortal Kombat had more character animation than the SNES versions. Was that due to more ROM cart space or the faster Genesis processor?
I am pretty sure that the Genesis was more capable overall in terms of animation. This includes Disney games, for example. Can't explain why however.

Also, I think that Mortal Kombat games on SNES are actually using horizontally compressed sprites (in order to be of the correct size once the 256 * 224 resolution is stretched to 4/3 by the TV). So this means smaller sprites, so less space required in the rom.

Street Fighter on Genesis runs in the 256 * 224 mode, so that's the same as the SNES game, so the sprites must pretty close on each console (of course, the colors won't because the Genesis is limited, and the palettes were remade). I don't know if there are more animations.
 
It always seemed like Genesis fighting games like Street Fighter and Mortal Kombat had more character animation than the SNES versions. Was that due to more ROM cart space or the faster Genesis processor?

I think I remember reading that you could store more sprite/tile data on cartridge due to lower sizes thanks to lower color depth, decompression of more densely packed data thanks to the faster CPU, and Sega being far more affordable compared to Nintendo for ROM sizes to third party publishers. Basically, you could get roughly one size greater for a Genny cartridge compared to the SNES version, like 8Mb more per title, for the same cost as well as Sega allowing them to find more savings by shopping around or manufacturing their own carts.
 
I think I remember reading that you could store more sprite/tile data on cartridge due to lower sizes thanks to lower color depth, decompression of more densely packed data thanks to the faster CPU, and Sega being far more affordable compared to Nintendo for ROM sizes to third party publishers. Basically, you could get roughly one size greater for a Genny cartridge compared to the SNES version, like 8Mb more per title, for the same cost as well as Sega allowing them to find more savings by shopping around or manufacturing their own carts.

Another reason might be sound: since the SNES uses samples, a pretty significant part of the ROM space had to go towards storing them and graphics might have had to be trimmed down to get everything to fit.
 

Sapiens

Member
Wait, so every sound that the SNES produced had to come from samples being modulated? You just couldn't send it instructions to play sounds? Did the system come with base samples right in the hardware or was it all cart dependent?
 
I'm not really knowledgable at all about this but my understanding is that the CD's cpu could be used to run programs, prepare graphics, run the drive, etc, but it only had access to the Sega CD's RAM and chipset. It couldn't control or access anything on the Genesis side. The Genesis's CPU had to handle copying data out of the Sega CD's RAM to it's own RAM before that data could be used for output by the VDP or YM2612, and IIRC the Sega CD's CPU had to be halted while this happened.

Yeah, I really don't think the Megadrive/Genesis was designed with major expansions in mind.

I don't think it was that bad, though maybe I'm wrong so take this with a grain of salt. CD 68k should have been able to run during all this, it had whole 512KiB of RAM to itself.
 
Top Bottom