6 ms·

> Most likely most game devs used someone else's RSP code Yeah, almost all RSP code used was written by SGI/Nintendo and used as shipped in the SDK. For a lon

> Most likely most game devs used someone else's RSP code Yeah, almost all RSP code used was written by SGI/Nintendo and used as shipped in the SDK. For a long time emulators simply high level emulated the RSP code based on the hash of the RSP binary and accepted that a few games like Rogue Squadron simply wouldn't run.

JamesSwift 4y ago
I couldnt find an answer online... what does RSP stand for?
- mikepurvis 4y ago
  Reality Signal Processor: https://www.retroreversing.com/n64rsp https://www.retroreversing.com/n64rsp Basically a very, very early programmable GPU, but you were writing actual firmware for it, rather than writing the kind of high level shader functions that would come a decade+ later.
  - tadfisher 4y ago
    I always heard it referred to as "microcode", and there were different RSP microcode packages floating around, shipped by Nintendo/SGI, or programmed from scratch and included in the ROM.
    - monocasa 4y ago
      Yeah, it was called that, but the term microcode was a bit of a stretch. It's a relatively straightforward 32bit MIPS with a 8x16bit SIMD vector unit strapped to the side as MIPS coprocessor 2. One cute thing is that since it can only access 4KiB of data, and load/store offsets in MIPS machine code are 12 bits, you can build any pointer in the load/store itself simply offsetting from the zero register. That's in contrast to most MIPS code where you generally need to build the pointer in a register first (or at least burn a register to be the global pointer).
      - moring 4y ago
        Just to point out: You can still do this (with any processor that has a zero-register, otherwise you'd still have to "burn" a register and you could just use a real global pointer). This technique isn't made impossible by larger RAM, it just cannot access anything beyond 4KiB (1). If that is enough for your "hot" data, you could still use it. (1) 2KiB for RISCV, because immediate offsets are 12bits signed, and the upper end of the address space is usually not mapped to RAM. That is, 4KiB are possible with RISCV if you control the memory map.
        monocasa 4y ago
        A lot of processors don't even map usable RAM at address zero is the real problem. For instance a lot of simpler RISC-V chips are copying the basic Cortex-M memory map which places ROM low in memory. Even on systems with MMUs, it's very common that the kernel won't let you map RAM at address zero for several reasons. And the sizes are being talked about are about the size of a single page.
kmeisthax 4y ago
I've heard Nintendo didn't even release an RSP SDK until really late in the N64's life cycle. AFAIK Factor 5 loved writing custom microcode for it.
- somat 4y ago
  I would bet it was not "loved", probably more "hate it with the passion of a thousand suns". Any way you slice it, they were good at it. I bet whoever worked at factor 5 in the RSP department would have some good war stories to tell.
  - Arrath 4y ago
    Yeah I would love to read some if they ever surfaced.
  - aikinai 4y ago
    I briefly worked with the guy. Knowing him, I expect he loved it.
fexecve 4y ago
There's a fun conspiracy theory that Nintendo intentionally made the default RSP binary they provided sub-optimized, so that later in the console's life they could release an optimized version so that games continue to appear to get better. This is likely entirely rubbish, of course.
- monocasa 4y ago
  Yeah, probably rubbish. What's more likely is that it started as a fairly straightforward port of the code for SGI's RealityEngine 3D accelerators which were focused a bit more on correct offline rendering than real time.
- justinator 4y ago
  Not sure about your story, but there was a pretty bad bug in Mario 64 - their flagship game, that degraded performance. If I remember, the fix was a one-line change.
  - leidenfrost 4y ago
    One line change, from a developer that consistently analyzed the decompiled data over the course of years, and with 2020's tooling. The original devs were in a time crunch in the 90s with the limited experience they had for 3d games. It's possible that they were aware of the bug but said "eh, it's playable" and launched it.
    - justinator 4y ago
      > but said "eh, it's playable" and launched it. That does not sound culturally Japanese to me.
    - als0 4y ago
      I think you raise the right point. I remember reading about how the team was burned out. > What was the atmosphere like during the final days of coding? I think there was a lot of panicking going on. But it was still very organised, there was lots of people working very hard. I think it was quite laid back at the very end, not many bugs, gameplay was sorted out on time. One of the programmers had quite a hard time of it – two of them decided not to make games anymore because of Mario 64. Not because they didn’t enjoy it, but because they’d burnt themselves out. https://pixelatron.com/blog/the-making-of-super-mario-64-full-giles-goddard-interview-ngc/ https://pixelatron.com/blog/the-making-of-super-mario-64-ful...
lostgame 4y ago
Didn’t Rare often write their own custom RSP microcode? Maybe I’m mixing that up with another developer, but I think I read that in an interview.
- foldor 4y ago
  Rare had many teams working siloed and independently. The team that made Diddy Kong Racing made a custom microcode based heavily on the official Fast3D with several differences. This microcode was updated and used in that teams next N64 games Jet Force Gemini, and I believe it was also used in their next cancelled game Dinosaur Planet, which later was released on GC as Starfox Adventures. I'm reasonably certain it was used in Mickey's Speedway USA as well, but I'm not certain.
danbolt 4y ago
It’s kind of a shame that the standard library’s scheduler didn’t let you enqueue your own microcode tasks to be executed. I think a lot of games could have their own custom SIMD logic and made some unique stuff.

JamesSwift 4y ago

I couldnt find an answer online... what does RSP stand for?

mikepurvis 4y ago
Reality Signal Processor: https://www.retroreversing.com/n64rsp https://www.retroreversing.com/n64rsp Basically a very, very early programmable GPU, but you were writing actual firmware for it, rather than writing the kind of high level shader functions that would come a decade+ later.
- tadfisher 4y ago
  I always heard it referred to as "microcode", and there were different RSP microcode packages floating around, shipped by Nintendo/SGI, or programmed from scratch and included in the ROM.
  - monocasa 4y ago
    Yeah, it was called that, but the term microcode was a bit of a stretch. It's a relatively straightforward 32bit MIPS with a 8x16bit SIMD vector unit strapped to the side as MIPS coprocessor 2. One cute thing is that since it can only access 4KiB of data, and load/store offsets in MIPS machine code are 12 bits, you can build any pointer in the load/store itself simply offsetting from the zero register. That's in contrast to most MIPS code where you generally need to build the pointer in a register first (or at least burn a register to be the global pointer).
    - moring 4y ago
      Just to point out: You can still do this (with any processor that has a zero-register, otherwise you'd still have to "burn" a register and you could just use a real global pointer). This technique isn't made impossible by larger RAM, it just cannot access anything beyond 4KiB (1). If that is enough for your "hot" data, you could still use it. (1) 2KiB for RISCV, because immediate offsets are 12bits signed, and the upper end of the address space is usually not mapped to RAM. That is, 4KiB are possible with RISCV if you control the memory map.
      - monocasa 4y ago
        A lot of processors don't even map usable RAM at address zero is the real problem. For instance a lot of simpler RISC-V chips are copying the basic Cortex-M memory map which places ROM low in memory. Even on systems with MMUs, it's very common that the kernel won't let you map RAM at address zero for several reasons. And the sizes are being talked about are about the size of a single page.

kmeisthax 4y ago

I've heard Nintendo didn't even release an RSP SDK until really late in the N64's life cycle. AFAIK Factor 5 loved writing custom microcode for it.

somat 4y ago
I would bet it was not "loved", probably more "hate it with the passion of a thousand suns". Any way you slice it, they were good at it. I bet whoever worked at factor 5 in the RSP department would have some good war stories to tell.
- Arrath 4y ago
  Yeah I would love to read some if they ever surfaced.
- aikinai 4y ago
  I briefly worked with the guy. Knowing him, I expect he loved it.

fexecve 4y ago

There's a fun conspiracy theory that Nintendo intentionally made the default RSP binary they provided sub-optimized, so that later in the console's life they could release an optimized version so that games continue to appear to get better. This is likely entirely rubbish, of course.

monocasa 4y ago
Yeah, probably rubbish. What's more likely is that it started as a fairly straightforward port of the code for SGI's RealityEngine 3D accelerators which were focused a bit more on correct offline rendering than real time.
justinator 4y ago
Not sure about your story, but there was a pretty bad bug in Mario 64 - their flagship game, that degraded performance. If I remember, the fix was a one-line change.
- leidenfrost 4y ago
  One line change, from a developer that consistently analyzed the decompiled data over the course of years, and with 2020's tooling. The original devs were in a time crunch in the 90s with the limited experience they had for 3d games. It's possible that they were aware of the bug but said "eh, it's playable" and launched it.
  - justinator 4y ago
    > but said "eh, it's playable" and launched it. That does not sound culturally Japanese to me.
  - als0 4y ago
    I think you raise the right point. I remember reading about how the team was burned out. > What was the atmosphere like during the final days of coding? I think there was a lot of panicking going on. But it was still very organised, there was lots of people working very hard. I think it was quite laid back at the very end, not many bugs, gameplay was sorted out on time. One of the programmers had quite a hard time of it – two of them decided not to make games anymore because of Mario 64. Not because they didn’t enjoy it, but because they’d burnt themselves out. https://pixelatron.com/blog/the-making-of-super-mario-64-full-giles-goddard-interview-ngc/ https://pixelatron.com/blog/the-making-of-super-mario-64-ful...

lostgame 4y ago

Didn’t Rare often write their own custom RSP microcode? Maybe I’m mixing that up with another developer, but I think I read that in an interview.

foldor 4y ago
Rare had many teams working siloed and independently. The team that made Diddy Kong Racing made a custom microcode based heavily on the official Fast3D with several differences. This microcode was updated and used in that teams next N64 games Jet Force Gemini, and I believe it was also used in their next cancelled game Dinosaur Planet, which later was released on GC as Starfox Adventures. I'm reasonably certain it was used in Mickey's Speedway USA as well, but I'm not certain.

danbolt 4y ago

It’s kind of a shame that the standard library’s scheduler didn’t let you enqueue your own microcode tasks to be executed. I think a lot of games could have their own custom SIMD logic and made some unique stuff.