Re: [hatari-devel] Does CPU setting work?

[ Thread Index | Date Index | More Archives ]

I think it could solve also couple of other things, I don't know how it's done now but generally, the clock should be divided into separate entities like Videl, DSP, CPU, FPU, bus, ... so the setting shouldn't be actually CPU 16/32 but something as "base clock multiplier" to simulate functionality of Nemesis/Phantom, as this is the only setting which makes sense for non-accelerated setup (by accelerated setup I mean emulation of CT2, CT60, ...)

Btw, I have also noticed that 16 MHz setup isn't exactly 16 MHz, at least when it comes to bus activity, it gives me faaaar better results than on real hardware.

And btw #2, what about the winuae build crashing, is it now in some kind of development stage, i.e. it's OK if it crashes (for example Moai or Menace used to work, now they don't).

On Mon, Jul 1, 2013 at 5:44 AM, Laurent Sallafranque <laurent.sallafranque@xxxxxxx> wrote:

I think this is one of the first problems to fix for the 68030 accuracy emulation (I mean a real 16 Mhz clock) and not a 8 Mhz with cycles divided by 2.


Le 30/06/2013 15:53, Douglas Little a écrit :
I also noticed this but wasn't sure if the problem was specific to my own build...

The implementation also looks like it divides instruction cycles by N (e.g. divide by 2 for 32mhz?) and some instructions take an odd number of cycles (e.g. several common ops take 3 cycles)... so it's only approximately 2x speed.


On 30 June 2013 10:21, Miro Kropáček <miro.kropacek@xxxxxxxxx> wrote:

to my surprise, setting CPU to 16 or 32 MHz makes no difference in performance of my CPU/DSP app at all (when I measure FPS for example). I tried the "basic" Hatari only as Hatari/WinUAE is giving my a nice set of bus errors and crashes with my DSP stuff.

Is this intentional/known fact?

MiKRO / Mystic Bytes

MiKRO / Mystic Bytes

Mail converted by MHonArc 2.6.19+