| Re: [hatari-devel] rev 3689 : splitting cpu cycles above 20 |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
> with 3 specific falcon functions for this, I think it should be fine
to do a lot of the videl emuation (and then call the usual functions to
display the resulting pixels on screen)
Yes, that would be the main idea.
I'll check all the "problems" I detected so far in a next thread, and
we'll see together what to do for this.
Thanks
I've spent a lot of time in the 68030 cycles and the DSP cycles.
I think the DSP is now quite "accurate". I will stop working on it for a
while.
I would like now to concentrate on the 68030 part of the falcon only
(without involving the DSP).
Then I'll reintroduce the DSP and finish to fix the accuracy.
But I need a better accurate 68030/crossbar /videl before.
I'd like to add the FIFO to the crossbar first.
Then, I'd like to have a look at the videl.
My aim would be to :
1) have a working videl (HBL, VBL, TIMERS, correct display, "Rasters
:)", ...)
2) be able to use the videl "bean position" to do precise measures (as
you do with the shifter with the Video_GetPosition(),
Video_Calculate_adress(), ... functions).
I would like to run 10 NOPs and read the beam position, then compare
with my real falcon and get the same value (or close).
Then I could measure all the instructions and verify is they're using
the good cycle timings. (10 ADD, 10 DIVS, 10 MOVEMS, ...)
(10 is an arbitrary value, it could be 1 instruction, or 1000 instructions).
The same after for some crossbar exchages if necessary.
This wouls also allow to add correctly the VIDEL Waitstates.
Do you agree with this ?
Laurent
Le 07/01/2012 00:49, Nicolas Pomarède a écrit :
On 07/01/2012 00:28, Laurent Sallafranque wrote:
Le 07/01/2012 00:13, Nicolas Pomarède a écrit :
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.
Yes, I agree here.
For now, I don't try to be that accurate (and it wouldn't make sense
from my point of view, as DSP and 68030 are working with different
clocks).
This kind of optimisations would be for a specific case and would
necessite a lot of energy to code it.
I'm more trying to have a "cycle accurate" 68030 because it's it who
drives all the other components (and the DSP).
OK, but we should avoid putting "test" code that don't have a really
measurable impact in the source tree. Else, it's difficult for other
people that might want to help to understand the way emulation works.
If the while has no effect (which is what I think in almost every
case), then we should remove it ; it adds unncessary code to the cpu
emulation (which is already quite complicated :) )
I'm soon going to start the videl emu.
I already tried it once last year, but there's a problem for now : the
video code is too much melted in many hatari functions.
I don't want to add some if falcon else STE everywhere in hatari to
point on the videl code or the video code.
(I managed to split properly crossbar and stedma sound, because SteDma
sound was not too much melted into hatari's source.
Video source is a nightmare (it's called from too much other sources).
Do you think it would be possible to separate the calls of video.c
before I split, just to do it cleanly ?
Yes, it's possible. But you would need to list what functions you want
to split according to your code, so I can give a look.
In my opinion, there shouldn't be that much code to split :
- vbl
- hbl
- timer b interrupt
with 3 specific falcon functions for this, I think it should be fine
to do a lot of the videl emuation (and then call the usual functions
to display the resulting pixels on screen)
Nicolas