Decreased S-CPU Velocity: Real or Imagined?

[TOUKO]

Ok for axelay but the starfox demo is a different, what cost the most and *by far* in this case is the 3D math calculations and the 3D rendering. If you get the engine done then you can consider to make a game from it without much troubles. Any game logic will have an insignificant cost on the CPU compared to the 3D stuff.

Agreed, but is not a proof of anything, you can have the CPU ressource for your demo, but not enough for collisions, and all around .
Sorry but your arguments can be applied to GH demo, the difficult part is to have many sprites on screen with collisions without any slowdown, the rest is easy to do,in GH the sprites are simply clones, i think all move fit in VRAM because they are very limited,same for Ai and physic ,which are realy simplistic .

The MD version of the demo uses more complex compression methods. I used about 5/6 compression schemes for the tilemap and about 7 or 8 for the tile data

May be, but same final result,if you want impress, do the same just with 68k, and not 68k+z80 ..

[DoNotWant]

May be, but same final result,if you want impress, do the same just with 68k, and not 68k+z80 ..

Should the SNES demo be done without the SPC700?

[TOUKO]

Should the SNES demo be done without the SPC700?

It's different, i think most of the audio work in snes version is done by 65816, it stream audio directly to SPC .
But i don't know exactly what sort of technics (audio and tiles) psycopathicteen use ..
In Md case all audio was done by z80,let a big amount of 68k cycles free ..

i think we should stop derivating, this is not the good topic for CPU comparison

[Drew Sebastino]

Well, I originally typed out something much larger and "aggressive", but I've decided to play "nicer". Here we go...

Why do you need to be that aggressive ?

Do you see me starting arguments? That'd be like If I went to Sega16 just to say "The 68000 is trash, the 65816 is better because it can handle Space Megaforce."

their biased point of view.

...

You can definitely find particular situation where the 65816 will perform well (and why not even outperform the 68000) but generally the 68000 will be the clear winner and by a large margin.

Why do you find that the 68000 "is the clear winner", but nobody else else does? Is it because of their "biased point of view"? Anyway, psychopathicteen made a code that performed better on the 65816 and you don't like it because he "ported" it over to the 68000 and was faster on the 68516, so you make a code on the 68000 and "port" it over to the 65816 and it's faster on the 68000, to show that the 68000 is faster because it handled that code better, completely disregarding what psychopathicteen wrote. From what I got of the codes, the 65816 and the 68000 are better for different things, but you don't want a draw, you want to win. I understand that the Genesis's 68000 is still faster than the SNES's 65816 but not even relatively close to 4x. (Don't even pretend you didn't say that.)

Anyway, can we finally settle on a draw and not have another one of these issues?

[Stef]

Do you see me starting arguments? That'd be like If I went to Sega16 just to say "The 68000 is trash, the 65816 is better because it can handle Space Megaforce."

Did you noticed that i basically replied to psychopathicteen and argued about why his demo is not enough to say "we can port GH on the SNES" ? Of course you are more than welcome on Sega-16 and get some technicals talks, as soon your arguments are valid and you are not aggressive against others members.

Why do you find that the 68000 "is the clear winner", but nobody else else does? Is it because of their "biased point of view"?

Nobody else does ? Are you speaking about the general statement and the one we find here ?
I really wonder in which world you live... Did you have ever had a look on specialized hardware forum ?

Anyway, psychopathicteen made a code that performed better on the 65816 and you don't like it because he "ported" it over to the 68000 and was faster on the 68516, so you make a code on the 68000 and "port" it over to the 65816 and it's faster on the 68000, to show that the 68000 is faster because it handled that code better, completely disregarding what psychopathicteen wrote. From what I got of the codes, the 65816 and the 68000 are better for different things, but you don't want a draw, you want to win.

But you can take the code from psychopathicteen if you want, take the *best* code for your 65816 but then consider to take the best one for the 68000... then you can compare. And of course there is a win, again these CPU does not compete in the same category. Even clocked at 3Mhz (which is fast regarding the required memory speed) the MD 68000 has the edge by a large amount. You don't want to accept it but that is just simple truth. The only advantage of the 65xx serie CPU is the price, it's a really cheap CPU but then you have to pay it elsewhere, as the general very poor "efficiency".

I understand that the Genesis's 68000 is still faster than the SNES's 65816 but not even relatively close to 4x. (Don't even pretend you didn't say that.)

Oh yeah i said it, you better know than me are you Touko's cousin ?
I said the Genesis's 68000 is faster than SNES's 65816 and about twice as fast which is already a nice difference when you think the Genesis is 2 years older. A 6 Mhz 65816 should be on par with a 7.7 Mhz 68000 which is, actually, not a good score for the 65816.

[Khaz]

I have played with many CPU with different architecture in my programmer life and the first assembly i ever touched (maybe 20 years ago) was actually 6502 assembly (on a VIC20).

Then it sounds like you should have enough experience to know better than to try to pick this particular fight. The war between Genesis and SNES has been going on for decades now. Like any war that lasts decades, nobody has emerged a clear winner. There are no fanboys left - they have grown into fanmen.

The Sega Genesis was the first console I ever had. I loved it to death back then and I still do now. If you forced me to pick a side, I would be on YOUR SIDE. The reason I'm against you right now is because you're trying to make a ridiculous point. You're throwing around wild speculation that you believe GH can't be replicated, with nothing that specifically backs that point up.

When I say to "back it up", I mean with some serious analysis that warrants consideration. Something like "to reproduce GH you'd need these tile sizes in this video mode, you'd need this much time for sprite routines and this much time to process the AI and this much time for the rest, and due to the much faster way the Genesis does ____ there is no possible way the SNES can do the same job." That would warrant a response. Saying "This specific sample of code is slower on SNES" is totally meaningless, and you being a programmer yourself should know that.

Are you serious ? I just wanted to compare the CPU performance just to point out the problem with the 65xx architecture.

Uh, yes, I'm quite serious. DMA makes a huge difference to the speed of writing/copying blocks of data to either WRAM or VRAM. Since you were doing all your comparisons based on direct page instructions and not considering this advantage I don't think your assessment was fair.

And furthermore you missed my point entirely; the point was that pointing out subtle differences where the SNES doesn't come out on top is not proving ANYthing about what games can and can't run on it.

Oh really ? so please tell me how can you quantify it then ?

I DON'T.

I don't go around trying to say that Game X is too complicated for System Y because that would be a foolish thing to do - you can't prove it and you're just inviting people to prove you wrong. You talk exclusively about CPU power, which again you should know better than. The SNES is more than a 65816. The Genesis is more than a 68000.

Anyways, I don't see the point of this conversation here. I don't see why somebody would come into the SNES Development forums to try to convince people that the SNES is an inferior console. What is it you're trying to accomplish, Stef? Right now I only see two possible motivations: Either you're just the biggest GH fan on earth and you're trying to goad somebody into porting it for you, or you just hate the SNES and you're trying to distract us all from our work here.

Regardless, I think the best course of action would be to split this discussion out of this (extremely valuable!) thread. And I second my call for a dedicated "SNES VS GENESIS BLOODBATH" forum where we can just HAVE all these ridiculous discussions and keep them away from the actual work being done. I don't think it is possible to prevent people from debating it altogether.

I am sorry, again, for posting more.

[tepples]

You know, why don't we just do a topic split

PM me the split point and I'll handle it.

[psycopathicteen]

Okay I have a lot of posts to reply to.

The slowdown in Bad Apple is mostly the 65816 waiting for the SPC700 to respond to it.

Somebody said that I kept the frames in vram in GH. I could've did that because I only used 4 animation frames for enemies, but I used a dynamic animation engine instead because I anticipated eventually running out of vram.

[tepples]

The slowdown in Bad Apple is mostly the 65816 waiting for the SPC700 to respond to it.

That can be worked around by polling the SPC700 in other parts of your 65816 code, such as during tile decoding.

Anyway, I'll proceed to lighten the mood by missing the point:


To do GH, you'd need either Sega CD or MSU1 to stream large background and guitar parts. The Nintendo DS version is a 1 Gbit cartridge, and all other versions come on optical disc.


To do TF3, you'd need not only 3D acceleration but also a time machine. Valve can't count to three, and last time I checked, it was making enough money selling hats in TF2 that it doesn't need to make a TF3.

[93143]

It seems to me that using two HDMA channels, one indirect addressed to read from a buffer (or straight from ROM, if in repeat mode, though bank boundaries might be trouble) and one direct addressed to write the control byte, should save most of the time, as long as the SPC700 can keep up. That way you wouldn't need to repopulate a whole HDMA table every frame.

Did you uncover a reason not to use HDMA, or is it just not working yet?

[Stef]

Then it sounds like you should have enough experience to know better than to try to pick this particular fight. The war between Genesis and SNES has been going on for decades now. Like any war that lasts decades, nobody has emerged a clear winner. There are no fanboys left - they have grown into fanmen.

The Sega Genesis was the first console I ever had. I loved it to death back then and I still do now. If you forced me to pick a side, I would be on YOUR SIDE. The reason I'm against you right now is because you're trying to make a ridiculous point. You're throwing around wild speculation that you believe GH can't be replicated, with nothing that specifically backs that point up.

It's not even about SNES versus Genesis, i owned both consoles back in time and people who know me can confirm i always claimed i played more on my SNES than my MD and that my all time favorite game is Super Metroid. It's just about technical mis-information, i think there is nothing worst than that... Here what annoy me is that we can read the 65816 is a beast and even surpass the 68000 as it takes less cycles to execute comparable operations. I just want to explain why we should not compare on cycle and why the 65816 is definitely a poor choice as a main CPU (for whatever system actually, not only the SNES). I know the SNES has others flaws as the convoluted PPU with spitted OAM, sprites size restriction and memory arragement but all systems has its flaws (the Megadrive has only 4 palettes to play with and the sound system has some nice holes too) and honestly i think they can be worked out, at least partially. But here, in the SNES, the CPU is definitely and *by far* the main issue of the whole system. Honestly i tried to develop on SNES but the CPU is just so under powered you can't correctly use the offered graphics features. Accessing memory by bank of 32KB / 64 KB on a 16 bits system (released in 1990) is just ridiculous and painful for developers, it is as if i was coding on a 8 bits system with boosted graphics and audio hardware, totally unbalanced and very unpleasant. You can believe if you want that GH is possible on SNES, that is your right but the truth is that the CPU alone is a good reason to not see it happening. The guys from Treasures left Konami company because they wanted to have more freedom in their development but also because they felt limited by the SNES CPU, GH relies a lot on the power offered by the 68000 so definitely it would not work on SNES because of its *slow CPU*, that is...

If you are interested, here is an interview from the guys who actually worked on GH:
http://megadrive.me/2011/11/03/an-inter ... -treasure/

And a relevant part of it:

Q: Konami is a big 3rd party for Nintendo, so why are you now making games for Sega?
A: I’ve always been fascinated with hardware. People are constantly comparing Mega Drive to SNES, saying that the SNES has more colors etc…
But the Mega Drive has a 68000 processor, which is very easy for programmers to work with. I was a programmer for years, making games for the SNES, and I can tell you, the hardware is a pain in the butt. If consumers look at a still shot, they may think the SNES is better, but actually, if you tried to put Gunstar Heroes onto the SNES there would be no way. See those bosses? On the SNES they would slow down, that movement requries sooo much computation. It could only be done on the Sega hardware.
...
as I said the hardware is very easy to work with. All things considered, the 68000 is a very good CPU allowing room for experimentation while the SNES hardware limits you to their design standards. Scaling and rotation can be implemented in the Sega software, forget it on the SNES.

Then now free feel to ignore it... and continue to believe it can be done on the SNES.

When I say to "back it up", I mean with some serious analysis that warrants consideration. Something like "to reproduce GH you'd need these tile sizes in this video mode, you'd need this much time for sprite routines and this much time to process the AI and this much time for the rest, and due to the much faster way the Genesis does ____ there is no possible way the SNES can do the same job." That would warrant a response. Saying "This specific sample of code is slower on SNES" is totally meaningless, and you being a programmer yourself should know that.

Any program is just about dealing with data: read data, interpret it, transform it, modify it...
So taking the performance of extra basic operation as read and copy data is already a good start point to evaluate what you can achieve with the CPU. Of course that's not enough, i just say it's a good start point.
If you want more advanced maths to compare these CPU then we can go in it but trust me you won't like the result.

Uh, yes, I'm quite serious. DMA makes a huge difference to the speed of writing/copying blocks of data to either WRAM or VRAM. Since you were doing all your comparisons based on direct page instructions and not considering this advantage I don't think your assessment was fair.

Of course i do know what DMA is (and the MD also has a DMA) but the point was to compare the CPU (see my previous point).

I DON'T.

I don't go around trying to say that Game X is too complicated for System Y because that would be a foolish thing to do - you can't prove it and you're just inviting people to prove you wrong. You talk exclusively about CPU power, which again you should know better than. The SNES is more than a 65816. The Genesis is more than a 68000.

Ok, you don't, i try... and what do you expect ? do we need to reverse engineer entirely GH game to see if you can port the engine 1 to 1 ? Do you know at least what can the 68000 CPU do ? Again we can go further in the calculation, but do we really need it ??

[Stef]

The slowdown in Bad Apple is mostly the 65816 waiting for the SPC700 to respond to it.

Too bad to waste CPU time here, but you will probably try get back to the HDMA method ?
Reading the SPC7000 documentation, it looks like you have a 4 bytes port communication between the SPC and the main CPU. When you fed the SPC from the HDMA i guess you do something as write 1 byte of compressed data to port 0 and write a specific value to port 1 to notify the SPC a data is ready then the SPC can read and acknowledge it by writing 0 back to port 1 ? From this scheme you can probably build a BBR circular buffer inside the SPC RAM where the DSP will fetch its samples but i guess synchronizing read and write is all the matter (avoiding to read where write are occurring).

Somebody said that I kept the frames in vram in GH. I could've did that because I only used 4 animation frames for enemies, but I used a dynamic animation engine instead because I anticipated eventually running out of vram.

Does you dynamic engine re-allocate at each frame or it keeps tiles in VRAM as long it can ?

[TOUKO]

See those bosses? On the SNES they would slow down, that movement requries sooo much computation. It could only be done on the Sega hardware.

Aahahah, i 've seen many of this words for any console, from many developpers, i call this a self errection ..
"We are so good that we can only prove it on ....(replace by your favorite machine)"

[Drew Sebastino]

Are we really going to start this again?

[tokumaru]

Q: Konami is a big 3rd party for Nintendo, so why are you now making games for Sega?
A: I’ve always been fascinated with hardware. People are constantly comparing Mega Drive to SNES, saying that the SNES has more colors etc…
But the Mega Drive has a 68000 processor, which is very easy for programmers to work with. I was a programmer for years, making games for the SNES, and I can tell you, the hardware is a pain in the butt. If consumers look at a still shot, they may think the SNES is better, but actually, if you tried to put Gunstar Heroes onto the SNES there would be no way. See those bosses? On the SNES they would slow down, that movement requries sooo much computation. It could only be done on the Sega hardware.
...
as I said the hardware is very easy to work with. All things considered, the 68000 is a very good CPU allowing room for experimentation while the SNES hardware limits you to their design standards. Scaling and rotation can be implemented in the Sega software, forget it on the SNES.

I don't consider this proof of anything. It just means that this particular programmer, using the particular technique he used in one platform, probably wouldn't be able to replicate the same effects in some other platform with the same performance. It's arrogant to say that something is impossible simply because you haven't figured out a way to do it.

Fortunately, there's more than one way to implement the same idea, and if you design your algorithms around the limitations and strong points of each CPU/system, you're likely to succeed in implementing that idea. Unless we're talking about larger generational gaps, which is not the case of SNES vs. Genesis (although that didn't stop Chinese pirates from porting several 16-bit titles to the NES, with varying degrees of success).

Something that happens to me sometimes is that I spend a lot of time thinking of how to implement something non-trivial, and when I finally find the answer, it becomes my point of reference on how to perform that particular task, and I'll base all my performance estimations off of that. Then comes along someone else with a different point of view, and a new idea on how to do the same thing, and I realize that I didn't have the absolute answer after all. Sometimes it's not even someone else, I often think of alternative ways to implement something out of the blue, and the new way can be even twice as fast as the old solution.

In before someone calls me a SNES fanboy: Out of the 2 systems, the Genesis is my favorite. I grew up with it and I find the overall aesthetics of Genesis games more interesting. But I also like the SNES very much, and I don't consider either system obviously superior to the other.