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

[Eero Tamminen]

Hi,

On sunnuntai 20 maaliskuu 2011, Nicolas Pomarède wrote:
>> Nicolas, what do you think?
> 
> I also think a few improvements were made that would validate a new
> release. Most changes are small, but it's a fact that apart from Falcon
> emulation, Hatari now has a very good compatibility for STF/STE, so
> we're likely to have smaller incremental release in the future.
> 
> On my todo list, I have some fixes for dma audio/video synchronization
> (as reported by Evil / DHS in More Or Less Zero) as well as some
> precision improvements for ym sound. Code for that is already written, I
> need to integrate it and commit it.

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


> I'd like also to improve the first/last 16 pixels in STE mode when
> overscan + hscroll are enabled (color 0 is sometimes shown in Hatari,
> while it wouldn't be seen on a real STE). This would complete the video
> changes I already made for STE since 1.4 was released.
> 
> Regarding a release date, I'd rather have a target around May in order
> to be able to complete the above tasks (maybe it will be ready before).

Sounds good to me.

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
- F15 Strike Eagle 2 (I'd remove this if nobody can test it)
- DevPac 2.2 Monst (crashy)
- Neochrome (rasters)
- Protracker STE (50kHz replay)

As those are really ancient issues...


> Regarding videl, any improvements will go in 1.5 as it should work with
> old CPU core. But I think we should not postpone v1.5 release because of
> Falcon's parts, else it will take much too long before a new release.
>
> We'll release 1.5 with the current state of Falcon's emulation (except
> if there're some real regressions in Falcon mode : we should fix them
> before releasing)

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?


	- Eero

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)?