Re: [hatari-devel] Re: Next release

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 17/10/2016 à 10:56, Nicolas Pomarède a écrit :
> Le 16/10/2016 à 22:45, Eero Tamminen a écrit :
> > Hi Nicolas,
> >
> > Are you still planning to state saving rewrite before 2.0
> > release?
>
> Hi
>
> no, this will be after 2.0, else it would delay it again.
>
> > There are some remaining tasks at least for documentation:
> > * Change 1.9+ in compat list to new version number
> >   (and check that few of those earlier fixed still work)
> > * Complete release notes.  I think at least some things
> >   that Thomas did which might not yet be there (SCU/VME,
> >   ACSI...)
> > * todo.txt needs a lot of updates also, several listed
> >   items have been dealt with
>
>
> I will look at todo.txt to remove entries ; Thomas, could you check if
> release.txt includes your changes ?


Regarding those todo :

- Finish upgrading the CPU core of Hatari to the latest WinUAE
  which has better cycle accuracy needed by some programs:
        - Add Exception debugging support
        - Instead of calling Reset_Cold()/m68k_reset()/uae_reset()
          directly from newcpu.c, show user a notice (dialog)
          about what happened and let user do the reboot
          (see "Emulation reset, old-UAE vs. WinUAE core" mail-thread)
        - Make WinUAE core ST/STE emulation as good as with old UAE core
        - Document cmdline options for selecting prefetch etc
          once they're stable

->
- what does exception debugging support means ?
- I don't see any more call to reset directly, we have a dialog in case 
"halt" is reached, so point 2 could be removed.
- point 3 is done
- point 4 seems done too ? At least the doc mentions the accuracy 
difference between prefetch and cycle exact.



- Disable VDI mode for TOS v4 as it doesn't support it (and VDI mode
  is redundant as Falcon's Videl allows similar resolutions)

-> I added a warning dialog for this ; should we consider it's enough 
and really disable VDI choice in falcon mode ?


- Add support for hardware accelerated zooming with
  SDL YUV overlays or OpenGL

-> now that we have SDL2, I think we can remove this one


Nicolas