snes enhancement chips = total rip off

In know that Star Fox uses the FX chip for the polygons, Yoshi's Island for the scaling and rotation special effects, and Doom uses it for it's first person view, but other than that, I can't find anything special about any of the other games that use enhancement chips.

Take for instance the SA-1 chip. From the information I've read it's a 10Mhz 65816 with features such as decompression and a better DMA. That sounds pretty good, but look at the games that use it.

First there is Super Mario RPG. It uses turn based battle. Yeah sure like you need 10Mhz to calculate AI when it is turn based? It has prerendered graphics, but so does Donkey Kong Country, and that doesn't use a chip. Nothing looks any special here.

Then there is Kirby Super Star and Kirby's Dreamland 3. They're both platformers like 100 other games on the system. Neither of them have any kind of special animation or an unusually high amount of sprites onscreen. They're just platformers.

Some people act like they can tell the difference. I don't know if they really can tell a difference or are they just assuming they have a difference just because it has a chip. What do these games do that couldn't be done without the chips? They look like your normal Snes games to me.

If you *really* want to know, ask Byuu. He's the emulator author of Bsnes (there's also a debugger version). I know he's made comments in the past how developers never really took advantage of the SA-1. From what I've heard, the most what was offsetted from the main processor besides decompression, was complex sprite priority sorting (juggling the sprite attribute table entries).

They use to advertise DKC uses 32Megs ..meaning 32MB..so for that being a example what is the size Super Mario World in comparsion. Since between the two there is a obvious difference in sprites.

Quote:

---

Originally Posted by FoxHound

They use to advertise DKC uses 32Megs ..meaning 32MB..so for that being a example what is the size Super Mario World in comparsion. Since between the two there is a obvious difference in sprites.

---

32 Megs=4 MB, a megabit is 1/8 of a megabyte. Why on earth they even bothered with that crap back in the day is beyond me, I didn't know shit about memory/storage until I started hardcore downloading from the internet and had to start managing my space to keep from filling up the hard drive.

Super Mario World appears to be 512kb, so literally 1/8 the size of DKC, which sounds about right as SMW was honestly a really underwhelming game from a technical perspective. After seeing games like Mario is Missing on the NES and the NES pirate version of SMW, you realize the regular ol NES could've handled most if not all of SMW pretty easily. It seems, however, that all 2D Mario games are a little underwhelming for the time, even New Super Mario Bros. Wii feels like it could've been on the N64 with a slight downgrade (compare it to Smash Bros., for example).

As for enhancement chips in general, it's probably alot like the Sega CD and how many games ended up just being the Genesis version with a CD soundtrack. Though, for enhancement chips, you'd think they would utilize it more if they were going to bear the weight of the additional cartridge cost. A Sega CD or 32X game would cost the same to produce whether or not you utilized the additional hardware. Gotta love those CD soundtracks though, it even makes ultra generic games like Radical Rex and 3 Ninjas fairly entertaining.

Quote:

---

Originally Posted by dragonboy

Some people act like they can tell the difference. I don't know if they really can tell a difference or are they just assuming they have a difference just because it has a chip. What do these games do that couldn't be done without the chips? They look like your normal Snes games to me.

---

Just judging from memory I'd say that Kirby Super Star, Kirby's Dreamland 3 and Yoshi's Island look A LOT more complex than other SNES games - including Donkey Kong Country.

One reason for SA-1 was for its data decompression hardware, even if the added CPU power wasn't needed.

Also the SA-1 and other enhancement chips (DSP etc) tend to be much cheaper than Super FX. (not least because of the 128 kB of RAM in SFX carts)

I got into a side discusson with A Black Falcon in this thread: http://sega-16.com/forum/showthread.php?p=198225

About the practicality of having such expensive carts like Super FX or SVP (opposed to other enhancement chips on SNES which were far cheaper) and I suggested that a simple lock-on (game genie/S&K style) cart with Super FX/SVP hardware onboard would have been more useful in general, and could have attracted more developers to produce games in the format. You could have a game built into the passthough cart as well, to help justify the purchase, probably not costing too much more than existing SFX/SVP carts. (or they could have gone a little more expensive and added a bit more like expanded the RAM from 128 to 256 kB perhaps more)

One thing about Super FX though was that they later doubled the speed; 2 different enhancemt carts might confuse things too much, so maybe start with Super FX on-cart and release a lock-on enhancement when the Super FX 2 was ready. (otherwsie they'd probably stick with the slower model only)

One thing with the SNES is that the 256 color modes really facilitate 3D graphics compared to the Genesis being limited to 16-colors. (hence the copious dithering and garrish color scheme in Virtua Racing -even with 256 colors Star Fox uses a good bit of dithering as well)

The C4 chip used in Mega Man X2 and X3 was cool, but it wasn't used for much. All they used it for was a couple mid bosses, Sigma's virus, and the weapon demo in X3.

Quote:

---

Originally Posted by 17daysolderthannes

32 Megs=4 MB, a megabit is 1/8 of a megabyte. Why on earth they even bothered with that crap back in the day is beyond me, I didn't know shit about memory/storage until I started hardcore downloading from the internet and had to start managing my space to keep from filling up the hard drive.

---

MegaBits are and still are used to tell you the size of the memory chip, it will give you right size no matter if the chip is 1, 2, 4, 8 or 16bits wide. MD ROMs should not be measured bytes as they're in Words, with largest ROMs being 2KWord and one game being 2.5KWord in size :P

Quote:

---

Originally Posted by 17daysolderthannes

32 Megs=4 MB, a megabit is 1/8 of a megabyte. Why on earth they even bothered with that crap back in the day is beyond me, I didn't know shit about memory/storage until I started hardcore downloading from the internet and had to start managing my space to keep from filling up the hard drive.

---

dude-1: "Dude I got the new Super Street Fighter 2 game!!!!! Can't wait to play it!!!!"

dude-2: "Don't you already have Street Fighter 2 Turbo? Besides the new game isn't even the Turbo version."

dude-1: "But this game is 32MEGS!!!!!!!!!!!!!"

dude-2: "WTF is a meg?"

dude-1: "Gee, I dunno? It says it on the cover so must be a good thing?"

Quote:

---

Originally Posted by TmEE

MegaBits are and still are used to tell you the size of the memory chip, it will give you right size no matter if the chip is 1, 2, 4, 8 or 16bits wide. MD ROMs should not be measured bytes as they're in Words, with largest ROMs being 2KWord and one game being 2.5KWord in size :P

---

I don't agree - always tell the size in bytes. We don't care if it's one bit wide or a thousand. We care about the total storage. The only thing the width affects is the speed at which the data is fetched. A one byte wide cart with 4MB holds the EXACT SAME amount of data as a 16 byte wide cart with 4MB. A MB is a MB is a MB.

Specifying the size in bits was a MARKETING ploy to try to trick people into thinking they were getting more for less money - a common ploy foisted on the ignorant and unsuspecting public.

Sleazy Salesman: "See, THEIR carts are only 4MBytes. OUR carts are 32 Mbits!!!"

Idiot Customer: "WOW!!! I'll pay TWICE as much for it!!!!!"

Quote:

---

Originally Posted by Chilly Willy

I don't agree - always tell the size in bytes. We don't care if it's one bit wide or a thousand. We care about the total storage. The only thing the width affects is the speed at which the data is fetched. A one byte wide cart with 4MB holds the EXACT SAME amount of data as a 16 byte wide cart with 4MB. A MB is a MB is a MB.

Specifying the size in bits was a MARKETING ploy to try to trick people into thinking they were getting more for less money - a common ploy foisted on the ignorant and unsuspecting public.

Sleazy Salesman: "See, THEIR carts are only 4MBytes. OUR carts are 32 Mbits!!!"

Idiot Customer: "WOW!!! I'll pay TWICE as much for it!!!!!"

---

Don't hardware manufacturers go by bits in terms of RAM/ROM IC sizes? (seems to be prominent in arcade terminology as well)

There's...

MB's
Mb's

KB's
Kb's

Mega-Byte
Mega-bit

Kilo-Byte
Kilo-bit

Most people fail with the acronym terminology.
: (

like how no one understands about Kbps, Mbps, vs. KBps and MBps

One other nasty thing is, that there is not even a
normed Megabyte. It can be a binary Megabyte or
a decimal Megabyte. So the Megabyte is not 1024 KB
(as it always will be inside PC-hardware communication)
but 1000 KB.

This is how the hard drives can be always advertised
with the false size. And the more they "officially" can
hold, the more MBs you actually don't get. Hell, the
loss is measured in many many GBs for a loong time
already.

My "40 GB" drive only has 37,7 and my "160 GB" drive
has somewhere near 149,5. It's like I should get an
amount of free RAM pieces for the non-existant storage
place, but of course no one would do that.

That's why they introduced the binary byte notation, so you get Kibibyte (Kilobinary byte, or 1024 bytes) and Mebibyte (1024 Kibibytes), abbreviated as KiB and MiB. One gigabyte is only 93% of one gibibyte, so that's why you get 37 GiB on a 40 GB hard drive.

In practice, this 'standard' only adds to the confusion though.

Quote:

---

Originally Posted by PimpUigi

There's...

MB's
Mb's

KB's
Kb's

Mega-Byte
Mega-bit

Kilo-Byte
Kilo-bit

Most people fail with the acronym terminology.
: (

like how no one understands about Kbps, Mbps, vs. KBps and MBps

---

And you failed by adding apostrophes where they do not belong.

Quote:

---

Originally Posted by kool kitty89

Don't hardware manufacturers go by bits in terms of RAM/ROM IC sizes? (seems to be prominent in arcade terminology as well)

---

Yes, but that's because they STARTED as one bit wide. A 4 Kbit DRAM was 4Kb x 1. As they got bigger, they stayed as one bit for a long time. Eventually, someone made one that was 4 bits wide and marketed it as 4Kb x 4. They grew from there. That was for people selling CHIPS to ENGINEERS. Nobody sold memory that way in the computer business - you didn't buy a 512 Kbit expansion for your Atari 400/800, you bought a 64 KByte expansion. You didn't have a 64 Kbit cart with Star Raiders, you had an 8 KByte cart. MS BASIC wasn't 128 Kbits, it was 16 KBytes. You didn't put a 256 Mbit SIMM in your PC, you put a 32 MByte SIMM in it.

A hardware engineer might concern himself with bits. Users deal with bytes. The only reason to use bits is to confuse those users.

And by the way, if you're buying RAM or ROM, it's common to see it sold by the byte instead of the bit. The reason is chips often can have flexible buses that can do 4, 8, or 16 bit widths. Since the width is variable, it makes sense to simply specify the maximum capacity in the common unit - bytes.

I was thinking of this last night. If most Snes games only used slowROMs (2.68Mhz) because fastROMs (3.58Mhz) were "so expensive," then why were TurboGrafx games using 7.16Mhz ROMs 3 years before Snes even came out?

Quote:

---

Originally Posted by Devil N

That's why they introduced the binary byte notation, so you get Kibibyte (Kilobinary byte, or 1024 bytes) and Mebibyte (1024 Kibibytes), abbreviated as KiB and MiB. One gigabyte is only 93% of one gibibyte, so that's why you get 37 GiB on a 40 GB hard drive.

In practice, this 'standard' only adds to the confusion though.

---

Oh, never heard of this. It sounds like a small child is inventing words :-D. Gibibyte,
lol. The decimal bytes should not exist at all, it only confuses people. Where do
decimal bytes exist anyway except advertising and marketing a product?

Quote:

---

Originally Posted by N.Saibot

Oh, never heard of this. It sounds like a small child is inventing words :-D. Gibibyte,
lol. The decimal bytes should not exist at all, it only confuses people. Where do
decimal bytes exist anyway except advertising and marketing a product?

---

Mathematicians held a meeting where they imposed those standards without input from Computer Scientists. They were tired of Computer Science people "stealing" their prefixes and giving them different meanings. So what if any computer scientist knows that mega is 1024*1024, not 1000*1000? It's understood when you use one versus the other - at least by those who actually work in the field. If mathematicians are too stupid to know the difference, they can take some classes like we did. Changing the terms unilaterally is childish to the extreme. I refuse on general principles to EVER use the "correct" prefixes.
:mad: :p :D

Quote:

---

Originally Posted by dragonboy

I was thinking of this last night. If most Snes games only used slowROMs (2.68Mhz) because fastROMs (3.58Mhz) were "so expensive," then why were TurboGrafx games using 7.16Mhz ROMs 3 years before Snes even came out?

---

It was an 8-Bit CPU vs. a 16-Bit CPU.

Quote:

---

Originally Posted by Chilly Willy

Mathematicians held a meeting where they imposed those standards without input from Computer Scientists. They were tired of Computer Science people "stealing" their prefixes and giving them different meanings. So what if any computer scientist knows that mega is 1024*1024, not 1000*1000? It's understood when you use one versus the other - at least by those who actually work in the field. If mathematicians are too stupid to know the difference, they can take some classes like we did. Changing the terms unilaterally is childish to the extreme. I refuse on general principles to EVER use the "correct" prefixes.
:mad: :p :D

---

The problem are not the mathematicians, they really can "take a class" and it won't
hurt them much. The problem are the ordinary people, knowing enough about
computers to want a bigger hard drive and being able to connect it right after a few
tries. How the hell are they supposed to know, why the supposedly 500 GB hard
drive somehow has ca. 100 GB less than promised? A friend of mine once literally said
to me, he doesn't understand why the swap file takes up so much place on the new
unformated hds.

I say we just make a voting on this forum to decide if the decimal meaning of MB
should be totally removed from dictionaries and prevented from using. I'm already
voting for it, who is with me? ^^

N.Saibot.........pretty appropriate avatar for the screen name. :D

Quote:

---

Originally Posted by Da_Shocker

It was an 8-Bit CPU vs. a 16-Bit CPU.

---

That has nothing to do with it. I'm talking about ROM latency.

related on the HDDs showing smaller sizes... well, same deal is with flash sticks too, and they cannot be using some weird values... a 2048MByte flash stick will not show you 2048Mbyte of storage room... there's a chunck eaten off, and I have always believed that the missing chunk is reserved for the FAT..... ?

Quote:

---

Originally Posted by TmEE

related on the HDDs showing smaller sizes... well, same deal is with flash sticks too, and they cannot be using some weird values... a 2048MByte flash stick will not show you 2048Mbyte of storage room... there's a chunck eaten off, and I have always believed that the missing chunk is reserved for the FAT..... ?

---

Actually, SD cards show smaller because a certain percentage is permanently segmented for the use of hidden encrypted drivers. There special commands to let the SD interface fetch the encrypted data and validate it. Normal usage ignores that and subsequently, the card appears smaller.

Quote:

---

Originally Posted by Da_Shocker

It was an 8-Bit CPU vs. a 16-Bit CPU.

---

SNES's CPU is basicly the same architecture as the PCE's (with the 65C02 utilizing all the instructions the 65816 does iirc), Tomaitheous addressed this I beleive in the PCE vs SNES thread. So the PCE's CPU is basicly double the speed of the SNES's (actually more due to wait states).
I doubt using DRAM costs had anything to do with the SNES's slow CPU (DRAM rated for 8 MHz should have been readily available by that point), I'm really not sure why they went with such a slow clocked CPU. (shoould have been double that at least) Maybe the added I/O hardware onboard the CPU had something to do with that, but I though that ran at 1.79 MHz in any case, so would already use a divided clock. (being derived from the NES's I/O hardware) Hell, maybe even a 10.74 MHz CPU would have been practical. (DRAM might be an issue though, but by 1990 I kind of doubt it)

Quote:

---

Originally Posted by Da_Shocker

It was an 8-Bit CPU vs. a 16-Bit CPU.

---

That has nothing to do with what Dragonboy is talking about. He's talking about the speed of the rom. The bus *width* is irrelevant. Good point dragonboy.

Kool Kitty: Just the joypad ports are 1.79mhz mode, which really doesn't matter since you only read them once per frame anyway (it equates to like less than 0.1% resource per frame). *All* other I/O is 3.58mhz mode.

Quote:

---

Originally Posted by kool kitty89

SNES's CPU is basicly the same architecture as the PCE's (with the 65C02 utilizing all the instructions the 65816 does iirc), Tomaitheous addressed this I beleive in the PCE vs SNES thread. So the PCE's CPU is basicly double the speed of the SNES's (actually more due to wait states).
I doubt using DRAM costs had anything to do with the SNES's slow CPU (DRAM rated for 8 MHz should have been readily available by that point), I'm really not sure why they went with such a slow clocked CPU. (shoould have been double that at least) Maybe the added I/O hardware onboard the CPU had something to do with that, but I though that ran at 1.79 MHz in any case, so would already use a divided clock. (being derived from the NES's I/O hardware) Hell, maybe even a 10.74 MHz CPU would have been practical. (DRAM might be an issue though, but by 1990 I kind of doubt it)

---

Didn't they use a slower clocked CPU in the SNES because they intentionally wanted to
have NES-compatibility? I read somewhere, that they were going to make SNES
backwards compatible, but by the time Mega Drive started stealing all the show they
decided to bring the SNES out kind of unfinished - no compatibility, but still a slower
CPU.

I'm talking about cartridge ROM, not system RAM. Sure it slows to 2.68Mhz when it accesses ram, developers had no choice. Rom accesses on the other hand were selectable between 3.58Mhz or 2.68Mhz. A developer DOES have choice with the speed of ROM accesses, but not the RAM. Most developers chose 2.68Mhz ROM accesses anyway, dispite 7.16 Mhz ROMs were used for Turbografx games way before the Super Nintendo came out.


EDIT: I just thought of an interesting question. If a system has a slower cpu than another system, is it possible for the video/audio chipset to be designed in such a way that the system with the slower cpu is actually faster than the system with the faster cpu?

Quote:

---

Originally Posted by dragonboy

I just thought of an interesting question. If a system has a slower cpu than another system, is it possible for the video/audio chipset to be designed in such a way that the system with the slower cpu is actually faster than the system with the faster cpu?

---

Yes. The Amiga is a perfect example. By running the 68000 at ~7.2MHz and recognizing that the 68000 takes two cycles to do anything, every other memory cycle is GUARANTEED to be CPU-free, and therefore free for use by the custom chips. So until the bandwidth exceeds every other memory cycle, things like video and sprite fetch don't slow the CPU at all since the CPU wasn't using those cycles.

Four bitplanes of low-res graphics (320 wide) have no effect on the CPU. Five bitplanes takes about 1/4 the CPU cycles, and six bitplanes about 1/2 the CPU cycles. High-res graphics had the ability to take all the CPU cycles: 2 bitplanes of high-res (640 wide) have no effect on the CPU, 3 bitplanes takes about 1/2 the cycles, and 4 bitplanes takes all the cycles. That's why people avoided 16 color high-res on the Amiga if they could (OCS and ECS - the AGA was more complicated).

On the other hand, the Atari 8 bit computers (400/800/XL/XE) used a CPU that was exactly as fast as the memory, so when the ANTIC fetched the video data, it asserted a HALT line that temporarily stopped the CPU clock line, holding the CPU (a 6502) stopped for that cycle while the ANTIC did its DMA. Most modes people used stole about half the CPU cycles during the display period. Certain cell modes stole all the cycles for the first line of the cells, then once again stole half the cycles for the rest of the lines of the cells.

If one system had like 16MB of memory devoted to graphics, while another had 2kB but had the exact same cpu, wouldn't the 16MB be faster in it's own way because it doesn't need to waste time uploading frames to give comparable animation? That's why I doubt cpu speed and game speed are the same thing.

Quote:

---

Originally Posted by dragonboy

If one system had like 16MB of memory devoted to graphics, while another had 2kB but had the exact same cpu, wouldn't the 16MB be faster in it's own way because it doesn't need to waste time uploading frames to give comparable animation? That's why I doubt cpu speed and game speed are the same thing.

---

Only as long as the CPU can keep up with the game logic. You still need to be able to compute the interactions of all the players and objects in the game. Extra video memory won't help with that at all. What good is 16 MB of vram is the CPU can only handle two objects in real-time? Extreme example, yes, but it makes the point. Game speed is VERY dependent on CPU speed, more so than the graphics. Graphics could be handled via more memory, or a separate video chip, or any number of other ways. Game speed can be handled only ONE way - a faster CPU.

Quote:

---

Originally Posted by N.Saibot

Didn't they use a slower clocked CPU in the SNES because they intentionally wanted to
have NES-compatibility?

---

Nope. The way the CPU is setup - it inserts wait states on memory access. There's no reasons they couldn't have done this down to 1.79mhz which is NES speed (and they just that, all gamepad I/O reads put the processor into 1.79mhz via wait states). Also, while ram is 2.68mhz - if you're running code out of fast rom, then ram accessing opcodes are between ~3.05mhz-3.10mhz. The PC Engine is able to run in 1.79mhz mode too. Just set the processor speed to that (it does that to access "save" ram of the CD system/booster units. Super Star Soldier also puts the cpu into 1.79mhz mode during active display for parts where the CPU is just idle - doing nothing. Some have speculated that this was for TG Express to extend batter life.) The main SNES cpu always runs in 3.58mhz mode, it's the wait states on the rom/ram that bring it down (or think of it running at 21.44mhz mode since the wait states are on the master cycles).

Quote:

---

On the other hand, the Atari 8 bit computers (400/800/XL/XE) used a CPU that was exactly as fast as the memory, so when the ANTIC fetched the video data, it asserted a HALT line that temporarily stopped the CPU clock line, holding the CPU (a 6502) stopped for that cycle while the ANTIC did its DMA. Most modes people used stole about half the CPU cycles during the display period. Certain cell modes stole all the cycles for the first line of the cells, then once again stole half the cycles for the rest of the lines of the cells.

---

The CoCo systems used faster ram to avoid this issue. Video software accessed main ram (used for video ram) on odd access cycles of the faster ram. The cpu never gets a hit. And IIRC, this is also true for 1.79mhz mode.

Quote:

---

If one system had like 16MB of memory devoted to graphics, while another had 2kB but had the exact same cpu, wouldn't the 16MB be faster in it's own way because it doesn't need to waste time uploading frames to give comparable animation? That's why I doubt cpu speed and game speed are the same thing.

---

Well, one point to remember is that the NES has no DMA or block move instructions for moving stuff to vram. The SNES (and Genesis) on the other hand, have fast DMA modules for this. Really taking the load off the CPU. The CPU is still stalled in both causes (it can't do anything while DMA is in progress), but it's much faster than what the CPU can transfer. One thing that would speed up the CPU a little would be much more VRAM. A lot of rom could also help speed up the CPU a little as well. Lots and lots and lots of precalculated LUTs (and really large sprite animation tables) can help alot (especially on the 65x and more so on the '816).

I'm still at a loff for why the SNES's CPU was clocked so slowly or while the RAM was clocked even more slowly (or was that only slower due to wait states related to DRAM refresh cycles?).
They should have easily had a faster CPU (assuming its CMOS and they didn't have problems implementing the licenced core in their custom package). Faster DRAM should have been quite affordable as well. (and still a lot cheaper than the PSRAM the genesis used)

Quote:

---

Originally Posted by Aarzak

N.Saibot.........pretty appropriate avatar for the screen name. :D

---

Finally someone takes notice :-) Noob Saibot is my favorite character in UMK3,
since he helped me to complete the game on highest difficulties. He is so
overpowered, that it's no problem at all.
And back in the day when I was to weak to beat the game "for real" and was
boared by practicing with other characters, I just picked Noob Saibot and
finished the game fairly quickly.

The way the Snes only has 16kB of sprite memory, I find as a bigger limitation than the cpu speed. Just to get a little smooth animation you have to time all this dma crap perfectly so you won't miss the v-blank. If it had 64kB of sprite memory like the Genesis, all this dma timing wouldn't be an issue.