SNES Coprocessors: DSP-1 and Friends | Hacker News Reader

SNES Coprocessors: DSP-1 and Friends

jsgroth.dev

45 pointsRicoElectrico14 comments

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…

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.

Definitely not. Even a simple multiply is extra hardware on the SNES, and the fast multiply is part of the PPU such that you can't use it while mode 7 is active. That is why Mario Kart and Pilotwings in particular are using the DSP.

You could get away with it by reducing freedom of motion and achieving something akin to f-zero.

Also, trig tables were very common. Near discovered that the the entire CX4 processor's hardware ROM was just a lookup table.

Yeah, I used a ton of trig tables for software renderers in the late 80s/early 90s, but I'm just throwing ideas out there, since I've seen a lot of really great optimizations recently that were mostly missed during that time. This guy puts a lot of work into figuring out if there is a faster way to do trig calcs on the N64 than was used in SM64 (spoiler: there is):

https://www.youtube.com/watch?v=xFKFoGiGlXQ

Jez (CEO of Argonaut) once offered me an interview for the Starfox/DSP team, so I almost worked on this thing. He was very active on the coding groups on Usenet around that time.

I also thought of Kaze Emanuar in this context. His videos on optimizing for the N64 are amazing. Of course the optimizations he shows are really specific to the weird mini-SGI hardware, but it would be cool to see someone try to do something similar with the SNES.

Snesdrunk has pointed me to a couple of performance-focussed romhacks, the only one I can remember right now is https://www.romhacking.net/hacks/7163/

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!

This is the video that got me thinking:

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.

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.

Appreciate the feedback. I was just throwing a wild idea out there. I didn't know underspec'd the SNES CPU was. I think I was probably up to a 486@25Mhz by the time I was arguing with Jez [San of Argonaut] on Usenet about rendering optimizations!

> 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?

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.

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.

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.

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.

Reply on news.ycombinator.com