[hatari-devel] Some news

[Thomas Huth]

On Wed, 06 Oct 2010 22:16:05 +0200
Nicolas Pomarède <npomarede at corp.free.fr> wrote:

> Le 06/10/2010 21:26, Laurent Sallafranque a écrit :
> > Hello,
> >
> > I'm actually working on the main 68000 code (uae code)
> >
> > I've started to integrate the latest WinUae code to hatari.
> > Like this, we'll have a better 680x0 emulation, a much better 68030
> > (with MMU) and why not, a 68060 (if we want to emulate the ct60
> > cards and be able to see some recent demos).
> >
[...]
> That's good new, but try to keep a version of hatari that can be
> build with current uae or with winuae's one committing a new cpu core
> and removing the current one from mercurial does not look like a good
> option now, we will certainly need months of test/regression before
> considering the new core does all the current one does (I know some
> stack/exceptions used in some protections are not correctly emulated
> in winuae ; also some opcodes (tas for example) work differently).
>
> I think best would be to have a "winuae-cpu" directory in addition to 
> "uae-cpu" and have some define + flags in cmake to be able to choose
> the cpu core at compile time.

I second that, please open a new directory for that CPU core instead.
I suggest to simply use "cpu" as directory name instead, at least this
is what I used a couple of years ago when I started to work on the
WinUAE CPU core (but then got interrupted by Nicolas' improvements for
the old UAE core ;-)). You can find my old work here:

http://hatari.cvs.sourceforge.net/viewvc/hatari/hatari/src/cpu/?pathrev=WINUAE_CPU_BRANCH

Maybe it's a little bit useful to see which parts I had to modify to
get it working at least a little bit...


> I think it would be good also when modifying winuae's sources to not 
> remove amiga's specific code to put atari's one instead, but to keep 
> both with some conditionial defines.
> 
> eg :
> 
> #ifedef HATARI_BUILD
> .... <new hatari code>
> #else
> .... <original amiga/winuae code>
> #endif
> 
> This way we can keep track of all specific modifications made for
> hatari and it will be much easier to backport future winuae's
> improvements in hatari.

Hmm, but that will render the WinUAE code even more unreadable than it
currently is?

I think the best, but very time consuming solution would be to make all
those CPU core files as independent from the emulated system as
possible, and then to submit these patches upstream to WinUAE, but
whether they would accept such patches is another question...

 Thomas