3 ms·

The Sega Saturn is not an good target to emulate as a lot of code relies on cycle perfect due the lack of locking between the two cores. The J2 has different cy

The Sega Saturn is not an good target to emulate as a lot of code relies on cycle perfect due the lack of locking between the two cores. The J2 has different cycle times from the SH2 used in the Saturn. Since the J2 is quiet modular it might be possible to modify the timings but i somewhat doubtful that 2 vector units and two cores will fit on an affordable for hobbyist FPGA but i honestly don't know. Edit: Changed DreamCast -> Saturn

monocasa 6y ago
That's interesting about the different cycle times given that SH2 is probably one of the most pure 'one instruction per cycle' RISCs out there, even breaking apart the iterative divide into each cycle's operation. Is there any chance you can expand on the issues there?
- freemint 6y ago
  I would have to ask or rewatch all J-Core talks. I recall something like that: "We traded die space for speed so one instruction which takes one cycle on an SH takes 2 on J-Core." If you are really interested i can see if i can come back to you.
- JohnBooty 6y ago
  The Saturn has a complex array of custom chips, including a second SH2, two graphics chips, a DSP, etc. All sharing access to various resources such as memory. https://www.copetti.org/writings/consoles/sega-saturn/ https://www.copetti.org/writings/consoles/sega-saturn/ So, it's notoriously difficult to code for (if you want peak performance) and tough to emulate. I think each individual core is easy to emulate, but the whole salad of chips is another story. Coding Secrets on YouTube has some videos on writing code for the Saturn, like this one. Not SH2 specific, but wow. https://www.youtube.com/watch?v=czqwd43WQWM https://www.youtube.com/watch?v=czqwd43WQWM https://www.youtube.com/watch?v=wU2UoxLtIm8 https://www.youtube.com/watch?v=wU2UoxLtIm8 (mentions the incomplete documentation from Sega, as if the system wasn't complicated enough without iffy documentation as well)
  - nwallin 6y ago
    The Sega Saturn was ridiculous. "Chip salad" is a good way to start characterizing it, but I feel the need to drive it home. * 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.
    - justinjlynn 6y ago
      I honestly do sometimes feel a kind of nostalgia for the diversity and exploration offered by classical console systems. It felt like any unique, but great, hardware architectural idea could take the world by storm. Now it feels like everything has become fairly uniform - an application specific personal computer with essentially the same design. But then again, nostalgia is never what it used to be... So... Eh. You know.
deaddodo 6y ago
> The J2 has different cycle times from the SH2 used in the dream cast. The Dreamcast uses an SH4, not SH2; which is a superset of the SH2 instruction set, let alone completely different timings.
- freemint 6y ago
  You are correct. My bad. But the timing of the J2 and SH2 also differ.

monocasa 6y ago

That's interesting about the different cycle times given that SH2 is probably one of the most pure 'one instruction per cycle' RISCs out there, even breaking apart the iterative divide into each cycle's operation. Is there any chance you can expand on the issues there?

freemint 6y ago
I would have to ask or rewatch all J-Core talks. I recall something like that: "We traded die space for speed so one instruction which takes one cycle on an SH takes 2 on J-Core." If you are really interested i can see if i can come back to you.
JohnBooty 6y ago
The Saturn has a complex array of custom chips, including a second SH2, two graphics chips, a DSP, etc. All sharing access to various resources such as memory. https://www.copetti.org/writings/consoles/sega-saturn/ https://www.copetti.org/writings/consoles/sega-saturn/ So, it's notoriously difficult to code for (if you want peak performance) and tough to emulate. I think each individual core is easy to emulate, but the whole salad of chips is another story. Coding Secrets on YouTube has some videos on writing code for the Saturn, like this one. Not SH2 specific, but wow. https://www.youtube.com/watch?v=czqwd43WQWM https://www.youtube.com/watch?v=czqwd43WQWM https://www.youtube.com/watch?v=wU2UoxLtIm8 https://www.youtube.com/watch?v=wU2UoxLtIm8 (mentions the incomplete documentation from Sega, as if the system wasn't complicated enough without iffy documentation as well)
- nwallin 6y ago
  The Sega Saturn was ridiculous. "Chip salad" is a good way to start characterizing it, but I feel the need to drive it home. * 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.
  - justinjlynn 6y ago
    I honestly do sometimes feel a kind of nostalgia for the diversity and exploration offered by classical console systems. It felt like any unique, but great, hardware architectural idea could take the world by storm. Now it feels like everything has become fairly uniform - an application specific personal computer with essentially the same design. But then again, nostalgia is never what it used to be... So... Eh. You know.

deaddodo 6y ago

> The J2 has different cycle times from the SH2 used in the dream cast. The Dreamcast uses an SH4, not SH2; which is a superset of the SH2 instruction set, let alone completely different timings.

freemint 6y ago
You are correct. My bad. But the timing of the J2 and SH2 also differ.