AtariAge "CPU comparison"

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: AtariAge "CPU comparison"

Post by 93143 »

psycopathicteen wrote:Are you planning on uploading instruments as needed?
My original goal was real-time multi-channel streaming at high sample rates, without restricting music timing to VBlank. But obviously if you can do that, it should also be possible to change out samples in RAM during playback. And it would be nice to have a reasonably fast bulk data loader that didn't freeze the game à la SFA2...

I suspect it'll be a while before I'm ready to actually try out this method in the field. By then I may have a better idea, or I may have realized that this one has a fatal flaw or something...
rainwarrior wrote:
Revenant wrote:The "Nintendo crippled the CPU in order to make cartridges more expensive" is definitely "[citation needed]" material.
"Citation needed" is for stuff you think is true, but doesn't have a source. I'd say that's just "delete on sight" material, author inserting their own opinion instead of objectively reporting.
Technically what it said (following on from the part about the CPU being weak) was:
This was intentional on the part of Nintendo because it wanted to lower the cost of the system, and it provided connections for cartridges to have their own coprocessors when high performance processing is needed. This naturally drove up the cost of games that required such coprocessors.
Which could be considered technically true, but gives the wrong impression. I deleted it, and gave the following reason (visible only in page history):
This seems to be an unsupported extrapolation. The NES, Genesis and even N64 could and did use special hardware in cartridges; I am unaware of any indication that this feature was related to the choice of CPU in the case of the SNES.
But now I'm worried that I may have started an urban legend about coprocessors in N64 cartridges, which is not what I meant. If some dude on some forum starts claiming WDC or Conker or Naboo had an enhancement chip, you know who to blame...

Next up is to try to finesse some of the CPU stuff...
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: AtariAge "CPU comparison"

Post by Sik »

Even the Atari 2600 did, really (and at some point the Odyssey was going to - that's a console that didn't even have a CPU for starters). I don't recall of any extra hardware in N64 cartridges outside save RAM though, but I may be missing something obvious.

And yeah, people apparently were convinced Donkey Kong 64 really made some proper use of the Expansion Pak until one of the devs came out and admitted it was just to prevent a crash somewhere in the game, so I can see why some people may start thinking some games would need a coprocessor >_>
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: AtariAge "CPU comparison"

Post by 93143 »

Doubutsu no Mori's real-time clock, Mario no Photopi's flash card readers, and Morita Shougi 64's built-in modem. At least, that's what a quick Google turned up.

I didn't know that about DK64. Knowing Rare, it must have been one hell of a bug...
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: AtariAge "CPU comparison"

Post by tepples »

93143 wrote:Mario no Photopi's flash card readers
I wonder whether that game can be exploited to take full control, as Super Mario World and Pokémon Yellow and many Wii games were. Then it would become a flash cart. True, little else uses SmartMedia, but I think a few multi-format card writers that handle xD-Picture cards can still handle SM.
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: AtariAge "CPU comparison"

Post by Sik »

93143 wrote:Doubutsu no Mori's real-time clock, Mario no Photopi's flash card readers, and Morita Shougi 64's built-in modem. At least, that's what a quick Google turned up.
Touché.

And to Rare's credit, DK64 started as a 64DD game (and hence was made with the extra memory in mind). When they decided to turn it into a cartridge game they tried to cram it into less memory, and they did manage to pull it off... except for that one annoying crash, and it happened to stop if the extra memory was present. So they just made the game require the Expansion Pak and they claimed the game made use of the extra memory =P (also probably gave a good excuse to sell the Expansion Pak as it'd later be needed for Ocarina of Time, which was another 64DD to cartridge port)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: AtariAge "CPU comparison"

Post by tepples »

You mean Majora's Mask? Ocarina was a 64DD to cart port, but it came out a year before DK64.
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: AtariAge "CPU comparison"

Post by Sik »

Right, my timeframes keep being all messed up =P (and yeah now that I remember, OOT was always cartridge, Majora's Mask was the disk one that latched onto OOT)
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: AtariAge "CPU comparison"

Post by TOUKO »

I checked the SOR 3's sprites, and i am surprised by the number of sprites used for the foes(and may be for players too).
Up to 10 sprites are used for each meta sprites, it sounds like a wastle to me ..
i don't know how many cpu cycles are used to modify a single sprite entry on Md,but with this system i think a lot .
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: AtariAge "CPU comparison"

Post by Sik »

Yeah, but remember the MD has the ability of displaying rectangular-shaped sprites. In a beat'em-up the amount of tiles to be uploaded is a bigger issue (both for bandwidth and memory usage), so you're better off using more sprites in order to reduce waste from blank areas.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: AtariAge "CPU comparison"

Post by psycopathicteen »

Because audio streaming has been brought up, I wonder how a 1-bit adpcm format would sound like.

Such as something with a formula similar to this:

y(t) = x(t) + 5/2*y(t-1) - 5/2*y(t-2) + 15/16*y(t-3)

where y(t) is the signed 8-bit output, and x(t) is either +8 or -8.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: AtariAge "CPU comparison"

Post by tepples »

CVSD, a form of 1-bit ADPCM, is in Sinistar.
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: AtariAge "CPU comparison"

Post by TOUKO »

Yeah, but remember the MD has the ability of displaying rectangular-shaped sprites. In a beat'em-up the amount of tiles to be uploaded is a bigger issue (both for bandwidth and memory usage), so you're better off using more sprites in order to reduce waste from blank areas.
Of course i thought it was for maximising the sprites bandwidth, but i think (may be i am wrong) it's not really optimal on the number of sprites used, you can use bigger sprites here with the same result (for bandwidth).

For exemple the baseball bat use 5 sprites (8x8) .. :shock: ,good for bandwidth, but a little bit overkill no ??

Even with this , i think the SOR series have a very good sprites engine.
Stef
Posts: 263
Joined: Mon Jul 01, 2013 11:25 am

Re: AtariAge "CPU comparison"

Post by Stef »

Aside bandwidth i believe it has be made that way to optimize the sprite per scanline rendering and avoid sprite flickering as much as possible. That is for me the big advantage of having rectangular sprite (8x32 for vertical object) and sometime you have to use many smalls hardware sprites when you have thin diagonal object (pipe or sword)...
Even with this , i think the SOR series have a very good sprites engine.
Of course they have ;) I observed a bit the SOR2 engine and we can see they cut sprites (i mean just rendering half of it) when they are going out of screen, an optimization to limit the scanline flickering but which require more computation.
Actually having a good sprite engine is definitely something not easy to deal with. I'm certain that many game spent a big part of CPU budget with the sprite engine (not even considering collisions, just about displaying (meta) sprites in a somehow optimized way considering hardware resource limitation).
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: AtariAge "CPU comparison"

Post by psycopathicteen »

I found an audacity plugin that allows me to convert PCM to 1-bit dpcm quality, believe it or not. So far, setting it the output to 4-bit has more white noise, whereas 8-bit is more muffled. I haven't tried 6-bit yet.
ehaliewicz
Posts: 18
Joined: Thu Oct 10, 2013 3:30 pm

Re: AtariAge "CPU comparison"

Post by ehaliewicz »

tepples wrote:The fastest you could scroll on a GS was about 10 to 15 fps using the obscure "PEA field" technique that overlays the stack on the hardware frame buffer, and the back buffer is stored backwards as a block of self-modifying code.
Another guy used the same kind of technique to get what looks like 30+fps scrolling.
http://iigs.dreamhosters.com/gte/gte.html
https://www.youtube.com/watch?v=IsXPn6OCMF8
8-)
Post Reply