Re: [hatari-devel] 060 + DSP -> freeze

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


OK, I understand.

I thought about something like doing 2 68060 instructions and count only one cycle (or an average of the 2 instructions cycles), as the cycles are not really important here.
I mean CT60 users don't optimize their code, but just rely on the frequency of their accelerator card (many of them overclock it to higher frequencies).

Like this, it could "simulate" a 66 Mkh core (2x 32 Mhz), which is close to the CT60 frequencies.

Of course, this would only be available for 68060 emulation (we could also add an entry into the GUI for CT60 emulation now (32 Mhz for now)).

I know this is not really clean, it's just a thought like this, but it would be a nice feature to have a "close" CT60 emu in the next Hatari release ;)
(only if easily feasible of course).

Regards
Laurent


----- Mail original -----
De: "Nicolas Pomarède" <npomarede@xxxxxxxxxxxx>
À: hatari-devel@xxxxxxxxxxxxxxxxxxx
Envoyé: Lundi 29 Décembre 2014 10:37:00
Objet: Re: [hatari-devel] 060 + DSP -> freeze

Le 29/12/2014 00:17, Laurent Sallafranque a écrit :
> The patch is ok, (tested with Starstruck demo again ;)
>
> A little thought : as cycles all take 1 cycles in 68060 mode, would it
> be possible to run faster then 32 mhz only for 68060 to have a faster
> CT60 emulation ?)
>

That's a little complicated with current code, because 1 cycle is 
already the minimal for 1 instruction.
If you divide it again by 2 or 4, you will get 0 cycle per instruction, 
and nothing will work anymore.

Another solution would be to handle non integer cycle count (for example 
0.25). WinUAE has some code to handle this, but it's not used in Hatari 
for now (it would require some rewrite, I didn't have a look at this so far)

But as all cyles are internally multiplied by 256 in latest WinUAE code, 
something should be possible later.

Nicolas






Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/