Looking for CPU<->SMP interface timing test ROM

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.
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: Looking for CPU<->SMP interface timing test ROM

Post by TOUKO »

I have a question:
If the snes's APU ram was so fast (as i understand between 120 and 100 ns), why the WRAM is so slow ??
It was not a cost problem, because i thing a 120 or 100ns is a complete waste for APU's ram .
It was really for reducing cartridges costs ??
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Looking for CPU<->SMP interface timing test ROM

Post by Near »

Nintendo is infamously frugal on hardware costs.

They could have easily sprung for fast-speed WRAM in SRAM factor, which would've meant that cartridges could've easily gotten away with transferring critical functions into there instead of having to pay for FastROM.

The anemic CPU would've benefited from the lack of DRAM refresh and faster memory accesses.

Of course, the bigger "what if?" loss was that originally the VRAM was designed to be 128KiB, but got halved to 64KiB before shipping. That would have certainly added a few dollars onto the cost, but one can only guess what would've resulted if we'd had that extra memory. (maybe far nicer graphics, maybe no difference at all.)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Looking for CPU<->SMP interface timing test ROM

Post by tepples »

byuu wrote:Of course, the bigger "what if?" loss was that originally the VRAM was designed to be 128KiB, but got halved to 64KiB before shipping. That would have certainly added a few dollars onto the cost, but one can only guess what would've resulted if we'd had that extra memory. (maybe far nicer graphics, maybe no difference at all.)
Probably little difference, given that only 16 KiB of that could be used for sprites anyway.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Looking for CPU<->SMP interface timing test ROM

Post by psycopathicteen »

How much tweaking would it have taken to lower the CPU latency (or whatever it's called) of the 65816 core, like what Hudson/NEC did with Turbografx?
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Looking for CPU<->SMP interface timing test ROM

Post by 93143 »

With 128 KB VRAM, we might have seen more Mode 3 in games...

I don't know how feasible it might have been to hook the CPU up to a 16-bit system bus (as the SA-1 kinda did, but only with the ROM). Could have doubled the speed of DMA and substantially improved processing speed. (Backward compatibility would have been a nightmare, but they didn't end up implementing it anyway, so...) Using SRAM for WRAM, even just the bottom 8 KB, could have sped things up further. Getting rid of the half-cycle strobe, as Hudson did, would have been another big jump.

With the faster DMA, OAM could have been expanded without taking an excessive chunk of VBlank, loosening restrictions on sprite sizes and VRAM coverage. There are six unused bits in OAMADDH, so specifying extra tables could have been supported - or the table position could have been specified in OAM directly, allowing access to all of VRAM. (Now that I think of it, a 16-bit system bus with 16-bit DMA would imply a somewhat different design for the PPU register set...)

Combined with the doubled VRAM, this system would have crushed the Mega Drive even before the addition of the DSP-1. But at what price?

(Oh, and it would have been nice to be able to specify L/R gain on echo sends, rather than just on/off per stereo channel...)
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: Looking for CPU<->SMP interface timing test ROM

Post by TmEE »

MD was actually gonna have 128KB VRAM at some point also (and TeraDrive computer actually has 128KB VRAM connected, and some dev hardware used 128KB also apparently). DMA bandwidth doubles (as it will make the VRAM bus twice as wide), various tables get another address bit for their location and BGs and sprites can choose which 64KB they get their GFX from (there's no room for an additional bit in the tilemap and sprite table entries). Also makes interlace mode pretty much as usable as non interlaced.

I wonder if a custom DRAM part was really that much cheaper than a pair of PSRAM chips in the SNES...
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Looking for CPU<->SMP interface timing test ROM

Post by psycopathicteen »

If they had a SA-1 style CPU in the original system, it would be capable to DMA the entire 16kB of sprites at once and still have a lot of time left over. With the addition of 128kB of VRAM and an improved OAM, you can pretty much animate sprites any old way and not run into problems.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Looking for CPU<->SMP interface timing test ROM

Post by 93143 »

I do honestly regret my comment re: the Mega Drive. All of those changes would have made the SNES a better (and more expensive) console on its own merits; going out of my way to compare this alternate-universe SNES with its real-life rival is kinda pointless and smells of fanboyism. Sega left plenty of potential upgrades on the table too...
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: Looking for CPU<->SMP interface timing test ROM

Post by TOUKO »

I really thing that nintendo don't care too mush of the stock CPU power because they were sure they can extand it easily .
There are too many nonsense choices in the snes's design, 128ko of slow ram(32/64 of faster ram would have been enough),a stock 65816,DMA must be slow because of slow WRAM .
With a simple one phase CPU design, you can double the CPU speed with same RAM/ROM .

I think the goal was the cheapest system possible with an easy evolution ability in mind.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Looking for CPU<->SMP interface timing test ROM

Post by psycopathicteen »

Well, DMA speed was still a problem with enhancement chips, because everything still had to be pushed through to the sPPU side.

You know, I wonder if you can stick an FPGA in the system to act like an overclocked Ricoh 5a22, but I don't know how it would fit. Probably would look like a sloppy mess of wires. Wait, better yet maybe there can be a CPU deactivation mod, to allow the cartridge to control the system directly.
Post Reply