[hatari-devel] WinUae CPU for hatari

[Nicolas Pomarède]

Le 01/11/2010 23:34, Laurent Sallafranque a écrit :
> Hello,
>
> I've uploaded some files.
> This just let newcpu.c to compile.
> Next step is fpp.c to compile.
>
>
> The main changes I had to implement until now :
>
> - add of compat.h
> - rewrite TRY / CATCH in cpummu and newcpu
> - I've added a new define : AMIGA_ONLY ( to avoid compilation of amiga
> only parts).
> Tell me if this is ok for you or if I should to it in another way
> - I've also added some comments with Laurent as a tag. At these place,
> I've added a comment because I don't know what to do.
> - I've kept the oldUAE memory.c and memory.h files instead of the new
> ones from winuae.
> I don't know yet if this can have an impact on the new Winuae core we're
> trying to implement. (Eero : This explain why there are spaces instead
> of tabs in the hg diff of this file)
>
>
> I think there'll be soon 2 problems :
>
> 1) We'll need to adapt all these files to our own needs.
> So compatibility with original files will decrease (I think at newcpu.c
> file for example).
>
> 2) We'll need to change some parts of hatari's code that won't allow
> compatibility between oldcpu and newcpu (except if we include lot's of
> ifdefs but code may become too heavy and horrible to read).
>
> I think at old variable "cpu_level" used in hatari's GUI for example.
> It seems that this variable doesn't exist anymore and is replaced by :
> cpu_model
> So, we'll have to modify the GUI to allow new cpus, mmus, ..., or create
> a new directory for new parameters, or stop the old branch, ...
>
> There'll be soon a decision to take.

Hello,

regarding the need to change hatari to adapt to winuae's cpu, I don't 
think we can drop the "old" uae-cpu branch.

This may require to add quite a lot of #if in hatari (but not that much 
in fact, there're very few parts of hatari that really needs to "know" 
how the cpu emulation is working), but this is the only way to be able 
to track regressions : we must keep a way to compile with either cpu 
core to be able to track emulation's differences.

For variables that have a new names for example, I think the best way is 
to replace them with a macro (as Thomas did when he first worked on 
integrating winuae).

eg :

#ifdef OLD_CPU
#define CPU_MODEL cpu_level
#else
#define CPU_MODEL cpu_model
#endif

Creating an abstraction layer with some macros will allow to compile 
hatari with both cpu's core. This requires to modify some parts of 
Hatari, but it will allow to keep both cpu cores in a compilable state.

Nicolas