4 ms·

SNES Coprocessors: DSP-1 and Friends

45 points by RicoElectrico 2y ago

Y_Y 2y ago
> so programs will often operate in fixed-point decimal with a 16-bit integer part and a 16-bit fractional part Is this a mistake, or was there really some BCD-type magic going on?
- monocasa 2y ago
  It's not BCD style magic, but just a choice of units. Say instead of in meters, if the unit is 1/65536 of a meter, than you can describe those integers as 16.16 fixed point meters.
- NobodyNada 2y ago
  You're right, it's fixed-point binary with no base 10 involved. I think by "decimal" the author was just referring to the decimal point/the fact that there is a fractional part.
initramfs 2y ago
nice website! SNES were the perfect blend of graphics and speed- not being to slow or fast but really a preview for the 3d world with mode 7 and the FX.
- scheeseman486 2y ago
  I'd argue it wasn't, given than less than a year after they released the console in Japan they started stuffing carts with extra chips to make up for the processor performance shortfall. I'm not sure why they chose the Ricoh 5A22 but it wasn't for it's performance, there were rumors that they were targeting NES backwards compatibility until late in the console's development and the choice of CPU (among other hardware quirks, like the controller signaling) fits into that. Not to say that the SNES wasn't a 2D powerhouse thanks to it's powerful raster effects and developers eventually got better at working around the anemic CPU, but earlier games chugged, particularly if publishers cheaped out and used slower ROMs for the carts which cut the already slow CPU speed from 3.58mhz down to 2.68mhz. Mode 7 was a neat trick, but on the whole the core SNES hardware was really bad at 3D.
djfergus 2y ago
Amazed at the engineering commitment to Shogi (Japanese chess) games. Can anyone comment on the cultural impact of playing shogi on your tv, with a plastic corded controller? The ability to plug in a coprocessor many times faster than the main CPU is such a fascinating option (used all through the 80’s too, eg the Z80 boards for Apple ][) only to be limited to a niche genre…
qingcharles 2y ago
I wonder, with modern math programming knowledge, would it be possible to get the DSP-1 games optimized enough to run without the DSP? I've seen better ways to do things like SIN lookup tables lately that weren't common knowledge in the mid-90s.
- wk_end 2y ago
  Whenever people ask questions like this, my feeling is always: you’re welcome to try :) It’s hard to fathom, for people used to modern computing, just how limited the SNES’ 65816 is. Even at the time it was pretty underpowered. I don’t know about the specific techniques you’re referring to (though I’d be surprised if they weren’t known about back then, when lookup tables were king!) but something to bear in mind is that, in general, most advances in math programming knowledge since that era hinge on the availability of floating point, which is a non-starter for the SNES. The tiny amount of ROM available was also a limiting factor - I think Pilotwings was only 512kb, at most 1mb. There wasn’t even a lot of space for lookup tables!
  - qingcharles 2y ago
    This is the video that got me thinking: https://www.youtube.com/watch?v=xFKFoGiGlXQ https://www.youtube.com/watch?v=xFKFoGiGlXQ I was writing software texturers etc in the late 80s/early 90s, and even recently I've seen x86 people humble me with all sorts of info that I had no idea about at the time, concerning pipelining etc. I would just sit all day randomly reordering assembler instructions and reprofiling teapot renders to see if anything would move the needle.
    - wk_end 2y ago
      Yeah, this is a great example of what I'm talking about. Even though there was only (only!) a roughly five year gap between the two, to bring up the N64 in the same breath shows that you're wildly overestimating what the SNES gave you to work with. The N64 had an FPU and could work with floating point values. The SNES...couldn't. You're talking about pipelining; this video is talking about caches. Well, the 65816 has no pipeline. The 65816 has no cache. If you were writing doing 3D graphics in the late 80s or early 90s, you might've been working with a 286 or 386. These are chips that run circles around the SNES' 65816. And the R4000 in the N64? Forget about it. It was running at a clock speed nearly two orders of magnitude higher than the SNES' CPU, and could do vastly more per cycle to boot.

45 points by RicoElectrico 2y ago

Y_Y 2y ago

> so programs will often operate in fixed-point decimal with a 16-bit integer part and a 16-bit fractional part Is this a mistake, or was there really some BCD-type magic going on?

monocasa 2y ago
It's not BCD style magic, but just a choice of units. Say instead of in meters, if the unit is 1/65536 of a meter, than you can describe those integers as 16.16 fixed point meters.
NobodyNada 2y ago
You're right, it's fixed-point binary with no base 10 involved. I think by "decimal" the author was just referring to the decimal point/the fact that there is a fractional part.

initramfs 2y ago

nice website! SNES were the perfect blend of graphics and speed- not being to slow or fast but really a preview for the 3d world with mode 7 and the FX.

scheeseman486 2y ago
I'd argue it wasn't, given than less than a year after they released the console in Japan they started stuffing carts with extra chips to make up for the processor performance shortfall. I'm not sure why they chose the Ricoh 5A22 but it wasn't for it's performance, there were rumors that they were targeting NES backwards compatibility until late in the console's development and the choice of CPU (among other hardware quirks, like the controller signaling) fits into that. Not to say that the SNES wasn't a 2D powerhouse thanks to it's powerful raster effects and developers eventually got better at working around the anemic CPU, but earlier games chugged, particularly if publishers cheaped out and used slower ROMs for the carts which cut the already slow CPU speed from 3.58mhz down to 2.68mhz. Mode 7 was a neat trick, but on the whole the core SNES hardware was really bad at 3D.

djfergus 2y ago

Amazed at the engineering commitment to Shogi (Japanese chess) games. Can anyone comment on the cultural impact of playing shogi on your tv, with a plastic corded controller? The ability to plug in a coprocessor many times faster than the main CPU is such a fascinating option (used all through the 80’s too, eg the Z80 boards for Apple ][) only to be limited to a niche genre…

qingcharles 2y ago

I wonder, with modern math programming knowledge, would it be possible to get the DSP-1 games optimized enough to run without the DSP? I've seen better ways to do things like SIN lookup tables lately that weren't common knowledge in the mid-90s.

wk_end 2y ago
Whenever people ask questions like this, my feeling is always: you’re welcome to try :) It’s hard to fathom, for people used to modern computing, just how limited the SNES’ 65816 is. Even at the time it was pretty underpowered. I don’t know about the specific techniques you’re referring to (though I’d be surprised if they weren’t known about back then, when lookup tables were king!) but something to bear in mind is that, in general, most advances in math programming knowledge since that era hinge on the availability of floating point, which is a non-starter for the SNES. The tiny amount of ROM available was also a limiting factor - I think Pilotwings was only 512kb, at most 1mb. There wasn’t even a lot of space for lookup tables!
- qingcharles 2y ago
  This is the video that got me thinking: https://www.youtube.com/watch?v=xFKFoGiGlXQ https://www.youtube.com/watch?v=xFKFoGiGlXQ I was writing software texturers etc in the late 80s/early 90s, and even recently I've seen x86 people humble me with all sorts of info that I had no idea about at the time, concerning pipelining etc. I would just sit all day randomly reordering assembler instructions and reprofiling teapot renders to see if anything would move the needle.
  - wk_end 2y ago
    Yeah, this is a great example of what I'm talking about. Even though there was only (only!) a roughly five year gap between the two, to bring up the N64 in the same breath shows that you're wildly overestimating what the SNES gave you to work with. The N64 had an FPU and could work with floating point values. The SNES...couldn't. You're talking about pipelining; this video is talking about caches. Well, the 65816 has no pipeline. The 65816 has no cache. If you were writing doing 3D graphics in the late 80s or early 90s, you might've been working with a 286 or 386. These are chips that run circles around the SNES' 65816. And the R4000 in the N64? Forget about it. It was running at a clock speed nearly two orders of magnitude higher than the SNES' CPU, and could do vastly more per cycle to boot.