Why did Super Mario RPG and Kirby Super Star use an SA-1?

[Fisher]

I've heard about a StarOcean hack that used no SDD1 chip.
Instead, it used a larger ROM.
That would be a nice thing to do on SFA2 too.
SA1 is a different history...

it's always felt like an early SNES

Comparing with other SNES games the end result is kind of disappointing.
I wasn't aware that this specific Kirby's game used a special chip back in the day, and I found quite annoying it just worked in the "not unlocked" SNESes.

I just imagine how different the DK games would be if they used and explored that chip capacities...
Well... anybody can imagine lots of things. And this sure would make a _very_ long topic.

[Drew Sebastino]

SA1 is a different history...

Exactly; making KSS run on the SNES only would be a near rewrite.

I just imagine how different the DK games would be if they used and explored that chip capacities...

I'm not quite sure what they would have done; everything that could be considered a technical limitation (not much stuff onscreen, no complex AI) could also be considered part of the game's design. The game could have looked much better if background tiles were loaded in with the level moving, (backgrounds are pretty repetitive and obviously part of a tileset, which doesn't work way to well with the otherwise varied graphics) but I think this has much more to do with cartridge space and extra effort on developing more of the environment. I will admit, I've never had a clue how they prerendered the backgrounds; with the objects, you can just take a picture of the whole thing from whatever camera angle, but there's no way to do that way with the whole background, and even if there were, you'd have some really weird sheering issues. There are loads of perspective issues in the game, (particularly prevalent with hard edged platforms) but that's unavoidable.

[MottZilla]

I don't understand why you say sloppy programming like they should have just "got good" instead. In the real world of making these games the consumer and the developer doesn't care if a game has sloppy code. The consumer cares that the game works and the developer cares that the product is finished on time.

Well, wasn't this game more expensive than other SNES games at the time? It's not like there were no drawbacks to using the SA-1 (otherwise, every game from the time period would have it.)

That wasn't my point. My point was primarily that spending significantly more time developing a game isn't always an option. Adding the SA-1 certainly did raise the cost of games which is probably why I believe of the fairly small number of games that used the SA-1 only a fraction of those were released outside Japan. You'd want to be very confident in your game selling well enough if you were going to raise the cost. More games could have benefited from the SA-1 if it had been offered in a 32X-like or Game Genie sort of form factor. But then you risk confusing consumers.

Isn't that what most people complain about with the SNES? The lack of processing power.

Most people see how Super R-Type and Gradius III run like shit, and then look just at 3.58 and compare it to 7.68 without taking into account memory accesses per cycle, or bus width, or ISA, or whatever.

There are other examples too but I think those are infamous for slow down. I think you are saying how people compare the SNES CPU clock against the Genesis without understanding they are different designs. But what about comparing the SNES to the TurboGrafx 16/PCE which does share CPU design? And its CPU really does run at over 7mhz. And it came out prior to the SFC.

[93143]

I'm not quite sure what they would have done; everything that could be considered a technical limitation (not much stuff onscreen, no complex AI) could also be considered part of the game's design.

That just proves the game was smartly designed around the technical limitations. Perhaps they'd have gone in a slightly different direction given quadruple the processing power plus a bunch of potentially useful bells and whistles. Like how Yoshi's Island made clever use of the Super FX, without being obviously a Super FX game.

the fairly small number of games that used the SA-1

The SD2SNES incompatibility list has 26 SA-1 games on it. That's the same size as the DSP-n library, which isn't too bad considering the first one came out in 1995...

But what about comparing the SNES to the TurboGrafx 16/PCE which does share CPU design? And its CPU really does run at over 7mhz. And it came out prior to the SFC.

But it doesn't share the same CPU design. The HuC6280 is 8-bit. It's a slightly souped-up NES CPU.

All that demonstrates is that Nintendo wasn't absolutely locked to low clock speeds once they picked the architecture - they could have customized the CPU to get rid of the phi1/phi2 nonsense and doubled the clock, but they didn't. It does not mean the PC Engine CPU was twice as powerful.

...

The sad fact that no existing game really exercises the SA-1 is unlikely to change in the near future, given how tough it is for a hobbyist to make a game that takes proper advantage of just the base console. Also, if I understand correctly, emulation of the SA-1 is not currently accurate enough to serve as a development environment for a game that pushes its limits; apparently a memory controller capable of giving two CPUs simultaneous access to multiple single-ported writable memories is hard to emulate for some reason...

[Oziphantom]

The 65816 doesn't limit their clock to 3.5 in any way, even with the requirement for Phi0/1, it is stable when over-clocked to 20mhz using the WDC fabrication, maybe Nintendo dropped the fab tech to make it cheaper? A NMOS 6502 will do 4Mhz fine according to Mencsh, the HMOS-II 8500/2 will do it as well.

I would think the main reason they used an SA-1 was for copy protection and region locking, at the end of the SNES life piracy would have been a bigger issue than before and the Grey/Red imports markets would have been well established and oiled.

You shouldn't however use every chips feature for the the sake of it, you should use what you need for the gameplay at hand. Maybe the bitmaps gave better compression so using the built in hardware bitmap->planes was the main use, especially since it was something a stock SNES couldn't do. Or the Huffman bit stream assistant, or the Extra ROM it allows, or the Extra RAM. Maybe running a 65816 at 10mhz allowed them to just use C and hang the cost, but dev faster. Using a 10mhz chip would have allowed them to do more in a scripting system which on a games of the larger size, helped a lot, as you could get the cheaper designers to do more logic work.

What is the Nintendo SNES SDK? I've not heard or seen anything about it, got a link?

What cart size does the Star Ocean no SDD-1 patch use? But again it might have been cheaper for them to use the SDD-1 than the larger ROM size when you factor in the money saved on piracy.

[hex_usr]

The Star Ocean no S-DD1 hack expands the ROM size from 6 MiB to 12 MiB (48 Mbit to 96 Mbit), which is more than any ExHiROM or ExLoROM. I believe the SD2SNES supports this hack already. Street Fighter Alpha 2 does not have a 12 MiB hack.

Specifically, the memory map goes like:

Code: Select all

SFC               PC
$00-7d:8000-ffff: $000000-$3effff
$7e-7f:8000-ffff: Console WRAM ($3f0000-$3fffff are 0x00)
$80-ff:8000-ffff: $400000-$7fffff
$40-6f:0000-7fff: $800000-$97ffff
$70-7d:0000-7fff: Cartridge SRAM ($980000-$9effff are 0x00)
$7e-7f:0000-7fff: Console WRAM ($9f0000-$9fffff are 0x00)
$c0-ff:0000-7fff: $a00000-$bfffff

[psycopathicteen]

What is the Nintendo SNES SDK? I've not heard or seen anything about it, got a link?

It's just a theory of mine that I've pieced together through bits of information I could find. It sounds like developers were so strict with time they couldn't even write original code, and had to rely on reusing the same code from 1990 without improving or altering it in any way.

[adam_smasher]

I mean, of course developers saved time by reusing old code and building off their existing engines. That doesn't mean that it came from Nintendo as part of a formal SDK.

TBH, I suspect that if Nintendo provided devs with a library of sample code, it would've been leaked at this point.

[lidnariq]

We know they provided a set of sample routines ("library"?) for using the mouse, super scope, and multitap: Fullsnes § detecting controller support by searching for magic strings inside ROM images

[93143]

The 65816 doesn't limit their clock to 3.5 in any way

It does if you need to operate reliably in a 120 ns memory without wait states.

Which suggests another obvious way to improve matters, that Nintendo actually used for slower memory areas... but it wouldn't get you to 7.16 MHz; maybe making the process reliable to 10.74 in order to go from 3.58/2.68 to 5.37/3.58 didn't seem worth it...?

There's also the trick the SA-1 used, which was to use 16-bit memory with a smart interface. A 65816 can sustain 10.74 MHz in ordinary FastROM this way, even without eliminating the address half-cycle, unless it encounters a branch or a random data access...

[psycopathicteen]

The 65816 doesn't limit their clock to 3.5 in any way

It does if you need to operate reliably in a 120 ns memory without wait states.

Which suggests another obvious way to improve matters, that Nintendo actually used for slower memory areas... but it wouldn't get you to 7.16 MHz; maybe making the process reliable to 10.74 in order to go from 3.58/2.68 to 5.37/3.58 didn't seem worth it...?

Okay, I think I figured out what you're talking about. Having the memory accessing "half" cycle longer than the other.

Code: Select all

       SNES 93143
200ns  5/8  5/6
120ns  3/6  3/4

[Myask]

I was under the impression that SMRPG needed the speed for some attack animations that used a layer, but I'm not very in-the-loop on that.

[psycopathicteen]

I just found something that would be a limitation for SA-1 games, and that is sPPU write speed. The SA-1 only works with if the SNES is in slow ROM mode. There's a work around of doing self modifying code, and being able to buffer the DMA data with the SA-1. Are writes to sPPU and DMA still fast in slow ROM mode? If not would the SA-1 not work if the S-CPU is put in fast mode when doing vblank stuff, just as long as it's not touching ROM?

But other than that, I really want to make an SA-1 game. If I make an Alisha's Adventure 2, I'm definitely going to use the SA-1. It looks like Nintendo got their shit together when they designed it. I like how both the S-CPU and SA-1 can share the same memory space, and even the same ASM code, and how the S-CPU can even make use of the SA-1 registers.

[lidnariq]

DMA is always on its own weird timebase (4&4)
Otherwise, memory accesses to $xx2000-$xx3FFF and $xx4200-$xx5FFF are "fastrom" timing (3&3).
"slowrom" timing is 3&5.

[Drew Sebastino]

I really want to make an SA-1 game. If I make an Alisha's Adventure 2, I'm definitely going to use the SA-1.

Wait wait wait; weren't you a big advocate for saying the plain old SNES CPU is strong enough?