also there's a sixth cpu dedicated to doing sound but that was the norm at the time
apparently they might've been planning genesis back-compatibility because they used the 68000 as the audio coprocessor in the saturn, the same chip as the cpu of the genesis (this was common; the ps2 used the ps1's main cpu as an audio coprocessor which enabled near-perfect ps1 back-compatibility, and the gba did the same for the gbc)
-F
@curls as we understand it there were two pairs of identical processors (that is, processors a and b were the same, and c and d were the same, but a and b were entirely unrelated to c and d) and one main controller that was a completely different architecture and also included a DSP that was used for matrix calculations for 3D graphics
I don't know if cache was shared; I think main memory was though. vram was Weird™.
-F
@curls as vram usually is. as i understand it it was quad-port ram, which is already pretty strange, with one port for each of the main cpus and gpus, excluding the main controller which i don't think had access to vram
-F
@curls oh also apparently the DSP in the main controller was basically six processors running in parallel and you had to code it like some kind of VLIW thing
we're learning this from https://www.youtube.com/watch?v=c-4Q8Dn6Ndo this video, which is one of the programmers for Sonic R talking about how it worked
-F
@curls oh no it's worse than that, it's not six processors, it's one DSP with a *fully controllable pipeline*
so you don't just tell it "multiply these numbers" followed by "add this number to the result", then "multiply these other numbers", you tell it "multiply these numbers" followed by "add this number to the result while also multiplying these other numbers"
-F
@curls maybe it's better to describe it as having a bunch of parallel fetch/decode units and a bunch of execution units in its single ALU that can all do different tasks at once, instead of the whole ALU being occupied while doing a single instruction that doesn't use half of it
i can't begin to imagine how you'd design a chip like that
-F
@Felthry I can't being to imagine *why*. backwards compatibility aside, it sounds like a Frankenstein monster of components with no direct goal in mind besides allowing more code to run at the same time, potentially. I guess that's just what 3d graphics demanded back then. It's also amazing considering Sonic R was eventually ported to PC.
@curls I'm pretty sure a sega genesis with a sega CD and a 32X attached would be more monstrous, honestly
-F
@Felthry I guess the processors were similar enough that you could offload background stuff to them if you wanted to, but I can't imagine it would simplify anything considering the synchronization and communication would be so complicated. was the cache shared at least?