|Re: [hatari-devel] rev 3689 : splitting cpu cycles above 20|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
I've splitted cpu instruction not for the DSP, but for the sound (maybe
it's not useful and in this case, I'll remove it) :
At 50000 Khz 16 bits stereo, the crossbar needs an internal interrupt
every 60 cycles.
A movem with all the registers can take more than 150 cycles.
A demo like Amanita (DHS) uses a lot of these movem.
So, I've decided to split the big instruction (in cycle) to be sure to
execute all the sound updates between the crossbar and the DSP (in SSI
Do you think this is a good idea ? (I think Amanita sounds better with
it, but I'll have to listen many times with and without the cycle
splitter to be sure of this).
Le 07/01/2012 00:13, Nicolas Pomarède a écrit :
I saw your patch to split cycles when cpu cycles > 20 and call dsp on
every chunk of 20 cycles.
Did you do this for a particular demo/game where this improves the
emulation ? Or is this just a test ? Because I don't think doing this
will change anything to cpu/dsp emulation.
The point is that once you know curr_cycles, it's too late to call the
dsp in chunks of 20 cycles, because the 68030 instruction has already
been emulated, the possible read/write were already done, so splitting
the resulting number of cycles in chunk of 20 cycles will not help the
From the point of view of the dsp, all read/write/memory accesses made
by the 68030 were made at cycles 0. If you split in chunk of 20 after,
it won't change anything, the cpu has already altered its registers or
the RAM or the data exchanged with the dsp.
What you really need is not call dsp_run more often *after* the cpu
emulation, it's to call dsp_run every 4 or 8 cycles *while* emulating
*every* cpu instructions (the same things that winuae does in the most
precise 68000 cycle exact mode).
But doing that is really complicated, because you need to know the
inner working of each 68030 instruction, and that's unfortunately not
described in any official doc.