J2 open processor: an open source processor using the SuperH ISA

What does that entail?

What skillset does one need?

How do you connect with your users? The ones with the weird hardware?

* Two SH-2s. These CPUs occupied different places on the buses (plural) and were generally running different code to perform different tasks. It is incorrect to think of the two CPUs on the Saturn as being equivalent to x86 SMP; (or dual core, for that matter) the two CPUs were not interchangeable.

* An SH-1. This controlled the CD-ROM, and was only able to run code baked into ROM.

* The VDP1. (video display processor #1) It drew sprites and polygons.

* and VDP2, which drew backgrounds.

* A bus controller. The two SH-2s were hard pressed to deliver the computation needed for geometry transforms, so the bus controller contained a DSP which was often used to calculate geometry.

* A 68000. The Amiga, Macintosh, and Sega Genesis (and lots of others) used a 68000 as a CPU. This was generally given control of the...

* FM synthesizer. It was based on the YMF262, aka the OPL3, which drove the Sound Blaster 16.

I think that one of the SH-2s was tied more tightly to VDP1 and the bus controller DSP, and the other was tied more tightly to VDP2. I think I remember reading that a general common architecture was for game logic and VDP2 control to run on one SH-2, and the other SH-2 would feed geometry into the DSP which would feed into VDP1.

The VDP1 was a strange beast. Basically every hardware graphics accelerator you've ever heard of has used polygons as its basic primitive, but not the Saturn. The Saturn used quadrilaterals. It's not incorrect to think of the VDP1 as being a super duper sprite engine that was fast enough to build 3D stuff with sprites.

The VDP1 was not powerful enough to draw the whole screen. If a 3D Saturn game was to look good, significant parts of the screen would have to be drawn by the VDP2. It was mostly up to the task; it could display something like 7 layers of background, with two layers having full perspective control and 5 more with decreasing levels of scaling/translation. (SNES Mode 7 gave 2 layers, one with partial perspective control (I'm forgetting the technical term) and another with just translation) A good looking level/game required incorporating the VDP2's perspective background layer into the level. But since the VDP2 took different parameters than the VDP1 did, lots of games matched the VDP2's background very poorly with the VDP1's foreground.

That system was wild.

One example of such an head ache would be the branch delay slot. It works really well if you have the compiler perform an reorder of instructions for you so the chip can do more while waiting for memory.

In a modern pipeline CPU with register renaming, out of order execution this ISA level reordering would be at best complicating the implementation.

The branch delay slot makes sense where you aim to wait 1-3 cycles for memory loads but becomes a meaningless complication in the face of 10's or 100's of cycles waiting for memory seen on high clocked CPUs today.