I finally have proof!

Quote:

---

Tomaitheous(?), 108 Stars, and dragonboy would constantly get into flame wars over the SNES/Genesis technical capabilities.

---

They were flame wars? There was a lot of debating and proving/disproving discussion of technical points, but I don't remember them getting particularly nasty.

Who is GZeus? I don't remember 'im.

Quote:

---

Now I'm not going to be polysalovic and I just woke up so, I do acctually beleive that Dragon Boy is correct (about the Sound Chip). It doesn't seem too unbeleivable that a sound chip could help and/or fuck up a processor.

---

Nah. The saturn != snes != genesis. What applies to one, doesn't necessarily apply to the other on the technical side. The SNES a DSP (wavetable synth chip) and a dedicated and isolated CPU to handle the sound without *any* requirement or resource from the main CPU. The music and sample data is self contained within the sound processor separate memory. It doesn't slow down the system. Even if you *streamed* 8khz ADPCM samples from the cart (which almost no game does), that's only 60bytes per frame (1/60 NTSC). That would equate to something like 1% CPU resource.

My source is experience with low level console coding. I do more console coding then I do playing games. But I'm not a God or even a demi-god (some have said such though ;) ) or anything, just a humble console dev'r :D

This is all I would like to contribute to this thread:

http://i5.photobucket.com/albums/y16...7081788927.gif

http://i5.photobucket.com/albums/y16...7079940948.gif

Best

Contribution

Ever

Any excuse to post GARBAGE DAY!!

I know you guys are going to yell at me saying this, and I'm afraid of saying this, but we all know the Sega Genesis had a 7.67Mhz 68000 and the Super Nintendo had a 3.58Mhz 65816, but the 65816 was more cycle efficiant, meaning that it could do more in less cycles, if and only if it was programmed correctly.

The reason why Super Nintendo games had slowdown was because most games ran in 2.68Mhz mode instead of 3.58Mhz, and consisted of bad programming.

See by 1990, the 68000 was out for a long time and was a very popular chip, so it was common for people to know how to program them, and there were a lot of old pros at it. When the Snes came out, programmers were like "what the hell is a 65816?" and didn't understand how to program it as efficiently as possible and never realised it's potential. People were so used to the 68000 instruction set, they thought they could try using 68000 optimizations on the 65816, but in reality because the 68000 and the 65816 were so different, it ended up making the 65816 worst off than it was without. Add to that, the 68000 was a much more easy to learn and easy to program chip than the 65816, so noobies to the programming world already did a better job with the 68000 than they did with the 65816 on their first day.

The reason why I'm making a demo is to show off the 65816's untapped power, because I know you guys like to talk shit about it.

This is all I'm going to say about it, so just do yourself a favor and research the instruction sets yourself and learn how to optimize both cpus, instead of only the 68000, so you can have an accurate comparison, please?

btw, I added a little parallax scrolling to it. I'll try to add more layers to it later.

So layer scrolling, (which on MD would be matter of doing 2 writes, in 2 instructions... actually 3 so you could get scrolling effect).... this will become something interesting when you make ALL the sprites collide with each other... right now its really doing nothing...

There is collision detection. When one of the blue glowing sprites collides with a normal sprite the normal sprite disappears and reappears at the top left corner of the screen.

Quote:

---

Originally Posted by dragonboy

The reason why Super Nintendo games had slowdown was because most games ran in 2.68Mhz mode instead of 3.58Mhz, and consisted of bad programming.

---

I'm no expert in programming but this sounds a little ludicrous to me, you're saying that SNES games were slower due to programmers purposefully gimping their own games by choosing a slower mode over a faster one? surely if someone specifically chooses that mode over the other it's due to some kind of benefit that must come with it, that's only logical.

Quote:

---

Originally Posted by dragonboy

noobies to the programming world already did a better job with the 68000 than they did with the 65816 on their first day.

---

Seriously the SNES had most of the biggest, most efficient and talented programmers from the time working on it, I'm sure if there were ways of getting more out of the CPU then companies such as Capcom, Konami and Rare (have a look at what Rare achieved on the N64 with Conker's BFD, great textures, full voice acting with lip synching, lighting, many of which were the N64 major weaknesses) would've done it, and after doing it the other lessor companies would've ripped off their programming code like they always do.

Quote:

---

Originally Posted by jesus.arnold

I'm no expert in programming but this sounds a little ludicrous to me, you're saying that SNES games were slower due to programmers purposefully gimping their own games by choosing a slower mode over a faster one? surely if someone specifically chooses that mode over the other it's due to some kind of benefit that must come with it, that's only logical.

---

Well I think he used "most" wrong. When you go into programming a brand new unknown chip, you don't know what it can do and you don't know the limitations of the CPU, its entirely plausible that some games were poorly coded.

Quote:

---

Originally Posted by dragonboy

I know you guys are going to yell at me saying this, and I'm afraid of saying this, but we all know the Sega Genesis had a 7.67Mhz 68000 and the Super Nintendo had a 3.58Mhz 65816, but the 65816 was more cycle efficiant, meaning that it could do more in less cycles, if and only if it was programmed correctly.

---

Actually, a 3.58 MHz 65816 is about the same speed as a 7.7 Mhz 68000 on cycle count. The 65816 is more efficient, but running at half the clock speed. The BIG difference is in the registers: the 68000 has 16 registers available for use (15 if you actually use a stack); the 65816 has 3. That makes the biggest difference as you're forced to put everything into memory. To help make up for the lack of registers, it makes a special page-addressing which is faster to access, but the 68000 has that too, plus HALF of the Genesis RAM is accessible via the faster addressing mode.

Jesus.arnold, the slower 2.68Mhz mode was usually used because the faster ROM was expensive. The 68000 can only accesses memory every 4th cycle so it could run at the full 7.67Mhz with much slower ROM.

Quote:

---

Originally Posted by dragonboy

Jesus.arnold, the slower 2.68Mhz mode was usually used because the faster ROM was expensive. The 68000 can only accesses memory every 4th cycle so it could run at the full 7.67Mhz with much slower ROM.

---

Okay I think I get what you're saying, it was an issue with manufacturing costs.

This doesn't change the larger picture though, for the last 30 minutes I've been reading through forums which all seem to agree that the SNES CPU was extremely out of date when it was used and that Nintendo knew this but only used it because they originally planned to include NES backwards compatibility, there's no talk of it being "equal" or "better" than the Mega Drive's CPU, only some talk here and there of it not being quite as inferior as it appears to be.

In my experience when you look at the video game libraries for all other systems out there you usually find that programming knowledge and understanding of the best way to make games for a system always grows with time, the PS2 was horribly difficult to program games for, probably substantially worse then for the SNES and look what they accomplished with that. At the end of the day the SNES had a full console lifetime with support from a hell of a lot of the best companies of the time so it seems unlikely to me that it wouldn't have seen it's full potential.

What are the most CPU intensive SNES games out there anyway? perusing through one of those forums earlier someone mentioned, I think it was the 3rd Parodius game, what else would be it's best? for some reason I'm having trouble thinking, I always seem to associate the SNES library with vibrant colourful graphics more than loads of sprites and explosions.

The 3rd Parodius game is certainly not a good game for showing SNES CPU power :shock: It actually has constant slowdown at all times.

The 2nd Parodius game (just called Parodius - Nonsence fantasy in the west) runs much better (and happens to be probably my favourite shooter on the SNES), but though it has a good amount of bullets and a respectable amount of sprites there's no parallax scrolling to speak of which makes it very crude in comparison to something like Thunder Force IV

Quote:

---

Originally Posted by Chilly Willy

The BIG difference is in the registers: the 68000 has 16 registers available for use (15 if you actually use a stack); the 65816 has 3. That makes the biggest difference as you're forced to put everything into memory.

---

And yet a '816 at the same speed as a 68k is faster. The '3 regs' only appears as a hindrance if you're coming from some other processor architecture. And you're forgetting, it's 8 address registers of the 68k V 128 address registers of the '816. If anything, given the 68k's slow memory access cycles and its quick register to register operations, it should've had more registers. The '816 can access it's whole memory range with long mode instructions at a cost of +1 cycle. But honestly, you'd keep things of importance near/local. That's a given even on the 68k where I put code close to work ram so I can use WORD range addressing.

Quote:

---

I'm no expert in programming but this sounds a little ludicrous to me, you're saying that SNES games were slower due to programmers purposefully gimping their own games by choosing a slower mode over a faster one? surely if someone specifically chooses that mode over the other it's due to some kind of benefit that must come with it, that's only logical.

---

Slow roms were the only available option from Nintendo to developers when the SNES first came out. It was also an economical option later on. Slower roms are cheaper.

And the SNES processor isn't really running at 3.58mhz in fast-mode rom. For instructions that are implied or have immediate operands it's 3.58mhz, but any instruction that touches work ram (including ZP registers which get a lot of usage) steps the processor down to ~3.01mhz. It's safe to assume the average speed of a fast-rom game is about ~3.15mhz.

If you think your favorite japanese game companies were efficient at writing fast game code, think again. Their primary goal or priority was to get a game out, not write the fastest or best code possible - functionality over speed is priority. I've traced/stepped through enough games to know this. I've seen code that looks like it was written with a bunch of macros. When it comes to slow down, say from 60hz to 30hz (half speed) - it can come down to a single instruction that can cause it to miss a frame:

You have something like this:

wait_vblank:
lda #$01
sta <_vblank_state
.loop
lda <_vblank_state
bne .loop
rts

The video processor interrupt routine writes 00 to _vblank_state on every vblank interrupt. If the wait_vblank function is a hair too late, you get instant 50% slow down. There are some other methods around this, but they rely on other specific situations being true. If they are not true or met, the game can lock or glitch, etc. Most games use the typical wait_vblank setup. Music is usually tied to the interrupt routine itself so it won't slow down, but games that manaully call the music routine after a wait_vblank function will have slow down in the music as well. Anyway, my point is that something really small in cycle times can cause a 50% as much as a large delay in cycles. 50% slow down is common because the CPU almost always has enough time to finish the task in two frames. But there are games like Gradius 3 where the slow down lasts like 3 frames or more. That's just ridiculous. That is bad programming.

What really boggles the mind is when you see slow down in a SNES game that really should not be an issue. The first game that comes to mind is Demon's Crest. I remember a part with 4 smallish enemies onscreen and the game slowed down. It was a joke or rather the programmer was a joke.

Space Megaforce is definately the most sprite intense game in it's library. Also check out Wild Guns, Smash tv, Biometal, Cybernator, Super Macross and a few others.

In the Super Mario Allstars + Super Mario World edition of Super Mario World, Nintendo actually erased all the slowdown that was in the original version.