CPU comparison: SNES vs. Genesis vs. TG16

[Greg2600]

Just as a layman, I felt the Genesis performed better. However, like games almost always looked better on SNES.

[Arkhan]

Just as a layman, I felt the Genesis performed better. However, like games almost always looked better on SNES.

 

thats because the Genesis has some assinine color limits.

 

[Rex Dart]

How many colors CAN a donkey see?

[Greg2600]

 

thats because the Genesis has some assinine color limits.

 

Yes, Genesis is like 512 total colors but only 64 on screen at once, 183 including shadow/shading. SNES is 32K colors, more on screen, more sprites on screen, and higher resolutions. Also, SNES allowed high resolution backgrounds, Genesis didn't have much in terms of those. So Genesis had the superior processor, but the rest of the system was not as good as the SNES.

[twoquickcapri]

The genesis only has 61 colors on screen at once. Its uses four 16 color palettes and one color in each palette is the same color. Its normal used for the transparent pixels. So I guess its really 60 color if clear dosen't count as a color.

[evilevoix]

And you only need to buy the game + 2 premium controllers to have a fun time with a friend.

 

the game + 2 premium controllers + a Multitap + a modded TG16 or an imported PCE + a AV Out upgrade to get anything other than RF.

[NinjaWarrior]

I think Billy is some blind SNES Fanboy

 

The Super NES has the slowest CPU ever,

 

Alot of Slow Down in Gradius III, Super G n G and others

 

I give the Nod to the Genesis/Mega Drive

 

Also about Street Fighter 2, I give the Nod to the PC Engine, I have it on all 3 Systems

 

I played it with the SNES Pad, Avenue Pad 6, 6 Button, Hell I even played it once on the Genesis 3 Button Pad

[gorfcadet]

I know this was supposed to be a processor discussion, but since others have brought up games and controllers I thought I'd chip in.

I was utterly amazed by AfterBurner on the PC Engine/ Turbografx compared to the Sega Genesis version. Was that scaling and rotation on the T16? Genesis had the standard redrawn sprites at different sizes to fake scaling. SNES didn't have a version to compare obviously, but that would have been interesting. Space Harrier and Altered Beast were clearly better on Genesis, but AfterBurner somehow stands out. I'm currently trying to get a copy of Power Drift on PC Engine/T16 to try out. That one didn't have a counterpart until the Saturn IIRC.

I'll agree the SNES puts a pretty coat of paint on the Street Fighter series, but those contollers are poo for fighters. To play it well, a gamer needs six buttons on the face of the controller. Sega and NEC got it right. Of course they were later controller revisions; Street Fighter wasn't the direction of gaming when any of these three systems were designed. Nintendo stubbornly held to the shoulder buttons plus 4 layout. Because of that reason I always go to the Sega versions (I don't have the PC Engine one yet.)

The only non Street Fighter game I can think of that all three had was Bomberman. Umm, they were about the same. I have all three and they're all good. All required extra stuff to play multiplayer. Turbografx was the only one that was 5 player instead of 4. HUDSON WINS!!! jk. (I'm comparing T16 Bomber93, Mega Bomber, and Super Bomber.)

 

All that said, I think the idea of benchmarks and which is better is silly. It isn't a Win PC where all three can run the SAME copy of Diablo to different results. The code and programming solutions were completely different. Street Fighter was built completely different for each system. It was a completely different piece of software each time by different programmers. They found different solutions to the unique problems created by each piece of hardware. Street Fighter Alpha 2 was pretty good on the Snes. Does that mean the Saturn and PSX was only a little better than the Snes?

 

Thanks for the processor breakdown for those posters who took the time. I do find that stuff interesting. It makes games like Gunstar Heroes, T16 AfterBurner, and Parodius seem like real accomplishments.

 

All of this made me realize how lucky I was to have a kid brother. Between the two of us, we never had to choose. I got the Sega and T16 and he got a SNES. It was nice just being able to play whatever regardless of system.

[madmax2069]

The Genesis definitely had the better CPU of the three, a 32/16bit (hybrid) 68000 CPU running at 7.67mhz, and a second z80 CPU running at 3.58mhz (I do believe used for in conjunction with the sound chip when running Genesis games, and used as a main CPU when running master system games) .

 

The SNES Ricoh 5A22 (based on the 65c816) is a 8/16bit CPU ran at different speeds depending on what speed the ROM chips was used on the game cart (from what I understand), the Ricoh 5A22 could run as fast as 3.58 MHz only when faster ROM chips was used in the cart.

 

The TG-16 Has a HuC6280A (based off the 6502) is a 8 bit CPU that runs from 1.79 or 7.16 MHz (selectable by software).

Edited May 31, 2013 by madmax2069

[kool kitty89]

The SNES CPU and the TG16 CPU both can do 1.5 MIPS. You can't compare processors just based off of their frequency.

 

For reference the Genesis CPU can do .96 MIPS.

 

 

 

 

 

Drop the attitude. I'm getting tired of reading your know it all a-hole posts.

MIPS is just as misleading as MHz . . . there had to be actual context to the benchmarks. At best, you can use Dhrystone MIPS performance somewhat evenly on performnace of some types of applications. However, there's TONS more context to that too. (and that's assuming you're figures are actually a standard Dhrystone-like test -which I rather doubt)

 

The PCE and SNES CPUs are at least pretty close in overall architecture, with some trade-offs, so it's easier to compare. However, for the vast majority of cases useful in games of the time (at least as far as all the technical examples I've seen argued by programmers), the HuC6280Aat typical 7.16 MHz wipes the floor with the 2.68 MHz (typical) SNES CPU.

The MD's 68k has vastly different merits by comparison, with typically slower by much more powerful instructions, emphais on performance with 16-bit operations, 32-bit linear addressing, and 32-bit operations as well. (though you probably wouldn't be using the 32-bit stuff much)

 

That 2.68 MHz thing is a huge deal to keep in mind too. 3.58 MHz is a bit weak but not THAT bad overall, buta huge number of games (particularly from the 1st half of the system's life) were stuck at 2.68 MHz because Nintendo used slow main RAM and slow ROM. That's also almost certainly the main reason the CPU is capped at 3.58 MHz too, otherwise I don't see why Ricoh should have had problems at least managing 5.37 MHz or perhaps 7.16 MHz at reasoanble yields in 1990. ROM speeds would be limited regardless (due to cost), but using faster RAM would have been a huge deal. (a better DRAM interface should have allowed 3.58 MHz -similar latency to Amiga or ST, but I'd argue opting for SRAM would have been worthwhile even if it meant dropping to 64 or 32k to keep costs down -and a single 32kx8-bit 120 ns SRAM should have been totally reasonable at the time, and fast enough to handle 7.16 MHz 650x access times without wait states) Hell, they also could have gone with slow DRAM plus a smaller SRAM scratchpad for high-speed code/data. (a cheap 8kx8-bit 120 ns SRAM)

 

 

There's also other weird design aspects of the SNES that hamper performance and just seem to make little sense given the overall cost and (especially) 2-3 year newer tech potential over the PCE and MD. There's a lot of things that LOOK good as specs, but are huge problems in reality. (stupid problems and limitations with the sprite engine for example, making it generally less powerful and much more painful to use than the PCE or especially the MD -relating both to some odd aspects of the sprite tables that add unnecessary CPU overhead and progamming complexity, and then there's the stupidly limited sprite size selection limits too)

 

I could go on, but this thread is supposed to be about the CPUs.

 

 

 

 

that wasn't what we were doing, and even so, you can do that to an extent if the processors are related. The SNES's CPU is based off of the successor of the TG16's CPU. It's a direct improvement with alot of new features. It should be able to run code faster (The 65816 is backwards compatible with the 65C02), but often won't manage that because of its balls-slow speed.

 

The 65816 can do far better than the crapass stock SNES one. That's what they did with the SA-1. and the SuperCPU C64 addon. In the case of TG--->SNES, it sure won't do that so good though.

Yeah, the MPU block of the SA1 (10.74 MHz 65816 with high-speed scratchpad) was pretty nice. Then again, had Nintendo been more reasonable in the first place with a faster CPU config (and some reasonable trade-offs), they wouldn't have needed that either. (could have put the cost/complexity of that block of SA1 into other things . . . or just made it cheaper in general )

 

It's kind of like comparing the crappy 2.8 MHz stock Apple IIGS to the accelerators. (well, except 2.8 MHz was a little more excusable in 1986 than 2.68 MHz 1990 . . . still lame on Apple's part even for '86 though -assuming it wasn't an early yield problem at WDC, common DRAM a la ST or Amiga should have allowed 3.5~4 MHz on the '816 or faster with a cache/scratchpad)

 

 

Aside from the 2.68 MHz thing on the SNES, I mentioned above, I think there's also the issue of the HuC6280's memory mapping scheme compared to the '816's segmented 24-bit address modes. I seem to recall the banking scheme in the 6280 was more programmer friendly and generally useful than the 816's segmentation, but I forget the details. (I seem to recall the '816 uses segments rather like 808x with fixed 64k segments rather than allowing something more flexible like multiple smaller banks accessible at once)

 

Also, on the C programming issue on 650x. One of the huge problems there is lack of registers, which is generally addressed in assembly by using zero page. Shouldn't it be possible to optimize a C compiler to make use of zero page registers as well?

 

 

 

Probably not. Likely not. But then again if it had a 68k the entire board would've likely had to change.

 

Some Genesis games suffered slowdown, but mainly when there was a lot of things going on at once, with all manner of sprite sizes or really CPU intensive routines that stressed the 68k. But it took a lot to stress that processor, at least compared to the SNES CPU.

 

Let me put it to you this way:

 

Rotation, scaling and stuff like Mode 7 and even polygons could be "faked"/done on Genesis using CPU intensive software routines.

 

There are games on Genesis that use polygonal models that run entirely on CPU brute force, the type that would take the FX processor on SNES. No, I'm not alluding to Virtua Racer, as that used the SVP chip. I'm referring to games like Red Zone and Star Cruiser (a JP only release). Rotation/scaling and pseudo-mode 7? Check out the rocking tower in Bloodlines, the "scaling" used in Panorama Cotton (which also shows off how the greater variety of sprite sizes available to the Genesis video display processor, in addition to CPU grunt strength, can pull off scaling and rotation on a console that actually doesn't have in hardware support for that sort of thing), and the secret area in the indie release, Pier Solar.

On this note, I think it's also interesting to consider that Sega missed a big potential middle ground for software rendering effects compared to what Nintendo did. (or the likes of SVP)

 

With the beefier CPU (not to mention chunky pixel tiles -vs SNES's bitplanes, mode 7 aside), albeit still not enough to push things on the level of Super FX or such, it would require something considerably less costly or complex than Super FX (or SVP for that matter) to produce that level of performance. Something closer to the little DSP1 chip (licensed NEC embedded DSP) that Nintendo had been using almost from day 1 in 1990 on the SNES would have been more in line with what the MD needed to get to "Super FX level" effects, or perhaps even less than that. (like just a fast ALU coprocessor that handled fixed-point multiplication and division very fast -a huge bottlneck for software 3D using the 68k, or also for handling software scaling or especially rotation/texture mapping effects)

 

Then again, the SNES also has a neat software rendering exploit with using a Mode 7 plane as a low-res 8-bit chunky pixel framebuffer, which is how Carmak managed Wolfenstein 3D astoundingly well without external hardware. (it uses a 112x80 256 color window scaled up to 224x160) The low res also cuts down on VRAM space and DMA bandwidth required for updating the buffer in VRAM.

 

 

 

 

 

The Genesis definitely had the better CPU of the three, a 32/16bit (hybrid) 68000 CPU running at 7.67mhz, and a second z80 CPU running at 3.58mhz (I do believe used for in conjunction with the sound chip when running Genesis games, and used as a main CPU when running master system games) .

 

The SNES Ricoh 5A22 (based on the 65c816) is a 8/16bit CPU ran at different speeds depending on what speed the ROM chips was used on the game cart (from what I understand), the Ricoh 5A22 could run as fast as 3.58 MHz only when faster ROM chips was used in the cart.

 

The TG-16 Has a HuC6280A (based off the 6502) is a 8 bit CPU that runs from 1.79 or 7.16 MHz (selectable by software).

Yes, the SNES is 2.68 MHz by default, and only on-cart SRAM or fast ROM can allow 3.58 MHz. (main RAM is limited to 2.68 MHz too)

 

By comparison, the PCE's 8k of work RAM is full-speed, and the vast majority of games use full speed ROM too. They could afford the otherwise costly premium ~140 ns ROMs thanks to NEC's vertical integration cutting out any overhead on that end of things with the little glob-top hucards being manufactured in-house. That said, there were undoubtedly still some trade-offs with that, and I'm sure that contributed to some of the smaller ROM sizes compared to MD games (in '88 and '89 MD games were mostly 512 kB with a few larger while hucards were 256 kB). The shift to the CD format already occuring at that point kind os skews things too though, so it wasn't just an issue with few larger games coming out later, but just few hucard games coming out at all by the early 90s. (there are a few 512k and 1MB games though, and the one massive 2.5 MB SFII card -1 MB was the cart address limit without a mapper iirc, still those weren't common either)

 

I'm not really sure how many, if any games opted for slow/cheap ~500 ns ROMs (and 1.79 MHz CPU speed in-ROM), but my impression was that it wasn't common at all. Plus, I'm pretty sure there's another reason for the slower CPU mode than ROM, but I forget what it is. (if they really wanted to target slower ROM speeds, it would have made a hell of a lot more sense to allow more middle ground too, like 3.58 MHz at the very least, and perhaps 2.38 and 5.37 -and again given NEC's manufacturing edge, I'd guess 3.58 and 5.37 MHz would have made the most sense for "slow" options)

 

IIRC, the 6280 also has more forgiving bus timing paramaters too, meaning ROM/RAM timing tolerances can be looser than "normal" 650x CPUs. (at least without the latter having a bus latch)

[Arkhan]

Also, on the C programming issue on 650x. One of the huge problems there is lack of registers, which is generally addressed in assembly by using zero page. Shouldn't it be possible to optimize a C compiler to make use of zero page registers as well?

 

That'd be nice. I would have assumed that the one C compiler targetting 6502 based CPUs would. I am not sure if it does or not, because I don't use it.

 

I know PowerC for C64 was a disaster, and HuC for PCE is pretty awful too with respect to efficiency.

[carmel_andrews]

The snes is handicapped by it's design, if they'd gotten the hardware and the processor to work as one (a bit like the Atari 8bit and PAG) it might have stood a chance against the genesis/MD

 

Also the problem with the 65816 is that it was basically 2 years late and not enough companies using it (WDC basically shot themseves in the foot by signing an exclusivity deal with Apple, in that Apple where the only computer company that could use the 65816 in a computer system), the point being that by the time the Apple IIGS came about the 68000 was already estbalished and upscale versions of the x86 processors had started appearing in pc's and there were more pc compatible makers in the market

 

Perhaps if JT hadn't poopoo'd commodore's (MOS's) attempt at an upscale 6502 that they were working on during the development of the c64/vic20, the market for upscale 6502 and other processors might have taken off earlier (instead of relying on the likes of intel and motorola to basically take that market)

[BrianC]

The only non Street Fighter game I can think of that all three had was Bomberman. Umm, they were about the same. I have all three and they're all good. All required extra stuff to play multiplayer. Turbografx was the only one that was 5 player instead of 4. HUDSON WINS!!! jk. (I'm comparing T16 Bomber93, Mega Bomber, and Super Bomber.)

 

All three? Those are all different games. SNES had 5 Super Bomberman games (counting 3-5, which came out only in Europe and Japan), Genesis/Mega Drive had 1, and TG-16 has 3 (Bomberman, Bomberman '93, and Bomberman '94). Mega Bomberman is a port of Bomberman '94 for the TG-16, though TG-16 version is 5 player rather than 4. Telling from videos, Super Bomberman 3-5 for Super Famicom support up to five players.

[mbd30]

Clever programming and special chips help compensate for the SNES' weaker CPU. But it's still the system's Achilles' Heel, much like the use of cartridges was the N64's one big weakness. They could have beaten the competition on everything if only they'd used a faster CPU.

[gorfcadet]

 

 

All three? Those are all different games. SNES had 5 Super Bomberman games (counting 3-5, which came out only in Europe and Japan), Genesis/Mega Drive had 1, and TG-16 has 3 (Bomberman, Bomberman '93, and Bomberman '94). Mega Bomberman is a port of Bomberman '94 for the TG-16, though TG-16 version is 5 player rather than 4. Telling from videos, Super Bomberman 3-5 for Super Famicom support up to five players.

 

I know there were many Bombermans that gen. I didn't mean to offend any Bman fans, The point of my post was to illustrate the similar capabilities of each system... and gripe about controllers; not spread misinfo about Bomberman.

[BrianC]

I know there were many Bombermans that gen. I didn't mean to offend any Bman fans, The point of my post was to illustrate the similar capabilities of each system... and gripe about controllers; not spread misinfo about Bomberman.

 

oh ok. I misread. I wasn't offended. Speaking of capabilities, the differences between Mega Bomberman and Bomberman '94 are really strange. The TG-16 version has more detail in the backgrounds and 5 players, despite how Genesis could probably handle this just as well. Music seems to be different, but the music in both is quality, with both games taking full advantage of the sound hardware.

 

I was surprised by how much smoother the TG-16 Space Harrier runs compared to the Genesis version of Space Harrier II. It still draws each frame rather than real scaling, but seems to have more frames and a smoother frame rate.

Edited August 14, 2013 by BrianC

[gorfcadet]

That's interesting; Afterburner seems to scale, but Space Harrier does seem to be like you say. Anyone play Power Drift? Does it scale or redraw? I want to pick that one up if it is good. I have the arcade cab and the Saturn import, but I love the 16 bitters and would like to have that gen's home port of Power Drift.

[kool kitty89]

The snes is handicapped by it's design, if they'd gotten the hardware and the processor to work as one (a bit like the Atari 8bit and PAG) it might have stood a chance against the genesis/MD

 

Also the problem with the 65816 is that it was basically 2 years late and not enough companies using it (WDC basically shot themseves in the foot by signing an exclusivity deal with Apple, in that Apple where the only computer company that could use the 65816 in a computer system), the point being that by the time the Apple IIGS came about the 68000 was already estbalished and upscale versions of the x86 processors had started appearing in pc's and there were more pc compatible makers in the market

 

Perhaps if JT hadn't poopoo'd commodore's (MOS's) attempt at an upscale 6502 that they were working on during the development of the c64/vic20, the market for upscale 6502 and other processors might have taken off earlier (instead of relying on the likes of intel and motorola to basically take that market)

That's an interesting point . . . and rather ironic given the status (or lack thereof) of the IIGS platform within Apple.

 

But that said, it's also important to note that there were very few platforms to use normal 6502s (or 65C02s, or the enhanced Rockwell 65C02 and WDC's compatible 65C02S) went beyond 2 MHz. Which is odd since at least 3 MHz NMOS 6502s were available (some sources mention 4 MHz), and considerably faster than that in the CMOS derivatives, yet almost noone seemed to use faster models. (aside from use in embedded controller applications)

 

I do realize that the aggressive bus timing (and resultant need for fast RAM) would have been one issue with using faster 6502s, but a bus latch should have helped with that somewhat (enough to at least allow a 3.58~4 MHz CPU to work on RAM with similar timing to the Amiga or ST), and including a fast local scratchpad (or perhaps a hardware controlled cache later on) combined with wait state generation for accessing slow memory should have helped that too.

Aside from the Apple IIC+, I don't know of any computers of game systems that used faster than 2 MHz 6502 CPUs. (and the IIC+ did so rather late too . . . particularly since Apple had never even introduced a 2 MHz Apple II in all the years prior to that)

 

 

Oh, and aside from platforms that actually demanded backwards compatibility with 650x CPUs, another interesting 8/16-bit CPU in a similar role would be the 6809, or HC6309 in particular. The latter still went no higher than 3.58 MHz, but from what I understand it's a very powerful little CPU (in general and clock for clock), and probably could have made a very interesting inclusion into a console design. (then again, those MOS designs were generally inexpensive to license and customize, so that would be a counter point there . . . still it makes an interesting alternative to console or arcade manufactuers considering Z80, x86, or 68k based CPUs in the late 80s -and as it is, certainly should have made a better CPU for the SNES) It still only has 16-bit addressing natively, but external memory mapping logic works around that quite well. (and quite possibly in more useful ways than the likes of the 65816's segmented 24-bit memory . . . let alone 808x, or even 286 protected mode's odd continuation of the 64k segments)

 

Actually in a sort of "design a hypothetical early 90s console" sort fo scenario on Atariage a few years back, the 6309 came up rather prominently. (that and the ARM2 in a slightly different context)

 

 

 

 

Clever programming and special chips help compensate for the SNES' weaker CPU. But it's still the system's Achilles' Heel, much like the use of cartridges was the N64's one big weakness. They could have beaten the competition on everything if only they'd used a faster CPU.

I'm not sure "clever programming" really benefitted the SNES more than its contemporaries. All of them have examples of better or worse programming practices as well as games better or worse optimized for the limitations and quirks of the hardware.

 

In any case, the SNES's CPU is hardly its only problematic area. The PPU (video chip) is a real mess in many respects, with some really frustrating and annoying problems and weirdness in addition to a bunch of interesting modes and features that end up practically useless for the most part, and other (sometimes obvious) features excluded that would be far more useful but aren't there. (like how there's the inclusion of 8bpp -256 color- tile modes, but that's too taxing on VRAM usage and VRAM update bandwidth to really be much use, but there's no modes using 5 or 6-bit tiles -which is doable given the use of bitplanes- among other things . . . including lack of hardware support for column scrolling, but support for the far more complex individual tile positioning that's kind of neat but too complex to be really useful . . . and also the only way to do column scrolling -which means it takes a lot more CPU overhead than would actual column scrolling tables, then there's various painful and limited aspects of the sprite engine including very restricted sprice sizes as well as a convoluted sprite table configuration that ends up wasting more CPU time, and then the slow/limited DMA block copy interface for updating VRAM, among other oddities and problems)

 

Then there's the rather costly and advanced audio subsystem that's extremely powerful on paper, but configured in such a limited manner and severaly restricted in use by the provided tools and lack of documentation, that it ends up being hugely wasteful compared to much cheaper alternatives that might have even managed nominally superior performance. (like the 8 channel Ricoh PCM chip used by the FM Towns, Sega CD, and several arcade systems . . . older, cheaper, simpler but still with notable advantages over the SPC700 module -especially in the way it's used in the SNES- plus it's a Ricoh part on top of all that -Nintendo's long-time chip vendor partner at the time)

 

And, of course, the aformentioned CPU and main RAM speed issues.

[NinjaFlicker]

Sega's hardware was a victim of Sega's software teams. Check out Golden Axe, for the system. The sky is neon turquoise. It's perfect for a laser death holocaust, but since everything else is using muted shading, the overall aesthetic looks like someone accidentally ruined a gif.

 

Throwing 6 inches of texture over a mile of dirt isn't helping matters any. It's like they thought they were programming a Dreamcast game, and were shocked when they suddenly ran out of cart space.

 

Contrast it to something like Alien Soldier or Pulseman, both of which were designed with the system's limitations in mind, and could easily pass for NEO-GEO titles.

 

Then there's Sega's own conversions of their super scaler games. There's no excuse for Thunderblade to play with a frame rate similar to Myst, in a world where Cotton and Road Rash also exist.

[gorfcadet]

Sega's hardware was a victim of Sega's software teams. Check out Golden Axe, for the system. The sky is neon turquoise. It's perfect for a laser death holocaust, but since everything else is using muted shading, the overall aesthetic looks like someone accidentally ruined a gif.

 

Throwing 6 inches of texture over a mile of dirt isn't helping matters any. It's like they thought they were programming a Dreamcast game, and were shocked when they suddenly ran out of cart space.

 

Contrast it to something like Alien Soldier or Pulseman, both of which were designed with the system's limitations in mind, and could easily pass for NEO-GEO titles.

 

Then there's Sega's own conversions of their super scaler games. There's no excuse for Thunderblade to play with a frame rate similar to Myst, in a world where Cotton and Road Rash also exist.

 

Keep in mind, Golden Axe, Thunder Blade, and similar titles came out years begore the games you compared them to. Axe and TB were early system titles if not launch window. Alien Soldier, Cotton, and Pulseman were late in the life cycle with larger roms and more programming experience on the system.

 

The Golden Axe games did seem to occassionaly be done by a color blind person though.

[NinjaFlicker]

Keep in mind, Golden Axe, Thunder Blade, and similar titles came out years begore the games you compared them to. Axe and TB were early system titles if not launch window. Alien Soldier, Cotton, and Pulseman were late in the life cycle with larger roms and more programming experience on the system.

 

The Golden Axe games did seem to occassionaly be done by a color blind person though.

 

Hmm. Good point. But at the same time, look at Sega's Master System library - Double Dragon 1&2 on the NES pays tribute to clean lines and suggested texture. Double Dragon on the SMS is a riot of bizarre color choices and absurdly detailed backgrounds that remind you they can't actually handle perspective yet. Altered Beast on the SMS throws grape jelly on everything, because purple rocks. But even in 16 bit games that were known for their great graphics, Sega finds a way to hint that art is difficult for them. Look at the trees in Ghouls N' Ghosts, compared to the original. Yes, I know they needed to redraw a few things to fit in limited cart space, but they do so in a way that's usually left to the cheapest European Amiga conversions. This is coming from Japan, a country where kids are taught art as if it were a science, beginning in elementary school. It's rare to see that kind of mistake...

 

The Sonic team guys made the Genesis look like an entirely different system.

 

Then there's the super scalers. Yes, Cotton had far more space to play with, but Road Rash actually wrote sprite scaling in software, in order to pull it off. (I think Cotton did too, but it's impossible for an amateur like me to tell.) And sure, Sega can't be faulted for not thinking of it first, but there are smoother super scaling style games on the competition. Square and Hudson would have done far more with the 4meg Sega gave themselves for SMS Afterburner.

[kool kitty89]

Sega's hardware was a victim of Sega's software teams. Check out Golden Axe, for the system. The sky is neon turquoise. It's perfect for a laser death holocaust, but since everything else is using muted shading, the overall aesthetic looks like someone accidentally ruined a gif.

 

Throwing 6 inches of texture over a mile of dirt isn't helping matters any. It's like they thought they were programming a Dreamcast game, and were shocked when they suddenly ran out of cart space.

 

Contrast it to something like Alien Soldier or Pulseman, both of which were designed with the system's limitations in mind, and could easily pass for NEO-GEO titles.

 

Then there's Sega's own conversions of their super scaler games. There's no excuse for Thunderblade to play with a frame rate similar to Myst, in a world where Cotton and Road Rash also exist.

The Sky thing is particularly weird since that palette entry isn't really critical for some other game art . . . a pastel powder blue (as in the Arcade game) would work fine for pretty much any graphics using that.

 

Thunderblade doesn't have framerate issues, it has sprite animation issues, it's a ROM limitation thing. OTOH Road Rash DOES have huge framerate issues due in part to realtime scaling limitations. (or semi realtime, since it's more likely they scale/buffer animation fames somewhat ahead of time rather than purely on the fly -similar to the way realime decompression works in most games)

Panorama Cotton is a ground-up MD-optimized game (not an arcade port) with a LOT of animation used to fake scaling and a combination of animation and neat tile tricks (including heavy line/column scroll exploits) to fake 3D perspective/skewing/textures. (and IMO, those effects are a lot more impressive than simple sprite scaling)

 

A better counter would be compairing the quality of After Burner to Super Thunder Blade or Space Harrier 2 (or comparing PC Engine contemporaries), as far as arcade-style scaling based pseudo 3D games.

On that note, After Burner on the SMS, while a neat attempt technically, was a pretty wasteful way to go overall. (going for large, preshifted/animated tile-based software sprites at the expense of massive ROM usage and choppy gameplay -it's 512k just like the MD and PCE versions- while going more in line with Tengen or -especially- Sunsoft's NES conversions would have been better, and quite possibly allowed for considerably better overall animation/detail and color usage at the expense of smaller objects and flicker -Space Harrier has similar issues, except it at least mixing in some hardware sprites)

 

There's tons of impressive in-house Sega games too, and 3rd party ones, but your main complaints come from very early games on the system using small ROMs (all below 1MB -most 512k) and working with limited experience and limited knowledge of the system. (not just a matterof learning the hardware either, but DISCOVERING the potential, since the raw development tools -or what passed for them back then- hardly comprised full documentation of the hardware, let alone potential exploits not intended by the designers)

 

Hmm. Good point. But at the same time, look at Sega's Master System library - Double Dragon 1&2 on the NES pays tribute to clean lines and suggested texture. Double Dragon on the SMS is a riot of bizarre color choices and absurdly detailed backgrounds that remind you they can't actually handle perspective yet. Altered Beast on the SMS throws grape jelly on everything, because purple rocks. But even in 16 bit games that were known for their great graphics, Sega finds a way to hint that art is difficult for them. Look at the trees in Ghouls N' Ghosts, compared to the original. Yes, I know they needed to redraw a few things to fit in limited cart space, but they do so in a way that's usually left to the cheapest European Amiga conversions. This is coming from Japan, a country where kids are taught art as if it were a science, beginning in elementary school. It's rare to see that kind of mistake...

 

The Sonic team guys made the Genesis look like an entirely different system.

 

Then there's the super scalers. Yes, Cotton had far more space to play with, but Road Rash actually wrote sprite scaling in software, in order to pull it off. (I think Cotton did too, but it's impossible for an amateur like me to tell.) And sure, Sega can't be faulted for not thinking of it first, but there are smoother super scaling style games on the competition. Square and Hudson would have done far more with the 4meg Sega gave themselves for SMS Afterburner.

I wouldn't say Sonic Team specifically . . . and besides that Yuji Naka (of Sonic fame) was responsible for the MD version of Ghouls N' Ghosts too. (and overall, I really don't see the critisim there . . . given the ROM limits and release date, it's not bad at all, it's only 640k and the Supergrafx version isn't all that better considering it's a full 1 MB hucard)

 

There were tons of good internally developed Sega games on the MD, and even looking early on, you've got things like Revenge of Shinobi that were pretty well designed and aesthetically optimized. And slightly later (1990) you got stuff like Castle of Illusion really starting to show things off.

On the other end, you've got things like Alex Kid early-on too . . . particularly weak in gameplay and art. (surprised you didn't mention it actually)

 

And in terms of Double Dragon. Sega's version was an arcade port while the NES game was heavily reworked in general. For the most part, the color and detail in the SMS game worked well IMO, and it has several strong points. (the hair color choices are a bit odd though) The flicker is a legitimate criticism, but what's weirder is that it's not mostly due to sprite bandwidth limitations, but most often due to overlapping prioirt issues (almost like Z-fighting in 3D games) when 2 characters get too close together. (it doesn't seem to be a quirk of the normal flicker routine used, so I'm thinking it's either a problem related to sprite sorting, or something done intentionally to avoid sprites becoming obscured too easily -as it mostly happens when one player is nearly totally covered by another)

The only other real complaint (that doesn't just apply to NES differences from the arcade original) is the difficulty being too low in general, mainl relating to the infinite respawn continues. (with neither limited continues nor checkpoint-progress penalties typical of coin-op to home conversions)

 

And hell, Double Dragon in general tended to have major problems in home conversions, including poor quality in the 8 and 16-bit computers and the later Genesis release as well, among others. (and the arcade game itself has some big problems with slowdown)

[Austin]

Anyone play Power Drift? Does it scale or redraw? I want to pick that one up if it is good. I have the arcade cab and the Saturn import, but I love the 16 bitters and would like to have that gen's home port of Power Drift.

 

It's not very good. Playable and mildly enjoyable, but if you have the Saturn one there is no comparison. It's like going from the arcade version of Outrunners to the Genesis version. Ok, maybe not that bad, but not really worth shelling out the money for. Try it on an emulator to see for yourself.

[gorfcadet]

Thanks Austin! I actually have the standup arcade cab of Power Drift so I don't know why I feel the need to plunk down for it, but I love the SEGA arcade racers. I'll pass on it unless I find a super deal.

[malducci]

Block Transfer Instructions - a "poor man's blitter" - the 6502 is very slow at doing block memory copies, having an instruction to do it would speed things up probably by 4-5 times vs a stock 6502.

 

68K is very good relatively at memory copies, in a single instruction you can move 56 bytes at a time (using 14 registers + 2 as pointers), with the pointers automatically incremented at the end. Plus the 68000 does 16-bit memory accesses.

 

Even using full 32bit regs on the original 68k, it's not that much faster than the Txx opcodes of the 6280. I wrote a few mem copy routines for the 68k. A copy loop that did fourteen 32it regs for 56 bytes per instance took 5.1 cpu cycles (just the copy and loop, excludes the prep overhead). Txx instructions are 6 cpu cycles a byte. If you unrolled the copy part of the 68k loop, 26 times to negate overhead of the sub/branch - you're looking at 4.64 cpu cycles per byte. More limited though (need multiples of 26*56bytes). 6 vs 5.1 cycle per byte isn't that big of a difference.