CPU Performance: TurboGrafx-16 vs Genesis vs Super Nintendo

[@drd2093]

As an emulator author, I have to say this test is suboptimal. You need real-world work to benchmark, which is why things like dhrystone exist. In point of fact, every time the m68000 accessed memory, it’s 4 clock cycles wait per 16 bits, whereas the 65816 and 6502 are 1 clock cycle per byte. So for instance doing 8-bit operations (very common then), 65816 would have an advantage over the m68000 and be roughly equal for 16-bit operations, just by memory wait time.

[@DutchRetroGuy]

It should probably be pointed out here that each CPU has it’s own strengths and weaknesses. Case in point, the 68000 code as shown is not an optimal implementation of the algorithm selected and does not represent how 68000 coders would normally approach code like this. Setting aside that 16 bit CPU’s always do worse at 8 bit operations than 16 bit ones, both the instruction used for adding (ADDI #1,D0) and the way the loop has been set up (forcing three loops while the 68000 can do this using just two) artificially limit the 68000’s speed compared to what it actually can do. Now, you don’t want to use the two-loop option for fairness, which is reasonable. However, the inner loop code can be improved without breaking the spirit of the challenge here, which ought to give a more realistic image of relative performance. Either preload the values in registers (for instance d4 & d5) and use move.b d5,d0 & add.b d4,d0 or use addq.b #1,d0 Both of these changes will make the code run significantly faster on the 68000. In the case of the addq.b, the inner loop drops from 26 cycles to 22 cycles (18% faster). In case of using registers rather than immediate values (as is the norm for 68000 coding wherever possible), the inner loop will go from 26 to 18 cycles (44% faster). Edit: actually you don’t need extra registers. Just use moveq #1,d0 and addq.b #1,d0 - just as fast as preloading register. That’s what I get for writing code at 1 AM I guess 😅 All this said, this was an interesting video - it’s nice to see some comparisons between these venerable beasts 👍

[@DutchRetroGuy]

And just to be clear, as I know that text communication can sometimes be misread, my post above is not meant as being negative - I really do think it’s quite nice to see some comparisons of code between these CPU’s and both the 6502 family and the 68000 family hold a special place in my heart. It’s only meant to show that comparing between CPU families is tricky business, as each really should be programmed differently in order to get good performance. Thanks for the video 😀

[@hagopds]

Very cool! I wasn't aware of the 68000's moveq instruction, and it appears to support signed 8-bit fields from -128 to 127. This would be equivalent to the other consoles loop of 1 to 255, and should run faster as moveq requires fewer clock cycles than move.b. It's amazing to see what programmers were able to achieve in the 16-Bit generation. Using optimizations as you suggest and clever coding, they were able to produce games beyond what many considered possible.

[@DutchRetroGuy]

@@hagopds yeah, the 8 & 16 bit era's were awesome for getting great stuff outside of what you'd expect :)

[@Yuuretsu]

This is a fascinating read. I only understand part of it but it sounds like the Motorola 68000 would definitely be the fastest overall.

[@DutchRetroGuy]

@@Yuuretsu well, that's not always true either. I'd argue it's going to be faster in most cases, but comparing performance across CPU architectures is really tricky. There are cases in which the 6502/65816 will be faster. Just to give an example of that: CPU interrupts are way, way faster (clock for clock) on the 6502 and 65816 than they are on the 68000. So if your code needs a lot of them, those CPU's will perform better - given similar enough clockspeeds. Similarly, 8 bit operations are much closer in speed, with a number of them faster on the 6502/65816 than the 68000. On the other hand, if you want to copy some memory from one place to another, the 68000 is faster than either of the 6502/65816. And you can keep making specific examples for all kinds of this, which is what makes it hard to be exact :)

[@dm8dd]

30 years later pc engine proving it's still a pocket sized rocket

[@Elgo2024]

They didn't call it the Turbo GrafX 16 for nothing.

[@etank222]

This does line up with something the legendary shooting game programmer Yuichi "Healthy" Toyama once said about his experience working on the PC Engine (Seirei Senshi Spriggan, specifically) after having just come from working on the Mega Drive: Compared with the Megadrive, the PC Engine has a larger color palette, but you’re limited to one background layer. So at first I thought “This is going to be sad!”, but once we started developing for it and I saw the faster CPU speed and the CD-ROM that allowed full voice-acting, I realized we could make something great! I soon became an ardent fan of the PC Engine.

[@Ehal256]

The code here on the megadrive is far from ideal. It could easily be nearly twice as fast :)

[@apollosungod2819]

etank 2 the idea is that back then the very skilled game dev teams would develop full assembler development tools to fully utilize the hardware they were using especially if they were making a hardware exclusive game as in the case of the NEC PC-Engine and Super CD-ROM2 system mainly due to the install base being able to SUPPORT this. Further, the NEC PC-Engine got an additional boost with the Arcade Card Pro or Arcade Card Duo, essentially adding MORE work ram for the Super CD-ROM2 storage medium so any so called fan developer should make specific games that require and only use the Arcade Card Pro/Duo Super CD-ROM2 mostly due to the expanded work ram which allows the 8 bit CPU to truly flex it's capabilities beyond those that were once believed... this is why in Japan the Arcade Card Pro/Duo was FULLY supported... the install base was there however new videogame systems and new 32bit games may have taken all the cover stories which could cause confusion when as a gamer you (assuming you lived in Japan) would pick up a gamer magazine and see all the new games being talked about. The Super FamiCom still has a very powerful 16bit CPU but technically the hardware still needed an average of two years to develop an original game from scratch... and when you have so many new hardware being released, it can really derail things even for Nintendo which did not manage to expand the Super FamiCom like they were able to do with the 1983 FamiCom... Meanwhile the Sega MegaDrive again has a very powerful 16bit CPU so ideally game devs should learn that CPU and code for it natively as well as the VDP and sound chipset system... however a major problem since around 1992 was that Sega of America's 90s staff was deliberately rejecting many Japanese games from being translated to English because they were more interested in hoarding all the profits from their shitty games and contract games that were much lower quality and sloppy coded efforts... which was just a disaster... further it was 90s Sega of America staff that pushed for the creation of the 32X and the idea that Sega MegaDrive devs needed to waste their time programming on additional CPUs like SH2s instead of learning how to code for those CPUs on the full next generation hardware in the Sega Saturn which immediately got affected because during 1994 and 1995 you had Sega of America basically requesting and sending programmers to make games for 32X which ended up tanking, NOT SELLING at retail... contrary to popular belief by fanboys, that hardware and games was sitting in stores with angry retailers which was the source of said retailers later refusing to carry the Sega Saturn... and further those games became total losses since there was no profitable 32X install base and nor were gamers stupid enough back then to fall for that trap... This is why later when again Sega of America's 90s staff refused to support the 1MB and 4MB RAM Cartridges for expanding the work ram in the Sega Saturn that in Japan they made the decision to not require it in FEAR of the games not being localized for North America which was were the U.S. subsidiary branch was playing gate keeper while Bernie Stolar was pushing his own agenda which consisted of forcing the Sega Saturn to be killed off by not supporting it... and why the Japanese headquarters should never have hired that guy and should have fired Tom Kalinske years earlier.

[@iwanttocomplain]

@@apollosungod2819 I’ve not heard that SoA were distributing profits from the US branch around themselves or that Sega decided that was a good idea, as an incentive I suppose. Then SoA blocked Japanese games because that would mean less competition for their own dreadful games. Also about not supporting the ram expansion carts. The 32X was a good idea though I don’t like the look of it. The only problem was that it was designed, built, shipped and marketed then declared to be discontinued all at the same time. If it was kept on the market it would have seen games and success. It was also a chance for developers to learn SH-2 cpu programming. I think a Genesis on steroids is a great idea.

[@demonology2629]

I'd like to see more of these types of videos in the future thank you

[@hagopds]

Thank you very much, I'm hoping to have a new one ready soon.

[@CharlesHepburn2]

For the Turbo to have suceeded in the US, they should have #1) Brought over from Japan more awesome games... their was a ton of great games in Japan. #2) Had 2 controller ports on the system itself and include composite out on the base console itself. Buying a TurboTap and TurboBooster for those functions made them look like they were nickle and dime-ing the consumer. #3) Hardware spec wise... it would have been nice to have 2 background layers and way more RAM (like the SuperGraphx). #4) Make their system and games slightly cheaper than Sega and Nintendo... maybe intro price of $149 for the console and the top end games max at $39. #5) Skip the CD add-on device and bring out the TurboDuo earlier with the Arcade Card built in... so have a low end inexpensive console and a more expensive TurboDuo (maybe at $249 at launch). With all that being said, the most important thing was the games... that's really what matters.

[@jodafro619]

they couldn't get many games due to nintendo's monopoly on the third party developers at the time. even sega master system fell due to that and both were way better than the nes spec wise

[@jasonblalock4429]

The problem with the TG-16 in the US is, imo, much more basic: It was a 1987 console being sold in 1989. When the PC Engine first released in Japan, it was a truly great system. If Hudson had quickly exported it, the TG-16 probably would have done much better. Instead, they delayed two years, until after the Mega Drive was already out. The TG-16 came out almost simultaneously with the Genesis in the US, leading to a head-to-head battle it wasn't capable of winning.

[@jodafro619]

It seems a lot of people are still ignoring the elephant in the room that is named Nintendo...

[@CharlesHepburn2]

@@jodafro619 it wasn’t an elephant in Japan… PC Engine took over quite a bit there. NEC could have been 2nd in USA though.

[@jodafro619]

@@CharlesHepburn2 i was talking about in the united states. nintendo had a giant hold on the thrid parties that aided in killing the tg 16 as well as the sms desite both being technically superior than the nes.

[@DevMeloy]

I owned a TG-16 back in the day and love it as a console.. the only negative was the fact that support dropped off pretty quick and a lack to AAA games. The good thing was having original games that none of my friends had.. oddly enough TV Sports Football was amazing, throwing the ball was way better than anything else! And battle royal wrestling always brought a smile to my face!

[@hagopds]

Nice! The TG16 had many great exclusives and the 5-player option was awesome. As you may know, the Turbo (PC Engine) was very popular in Japan and the best selling console before the release of the SNES. There were many excellent Japanese Turbo titles we didn't see in North America which was unfortunate. The TG16 could have been a huge success if its launch and marketing was better handled.

[@jeffdavis6657]

I had a TG16CD too. I was not a fan of the TV Sports games, though I did like the hockey one. I did manage to enter the cheat "The Cooker" before my brother noticed. I beat him bad. I think the score was 128 - 14

[@TheInsaneShecklador]

I never had TV Sports Football but Battle Royale was a lot of fun.

[@TurboXray]

Again, you get specs wrong. The PCE/TG address bus is 21bit, not 16bit. The "logical address range" is 16bit, not the bus. The SNES process isn't going to run at full 3.58mhz (fastrom) because "workram" is running at 2.68mhz.. and the 65x design leans heavily on ram (instead of registers like the 68k design).

[@ailaxl]

I think your understanding of the SNES is a little off. It had an extra 8-bit bus compared to the Genesis/MD, not that it switched between 8 up to 24. The SNES CPU also, despite obviously being slower, could still render more on screen at once as the efficacy of it's otherwise lackluster CPU could output 1.5 MIPS compared to the Genesis's 1.4 MIPS. Genesis could more easily scroll however - one of the benefits of having a higher clock speed (which they marketed as "blast processing" which isn't actually a thing) which is why faster games on the SNES usually experienced slowdown aside from, somehow, a few notable exceptions where the SNES developers must've implemented some form of witchcraft.

[@miriamalmeida6687]

Snes best ❤

[@SaadAzim]

Interesting video. I'd like to point out, the TurboGrafx-16 & SNES CPUs would probably benefit from using zero page addressing. The first 100 bytes of RAM can be accessed using an 8 bit address, something along the line of "lda $00". (Though the exact code depends on the assembler.)

[@mercster]

Cool test... however, I would also like to see a test that hits more of the subsystems. For instance, a few memory/bus intensive operations, and some simple graphic-manipulation things. Some using sprites, some drawing primitives. You may have done something similar to this, I will check. Anyway if not, maybe an idea for the future.

[@hagopds]

Thank you and very good suggestions. I agree that testing video and memory operations would be interesting and something I am considering for an upcoming clip.

[@meatballmeatwad5730]

Very informative video. Wow the Turbo graphix 16/PC Engine CPU exceeded my expectations. It's about time someone talked about the specs of the turbo graphix 16 and compared them to the genesis and snes. I could find very little info online. Can you make more videos comparing all of the specs of the 3 consoles to determine which is truly the most powerful of the three? From what I've seen, I would say the genesis.

[@hagopds]

Thank you very much. That's a great suggestion to compare each systems overall capabilities, including graphics and audio. I'll start looking into it :-) You're probably right about the Genesis performing best, although the results may surprise us once again.

[@youtubeshadowbannedmylasta2629]

haha no genesis wasn't, the only thing it had going for it was the cpu.

[@MrLtia1234]

The 68k is very CISC, is the thing - whilst the 6280A (basically a monster 6502) isn't RISC, compared to a generation later ('16 bit') it's much simpler. That's surely the reason for the speed.

[@ostiariusalpha]

Probably doesn't hurt that 8-bit operations are very efficient at simple tasks, such as shown here.

[@alaggan]

The SNES also had a maths co-processor residing in the graphics ship to help speed up certain calculations, though as to how much it actually boosted performance, I'm not sure.

[@spencerstevens2175]

At the end of the day you dont sell consoles with tech specs and wizardry. You sell them with marketing and good software.

[@Elgo2024]

Which all 3 had.

[@KingsRight]

i always liked turbo most. i loved the size of those games.. hu cards. i beats the others in colors too. 512.

[@TheInsaneShecklador]

I remember opening up some of the cartridge games back then and finding them to be mostly air with circuitry no bigger than the TG16's HuCards. Same with the consoles. Lots of empty space inside. I always wondered why my TG16 was so much larger than the PC engine or the Turbo Express for that matter. I guess most Americans were not ready for tiny consoles or compact HuCards.

[@danboid]

I shared this on the Uzebox forums and Uze did a similar test on the Uzebox. I don't think I can post the link here as YT keeps deleting my posts but the Uzebox is a bit faster than the SNES but not quite as fast as the Megadrive, when video output is enabled using this test. Not bad for an 8 bit console!

[@Granite165]

As someone who grew up with a TG16, thank you for giving me this. Now I can put my backwards baseball cap on, skateboard down the road and shove this in the face of every SNES owner I ever knew. (had no idea there was that much of a spec difference between the TG16 and the others though, wow!)

[@jc_dogen]

@@inceptional pc engine does 3.3 million mips. snes btfo

[@lucianoclaudio2335]

If only the geniuses at Treasure got their hands on the PC- Engine/TG16. They know how to squeeze a system and get the best out of it.

[@AngryCalvin]

I wish Konami did more for the system. The games they did make for it were wild. Konami was also the one who put out the mini consoles in recent years.

[@markmeadows7093]

Nintendo had a chip that could do two things per clock cycle.

[@tymepilot8471]

OMG Thank you

[@hagopds]

I appreciate it, thank you.

[@andydepressivum8808]

love you channel

[@ClevertonHeusner]

Interesting benchmark.

[@brunomass]

I may be wrong but the 68000 and the snes processor are moving 16 bits in their workload, whereas the tg16 processor is moving only 8 bits. So technically snes and genesis are doing double the processing.

[@MilkoSinani]

Wow… great job

[@smokeydops]

This test is highly, highly flawed and given the wide gap in instruction set between the M68K and the other chips it really isn't comparing apples to apples but even if you were doing apples to apples (which of course these *are* both CPUs), you **need** to use real hardware for these tests. You cannot use emulators, they are untrustworthy for performance, even if multiple emulators agree.

[@Sakanakao]

Your Genesis code isn't writing the result to RAM, but your PCe/SNES code is, making the operation an unfair comparison. If the result was valid in d0 then it's equally valid in the A register on the other two. There should be another move to RAM in the inner loop of the Genesis one.

[@erockbrox8484]

Please do it again with the SA-1 chip for the SNES. The SA-1 chip is like 12 mhz, which should make it the fastest.

[@104d_3rr0r_vince]

I don't think that snes is a real 16bit machine. The cpu has an 8bit databus. It's like calling 68000 32bit because he is internally 32bit. Nice video.

[@104d_3rr0r_vince]

@@inceptional What numbers? I was specific about the CPU bits. Correct if I'm wrong.

[@johnrickard8512]

They don't call it "Turbo" for nuthin!

[@CB3ROB-CyberBunker]

ofcourse a 6502 based system at the same clockrate as 'pretty much most everything else out there' outperforms any other cpu core on i/o throughput per cycle operations... even if you forgot to clear or set decimal mode and the carry flag before using adc :P (not sure if the snes has it. the nes doesn't. but set or clear it anyway as 6502's power up with most flags undefined) and didn't use zero page addressing. LDA #$01 outside of the loop, STA $04 (zeropage) to set it $04 to 1 again, INC $04 (3 cyles, unlike immediate ADC's 2 cycles, but no STA needed) to add one probably is faster. plus without a CLC anywhere you're not sure if you're adding 1 or 2 on the first iteration. adc... add with carry. it doesn't only set or clear the carry. it also adds the carry if it's set.

[@rubendarioreymartinez2073]

Increíble vídeo 🎉, el cpu del pc engine es más rápido y eficiente que el cpu del mega drive , saludos desde colombia 🇨🇴

[@vitorpassos6420]

You used a SlowROM on the Super Nintendo, using FastROM the speed is 28 seconds.

[@hagopds]

Thank you, that's a great suggestion. My understanding is that SlowROM and FastROM only affect the speed of reading ROM. It will be interesting to try, although it may not affect the performance in this case as there are no ROM read operations in the code.

[@aaendi6661]

@@hagopds It reads from ROM every time it reads an instruction.

[@hagopds]

@@aaendi6661 I see what you mean. I think Slow/FastROM only affects cartridge ROM access, which this test algorithm does not have. Just for fun, I repeated the SNES test using FastROM and the results are the same (almost 37 seconds). Memory was expensive during the SNES's lifetime and SlowROM gave developers the option to use cheaper, albeit slower ROM chips. Thank you very much for the interesting discussion.

[@aaendi6661]

@@hagopds Did you jump to banks $80-$ff? FastRom only works in those banks.

[@hagopds]

@@aaendi6661 That's correct, I set the initialization header to FastROM and a long jump to bank $81.

[@amd8809]

From what I've seen the snes was last in his test 23 seconds vs 36 seconds. Despite being behind, it even showed better efficiency, because if the MEGA has 100% more performance or twice the Clock, it could even give twice as much. Example 23 seconds and the SNES 46 seconds - which shows an efficiency of up to 50% on the snes or an average of 20% to 30% more efficient than the mega processor. We can say that the snes processor is 30% faster, but in general the Mega was 50% faster. But also usually the Mega is 3 times faster that in games Fact , but we found that you can still get almost twice the performance of a snes still. This is squeezed to the last drop as the benchmark does. Surprising is that the PC engine has won and even with a good margin from the mega 17 seconds vs 23 seconds which gives 20% which matches the average performance of the snes which was between 20% to 30% over the mega. Since both PC Engine and Snes architecture are from the same family. But of course this test didn't use the Processors to the Max giving only instructions that BOTH or ALL had. If not MEGA would win and snes instead of having 50% more performance would have been on average 20% I think a test using everything would look something like this. 1-Mega = 21 Seconds 2-PC Engine = 23 Seconds 3-SNES = 29-31 Seconds But as he said it's a synthetic test

[@dallacosta2868]

Cope.

[@lw7918]

@@dallacosta2868 fart sounds.

[@Sinn0100]

Why didn't you include the Sega Genesis's co-processor the Zilog Z-80 in this comparison? It can and was used to help the Genesis produce games.

[@daedalus547]

For the same reason he didn't include the SA-1, CX4 or FX chips for the SNES. All of these are "Co-processors"

[@orlandoturbo6431]

The United States should have the TurboGrafx 16 with the Supergrafx parts inside. NEC and Hudson Soft should have brought their AAA titles over and they should have made better fighting games and sports games for North America market. How in the world was the PC Engine popular than the Mega Drive anyway Mega Drive had better games. Compare the PC Engine games to the Mega Drive games and you can see what system has the better games.I would like to know what do the Japanese people think about the Mega Drive.

[@j-morecoffeepls]

‘Should have’

[@iwanttocomplain]

It’s surprising just how many games were exclusive for the Japanese Mega Drive... but then 3.5mill is still a reasonable install base. But then, the population is a wealthy 125mill. The Famicom selling 17mill is impressive and suggestive of a craze. The PC Engine (all versions) moved 10.8mill, for reference. UK bought 4mill Mega Drives with half the population (60mill) which outsold the SNES around 2:1. The Amiga sold 1.5mill and the SNES 1.7mill. I think, to the Japanese, the PC Engine was the shoot-em-up machine and the SNES was for jrpg’s.

[@sunnohh]

They did bring most of their “AAA” games, they just marketed like shit

[@orlandoturbo6431]

@@sunnohh I think they should have release familiar games for the TurboGrafx16. Every console had Mortal Kombat and Earthworm Jim but not TurboGrafx16. Even Tiger Electronics had Mortal Kombat and Sonic the Hedgehog handheld.

[@frun]

I can guess Sega is far superior due to the 16bit data bus versus 8bit, considering only the specs shown.

[@cliffchampion5501]

But the games it produced often looked less impressive then Super Nintendo

[@juniornintendo]

Snes the best console .

[@nitrofurano_]

turbografx has a 8bit cpu based on 6502, its not 16bit (even considering it runs at 8ghz)

[@RedRanger2001]

TurboGrafx 16 is 8-bit.

[@MrDarchangelomni]

Ok your results are artificial and misleading, the single most important factor when determining the general speed of a processor IS NOT its clock speed, but rather its intsructions per clock cycle rate... All of the cpus mentioned have real word actual benchmarks, that can not be duplicated by any current emulator. Genesis did not have 32 bit registers, it could execute 32 bit instructions by multiplexing two individual 16 bit registers into one output, however this took twice as long as executing a 16 bit instruction. The 68000 was designed like the 80286 and early 80386 SX to solve a unique problem, giving access to 16 mb of memory while maintaining backward compatibility with the 16 bit data bus found in all the motherboards/backplanes at the time of its creation, It was designed to be a swiss army knife to be generally useful for alot of applications but specialize in none. The 6502 was a stripped down version of the 6800, both were worked on by the same designer, his goal was to take away all the extra features and make a highly efficient, high op per cycle memory access calculation monsteer, and he succeeded the 68k does about .18 operations per clock for a total of about 1.4 mips and the 6502 does about .4 operations per clock for a total of about 1.5 mips, The modified 65816 in the SNES had a variable clock from about 1.5 to 3.5 mhz, and generally operated from 1.5 - 1.7 mips notice that in real life mips, does not increase proportionally with clock due to circuit timings. Fact is , and its been done, on real hardware, Computing a fractal on screen, using a 240p resolution, the TurboGrafyx is the fastest, but The Snes is only microseconds slower thanks to coprocessors, and The SNES can rotate the entire screen real time while calculating the fractal and display it in 32000 colors, using scanline interupts... something either of the other systems couldn't even do with all of their add-ons. So when talking pure Mips yes the TG16 is King and it also had the Highest Resolution possibilities, but for something that comes in just .2 mips slower on average, you can get true matrix transformations, 32000 colors, and real signal processing in the SNES... In my opinion SEGA made an architecture mistake, that not only led to it being the slowest, with the least amount of color and the poorest possible sound from Yamaha/Texas instruments combination FM Synth... SEGA could have made a few architecture changes and been the best gaming console until The Playstation if They would have kept the Z80 as the main CPU / Used The VDP for Tile based graphics, on a 16 bit data bus to a framebuffer, then backended that framebuffer to the 68k on a seperate bus, ran the memory at 14 mhz, so the z80/vdp and 68k could essentially use it at the same time, and dedicated the 68k to special effects more color depth and signal processing the sound... I have gave it alot of thought and every way I look at it making the 68k the main cpu sacrificed 1.5 mips of available processing power in the hardware they already sold you. Its a shame really, I woulld have loved to see it, and we as consumers as well as SEGA would have benefited by Nintendo not owning the market all those years. BENCHMARKS ON REAL CHIPS: en.wikipedia.org/wiki/Instructions_per_second

[@hicknopunk]

Isn't the pc-engine 8 bit, the snes cpu has some 24 bit bus...the genesis isn't exactly 16 bit either

[@javiiermendes]

32 years latter the NEC internal benchmark that put the Hu6280 to 1.5 MIPS VS Genesis .75 MIPS. Steel today peoples don't see that all this is part of the commercial campaign . Put 128 bits CPU on Genesis don't do better graphics or better games necessarily. Now it's to late, it's done any one of them never ever will return with a new console. But wait, you can play the best of both system and enjoy the games for the very first time without the prejudices of which one has the fasted CPU because are pointless in this era.

[@SONIC19888]

How much did they pay you to defend the Sega Genesis?

[@cliffchampion5501]

I still don’t get why the games produced on Genesis often looked less impressive then Super Nintendo and sounded less impressive.

[@fringeelements]

Didn't have ADPCM sound but FM synth. Also, early in the Genesis' lift, SEGA I think released the GEMS sound font as a kind of "starter driver" for developers early on. It ended up being used by way too many developers instead of developing their own sound drivers. That said, the SNES was always going to sound better anyway just because it had ADPCM sound samples. The GEMS driver which ranged from tinny screeches to fart synth was more a product of lazy devs than anything wrong with the Yamaha FM synth chip they used. Even Sega of America used GEMS in Sonic Spinball. SNES games would generally look better just because they had more colors, and any pseudo-3D games would look better since the SNES could rotate an entire plane (F-Zero), while the Genesis had line-scrolling offsets which could "rotate" (as far at the player is concerned) background objects but only to a limited amount until they were too distorted. See the Sega Genesis batman game for lots of examples of the closest thing the Genesis has to SNES' "mode 7". Transparency is a non-factor for the time, since dithering worked well on CRTs due to color-blending, and really wasn't mentioned at the time. SNES hardware transparency is something really only brought up in modern times with people looking at the games on modern LCD monitors. I'd recommend a program called "shader glass" and using the preset crt-matthias for the closest approximation for how games looked with a crt at the time. Much of it is down to devs though and how their games looked. Look up "Megaman X Genesis" to get an idea of what the SNES and Genesis look like when making the same game with nearly the same basic graphical assets. That said, the genesis was generally a better pure sprite-pusher and could handle more sprites and objects moving around and animating than the SNES. The 128 on-screen sprite limit for the SNES vs. 80 for the genesis was technically true, but the Genesis could generally handle "more going on", and this was a result of just having a better CPU in practice by devs who actually knew how to use the 68000, contra synthetic tests which the 68k performs poorly on. Compare the Genesis vs. SNES versions of Samurai showdown for the clearest difference. IMO the SNES version of Samurai Showdown still looks better overall, but you can see the Genesis used more sprites for the characters. This was really the only thing the genesis had going for it, so marketing pushed it hard as "blast processing". The genesis also apparently had faster DMA, but this was practically irrelevant since loading times for cart games wasn't really a thing. But 90% of the time you don't have enough onscreen that would slow down either the SNES or the Genesis. Nintendo also put enhancement chips in carts later on, while Sega went for add-ons. Yoshi's Island and Super Mario RPG used add-on chips, and if buyers didn't know this, they might presume those games could be done natively on the SNES.

[@Vegeta-79]

First of all,what determines if a console is 8 or 16 bit is its CPU so the tg16 it can't be considered a 16 bit . It can be considered an hibrid console,not a true 16 bit. Put this on your heads,tg16 is inferior in almost specifications if compared with the other two

[@Elgo2024]

Thats why the PCE/TG16 could not only display 4 times the number of colors as the SG/MD but larger and more sprites with less slowdown.

[@Vegeta-79]

@@Elgo2024 and the Mega Drive with 3 times more parallax,more special effects,more sound channels,more and bigger sprites,better animation... The Mega Drive only loses in colour. In other departments it completely obliterates tg-16.

[@TurboXray]

Your 68k code isn't even equivalent to the 6280 or 65816 - why are you writing to ram on those examples and not the 68k one? I mean, it's not like this represents anything other than some arbitrary limitations (which are 8bit biased or is that just a coincidence?) and not actual performance, but at least make them equivalent.

[@cristianramallo8042]

oro en polvo

[@DukenukemX]

You're benchmarking emulators, not the actual hardware.

[@HauntingTheHoly]

Monotone, BORING, terrible. Made it seconds.

[@miriamalmeida6687]

Snes the best console

[@the_real_MarcGyver]

1sts gen sega console with volume slider and headphone jack with a built-in yamaha soundchip, we all knew as kids it was the best system & we know it now as adults. suck it, nintenerds.

[@Vegeta-79]

That's the one i still have❤️

[@davidaitken8503]

Sorry, buddy. The truth is the main CPU wasn't really the deciding factor on any of these old systems. It was all about the built in graphics functions. That is what allowed all of them to display lots of sprites and tiles at 60 hz with silky smooth scrolling. Something PC's of the time with hundreds of times more power couldn't pull off. The SNES was king in terms of advanced graphics functions and it, along with the Turbo Grafx 16 could display far more impressive visuals than the Genesis. You don't need a spread sheet to see that. Just play some of the games.

[@Vegeta-79]

@@davidaitken8503 The Snes could pull off advanced grafics that neither Megadrive and turbo grafx 16 couldn't,at least natively, like mode 7 ,zoom/scaling and rotation,much more colours on the screen. On the other hand,the turbo grafx 16 could display more colours than the Genesis/Mega Drive and that's only that,because Mega Drive VDP or it's grafics processor was much more powerful that the tg16 in every aspect like, parallax scrolling,resolution,number of sprites,and every other specifications,not to mention it's CPU Motorola 68000 which was more powerful than either SNES and tg16. I'm sorry but this video is wrong and misleading. Sooo wrong... Even the tg16 sound chip is worse than the other two. Can you imagine it playing soundtracks like Streets of Rage 2 or Donkey Kong Country? I thought so

[@davidaitken8503]

@@Vegeta-79 I can't imagine either the TG16 or the Genesis doing the music to DK Country. As I said, the power and capabilities of these 3 game systems had almost everything to do with their built in graphics (and audio) functions and the SNES was the winner in that regard by a significant degree. It was more capable then the Neo Geo. The reason why the Neo Geo had such expensive games is the data on the cartridges was uncompressed, allowing them to use the cartridge as one big cache. As far as Turbo Grafx 16, the larger sprites and color palette could make some types of games look more impressive than Genesis games while showing serious shortcomings in others.

[@Vegeta-79]

@@davidaitken8503 i'm a lucky man because i have a Mega Drive 1 and a Super Nintendo,both originals. But i woudn't mind having a turbo grafx 16 foi,original of course but i find it much more dificult to find here in Portugal. It would be amazing

[@TechRyze]

Using emulators 😒

[@gusposey8218]

Two Words: Blast Processing Case closed.