Mods delete this thread. I do not want to argue with people.

[Ziggy]

Essentially it makes the CPU spin in place for a bit, doing effectively nothing.

Then it should be easy to fix, no?

[MrPopo]

well why would they do that?

...did sega slip them some cash?

I'd need a lot more context as to when this code gets executed. As I mention earlier, it's a tiny fraction of a second that gets added. This piece of code would need to be all over the place to make a noticeable amount of slowdown.

There are valid reasons for wanting to have your code wait. One is the propagation delay of digital signals. If you output something to the screen it will take longer than the time for your next instruction, and maybe you want to wait for that.

[MrPopo]

Essentially it makes the CPU spin in place for a bit, doing effectively nothing.

Then it should be easy to fix, no?

That's assuming it's broken. It can also have a lot of unintended consequences. When you're down at the assembly level there are quirks to how a CPU is designed that can really screw with things depending on how you order your statements. You have to worry about things like the pipeline, for example.

[AppleQueso]

In other words, yanking this piece of code out would probably give you results similar to what happens with many playstation games when you try to play them on ps2 with the fast loading option enabled? Shit may turn out okay, but it could end up totally crashing some games?

[Ziggy]

well why would they do that?

...did sega slip them some cash?

I'd need a lot more context as to when this code gets executed. As I mention earlier, it's a tiny fraction of a second that gets added. This piece of code would need to be all over the place to make a noticeable amount of slowdown.

There are valid reasons for wanting to have your code wait. One is the propagation delay of digital signals. If you output something to the screen it will take longer than the time for your next instruction, and maybe you want to wait for that.

Ah, I see. Set a SNES cart on fire or saw it in half and I'll fix it. But show me the code of the game and I'll have no idea what I'm looking at.

[MrPopo]

Assembly's a really fun subject. You're really down in the nitty-gritty of the processor and there are some really neat tricks you can do to squeeze out performance if you know enough about the processor.

[gtmtnbiker]

If you want to try out assembly, a good place to start would be using a microprocessor simulator. In grad school, I did some embedded systems projects that we designed ourselves (hardware, software, etc). I would debug/test my code using a simulator since we didn't have any sort of remote debugging capabilities that might exist today.

Here's an example:
http://www.edsim51.com/

[Aaendi]

well why would they do that?

...did sega slip them some cash?

Yes. I'm afraid that is the case.

This piece of code would need to be all over the place to make a noticeable amount of slowdown.

...and there are copies of this code all over the place.

[Lokkenjawnz]

I'd say this is total BS. Like MrPoPo said, you need to add delay sometimes in programming to make sure everything syncs up properly. Not to mention that such a small delay would have to be repeated thousands of times to even get anywhere near perceptible. To think that this was done in some way to sabotage the SNES is a bit ridiculous to say the least.

[gtmtnbiker]

This piece of code would need to be all over the place to make a noticeable amount of slowdown.

...and there are copies of this code all over the place.

We would need to understand the context that the code was used.

As a software developer, I would never deliberately try to produce slow/bad code. That's just unheard of. Yes, you might produce code that is not as efficient and you might need to go back to improve it. Often times, you would run a tool such as Rational Quantify to profile code and see where it's spending its time. Otherwise, it can be like looking for a needle in a haystack. Who knows what kind of tools they had during the SNES development days.