[hatari-devel] I'm lucky ;) K.prg is working
Laurent Sallafranque
laurent.sallafranque at free.fr
Wed Feb 24 01:00:52 CET 2010
> Could you try a few programs to see if results are better ?
Worse :
- HMMM demo stops at startup
- Bound2 (it has always been a very timing sensitive demo)
- Solonuminescenz freezes at startup (+ stack overflow, never seen before)
- K.prg still freezes at startup
- Graoumpf tracker reacts like K.prg (it's the same code). It was
running before
- Audio Fun machine give a continuous noisy sound
- H2O intro runs the sound but displays only white screen anf is freezed
- Untgo (Lazer) freezes at startup
- Crown of creation freezes at presentation screen. It was running until
the game.
Better :
- Whip sound seems better (no more noise on left microphone channel)
I've stopped the tests here. There are probably some more programs that
crash now.
The 3 first tested programs are really "timing sensitive".
But, I'll keep this version and try some more tests before eventually
returning (temporary) to older version.
There are still a lot of cycles > 50
122
90
94
126
...
Regards
Laurent
npomarede at corp.free.fr a écrit :
> On Tue, 23 Feb 2010, npomarede at corp.free.fr wrote:
>
>> On Tue, 23 Feb 2010, Laurent Sallafranque wrote:
>>
>>> I've returned to the original code, and I've tried this :
>>>
>>> if (regs.spcflags) {
>>> do_specialties();
>>> // return;
>>> }
>>>
>>>
>>> It doesn't work. (And I think I can't use "F12" or close Hatari's
>>> window, it doesn't react anymore).
>>
>> That's why I said I would have a look this evening, this part of the
>> code is very sensitive :)
>
>> From my understanding, the problem was not calling DSP_Run before
> returning, as this part of the code never returns if the user doesn't
> use the gui.
>
> The problem is that you run the DSP for "cycles" cpu cycles, but this
> doesn't take into account the fact that an exception/interrupt can
> occur and will add at least 56 cycles to the current instruction.
>
> I pushed a new version that correctly compute all cycles spent in CPU
> emulation before calling DSP emulation. Maybe this will not fix all
> problems, but this should give much better synch between cpu<->dsp
> when some cpu interrupts happen (vhl, hbl, ...)
>
> This certainly explains why you got better results when turning timer
> D off. With this new version, you shouldn't get different results when
> timer D is on or off.
>
>
> Nicolas
>
>
>
More information about the hatari-devel
mailing list