N64 RDP/RSP

swaaye

Entirely Suboptimal
Legend
Supporter
I've been reading a lot about emulation lately and have been learning a lot about some of the parts of the N64 architecture. I didn't really know before that the big RCP chip had two major parts: the RCP and the RSP (Reality Signal Processor?). The name makes me think it usually deals with audio. I've also read that N64 has some sort of vector unit, this must also be the RSP's task.

I was hoping someone could shed some light on these two pieces. How many things did the RSP end up doing in a typical game? Am I correct in assuming that the "microcode" that many developers hand-tweaked was run on the RSP?

How capable was the RSP/RCP at doing its tasks? Was it really a good idea for Nintendo to keep a dedicated sound chip out of N64? I can't imagine sound is all that cheap. If it was, Gamecube and Xbox (dunno what's in PS2) wouldn't have their own dedicated audio chips.

N64's CPU is really a wimp, and like some have told me on here, it was even more handicapped by the latency of the garbage RDRAM (wtf was N thinking using that stuff?). I'd imagine that doing as much as possible on that RCP chip was the only way to get good performance.....you don't want to try to push any more info across that unified memory than absolutely necessary.
 
The RDP basically just reads a FIFO and raterizes polygons.

The RSP is the transform portion of the RCP, although it's really just a DSP like R4000 core with 8 bit integer vector ops.

In a typical N64 game the RSP would do transforms, lighting, clipping, triangle setup and some of the audio decoding.

The was no specific requirement that the RSP do any of those and it was relatively common to do audio on the main CPU to increase the graphics performance. I've also worked on N64 games that used custom uCode and clipped on the main CPU.

The RSP is completly programmable, but only a very few devs at the end of the N64 lifecycle were given documentation and tools to rewrite the uCode.

FWIW writing N64 RSP code (triangle setup in particular) makes writing PS2 VU code look trivial.
 
Thanks for the explanations ERP. You worked at BOSS right? I loved Top Gear Rally and World Driver. Spent hours and hours with Top Gear Rally instead of studying for physics. :devilish:

Heh, it sounds like the N64 architecture was designed to be a pain in the ass. You guys had to try to figure out what processors to use for what.

Makes me think the engineers didn't design it with a specific goal in mind for each part. Or they didn't really know how games were programmed and laid out a bad design which was later reworked (as best as possible) by game developers to make the most of it all.

It also amazes me that Nintendo was so secretive with the uCode tools. You'd think they'd have wanted the developers to have the best access possible to the hardware to make games that stood out. Instead it sounds like they kept the ucode programmability for their 1st party teams. Or they were just dense and didn't see the opportunity......

If one thing about N64 could be changed, what would it be? Texture cache? Different RAM? Non-unified RAM? Another vector unit? Blah Blah?
 
No as a whole although the system had some glaring problems it was well designed. The principles were clearly based on early SGI hardware.

I believe the issue with RSP docs and tools was as much about support as anything else. SGI had bad experiences when they'd given one of their customers uCode access previously to one of the RE's. There may also have been some degree of fear on Nintendos part about quality control and test. Setting up extremly subtle bugs in the uCode was really very easy.

The tools were incredibly basic, no working debugger, and the docs were not much more than an instruction list, we got finally got them after years of requesting them under the understanding that there was no tech support.

I worked on both TGR and WDC, including writing the uCode for the later.
 
Re: N64 RCP/RSP

swaaye said:
N64's CPU is really a wimp, and like some have told me on here, it was even more handicapped by the latency of the garbage RDRAM (wtf was N thinking using that stuff?). I'd imagine that doing as much as possible on that RCP chip was the only way to get good performance.....you don't want to try to push any more info across that unified memory than absolutely necessary.

Garbage RDRAM or not you gotta remember this gaming console was released in 1996 when the other high end competing gaming platforms were the SEGA Saturn (1994), Sony Playstation (1994) and whatever was considered highend in 1996 in the PC world.

There was also the SEGA Model 3 Arcade hardware that was released in 1996 with Virtua Fighter 3 but that hardware was beyond the price of a high end PC back then.

RDRAM finally arrived in PCs in late 1999, made a console comeback in 2000 with PS2 and is due a redesign/refresh with XDR-DRAM some time this year or next.

Heh, it sounds like the N64 architecture was designed to be a pain in the ass. You guys had to try to figure out what processors to use for what.

Supposedly there were game devs that complained that SEGA's Saturn was a nightmare to program for due to having dual cpus. N64 supposedly had the same complaints for the reasons you noted however that did not stop game developers from cranking out games like Mario 64, Zelda OoT, World Driver, Top Gear series, Turok series, GoldenEye 007 by RARE, Pokemon Stadim series, Donkey Kong 64, Star Fox 64, Nights into Dreams, Burning Rangers, Virtual On, Virtua Fighter 2, Radiant Silvergun, XMen vs Street Fighters, Panzer Dragoon series Saga, etc, including a prototype Shenmue.

In fact the biggest handicap the N64 ever had was that it did not have the 64DD even remotely ready for launch in 1997 to provide the N64 with something to answer the CD-Rom media standard of back in the dayz.
 
In fact the biggest handicap the N64 ever had was that it did not have the 64DD even remotely ready for launch in 1997 to provide the N64 with something to answer the CD-Rom media standard of back in the dayz.
i agree with this wholeheartedly. seriously, what has really been accomplished, gameplay wise, on this generation of consoles that really couldn't be done on the n64 (assuming a mass storage solution)? not much really, save a few break out titles.
 
I played MANY more N64 games than games on any of the newer consoles. I have gamecube and Xbox and really only enjoy maybe 6 games combined. My favs this gen are Eternal Darkness, Halo, F-Zero GX, KOTOR, ExtremeG 3. I also have Rogue Leader and Rebel Strike but they are too arcade-y for me....but I love the graphics and the theme :) I just wish Factor 5 would go more space-sim style, ala X-Wing/TIE Fighter.

To me a lot of the games are just retreads, like you (Akumajou) sort of imply, of genres established on the first gen of 3D consoles. I never had a Saturn. PSX wasn't all that appealing to me. I bought it only for Gran Turismo, but did play the hell out of that.

N64 is really an intriguing hardware design. It's obviously massively cost oriented, with as few dedicated chips as possible. It's just sad that their only choice back in '93-'94-'95 when it was being developed for fast RAM was the horribly latency overwhelmed RDRAM. I have a feeling that some DDR SDRAM in there would have made an incredible difference.

I'm not convinced that the cartridges were that much of a handicap. Sure they were a pain, but they had serious advantages in load time. I hated PSX's load time and CDROM cranking noise. From the sound of it texture quality on N64 was primarily limited by the 4K texture cache while the RDRAM destroyed processing efficiency of the entire system. Cartridge would be the last to go, IMO. At least in that gen.

It's amazing how much Gamecube remedied that situation. You don't hear developers complaining about RAM latency or texture limitations anymore :)
 
Nintendo64 should have had 8-10 MB of lower latancy RAM and 16k texture cache. especially by 1996, but unfortunately, the spec was kept at what was to be used in 1995.
 
As crippled as the N64 processor was it was still a lot better than the PSX it was competing with.

It had signficant bandwidth problems when rendering with Z on.

And of course the 4K texture cache needed to be bigger.
 
Strange tho that PSX games typically ran at faster framerates and with more polys on-screen. Could this be due to the less than ideal microcode libraries for the RSP or what?
 
It was a combination of things.

As I mentioned, with ZBuffering on (nearly all N64 games) the RDP was pretty fill limited.

The early uCode libraries were way too accurate and as a result not very fast. The somewhat ironically named "Fast3D" uCode, later versions of the uCode were a lot better.

And quite honestly there was a shortage of high quality developers on N64, and it was an easy machine to screw yourself and et very poor performance on.

I would bet, and I don't have any evidence outside most of my own testing, that the majority of N64 games were fill limited and not polygon limited.

I also think that there are a lot of inflated PSX numbers, and a lot of people assume that N64 games had a lot less polys simply because of the poor textures in a lot of cases. I've run a lot of top tier PSX games through emulators when they first stated to appear just to look at what they were actually doing and most have far fewre polygons on screen than the claims that were floating around.

FWIW I'd also guess that WDC pushes more polygons that most PSX games (significantly more than any I ever looked at in an emulator). And probably more than any other shipped N64 game but I couldn't proove that. It renders everything with no Z buffer, and the transform load was shared between the main CPU and the RSP. For the most part it demonstrates extremly balanced RDP/PSP/CPU usage.

Most other uCode tweaks I know of were slight performance gains or tweaks to the lighting model.
 
World Driver was a very impressive game for sure ERP. I was really only impressed with TGR and WDC as far as racing, and maybe FZero X. Most of the other racers were too fake with regards to control, IMO. Especially some of the other Top Gears.

I'm thinking of hitting eBay and rebuilding a small collection of N64 games. I'm regretting selling everything a couple of years ago :)
 
DDR-SDRAM in the N64 wasn't possible. N64 debuted in Q2 1996, DDR RAM wasn't available commercially until Q1 2001.
 
Really?

Why my old GF2 GTS had 32MB of DDR-SDRAM at 200Mhz if the graphic card was released in the year 2000?
 
Doesn't matter, as that's still three to four years after the launch of the console. Besides, DDR memory would have required many more pins on the RCP packaging, one RDRAM channel (1st gen, remember) is just 13 signal pins if I remember correctly, + a few grounds and power on top of that (which would be fed from the PCB, not RCP).
 
What were the actual latencies of N64 mem anyway?

I know why and how RDRam got the bad rep with early Intel PC boards, but if you measure CPU access latencies on PS2, the results are pretty much in-line with DDRs of the time.
 
Fafalada said:
What were the actual latencies of N64 mem anyway?

I know why and how RDRam got the bad rep with early Intel PC boards, but if you measure CPU access latencies on PS2, the results are pretty much in-line with DDRs of the time.

We timed it at about 64 clock for a read. (I guess that's about 640ns give or take).
There was no way to prefetch and no read under write.
 
Fafalada said:
if you measure CPU access latencies on PS2, the results are pretty much in-line with DDRs of the time.

Doesn't surprise me that much really, as latency with DRDRAM varies a lot with how many devices sits on the channel. Accesses to the first device is auto-penalized by the hardware to be just as slow as the last - and a channel can be 20+ cm long and have 32 devices on it. It can be so long several words will be sent out by a memory device before the first word in the burst reaches the memory controller... :p

64 clocks with plain RDRAM tho is pretty brutal! UGH. I knew it was BAD, didn't think it would be THAT bad! SGI used multiple RDRAM channels in their cheaper gfx hardware, the Indigo workstation had four parallel RDRAM channels (4x8 bits @ 500MHz = 2GB/s theoretical, though it could have been 600MHz too or even faster I guess), hopefully that would have brought down access times a bit.

Guess dual channels would have been too expensive for Nintendo, though the hardware sure seems to could have used it...
 
640ns! Is that en par with EDO DRAM?

But really, when N64 was being created, EDO was the state-of-the-art. SDR SDRAM showed up around 1996, but that was way too late for it to show up in N64, and it would have been premium priced too.

Oh well, I suppose we must admit that RDRAM was definitely the way to go for a system being developed in 1993-5 or so.

With latency like that there was sure no way they were able to take advantage of the purported 500MB/s bandwidth. What did usable bandwidth end up being?
 
Back
Top