Re: [hatari-devel] Emulation on separate CPU cores

[ Thread Index | Date Index | More Archives ]

Le 04/12/2022 à 11:55, Miro Kropáček a écrit :
On Sun, 4 Dec 2022 at 11:20, Thorsten Otto <admin@xxxxxxxxxxx <mailto:admin@xxxxxxxxxxx>> wrote:


    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 and apple.

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.


Mail converted by MHonArc 2.6.19+