[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