[J-core] Sega saturn retrocomputing.

[Rich Felker]

On Tue, Jul 19, 2016 at 03:44:08PM -0500, Rob Landley wrote:
> 
> 
> On 07/19/2016 08:55 AM, Christopher Friedt wrote:
> > On Jul 18, 2016 11:51 PM, "Rob Landley" <rob at landley.net
> > <mailto:rob at landley.net>> wrote:
> >>
> >> FYI:
> >>
> >> http://hackaday.com/2016/07/11/cracking-the-sega-saturn-after-20-years/
> > 
> > I think I sent a link on the ML to the YouTube video about a week ago.
> > 
> >> (Alas, when we looked at possibly doing an FPGA saturn clone with J2 as
> >> a side project for the 20th anniversary, it turned out there were some
> >> tight timing constraints that make games misbehave very easily, at least
> >> in software emulation. I think some j2 instructions take different
> >> numbers of clock cycles than sh2 did? Don't remember the details, but we
> >> shelved the idea...)
> > 
> > I'm still interested in doing some Qemu work. Currently the SH core
> > (even before J2 additions) is not cycle-accurate, which is a bit of a
> > critical error made by the initial Qemu SH port.
> 
> No, qemu is never cycle accurate for anything it emulates. It's a
> dynamic code translator, not a cycle accurate simulator. (Cycle accurate
> simulators are 1/100th the speed of qemu. At a design level you can only
> ever get cycle accuracy by slowing DOWN from the fastest you can do, and
> caring about that level at all opens a can of worms of complexity that
> costs you an order of magnitude of speed before that's even an issue in
> the first place.)

Slowing down everything to worst-case is only needed if you're trying
to synchronize to an external real-time clock. If you just need
cycle-accuracy between components of the emulated system and only
synchronizing to real-time occasionally (like once per video frame)
then high performance is very possible. There's no reason it can't be
done with a dynrec approach (inserting synchronization in the
translated instruction stream at every instruction that can
potentially access other hardware/other cpu cores; this has
non-trivial but non-catastrophic cost) but it's also possible to do
fast interpreted emulation. I know approaches that should be at least
20% as fast as qemu and perhaps 50% or better.

Rich