SNES vs Genesis

[tokumaru]

Sega Genesis (the name is appropriate as it was very popular in North America where it went by that name)

If you're picking a name based on popularity, maybe you should consider that everywhere else in the world it was called "Mega Drive", it was only called "Genesis" in North America. The SNES on the other hand, was only "Super Famicom" in Japan (maybe other parts of Asia as well?). So there are probably more people in the world who had a Mega Drive and/or a SNES than people who had a Genesis and/or a Super Famicom.

[TmEE]

Only thing I can think of why MD does not have palettes separated on different layers is that they ran out of silicon real-estate. That remains to be seen until someone decaps the VDP and takes a look.
Some arcade boards do use the MD VDP, but with external RAMDAC and utilizing the digital color bus of the VDP to do 8 palettes (4x BG, 4x sprites).

As for CPU, 68K jumps far ahead when you do 16 and 32bit operations on it. 32bit ops take very few extra cycles but process lot of data. The CPUs are wildly different though, but the way I see it many tasks that take couple of instructions on 68K need 2...3x more code on the 65x type CPUs, in the end things even out. One is faster on some stuff, other does other things better.

[3gengames]

I found this forum post with code that says different, the 68K is much less efficient at some math math than the 65c816. And the 8-bit registers on the 65c816 don't help it's cause as 8-bit on 68K is non-existent.

http://www.assemblergames.com/forums/ar ... 21947.html

http://pastebin.com/f76e312e0

[tepples]

http://pastebin.com/f76e312e0

68000: 146 cycles
65816: 63 cycles
After compensating for the faster clock speed of the 68000 (15:7 ratio), the 65816 version is only 8% faster.

[TrekkiesUnite118]

I found this forum post with code that says different, the 68K is much less efficient at some math math than the 65c816. And the 8-bit registers on the 65c816 don't help it's cause as 8-bit on 68K is non-existent.

http://www.assemblergames.com/forums/ar ... 21947.html

http://pastebin.com/f76e312e0

You're going to just keep posting that over and over again aren't you? As I said over at NintendoAge, that example is only for pure CPU to CPU without the rest of the system and assumes they are both at the same clock rate. It doesn't take into consideration the large difference in clock rates between the systems nor does it take into consideration system bottlenecks. Best case scenario that bit of code will execute faster on the SNES. That's assuming it's well optimized and completely ignores the case of RAM access which has to be done at a slower clock rate of 2.68MHz. In the worst case scenario with the CPU running at 2.68MHz due to slower ROM (Which was common on the SNES), that bit of code executes slower on the SNES.

The same person who wrote that bit of code in that Assembler thread had this to say recently over at Sega-16:

The SNES is slower than the 68k in the Genesis; that's well known. But it's not slower by 50%. The real speed of the SNES cpu floats around ~3mhz (in fast mode. slow mode is strictly 2.68mhz) because of how the 65x architecture puts all the addressing vectors and data registers in zero page (or direct page as term is used on the '816). Instructions are made up of cycles and each cycle that touches main ram (work ram) is wait-stated down to 2.68mhz (rom fetch cycles are 3.58mhz if the rom is fast-rom). And even with the crippling 8bit data bus for the '816, the core of the processor is based on the 65x series which was very fast for instruction cycle times and the expansion to 16bit regs and math really give it a boost (not to mention some nice new instructions). From my tests, I'd put the performance around 70% of the MD CPU (disregarding a few advantages each processor has over the other in some cases).

He later went on to say that the 70% figure is only if your code is insanely well optimized on the SNES side.

[3gengames]

Warning: This guy is a disgruntled Sega biased fan. I'd not listen to him, as he's a person who spits numbers but yet seems to have never written any program in his life, so I doubt he can provide anything to this thread.

But yeah, 8% faster. The main key that I was going for is it's a piece of 16-bit math code for something we'd even use in a real game...and it performs on par. But whatever, I tried to make this so it'd have unbiased information but that's now gone through the window.

And he's also in this threa. But still, for the 65816 to have 70% of the performance with so few registers and needing to do many more memory accesses in some cases, it makes sense. But still, you're acting as if the 65816 gets about 50% or worse with how you word everything. Please, for the sake of keeping it interesting and not full of shit, can you not post again, Trekkie Kid?

[TrekkiesUnite118]

Warning: This guy is a disgruntled Sega biased fan. I'd not listen to him, as he's a person who spits numbers but yet seems to have never written any program in his life, so I doubt he can provide anything to this thread.

But yeah, 8% faster. The main key that I was going for is it's a piece of 16-bit math code for something we'd even use in a real game...and it performs on par. But whatever, I tried to make this so it'd have unbiased information but that's now gone through the window.

And he's also in this threa. But still, for the 65816 to have 70% of the performance with so few registers and needing to do many more memory accesses in some cases, it makes sense. But still, you're acting as if the 65816 gets about 50% or worse with how you word everything. Please, for the sake of keeping it interesting and not full of shit, can you not post again, Trekkie Kid?

I never said it was 50% worse, I said it was slower. And it's not just the CPU that causes problems, it's other bottlenecks in the System.

I'm not really biased towards Sega or it's systems. I like Nintendo's systems as well. However it seems there's a certain group of people who love to bash Sega's systems unfairly. When the argument pops up, I tend to defend the Genesis as it seems to get unfairly bashed. My criticizing your argument isn't keeping this thread from being interesting at all.

As for not programming, I actually do quite a bit of programming. It's just not in Assembly. I'd love to learn Assembly at some point, it's just finding the time to do it.

[3gengames]

If you don't know assembly, then why are you so vocal on something you don't have any clue how it works? Yeah, I think that says enough...as for being unfairly bashed, maybe learn a thing or two and come back and then scream how wrong we, programmers who work in assembly, are. I've worked with both architectures, 68 and 65 series, so I can assure you...you're not qualified to have an opinion as it's more than simple stuff that you're thinking of that's different, sorry...but it's the truth.

[TrekkiesUnite118]

If you don't know assembly, then why are you so vocal on something you don't have any clue how it works? Yeah, I think that says enough...as for being unfairly bashed, maybe learn a thing or two and come back. I've worked with both architectures, 68 and the 65 series, so I can assure you...you're not qualified to even peep on this stuff.

For Assembly I'm not qualified to go into much detail. However it doesn't mean I can't read or pay attention to what's stated in these discussions when they come up and point out areas where things don't add up. I didn't say unfair bashing was going on here, you were however doing that in the Nintendo Age thread. And if you truly didn't want me to see this thread, why on earth did you link me to it?

You don't have to be a master of assembly however to figure out how long it takes for a clock cycle to happen on a CPU when you know the clock rate. Nor does not knowing assembly prevent you from figuring out from that information how fast a block of code will execute when you know how many clock cycles it will take.

This thread is called SNES vs Genesis. But all you seem to be doing here is 68000 vs 65816 while ignoring every other aspect of the systems.

[3gengames]

There's lots of tricks you only learn by using assembly instead of just looking at the tech sheet.

And I linked it to show you the responses from people who actually know something, it wasn't so you could post in it. Thanks for ruining the whole purposed now, though. Although I'd still like to discuss this with the normals members. Not people with their Genesis shirts inside out trying to talk about another system. I mean, you are from Sega-16 and only joined NA AND here to get in your toots about how much the SNES was crushed by the genesis. But whatever, say whatever you want, this thread is dead to me now since you're here raining on the parade of being realistic with everything.

[tepples]

The closest thing to mode 7 on the Genesis is offset per column-pair and offset per scanline. It's enough to make the floor rock, but it can't rotate by more than about 1/8 radian (7 degrees) without noticeable artifacts. Without mode 7, how do racing games work on the Genesis? Is it the same principle as Pole Position and Rad Racer? Or would one need the Sega CD accessory to make Cameltry/On the Ball?

[3gengames]

Dunno, but this software implementation of a psuedo mode 7 is pretty well done, and probably written in C. Although I bet some inline assembly loops were included, too.

http://www.youtube.com/watch?v=wG4V_kLL0NI

ETA: Most games seem to use a just rad racer/screen update thingy, as the backgrounds framerates are pretty bad. But honestly I've always liked Genny for racing games as Mode 7 is just too bland after a while.

[TrekkiesUnite118]

The closest thing to mode 7 on the Genesis is offset per column-pair and offset per scanline. It's enough to make the floor rock, but it can't rotate by more than about 1/8 radian (7 degrees) without noticeable artifacts. Without mode 7, how do racing games work on the Genesis? Is it the same principle as Pole Position and Rad Racer? Or would one need the Sega CD accessory to make Cameltry/On the Ball?

Would the Special Stages in Sonic count?

Also there's some racing games on the Genesis that pull off decent polygon rendering such as Kawasaki Super Bike.

[tepples]

Special Stages in Sonic 1 have restricted geometry because of the overdraw limit. Make a straight wall of blocks like those and see what doesn't flicker. But the ones in Sonic 2 did impress me, in fact prefiguring Frequency and the multiplayer mode of Amplitude.

[TmEE]

Anything involving software rendering is going to be faster on MD. Bitplanes are not helping with it at all, DMA speed is higher in MD and you will not have problems when any access happens during active scan.
I have been playing Flashback on SNES past few days and the cutscenes really chug compared to MD version... frames often take half a second to render. That game does some really neat vectors/shapes/etc rendering in the cutscenes.