[hatari-devel] Multiple GEMDOS HDD, Enh. CPU MHZ select & VC6 Compatiblity

Eero Tamminen eerot at users.berlios.de
Thu Feb 5 21:53:18 CET 2009


Hi,

I'll answer here to one comment in the patch tracker:
> * I'll scratch CPU speed selector for now (P.S. there are issues currently
> with the existing CPU speed timing when compared to a real Falcon 
> [based on my 32mhz falcon, my demos run about the right speed at over
> twice the CPU rate]).

Do you mean that when you run your demo on a real Falcon
that's modified to run at 32Mhz, you had to set Hatari to
64Mhz to achive same speed with Hatari Falcon emulation?

> Don't know how to improve or fix this unfortunately.    

Are you using DSP?  AFAIK Hatari DSP isn't currently speed accurate
at all and missing some synchronization between Hatari & DSP which
can make things quite a bit slower.


On Thursday 05 February 2009, Kenneth Kaufman wrote:
> Thanks for all the feed back Thomas, its greatly appriciated and its all
> positive stuff :).
>
> > assume this happened because you've started your changes with Hatari>
> > 1.2.0, but then later created the diff agains the tip development>
> > version... that's not good.
>
> It must be... though I'm not entirely certain how this managed to
> happened. When I realised there was a newer version of HAtari on
> Mercurial I downloaded a copy of Tortoise and received a new copy from
> Mercurial. I compared each file using WinDiff and tried to rationalise my
> changes against the latest version, I must have made a mistake on those
> two files O_o.

This kind of issue can happen if you do "hg pull" and then overwrite
the files.  You can use "hg diff" to see what's changed.  If Windiff
is nice UI for viewing diffs, hg can be configured to use an external
diff viewer (hg manual mentioned about that) for the "hg diff" command.


>  > > o Visual Studio 6 Compatibility - > > You've got some strange
>  > > changes in there, for example:> > +#if defined(__WIN32__)>
>  > > BlitterState.have_src = true;> +#else> + BlitterState.have_src =
>  > > true;> +#endif> > That seems to be nonsense. Please try to read over
>  > > your patch again> before you send them in, so that this does not
>  > > happen.
>
> That is an error. The true should have been upper cased (Visual Studio is
> pedantic about C, if its a C file it applies all the old style C laws
> [like no built in type for bool]).
[...]
>   > Instead of using " #if !defined(__WIN32__) " here again, it might be
>   > a> better idea to create a unistd.h file for VC6 and stick it
>   > somewhere> where only VC6 can find it (maybe in the gui-win folder?)
>
> Yes, right... sorry.

You could actually copy the relevant parts of all the needed C99 standard
headers to this new directory and add "-I<dir>" to the compiler flags for
VC6.

Thomas, if there are other old compilers that would need supporting, maybe
the directory should be called something like "c89-compat" (I don't see what
unistd.h, stdbool.h etc have to do with GUI :-)).


	- Eero



More information about the hatari-devel mailing list