Originally Posted by
tomaitheous
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.
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.
