[hatari-devel] So, do you have a planned release date for 1.5.0?

Nicolas Pomarède npomarede at corp.free.fr
Sun Mar 20 20:24:53 CET 2011

Le 20/03/2011 19:53, Eero Tamminen a écrit :

> Anything for the STE PowerUp game STE music? :-)


I didn't remember this one ; what's was wrong, so I can see if I can 
reproduce ?

> It would be nice if somebody on this list could check the things that are in
> the compability list mentioned to have issues with Hatari v1.0 or before:
> - Enchanted Lands

The versions I used always worked. What meant "doesn't load at all" ? 
Did it stop after Thalion intro or before ? Could be related to the 
protection, but I don't have an original version to check it.
I think we can remove this "orange" warning.

> - F15 Strike Eagle 2 (I'd remove this if nobody can test it)

I think Thomas committed some fix for this some times ago.

> - DevPac 2.2 Monst (crashy)

Never crashed for me ; since Hatari now handles some complex 68000 
protections using stacks/exceptions/... I think we can remove this one too.

> - Neochrome (rasters)

Someone should test this, but I don't think it's still valid.

> - Protracker STE (50kHz replay)

I don't know protracker STE enough to judge its quality ; if someone has 
some examples I will have a look.

> I tested several Falcon demos using DSP with the old core and it seems that
> several have regressed (at least couple EKO's&  Lazer's demos, Hmmm demo).
> I guess the reason is that how timings are done has changed in DSP_Run()
> from what was in v1.4.  How that gets called is different between the CPU
> cores too:
> ----
> $ grep DSP_Run uae-cpu/*.c
> uae-cpu/newcpu.c:       DSP_Run( Cycles_GetCounter(CYCLES_COUNTER_CPU) );
> uae-cpu/newcpu.c:       DSP_Run( Cycles_GetCounter(CYCLES_COUNTER_CPU) );
> $ grep DSP_Run cpu/*.c
> cpu/newcpu.c:                       DSP_Run(cpu_cycles* 2 / CYCLE_UNIT);
> cpu/newcpu.c:               DSP_Run(cpu_cycles* 2 / CYCLE_UNIT);
> cpu/newcpu.c:               DSP_Run(cpu_cycles* 2 / CYCLE_UNIT);
> Laurent, is there something you could do for this?

This way of counting cycles should be equivalent. The main difference is 
that old cpu doesn't have correct cpu cycle for 68030 instruction (it 
uses 68000 timings) whereas new core has correct 68030 cycle counting.
So, this is not fixable with old cpu core. This is clearly an example of 
things that will only work with new core, nothing we can do about this 
(without loosing a lot of time by duplicating 2 dsp cores).

I wouldn't call these "regressions" in that case, because it was more or 
less working by luck with old cpu core : dsp code was tailored to make 
the demo works with a bad cycle counting. Now that we have correct 
timing in new cpu core, dsp was adjusted to work in the "correct" way.

I don't think we need to "maintain" DSP with old cpu core, regressions 
will happen, but huge improvements will happen too with new cpu core
-> dsp issues with only old cpu core should now be discarded/ignored if 
the programs work with new cpu core.

> PS. WinUAE's core doesn't have DSP_Run() calls in all m68k_run_* functions,
> should it have (at least in few more of them)?

Some m68k_run_* functions are not supposed to be called in Falcon mode, 
so this could be normal. Anyway, we can unify this latter when all other 
cpu issues are fixed.


More information about the hatari-devel mailing list