[hatari-devel] Wii port

Eero Tamminen eerot at users.berlios.de
Mon Jan 19 21:52:29 CET 2009


Hi,

On Monday 19 January 2009, Yohanes Nugroho wrote:
> Thank you very much for your inputs. I will try to answer some of your
> questions, and do some of the things that you asked. I was also
> planning to port hatari to Symbian, but for now most Symbian hardware
> are too slow, but I also will give some arguments about somethings
> that might be useful if a Symbia port is going to be made.

I've profiled and tested Hatari on TI Omap1, Omap2 and Omap3.  Only last one
is really fast enough to comfortably run latest Hatari. I assume this is not
just because it's faster (more MHz), but due to the larger cache size 
(Hatari main loop runs through quite a lot of code).

I'd suggest using much older Hatari version on phone (although those
versions lack a lot of features in later Hatari) with following settings:
- frameskip 2
- no zooming
- no borders
- more compatible CPU option disabled
- spec512 support disabled
- sound at 11Khz or disabled

(Except for sound emulation, more accurate HW emulation in Hatari versions
is slower as it does more.)


> > * why things like these are "GEKKO"(?) specific:
> > ---------------
> > +ifneq ($(GEKKO), 1)
> >        $(MAKE) -C tools/hmsa/
> > +endif
> > ---------------
> > ?
>
> two things:
>
> - currently the hmsa build system is a bit broken. It tries to use
> some objects generated from the cross compiler with objects generated
> from native compiler. It produces an error.

Could you mail a build log of with these errors?


> - If I build for target, WII doesn't have a command console, and thus
> such tool is useless. The same will be true for Symbian and most
> mobile devices. Should there be a way to disable building hmsa

Well, there could be an UI built on top of it (maybe with Python available
for Symbian), so it's not necessarily complete useless. :-)


> > * Why binary name cannot be "Hatari":
> > -------------------------------
> > +ifneq ($(GEKKO), 1)
> >  all: hatari
> > +else
> > +all: hatari.dol
> > +endif
> > -------------------------------
> > ?
>
> I think we should not assume the final output of the file should have
> a particular name.

I was just wandering which ifneq is redundant...

> On Wii, the output of the compiler must be 
> converted using a tool called elf2dol. In symbian, it must go through
> elf2e32 and then through makesis and signsis.

If you have ifneq for the "all" target and the name is different, this:
--------------------
+ifeq ($(GEKKO), 1)
+hatari.dol : $(ALLOBJS)
+	$(CC) $(LDFLAGS) $(ALLOBJS) $(SDL_LIBS) $(LIBS) -o hatari.elf
+	elf2dol hatari.elf hatari.dol
+endif
--------------------
Could be just:
--------------------
+# Executable for Wii
+hatari.dol : $(ALLOBJS)
+	$(CC) $(LDFLAGS) $(ALLOBJS) $(SDL_LIBS) $(LIBS) -o hatari.elf
+	elf2dol hatari.elf hatari.dol
--------------------


Btw. The ifneq/ifdef name should also be something that people can
recognize.  What is GEKKO?  A "WII_COMPILER"?


> > * These wii.* files don't seem to have anything Wii specific, so some
> > more generic define and file name should be used:
> > ------------------------------
> > -  unzip.c utils.c vdi.c video.c wavFormat.c xbios.c ymFormat.c zip.c
> > +  unzip.c utils.c vdi.c video.c wavFormat.c xbios.c ymFormat.c zip.c \
> > +       wii.c
> > ...
> > +#ifdef GEKKO
> > +#include "wii.h"
> > +#endif
> > ------------------------------

Ifdef should again be feature specific and probably put into the header
itself.

> yes, it is not wii specific, but for now, I don't know where to put it
> (there is no file that can be used as generic compatibility layer).

The file includes scandir(), alphasort(), chmod(), rmdir() function.

First two are actually already in included into Hatari in scandir.c file.
As your implementations for the the other two are dummies, I guess you could
put them also to the same scandir.[ch] files files, surrounded by
appropriate functionality ifdefs.


> > * Maybe you could instead of this put "Wii" into the version string
> >  (in HG version normally "devel", so it could be "Wii-devel"):
> > -----------------------------
> > +#ifndef GEKKO
> >        { SGTEXT, 0, 0, 14,2, 12,1, "============" },
> > +#else
> > +       { SGTEXT, 0, 0, 1,2, 38,1, "Wii Version (http://tinyhack.com)"
> > }, +#endif
> > -----------------------------
> > Thomas, maybe the Hatari name/version should be centralized in the
> > about dialog?
>
> that would be a great idea

Thomas, could you look into centralizing the Hatari name/version?


> > * I don't think we want kludges around devel SDL version bugs,
> >  your version of SDL should be fixed instead:
> > -----------------------------
> > +#ifdef GEKKO
> > +                       //delay to make the message visible
> > +                       SDL_Delay(2000);
> > +#endif
>
> The original code assumes that there will be a main window, and a
> console. The Wii only have a single console. The message displayed by
> error messages will be shown momentarily and returns to the main
> display. Symbian system will have the same problem (switch to console,
> and back to graphics mode).
>
> This is a temporary solution for displaying the error message. The
> correct way will be to make a dialog box that shows the error message,
> instead of putting the error to the console.

If perror() is used instead of a function that potentially shows a dialog
depending on --alert-level), the message's not supposed to be seen by normal
users, only by developers who run Hatari from console.


> > ...
> > +#ifdef GEKKO
> > +       SDL_ShowCursor(SDL_DISABLE);
> > +#endif
> > ...
> > +#ifdef GEKKO
> > +               SDL_Flip(pSdlGuiScrn);
> > +#endif
> > -----------------------------
>
> I think this code is the correct way to display cursors on devices
> that doesn't have hardware cursor. At least that what testcursor.c do
> in SDL tests case (included in SDL distribution).

Thomas, any comments on this?


	- Eero



More information about the hatari-devel mailing list