|Re: [hatari-devel] Emulation on separate CPU cores|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 04/12/2022 à 11:55, Miro Kropáček a écrit :
On Sun, 4 Dec 2022 at 11:20, Thorsten Otto <admin@xxxxxxxxxxx
I agree with Eero. Also he probably doesn't have the problem to be
cycle exact, since are no programs for Jaguar that depend on any
hardware tricks which rely on that.
I wouldn't be so sure about this. From his Patreon article
/The Jaguar is in a uniquely magical/terrifying place, where we have
some reasonably powerful chips and components operating in true
parallel, but we also still require a high degree of cycle accuracy if
we hope to maintain any kind of stability with the software./
/There was one fun case where the software had written a test to see if
the Blitter was finished with an operation, and if we hit that code
while the Blitter was indeed running, instead of spinning while reading
the Blitter status, the code would jump back to the instruction after
the read and just spin there checking an unchanging register forever!
This means that through a miracle of timing, on real hardware, we were
just never managing to get to this point in code while the Blitter was
operating, even though the developer had gone out of their way to expect
and handle such a case. They handled it in a way that would explode if
it were ever put to the test, and my emulator put it to the test! This
was the nature of most of the bugs I encountered in the final stretch,
incredibly delicate timing scenarios./
To me it looks like there's a fair amount of cycle accuracy emulated.
That guy is really good, so I wouldn't dismiss his achievement simply as
"nah, surely his emulator isn't that accurate and that's why it's so fast".
It's not about lessening what he did, but we're talking about different
hardware, so what can benefit for jaguar is not necessarily working for ST.
also, he wrote himself in the todo list that the emulator should emulate
bus access (not the case at the moment) and have cycle accuracy, so this
simplifies things a litlle at the moment.
as other pointed, what kind of parallelism does he do on several cpu ?
at the instruction level, on every HW access ? we don't know and at the
moment there's no source code to have a look.
so, I have nothing against this emulator, but let's not compare orange
Hatari is cycle accurate to 4 cycles or less ; for example consider on
ST the case where cpu and blitter run in parallel (non hog mode) for 64
bus accesses ; this makes 626 bus changes between blitter and cpu per
vbl, 31300 per sec. I'd really like to see the code that make a cpu
thread and a blitter thread working in parallel this way and the
overhead it adds just to keep the 2 threads in sync, with so many
context switches per sec.