• 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

Khaz

Member
Why make special chips when you can just create a console add-on?

This is the real answer. SEGA decided to put the extra chips in a single addon instead of in every augmented cartridge. Cheaper for everybody but the market didn't agree on buying extra hardware (even though they were more than happy to pay extra for augmented SNES games.)
 

Beartruck

Member
that still suffers from that muffled distortion that is inherent to the snes.

https://youtu.be/CdL8fJH2mic

on the other hand is super crisp.

You're comparing music on an actually released game to music on a romhack released 20 years after the system died. You couldn't cherry pick harder if you tried. Look, I can do it too:

https://youtu.be/tyF7LB_nd9w?t=1m44s

I think there are way too many old school fanboys in this thread. Yes, the genesis did have a faster CPU that made it better for some games(shmups), but the SNES had double the RAM, a larger color palette with more simultaneous onscreen colors, a higher resolution(depending on developer preference), scaling and rotation built in as a system level feature, and a much stronger sound chip. Take any game that was released on both systems with relatively little changed(Like zombies ate my neighbors) and the genesis version suffers in the comparison.
 

Dehnus

Member

How about yes? You can just stream data to the PCM of the Ym2612 too you know, same way tales does it and then some (due to having more bandwidth available and not having to halt the main CPU to do so). It just wasn't worth the cartridge space required. As rom memory was expensive, you might as well use it for other things.

But homebrew has already proven the possibility of it, with little to no impact on the CPU. Mixing however would require CPU time :(. If only SEGA had allowed the YM2612 Interupt lines to be connected to teh z80 or even just the cart. It would have opened up sooo many more possibilities.
 

00ich

Member
that still suffers from that muffled distortion that is inherent to the snes.

Yes, the SNES is in full DSP echo mode. The point is that through some poor fellow made PCM streaming work on SNES.

https://youtu.be/CdL8fJH2mic

on the other hand is super crisp.

...and not designed to fit at full game length on a cartridge.
Another drawback is that the genesis was reduced to FM sound "effects" when the PCM channel was used for music, be it a full PCM stream or just some beats from a tracker.

That's what makes streets of rage OST secretly even better: it leaves the PCM unoccupied. Otherwise there would be no screams and punchy sound effects.
 
Also, that graphical "gap" between early and late Gens games happens with pretty much every console, including the SNES. They are making it sound as if the Genesis is some genious piece of machine that performed magicand made later games look better.

Take a look at the early Final Fantasy 4 and the late Chrono Trigger, there's a major gap there too.
It's not Gens exclusive.

Treasure sure works some magic with Alien Soldier
 

Beartruck

Member
we are talking about the capabilities of the hardware not games that were released?
generally you do show the best of to show the limits of the hardware.

What it can do with 2 decades of additional fiddling is irrelevant. What matters is what developers were actually capable of. Did you know the Sega Saturn actually had better polygonal capability than the playstation? Neither did I for the longest time because outside of 1 or 2 Sega games no developer ever took advantage of it.
 

00ich

Member
How about yes? You can just stream data to the PCM of the Ym2612 too you know, same way tales does it and then some (due to having more bandwidth available and not having to halt the main CPU to do so). It just wasn't worth the cartridge space required. As rom memory was expensive, you might as well use it for other things.

But homebrew has already proven the possibility of it, with little to no impact on the CPU. Mixing however would require CPU time :(. If only SEGA had allowed the YM2612 Interupt lines to be connected to teh z80 or even just the cart. It would have opened up sooo many more possibilities.

Interesting, but I replied to somebody claiming PCM streaming was impossible on the SNES.
 

Dehnus

Member
Snes hardware was better from a technical point of view although some would argue this its probrably more an art direction rather than a physical limitation or a combination.

The extra chips added were more to accommodate 3d into game's as the original hardware was not designed with that in mind

Nintendo and sega had about the same amoumt of ganes with the added chips from memory but nintendo are probably remembered more because of starfox

I don't think you want to hear what the people of Treasure thought of it ;).

Spoiler: They weren't fans of the architecture ;).
 

jwhit28

Member
If Genesis didn't use special chips, why were we still paying $70 and $80 for games? We're SNES games offering the extra space cartidges AND extra chips for that same $80?
 

Dehnus

Member
Interesting, but I replied to somebody claiming PCM streaming was impossible on the SNES.

Oh it is, but you just have serious bandwidth constraints. The CPU isn't the biggest issue with the SNES, it's the bandwidth. Not only did the Megadrive have more of it (by quite a margin), it also used smaller sized datatypes. Less colours also means, smaller size. These things add up.
 

deriks

4-Time GIF/Meme God
Because they already had Blast Processing.

GENESIS DOES
hqdefault.jpg
 

lazygecko

Member
I don't know quite how Tales of Phantasia accomplishes the streaming (is it via the echo buffer?), but it sounds like Dehnus knows. And if that also comes at significant drawbacks for the CPU as Dehnus claims, it makes me wonder how applicable the technique would be during more general gameplay scenarios, which was more what I was alluding to. It's easier to get away with this kind of stuff for isolated intro and cutscene segments.

Another drawback is that the genesis was reduced to FM sound "effects" when the PCM channel was used for music, be it a full PCM stream or just some beats from a tracker.

That's what makes streets of rage OST secretly even better: it leaves the PCM unoccupied. Otherwise there would be no screams and punchy sound effects.

Soft-mixing 2 or more virtual PCM channels (at the cost of bit depth for each channel) for playing several samples simultaneously is a pretty common technique for many released Genesis titles.

And no, all the Streets of Rage games use PCM drums for music, mixed/layered with FM drums to varying degrees.
 

Dehnus

Member
I don't know quite how Tales of Phantasia accomplishes the streaming (is it via the echo buffer?), but it sounds like Dehnus knows. And if that also comes at significant drawbacks for the CPU as Dehnus claims, it makes me wonder how applicable the technique would be during more general gameplay scenarios, which was more what I was alluding to. It's easier to get away with this kind of stuff for isolated intro and cutscene segments.



Soft-mixing 2 or more virtual PCM channels (at the cost of bit depth for each channel) for playing several samples simultaneously is a pretty common technique for many released Genesis titles.

And no, all the Streets of Rage games use PCM drums for music, mixed/layered with FM drums to varying degrees.
Soft-mixing had limits though, but I think they maxxed out at 4 mixxed channels in certain games, don't know how far homebrew got in demos though. But they are demos, thus not a game running also wishing for some of that juicy bandwidth and CPU cycles :D.

As for the SNES, later in its life Nintendo became a bit more "free" with its sound requirements. According to interviews, you no longer needed to send in your sound patches to Nintendo to be "muffled up!" ;). And there are always ways to making something work, maybe at the expense of something else, but still ;). Factor 5 was able to produce Dolby Suround on an SNES and most of the tales streaming was done without heavy gameplay usually. Or with the screen not moving at all, like a scaling image or other effect that could be offloaded to the VPU. So while something predictable is happening it is easier to stream your data to the audio processor, without it affecting the rest of the game. But the people at Enix wrote a pretty good compression algorithm to fit the info on the cart and through the narrow bandwidth. It is quite a feat :).
 

Sapiens

Member
Wait, so how do the zooms in art of fighting work then?

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?
 

00ich

Member
And no, all the Streets of Rage games use PCM drums for music, mixed/layered with FM drums to varying degrees.
oh, you right. If I could remeber which game i meant...
Anyway here's a video how music on genesis is composed: https://www.youtube.com/watch?v=BA7XcAt15_0

On topic: the SegaCD ('91 in japan) came with a DSP for mode7 effects. The results, as demonstrated by thunderhawk, are very good. So that might be part of the reason, why Sega didn't release other games with DSP on them, too.
 
So here are a few more technically minded quotes regarding the SNES and Genesis CPUs.

Here's an interview with Kevin Seghetti - a programmer who worked on a cross platform title, 'Ballz':

Sega-16: How close were the two versions in terms of performance?

Kevin Seghetti: The 68000 far outperforms the 65816. The 68000 has 16 32 bit general purpose registers (eight data, eight address) and built in multiply and divide instructions. The 65816 has one 16-bit data register (A), two 16 address registers (X & Y), and no multiply instruction.There were a couple of factors in us being able to make Ballz work on the SNES:

We used the external DSP (same as in Pilot Wings) to do most of the 3D math
The Genesis code was not very efficient. It was written by Keith Kirby, who was really more of a game designer than a programmer. He coded out of necessity to get his ideas made, but never claimed to be good at it.

I believe the final frame rate between the two was about the same (pretty much had to be, since a lot of the logic was framerate based). At one point we were going to remove the Mode 7 floor since it was slowing us down (which is why the screen shots on the box don’t show a mode 7 floor), but we were able to optimize enough stuff to get it back in.

More here.

Here are a few more educated responses in a technical forum:

On the MD, I don't think any games have ROM that forces wait states, so all are accessed at the CPU's limit of 4 cycles per memory access (about 522 ns, or 526 in PAL) which gives 3.84/3.80 MB/s for 16-bit reads.

The SNES CPU accesses its DRAM at 2.68 MHz (373 ns) for 2.68MB/s and does the same for ROM on many games, but some later generation games used faster ROM that allowed the 3.58 MHz mode to be enabled for 3.58 MB/s. (the 280 ns memory cycle time Nintendo advertised)

[The SNES mostly ran at] 2.68 MHz, and always 2.68 MHz in work RAM for all games.

It almost certainly has nothing to do with Ricoh's ability to produce a fast enough chip, and probably everything to do with the memory interface used and Nintendo opting to invest in other areas and sacrifice some features that would have practically allowed the CPU to run at 2x or faster the speed that it did.

They could have implemented an interface to allow proper single cycle memory fetches rather than requiring fast enough memory to respond in 1/2 a cycle (iirc a simple 8-bit latch is all that's needed, sort of like use of a 16-bit latch to allow the 68000 to only hit the bus once every 4 cycles).

The SNES used DRAM for main memory, and even if it had used 120 ns FPM DRAM (common/cheap for the time -the Lynx used that type of DRAM), you'd need a wait-state mechanism for cases of slower random accesses. (which would be around 200-240 ns, not sure on the exact timing)
That should have meant the SNES easily could have run at 7.16 MHz in DRAM with some wait states dropping average performance somewhat. (still well over 3.58 MHz average performance)
In that case, somewhat like the lynx, programmers would want to avoid use of ROM directly and load most data/code into work RAM ahead of time (since RAM would be considerably faster than ROM -at least for early games . . . or any late gen games using cheap ROM in general). (albeit, in the lynx's case, the CPU can't access ROM directly and has to use a separate DMA interface -not sure if it's using the blitter or something else- to page the code/data quickly into DRAM -faster than the CPU could)


The claim about the SNES's memory access is rather loaded. At 3.58 MHz, it does complete a memory access at about 86-88% faster (280 ns vs 522 ns), but that's for an 8-bit read vs a 16-bit read on the MD. (so the MD takes ~1.87x times as long, but can read double the data in that time) And then there's the bigger issue of the SNES actually runs at 2.68 MHz for all games in RAM (and all early games in ROM as well), so that's only 373 ns accesses and the MD only takes 1.39x as long per access then. (but still can do 2 bytes in that time when the SNES is handling 1 byte)
And that's just memory accesses, not actually addressing performance benchmarks for running code. (the SNES executes most instructions much faster, but the simpler instruction set means more instructions needed for some operations the 68k does with fewer, slower/more powerful instructions -to which point it depends on the type of game, but the SNES is so slow that it still will only come close to even in better cases, more so with later 3.58 MHz games)

The PCE's CPU accesses ROM and RAM at 140 ns, so 273% faster than the MD (MD takes 3.73x as long to complete an access), but still 8 vs 16 bit meaning the PCE has a nominal ~87% bandwidth advantage over the MD's 68k. (double that for 8-bit specific operations -the same cases where the SNES would have a moderate advantage over MD bandwidth)
Then there's the actual computational performance again, still cases where the 68k could be preferable, but a much wider margin for the PCE's CPU to match to beat the 68k in other cases. (any case where the SNES would be closer to even with the MD, the PCE should beat both by a fair margin -some of the biggest exceptions where the MD would be better could be for 3D games, though the MD has a bigger advantage there with packed pixels vs planar on the PCE, so it wouldn't be an even comparison in any case)

You can read the whole thread here.

There are also limits to the sprites on each system which is best summed up here:

Many and often most 16-bit console sprite objects that we can see and think of as single sprites, are built out of multiple sprites. There are specific sizes that sorites can be and to get the most onscreen, you have to be efficient with how you cobbke together the right assortment of sizes for each object.

The SNES has a very restrictive bottleneck in that it can only use 2 different sprite sizes per scene. This leads to inefficiency, quickly reaching the borderline for sprites to drop out, but it also leads to uncreative developers making objects of too similar or repetitive sizings. That Gundam (Wing?) fighter for example, has two huge fighters... but they're all the same size and proportions.

The Genesis and PC Engine can mix up any of their various sprite sizes however they want. The Genesis has the pretty much the same proportionate sprite limitations in either resolution as the PC Engine does in its 256 pixel-wide resolution. When the PCE uses its higher resolutions, it keeps the same sprite limits (number onscreen, per line, etc).

The other advantage the Genesis has is that it can do tiny 8 x 8 pixel sprites, while the PCE's smallest is 16 x 16. This makes it more efficient for ports of games with tiny bullets and for smaller points sticking out of sprite objects. There is a workaround for the PCE to do 8 x 16 pixel sprites, but most PCE devs weren't very efficient in general.

The Genesis and SNES also usually use up an entire tile layer to fake huge sprites. Since the PCE only has a single tile layer, it usually does hige sprites with actual sprites.

The main bottleneck that all of these consoles work around is the sprites/pixels per line limit. The Genesis and PCE can only do up to the width of the screen for sprite pixels lined up horizontally. The SNES can do a bit more, but its sprite size restriction gets it to its limit sooner.

The SNES has much more trouble tossing around a lot if interactive sprites at a time. Gunstar Heroes or Contra Hardcorps filling the screen with explosions is easy to do, because it's strictly eye candy. A screen full of interactive objects with collision and AI patterns and things like reactive paths tend to slow down cpus the most.
 

lazygecko

Member
Soft-mixing had limits though, but I think they maxxed out at 4 mixxed channels in certain games, don't know how far homebrew got in demos though. But they are demos, thus not a game running also wishing for some of that juicy bandwidth and CPU cycles :D.

Most games use 2 channels simply so that gameplay samples don't interrupt the drums. I can't think of any games that actually use more during gameplay. I heard that Konami's driver for games like Contra Hard Corps supports 4 but doesn't actually use them.

Toy Story plays 4 channel modules during the opening and ending.

As for the SNES, later in its life Nintendo became a bit more "free" with its sound requirements. According to interviews, you no longer needed to send in your sound patches to Nintendo to be "muffled up!" ;). And there are always ways to making something work, maybe at the expense of something else, but still ;). Factor 5 was able to produce Dolby Suround on an SNES and most of the tales streaming was done without heavy gameplay usually. Or with the screen not moving at all, like a scaling image or other effect that could be offloaded to the VPU. So while something predictable is happening it is easier to stream your data to the audio processor, without it affecting the rest of the game. But the people at Enix wrote a pretty good compression algorithm to fit the info on the cart and through the narrow bandwidth. It is quite a feat :).

I read about the whole having to send your samples to Nintendo for processing thing in one interview. I could never figure out whether that was a required policy or if it was because the developer lacked the internal tech to do it themselves.

Information on how people actually worked with SNES audio seems extremly sparse compared to other systems which is a shame.
 

cireza

Member
If Genesis didn't use special chips, why were we still paying $70 and $80 for games? We're SNES games offering the extra space cartidges AND extra chips for that same $80?
You still had to pay for the memory required to hold the game rom. With games becoming 24, or even 32 Meg, the prices raised.

However, I don't know if this is actually a valid reason to raise the prices (at least, to raise them THAT MUCH).
 
SNES's had a custom Ricoh CPU operating at, like, 2 MIPS and the MD had an "off the shelf" M68K running at 8 MIPS.

How much is that in terraflops and could they do FP16?
bad joke

What I don't understand with the MD's Motorola though, quoted from Wikipedia:
The main microprocessor is a 16/32-bit Motorola 68000 CPU clocked at 7.6 MHz
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.
 

Sapiens

Member
oh, you right. If I could remeber which game i meant...
Anyway here's a video how music on genesis is composed: https://www.youtube.com/watch?v=BA7XcAt15_0

On topic: the SegaCD ('91 in japan) came with a DSP for mode7 effects. The results, as demonstrated by thunderhawk, are very good. So that might be part of the reason, why Sega didn't release other games with DSP on them, too.

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.
 

Sapiens

Member
How much is that in terraflops and could they do FP16?
bad joke

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.

Overclocking on the md CPU is a physical hack. Also, I believe some games, being programmed so tightly to the hardware restrictions, have problems if not running at stock CPU speeds.

I don't think it would have been in sega's best interests to start selling an MD with a slightly faster CPU that newer games could access. At least Sega showed restraint there.
 
Overclocking on the md CPU is a physical hack. Also, I believe some games, being programmed so tightly to the hardware restrictions, have problems if not running at stock CPU speeds.

I don't think it would have been in sega's best interests to start selling an MD with a slightly faster CPU that newer games could access. At least Sega showed restraint there.

Yeah, that's true. Would've been a little early for a Mega Drive Pro :)

I just wonder if Motorola sold their CPU's with a price range matching the stock MHz they offered. Amiga 500 seemed to choose the same clock frequence for their 68000, while on the Sega CD they went for a 12,5 MHz one. I'm guessing the price was higher for a higher frequenced one, plus I guess they developed faster and faster versions.

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.

One day I hope someone makes a MD, Sega CD and 32X combo game that just pushes all three to breaking point, just to see what the system could've done. Though i doubt the 32X scene and documentation is very large.
 

Sapiens

Member
Yeah, that's true. Would've been a little early for a Mega Drive Pro :)

I just wonder if Motorola sold their CPU's with a price range matching the stock MHz they offered. Amiga 500 seemed to choose the same clock frequence for their 68000, while on the Sega CD they went for a 12,5 MHz one. I'm guessing the price was higher for a higher frequenced one, plus I guess they developed faster and faster versions.



One day I hope someone makes a MD, Sega CD and 32X combo game that just pushes all three to breaking point, just to see what the system could've done. though i doubt the 32X scene and documentation is very large.

Finding out about how chip purchases occurred in the 80s and 90s would be interesting. It's also worth noting that some MD systems from sega shipped with non-Motorola clone 68ks. Maybe it was a cost cutting measure or maybe Motorola was no longer producing CPUs clocked at that frequency.
 
Finding out about how chip purchases occurred in the 80s and 90s would be interesting. It's also worth noting that some MD systems from sega shipped with non-Motorola clone 68ks. Maybe it was a cost cutting measure or maybe Motorola was no longer producing CPUs clocked at that frequency.

Interesting! Yeah one can wonder what the reason was. Man, Motorola really hit gold with that 68000 range.

Reading more on the processor, Wikipedia quote again:
Initial speed grades were 4, 6, and 8 MHz. 10 MHz chips became available during 1981[citation needed], and 12.5 MHz chips by June 1982.[4] The 16.67 MHz "12F" version of the MC68000, the fastest version of the original HMOS chip, was not produced until the late 1980s.
Seems like they offered a range of speeds, I guess Sega looked at costs etc. and ended up with the version in the MD, then by the time Sega CD went into development the higher frequenced one had dropped in price and was required for the Sega CD to work.

It seems the processor internally worked as a 32-bit one too, headstarting the move over to 32-bit processors at the time.
 

Fiendcode

Member
I said two things :

Genesis hardware was well designed.
SNES weak CPU was a way to reduce cost.

Seems pretty clear to me. If you disagree, then explain why, rather than telling me that I am ignorant. Thank you.
Sort of. The MegaDrive hardware was designed with the goal of bringing arcade quality games home and system itself is loosely based on Sega's System-16 arcade board. It was an affordable 68000 system at home basically.

With SFC the CPU wasn't chosen for cost but for familiarity and (likely initially) backwards compatibility. It's also worth noting that the original hardware design would've included the DSP-1 co-processor in the system itself but that chip was removed to save costs since it was largely used only for 3D games like Pilotwings.

There were different design goals with each and both definitely have their unique strengths and weaknesses. One really isn't better than the other though I'd say. Personally my favorite hardware design from then is probably the PC Engine, which punched well above it's weight for years versus the "true" 16-bit consoles.
 

Dehnus

Member
Most games use 2 channels simply so that gameplay samples don't interrupt the drums. I can't think of any games that actually use more during gameplay. I heard that Konami's driver for games like Contra Hard Corps supports 4 but doesn't actually use them.

Toy Story plays 4 channel modules during the opening and ending.



I read about the whole having to send your samples to Nintendo for processing thing in one interview. I could never figure out whether that was a required policy or if it was because the developer lacked the internal tech to do it themselves.

Information on how people actually worked with SNES audio seems extremly sparse compared to other systems which is a shame.

Yeah, never got why Nintendo did it, but I would believe Nintendo got more "liberal" with their requirements. From what I understood they tended to really mess up samples :(, and demanded you paid for the pleasure :(.

Oh well, luckily for developers those days are long behind them ;).
 

Sapiens

Member
Interesting! Yeah one can wonder what the reason was. Man, Motorola really hit gold with that 68000 range.

Reading more on the processor, Wikipedia quote again:

Seems like they offered a range of speeds, I guess Sega looked at costs etc. and ended up with the version in the MD, then by the time Sega CD went into development the higher frequenced one had dropped in price and was required for the Sega CD to work.

It seems the processor internally worked as a 32-bit one too, headstarting the move over to 32-bit processors at the time.

I think it had more do do with the math being processed at 16-bit and the addressing being 32-bit. 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...
 

Dehnus

Member
Sort of. The MegaDrive hardware was designed with the goal of bringing arcade quality games home and system itself is loosely based on Sega's System-16 arcade board. It was an affordable 68000 system at home basically.

With SFC the CPU wasn't chosen for cost but for familiarity and (likely initially) backwards compatibility. It's also worth noting that the original hardware design would've included the DSP-1 co-processor in the system itself but that chip was removed to save costs since it was largely used only for 3D games like Pilotwings.

There were different design goals with each and both definitely have their unique strengths and weaknesses. One really isn't better than the other though I'd say. Personally my favorite hardware design from then is probably the PC Engine, which punched well above it's weight for years versus the "true" 16-bit consoles.

Considering the CPU and bus of the SNES, I find it odd that people place the PC Engine on "8 bit level". The CPU used in the PC engine was slower, sure, but not that much slower than the SNES one. And it was a really tiny system ;). Filled with empty space in the USA :D. Really agree with that: "Was the little Console that could" feeling people seem to have with it :D.
 

hodgy100

Member
Yes, the SNES is in full DSP echo mode. The point is that through some poor fellow made PCM streaming work on SNES.



...and not designed to fit at full game length on a cartridge.
Another drawback is that the genesis was reduced to FM sound "effects" when the PCM channel was used for music, be it a full PCM stream or just some beats from a tracker.

That's what makes streets of rage OST secretly even better: it leaves the PCM unoccupied. Otherwise there would be no screams and punchy sound effects.

yeha someone streaming samples on the snes is impressive :)

but to use an actual retail example then. the megadrive version of Toy story had a mod player!

https://youtu.be/IPr4V1c2VqA
https://www.youtube.com/watch?v=Ajx_p__Wd90
 

Dehnus

Member
Like you wouldn't believe. You want bi-direction scrolling? That's a chip. You want a little overlay window on the bottom of Super Mario 3? That's a chip. You want that giant mike tyson punch out sprites? That's a chip.

https://en.wikipedia.org/wiki/Memory_management_controller

Not to mention for tiles, want more addressable tiles so your game doesn't look so bland? That's a chip ;).
In Japan even worse ;).
"You want an extra FM chip? that's a chip"
"You want a wave table synth? That's a chip"
"You want another square wave channel? That's a chip".

Oooh you want to save your progress? Oh, you better believe that's a chip!
hqdefault.jpg

https://wiki.nesdev.com/w/index.php/MMC1
 
You probably didn't witness Amiga/ST banter.

I did for a short time on Usenet and random social chat. (Amiga won that.). It was more limited on the US side, but I read enough trashtalk and was educated about UK slang from the constant flame wars from Euro users to last two lifetimes in the early '90s. By that time, I was more fully invested in console wars rather than early computers, anyway.
 
I think it had more do do with the math being processed at 16-bit and the addressing being 32-bit. 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...
Yeah, seems like a hybrid to support all 16-bit applications, but futureproof it for a move towards 32-bit in the long run.

Haha, yeah. You'd think Tom Kalinske would have thrown the 32-bit thing around in advertising, though maybe they wanted to hold back the push for a later console.
 

Celine

Member
If Genesis didn't use special chips, why were we still paying $70 and $80 for games? We're SNES games offering the extra space cartidges AND extra chips for that same $80?
Keep in mind that many of the SNES games with chips didn't use the biggest rom size available at the time to offset the cost of the additional chip.
Super Mario Kart is 4 mbit, Star Fox 8 mbit, Yoshi's Island 16 mbit.

Then we have example like Super Mario RPG with SA-1 (best addon chip for SNES IMO) that was full 32 mbit (but it was released in 1996).
 

Oemenia

Banned
I was talking about colors here. DKC has gradients that you could never dream of on Genesis, because the palette has a lot more available colors.


Nothing because I am not a technical person anyway. I simply talk about how I feel when playing the games, and you can pretty much witness the CPU advantage of the Genesis after playing most of the games on both systems. Also the console outputted most of its games at a higher resolution (that's only one example).

The SNES however displays much better gradients, combine this with its ability to make transparency, you get some extremely pretty and refined graphics in many games. But that's pure pixel-art, it does not involve "moving stuff on the screen". They both have very different strengths.

Otherwise, Sonic 3D and Toy Story are some of the games that make the best use of the Genesis color palette. Also, Jurassic Park Lost World has some pretty impressive green gradients (as well as some crazy special scenes). If you don't know about this game, definitely check it out.
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.
 

MTC100

Banned
The SNES CPU was more powerful, the fact that it is slower doesn't mean they "cheapened out".

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.
 
Top Bottom