tuxnes-devel

[Tuxnes-devel] compiling tuxnes for win32

[Jason D. S. <jd...@us...>]

Since I happened to be compiling some other programs for win32, I did 
the same with Tuxnes.  Naturally, it didn't work.

I used mingw32 on debian unstable, compiled with

   export LD_LIBRARY_PATH=/usr/i586-mingw32msvc/lib
   export CC=i586-mingw32msvc-gcc
   export RANLIB=i586-mingw32msvc-ranlib
   export AR=i586-mingw32msvc-ar
   ./autogen.sh
   ./configure --host=i586-mingw32msvc --prefix=/usr/i586-mingw32msvc
   make

and worked through the problems.  The attached patch is as far as I got.

Some notes:

- I had to remove io.h since it conflicted with a header include file 
<io.h>.  I didn't get far enough to find out if this caused problems. 
It should probably just be renamed.

- I imported mkdir.m4 from another project to check to see if mkdir 
takes two arguments or one.  I added this in m4/mkdir.m4 and modified 
autogen.sh accordingly.

- types.h is a pretty generic name and may conflict with a header file 
on some systems.  With mingw, I didn't have this problem but did have a 
problem with the _TYPES_H_ protective #definition.  So I renamed it to 
__TYPES_H_.

- Most of the other changes are good and obviously correct.  They may 
help compilation on some posix systems.  I've replaced some checks like 
"#ifdef __FreeBSD__" with better checks like "#ifdef HAVE_SYS_ENDIAN_H".

- Where I finally hit a wall was with mmap, which isn't available on 
Windows.  I don't know enough to write a replacement for it, although it 
looks like doing so would be possible (and would cause the code to make 
a lot more sense to me!).  From "man mmap":

  On  POSIX  systems  on  which  mmap,  msync  and  munmap are available,
  _POSIX_MAPPED_FILES is defined in <unistd.h> to a value greater than 0.


jason

Re: [Tuxnes-devel] compiling tuxnes for win32

[Mike M. <che...@ya...>]

Thank you for the patch, I'l see about commiting it.  Just one question
are you running from CVS?  The tuxnes-0_75_branch is latest Stable, it has
some fixes 0.75 did not but nothing that effects the build.

Comments within.
--- Jason Dorje Short <jd...@us...> wrote:
> Since I happened to be compiling some other programs for win32, I did 
> the same with Tuxnes.  Naturally, it didn't work.
> 
This is what the project needs, TESTING.  I'd like to make a realese for
what is in CVS, but it's pre-alpha.  I'd like to post any Windows bins
that we can get working.

> I used mingw32 on debian unstable, compiled with
> 
>    export LD_LIBRARY_PATH=/usr/i586-mingw32msvc/lib
>    export CC=i586-mingw32msvc-gcc
>    export RANLIB=i586-mingw32msvc-ranlib
>    export AR=i586-mingw32msvc-ar
>    ./autogen.sh
>    ./configure --host=i586-mingw32msvc --prefix=/usr/i586-mingw32msvc
>    make
> 
> and worked through the problems.  The attached patch is as far as I got.
> 
> Some notes:
> 
> - I had to remove io.h since it conflicted with a header include file 
> <io.h>.  I didn't get far enough to find out if this caused problems. 
> It should probably just be renamed.
> 
Hmm, <io.h> != "io.h";  The only thing I'd change it to is "_io.h" as
input-ouput.h is not my idea of short.  I don't know if this is realy a
problem or not.  It would seam that any name we use could exist as a
system header.

> - I imported mkdir.m4 from another project to check to see if mkdir 
> takes two arguments or one.  I added this in m4/mkdir.m4 and modified 
> autogen.sh accordingly.
> 
I'm going to start a branch for win32, this will be the first commit.

> - types.h is a pretty generic name and may conflict with a header file 
> on some systems.  With mingw, I didn't have this problem but did have a 
> problem with the _TYPES_H_ protective #definition.  So I renamed it to 
> __TYPES_H_.
Good catch.  This I think we should rename, put it some where else is more
like it.

> 
> - Most of the other changes are good and obviously correct.  They may 
> help compilation on some posix systems.  I've replaced some checks like 
> "#ifdef __FreeBSD__" with better checks like "#ifdef HAVE_SYS_ENDIAN_H".
> 
We need lots of this kind of house cleaning all over.  Feel free to go
nutz.

> - Where I finally hit a wall was with mmap, which isn't available on 
> Windows.  I don't know enough to write a replacement for it, although it
> 
> looks like doing so would be possible (and would cause the code to make 
> a lot more sense to me!).  From "man mmap":
> 
>   On  POSIX  systems  on  which  mmap,  msync  and  munmap are
> available,
>   _POSIX_MAPPED_FILES is defined in <unistd.h> to a value greater than
> 0.
> 
This is where nestra realy shines, our parent project.  The mmap is needed
for the hand made asm code that emulates the NES, there is a C based
emulator try using it for win32.  Currently the nes memory image MUST be
found at a [1]logical addess knowen by the person making the [2]asm code.

[1] The mmap makes the unix process see the same physical ram twice, at
two diffrent addresses we only use the mmaped one.
[2] In table.x86, the code in emulator_x86_asm.S is only used as a
fallback for self modifying code.

> 
> jason
> > ? m4
> ? win.diff
> Index: .cvsignore
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/.cvsignore,v
> retrieving revision 1.3
> diff -u -r1.3 .cvsignore
> --- .cvsignore	4 Dec 2003 15:23:58 -0000	1.3
> +++ .cvsignore	18 Feb 2004 01:00:05 -0000
> @@ -2,6 +2,7 @@
>  Makefile
>  Makefile.in
>  aclocal.m4
> +acinclude.m4
>  compdata
>  comptabl
>  config.cache
> Index: Makefile.am
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/Makefile.am,v
> retrieving revision 1.24
> diff -u -r1.24 Makefile.am
> --- Makefile.am	13 May 2002 17:52:42 -0000	1.24
> +++ Makefile.am	18 Feb 2004 01:00:05 -0000
> @@ -16,7 +16,7 @@
>  tuxnes_LDADD = table.o
>  endif
>  
> -EXTRA_DIST = table.x86 THANKS romfixer tuxnes.xpm tuxnes2.xpm BUGS
> CHANGES INSTALL.BSD
> +EXTRA_DIST = table.x86 THANKS romfixer tuxnes.xpm tuxnes2.xpm BUGS
> CHANGES INSTALL.BSD m4/mkdir.m4
>  
>  if HAVE_X86
>  noinst_PROGRAMS = comptbl
> Index: autogen.sh
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/autogen.sh,v
> retrieving revision 1.6
> diff -u -r1.6 autogen.sh
> --- autogen.sh	28 Oct 1999 02:16:40 -0000	1.6
> +++ autogen.sh	18 Feb 2004 01:00:05 -0000
> @@ -1,5 +1,6 @@
>  #! /bin/sh
>  
> +cat m4/*.m4 > acinclude.m4 && \
>  aclocal && \
>  autoconf && \
>  autoheader && \
> Index: configure.ac
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/configure.ac,v
> retrieving revision 1.1
> diff -u -r1.1 configure.ac
> --- configure.ac	5 Dec 2003 13:00:28 -0000	1.1
> +++ configure.ac	18 Feb 2004 01:00:05 -0000
> @@ -80,8 +80,9 @@
>  AC_HEADER_SYS_WAIT
>  AC_HEADER_TIME
>  AC_CHECK_HEADERS([fcntl.h features.h linux/joystick.h linux/soundcard \
> -	          ppm.h snss.h.h stddef.h strings.h sys/ioctl.h \
> -                  sys/soundcard.h sys/time.h])
> +                  endian.h sys/endian.h machine/endian.h sys/param.h \
> +	          ppm.h pwd.h snss.h.h stddef.h strings.h sys/ioctl.h \
> +                  sys/mman.h sys/soundcard.h sys/time.h winsock.h])
>  
>  dnl
> --------------------------------------------------------------------
>  dnl Checks for X11 header files
> @@ -230,19 +231,21 @@
>  
>  AC_TYPE_SIGNAL
>  AC_TYPE_SIZE_T
> +AC_CHECK_TYPES([suseconds_t])
>  
>  dnl
> --------------------------------------------------------------------
>  dnl Checks for library functions.
>  dnl
> --------------------------------------------------------------------
>  AC_FUNC_CLOSEDIR_VOID
>  AC_FUNC_FORK
> -AC_FUNC_MALLOC
> +# We don't use AC_FUNC_MALLOC since we have no rpl_malloc.
>  AC_FUNC_MEMCMP
>  AC_FUNC_MMAP
>  AC_FUNC_STAT
>  AC_FUNC_STRTOD
> -AC_CHECK_FUNCS([atexit ftruncate gettimeofday memmove memset mkdir \
> +AC_CHECK_FUNCS([atexit ftruncate gettimeofday getpwuid memmove memset
> mkdir \
>                  munmap strcasecmp strrchr strtoul]) 
> +FUNC_MKDIR_TAKES_ONE_ARG
>  
>  AC_SUBST(CFLAGS)
>  AC_SUBST(LDFLAGS)
> Index: controller.c
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/controller.c,v
> retrieving revision 1.4
> diff -u -r1.4 controller.c
> --- controller.c	5 Dec 2003 23:05:37 -0000	1.4
> +++ controller.c	18 Feb 2004 01:00:06 -0000
> @@ -574,6 +574,7 @@
>      static XEvent ev;
>      int nes_button;
>      int axis_i;
> +    int sleep = 0;
>  
>  #ifdef HAVE_LINUX_JOYSTICK_H
>      struct js_event js;
> Index: emu.c
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/emu.c,v
> retrieving revision 1.91
> diff -u -r1.91 emu.c
> --- emu.c	20 Jan 2004 14:41:46 -0000	1.91
> +++ emu.c	18 Feb 2004 01:00:06 -0000
> @@ -17,22 +17,32 @@
>  #include <features.h>
>  #endif /* HAVE_FEATRES_H */
>  
> -#include <stdlib.h>
> +#include <stdio.h> /* May be needed for dirent */
>  #include <ctype.h>
>  #include <sys/types.h>
> -#include <sys/ioctl.h>
> -#include <sys/mman.h>
> +#ifdef HAVE_SYS_IOCTL_H
> +# include <sys/ioctl.h>
> +#endif
> +#ifdef HAVE_SYS_MMAN_H
> +# include <sys/mman.h>
> +#endif
>  #include <sys/stat.h>
>  #include <dirent.h>
>  #include <errno.h>
>  #include <fcntl.h>
>  #include <getopt.h>
> -#include <pwd.h>
> +#ifdef HAVE_PWD_H
> +# include <pwd.h>
> +#endif
> +#include <limits.h>
>  #include <signal.h>
>  #include <stdio.h>
>  #include <stdlib.h>
>  #include <string.h>
>  #include <unistd.h>
> +#ifdef HAVE_WINSOCK_H
> +# include <winsock.h> /* Needed for some typedefs */
> +#endif
>  
>  #ifdef HAVE_LIBZ
>  #include <zlib.h>
> @@ -396,10 +406,12 @@
>  static void
>  traphandler (int signum)
>  {
> +#ifdef SIGTRAP
>    if (signal (SIGTRAP, &traphandler) == SIG_ERR)
>      {
>        perror ("signal");
>      }
> +#endif
>    if (ignorebadinstr)
>      return;
>    /* this will only affect subsequently-compiled code */
> @@ -1177,9 +1189,11 @@
>    memset (homedir, 0x00, PATH_MAX + 1);
>    if (!(ptr = getenv ("HOME")))
>      {
> +#ifdef HAVE_GETPWUID
>        struct passwd *pwent = getpwuid (getuid ());
>        if (pwent)
>          ptr = pwent->pw_dir;
> +#endif
>        if (!ptr)
>          ptr = "";
>      }
> @@ -1195,7 +1209,11 @@
>    if ((dir == NULL)
>        && (errno == ENOENT))
>      {
> +#ifdef MKDIR_TAKES_ONE_ARG
> +      mkdir (tuxnesdir);
> +#else
>        mkdir (tuxnesdir, 0777);
> +#endif
>        if ((dir = opendir (tuxnesdir)) == NULL)
>          {
>            fprintf (stderr, "Cannot open directory %s\n", tuxnesdir);
> @@ -2202,10 +2220,12 @@
>  
>    /* trap traps */
>    if (! disassemble)
> +#ifdef SIGTRAP
>      if ((oldtraphandler = signal (SIGTRAP, &traphandler)) == SIG_ERR)
>        {
>  	perror ("signal");
>        }
> +#endif
>  
>    /* start the show */
>    emulator->Start();                     /* execute translated code */
> Index: emulator_c.h
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/emulator_c.h,v
> retrieving revision 1.2
> diff -u -r1.2 emulator_c.h
> --- emulator_c.h	5 Dec 2003 23:05:37 -0000	1.2
> +++ emulator_c.h	18 Feb 2004 01:00:06 -0000
> @@ -30,6 +30,7 @@
>  #define _EMULATOR_C_H_
>  
>  #include <inttypes.h>
> +#include <stdint.h>
>  #include "types.h"
>  #include "emulator_c_iface.h"
>  
> Index: emulator_x86.c
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/emulator_x86.c,v
> retrieving revision 1.5
> diff -u -r1.5 emulator_x86.c
> --- emulator_x86.c	5 Dec 2003 23:05:37 -0000	1.5
> +++ emulator_x86.c	18 Feb 2004 01:00:06 -0000
> @@ -3,6 +3,7 @@
>  
>  #ifdef HAVE_X86
>  
> +#include <stdio.h>
>  #include <stdlib.h>
>  #include <string.h>
>  #include <sys/mman.h>
> Index: renderer.h
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/renderer.h,v
> retrieving revision 1.11
> diff -u -r1.11 renderer.h
> --- renderer.h	20 Jan 2004 16:23:38 -0000	1.11
> +++ renderer.h	18 Feb 2004 01:00:06 -0000
> @@ -13,6 +13,11 @@
>  #define HAVE_X 1
>  #endif /* !defined(X_DISPLAY_MISSING) */
>  
> +#include <sys/types.h>
> +#ifdef HAVE_WINSOCK_H
> +# include <winsock.h>
> +#endif
> +
>  #ifdef HAVE_LIBGII
>  #ifdef HAVE_GGI_GII_H
>  #ifdef HAVE_LIBGGI
> Index: renderer_util.c
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/renderer_util.c,v
> retrieving revision 1.3
> diff -u -r1.3 renderer_util.c
> --- renderer_util.c	20 Jan 2004 16:23:38 -0000	1.3
> +++ renderer_util.c	18 Feb 2004 01:00:06 -0000
> @@ -87,7 +87,11 @@
>  int resynchronize(int frame)
>  {
>    struct timeval now;
> +#ifdef HAVE_SUSECONDS_T
>    suseconds_t usec;
> +#else
> +  long usec;
> +#endif
>  
>    frameskip = desync = 0;
>  
> Index: renderer_w.c
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/renderer_w.c,v
> retrieving revision 1.3
> diff -u -r1.3 renderer_w.c
> --- renderer_w.c	20 Jan 2004 16:23:38 -0000	1.3
> +++ renderer_w.c	18 Feb 2004 01:00:06 -0000
> @@ -24,13 +24,15 @@
>  #include <stdio.h>
>  #include <stdlib.h>
>  #include <string.h>
> -#include <unistd.h>
> -#if defined(__FreeBSD__)
> -#include <machine/endian.h>
> -#elif defined(__NetBSD__) || defined(__OpenBSD__)
> -#include <sys/endian.h>
> -#else /* Linux */
> -#include <endian.h>
> +#include <unistd.h> 
> +#ifdef HAVE_ENDIAN_H
> +# include <endian.h>
> +#elif defined HAVE_SYS_ENDIAN_H
> +# include <sys/endian.h>
> +#elif defined HAVE_MACHINE_ENDIAN_H
> +# include <machine/endian.h>
> +#elif defined HAVE_SYS_PARAM_H
> +# include <sys/param.h>
>  #endif
>  
>  #include "consts.h"
> Index: renderer_x11.c
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/renderer_x11.c,v
> retrieving revision 1.4
> diff -u -r1.4 renderer_x11.c
> --- renderer_x11.c	20 Jan 2004 16:23:38 -0000	1.4
> +++ renderer_x11.c	18 Feb 2004 01:00:07 -0000
> @@ -20,7 +20,9 @@
>  
>  #include <sys/stat.h>
>  #include <sys/types.h>
> -#include <sys/wait.h>
> +#ifdef HAVE_SYS_WAIT_H
> +# include <sys/wait.h>
> +#endif
>  #include <errno.h>
>  #include <signal.h>
>  #include <stdio.h>
> @@ -28,12 +30,14 @@
>  #include <string.h>
>  #include <unistd.h>
>  #include <renderer_util.h>
> -#if defined(__FreeBSD__)
> -#include <machine/endian.h>
> -#elif defined(__NetBSD__) || defined(__OpenBSD__)
> -#include <sys/endian.h>
> -#else /* Linux */
> -#include <endian.h>
> +#ifdef HAVE_ENDIAN_H
> +# include <endian.h>
> +#elif defined HAVE_SYS_ENDIAN_H
> +# include <sys/endian.h>
> +#elif defined HAVE_MACHINE_ENDIAN_H
> +# include <machine/endian.h>
> +#elif defined HAVE_SYS_PARAM_H
> +# include <sys/param.h>
>  #endif
>  
>  #include "consts.h"
> @@ -368,6 +372,7 @@
>  	  break;
>  	}
>    }
> +#if BYTE_ORDER != BIG_ENDIAN && BYTE_ORDER != LITTLE_ENDIAN
>    if ((BYTE_ORDER != BIG_ENDIAN) && (BYTE_ORDER != LITTLE_ENDIAN)
>        && (bpp == 32)
>        && ! renderer->_flags)
> @@ -384,6 +389,7 @@
>  	       (BYTE_ORDER == PDP_ENDIAN) ? "PDP" : "Obscure");
>        fflush (stderr);
>      }
> +#endif
>    if ((renderer->_flags & RENDERER_OLD) && (scanlines && (scanlines !=
> 100)))
>      {
>        fprintf (stderr, "[%s] Scanline intensity is ignored by this
> renderer\n",
> Index: sound.c
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/sound.c,v
> retrieving revision 1.45
> diff -u -r1.45 sound.c
> --- sound.c	5 Dec 2003 23:05:39 -0000	1.45
> +++ sound.c	18 Feb 2004 01:00:07 -0000
> @@ -108,13 +108,17 @@
>  #include <stdio.h>
>  #include <stdlib.h>
>  #include <unistd.h>
> -#include <sys/ioctl.h>
> -#if defined(__FreeBSD__)
> -#include <machine/endian.h>
> -#elif defined(__NetBSD__) || defined(__OpenBSD__)
> -#include <sys/endian.h>
> -#else /* Linux */
> -#include <endian.h>
> +#ifdef HAVE_SYS_IOCTL_H
> +# include <sys/ioctl.h>
> +#endif
> +#ifdef HAVE_ENDIAN_H
> +# include <endian.h>
> +#elif defined HAVE_SYS_ENDIAN_H
> +# include <sys/endian.h>
> +#elif defined HAVE_MACHINE_ENDIAN_H
> +# include <machine/endian.h>
> +#elif defined HAVE_SYS_PARAM_H
> +# include <sys/param.h>
>  #endif
>  #include <sys/types.h>
>  #include <sys/stat.h>
> Index: types.h
> ===================================================================
> RCS file: /cvsroot/tuxnes/tuxnes/types.h,v
> retrieving revision 1.2
> diff -u -r1.2 types.h
> --- types.h	5 Dec 2003 23:05:39 -0000	1.2
> +++ types.h	18 Feb 2004 01:00:07 -0000
> @@ -23,8 +23,8 @@
>  ** $Id: types.h,v 1.2 2003/12/05 23:05:39 cheako Exp $
>  */
>  
> -#ifndef _TYPES_H_
> -#define _TYPES_H_
> +#ifndef __TYPES_H_
> +#define __TYPES_H_
>  
>  #ifdef __GNUC__
>  #define  INLINE      static inline
> @@ -79,7 +79,7 @@
>  #define  ASSERT_MSG(msg)
>  #endif
>  
> -#endif /* _TYPES_H_ */
> +#endif /* __TYPES_H_ */
>  
>  /*
>  ** $Log: types.h,v $
> > # $Id: mkdir.m4,v 1.1 2004/02/09 01:38:21 jdorje Exp $
> # FUNC_MKDIR_TAKES_ONE_ARG defines MKDIR_TAKES_ONE_ARG if, well, mkdir
> takes
> # one arg (instead of 2 like it does on POSIX systems).
> #
> # Take from a phantom file contributed to GNU "patch" that I can't find
> # anywhere except in mailing lists.  Attributed to Mumit Khan and Paul
> Eggert.
> #
> # Note that if you don't have the correct #includes in the test-compile
> code,
> # the compiler will give a missing-prototype warning but will succeed. 
> Yuck!
> 
> AC_DEFUN([FUNC_MKDIR_TAKES_ONE_ARG],
>   [AC_CHECK_FUNCS([mkdir])
>    AC_CACHE_CHECK([whether mkdir takes only one argument],
>      cv_mkdir_takes_one_arg,
>      [cv_mkdir_takes_one_arg=no
>       if test $ac_cv_func_mkdir = yes; then
>  AC_TRY_COMPILE([
> #include <dir.h>
>    ],
>    [mkdir (".");],
>    cv_mkdir_takes_one_arg=yes,
>    cv_mkdir_takes_one_arg=no
>    )
>       fi
>      ]
>    )
>    if test $cv_mkdir_takes_one_arg = yes; then
>      AC_DEFINE([MKDIR_TAKES_ONE_ARG], 1,
>        [Define if mkdir takes only one argument.])
>    fi
>   ]
> )
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

Re: [Tuxnes-devel] compiling tuxnes for win32

[Jason D. S. <jd...@us...>]

Mike Mestnik wrote:
> Thank you for the patch, I'l see about commiting it.  Just one question
> are you running from CVS?  The tuxnes-0_75_branch is latest Stable, it has
> some fixes 0.75 did not but nothing that effects the build.

Yes, I'm working from the CVS version.

> Comments within.
> --- Jason Dorje Short <jd...@us...> wrote:
> 
>>Since I happened to be compiling some other programs for win32, I did 
>>the same with Tuxnes.  Naturally, it didn't work.
> 
> This is what the project needs, TESTING.  I'd like to make a realese for
> what is in CVS, but it's pre-alpha.  I'd like to post any Windows bins
> that we can get working.

I have little knowledge about what libraries the renderers require or if 
it's even possible to get a windows executable to work.

There is an SDL renderer, right?  But I haven't compiled SDL for 
windows, and it will probably take a lot of work to do so.  (On the 
other hand this would allow me to compile other programs with sdl...)

What about dropping the other renderers and keeping only the SDL one? 
Is there anything provided by the others that SDL doesn't have?  Not 
that this is needed or anything, but it might make maintainence easier 
(like the GGI problem - I don't even know what GGI is).

>>- I had to remove io.h since it conflicted with a header include file 
>><io.h>.  I didn't get far enough to find out if this caused problems. 
>>It should probably just be renamed.
> 
> Hmm, <io.h> != "io.h";  The only thing I'd change it to is "_io.h" as
> input-ouput.h is not my idea of short.  I don't know if this is realy a
> problem or not.  It would seam that any name we use could exist as a
> system header.

I suppose so.  But as "io.h" it definitely doesn't work.  fcntl.h has 
#include <io.h> for some important typedefs, and these get skipped.

>>- I imported mkdir.m4 from another project to check to see if mkdir 
>>takes two arguments or one.  I added this in m4/mkdir.m4 and modified 
>>autogen.sh accordingly.
> 
> I'm going to start a branch for win32, this will be the first commit.

A "branch"?

>>- Most of the other changes are good and obviously correct.  They may 
>>help compilation on some posix systems.  I've replaced some checks like 
>>"#ifdef __FreeBSD__" with better checks like "#ifdef HAVE_SYS_ENDIAN_H".
> 
> We need lots of this kind of house cleaning all over.  Feel free to go
> nutz.

Probably a new header file could contain a lot of the stuff.  I think 
autoconf recommends a system.h.  support.h is also a good name.

>>- Where I finally hit a wall was with mmap, which isn't available on 
>>Windows.

> This is where nestra realy shines, our parent project.  The mmap is needed
> for the hand made asm code that emulates the NES, there is a C based
> emulator try using it for win32.  Currently the nes memory image MUST be
> found at a [1]logical addess knowen by the person making the [2]asm code.
> 
> [1] The mmap makes the unix process see the same physical ram twice, at
> two diffrent addresses we only use the mmaped one.
> [2] In table.x86, the code in emulator_x86_asm.S is only used as a
> fallback for self modifying code.

Ouch.

Given that computer speeds are continually advancing while the NES 
emulation requirements remain constant, I would think C-based emulation 
would be the way to go.

jason

Re: [Tuxnes-devel] compiling tuxnes for win32

[Mike M. <che...@ya...>]

--- Jason Dorje Short <jd...@us...> wrote:
> Mike Mestnik wrote:
> > Thank you for the patch, I'l see about commiting it.  Just one
> question
> > are you running from CVS?  The tuxnes-0_75_branch is latest Stable, it
> has
> > some fixes 0.75 did not but nothing that effects the build.
> 
> Yes, I'm working from the CVS version.
> 
> > Comments within.
> > --- Jason Dorje Short <jd...@us...> wrote:
> > 
> >>Since I happened to be compiling some other programs for win32, I did 
> >>the same with Tuxnes.  Naturally, it didn't work.
> > 
> > This is what the project needs, TESTING.  I'd like to make a realese
> for
> > what is in CVS, but it's pre-alpha.  I'd like to post any Windows bins
> > that we can get working.
> 
> I have little knowledge about what libraries the renderers require or if
> 
> it's even possible to get a windows executable to work.
> 
> There is an SDL renderer, right?  But I haven't compiled SDL for 
> windows, and it will probably take a lot of work to do so.  (On the 
> other hand this would allow me to compile other programs with sdl...)
> 
It's broke in tuxnes i'm affraid(read as sorry).

> What about dropping the other renderers and keeping only the SDL one? 
> Is there anything provided by the others that SDL doesn't have?  Not 
> that this is needed or anything, but it might make maintainence easier 
> (like the GGI problem - I don't even know what GGI is).
> 
Saddly the SDL renderer is beyond my help, but I can fix the first row of
problems with GGI.  The X11 forever will be the 3ie7 way to go for
linux/unix systems and I woulden't drop it unless X was replaced.

> >>- I had to remove io.h since it conflicted with a header include file 
> >><io.h>.  I didn't get far enough to find out if this caused problems. 
> >>It should probably just be renamed.
> > 
> > Hmm, <io.h> != "io.h";  The only thing I'd change it to is "_io.h" as
> > input-ouput.h is not my idea of short.  I don't know if this is realy
> a
> > problem or not.  It would seam that any name we use could exist as a
> > system header.
> 
> I suppose so.  But as "io.h" it definitely doesn't work.  fcntl.h has 
> #include <io.h> for some important typedefs, and these get skipped.
> 
Then we will have to come up with something.

> >>- I imported mkdir.m4 from another project to check to see if mkdir 
> >>takes two arguments or one.  I added this in m4/mkdir.m4 and modified 
> >>autogen.sh accordingly.
> > 
> > I'm going to start a branch for win32, this will be the first commit.
> 
> A "branch"?
> 
I may have jumped the gun, there should be a win32 branch if it breaks
others.  Good work thouh have bestoed upon and to the head it went.

> >>- Most of the other changes are good and obviously correct.  They may 
> >>help compilation on some posix systems.  I've replaced some checks
> like 
> >>"#ifdef __FreeBSD__" with better checks like "#ifdef
> HAVE_SYS_ENDIAN_H".
> > 
> > We need lots of this kind of house cleaning all over.  Feel free to go
> > nutz.
> 
> Probably a new header file could contain a lot of the stuff.  I think 
> autoconf recommends a system.h.  support.h is also a good name.
> 
Make it so.  If you should, put all the type.h stuff in there.  io.{c,h}
can be renamed to something else oi?

> >>- Where I finally hit a wall was with mmap, which isn't available on 
> >>Windows.
> 
> > This is where nestra realy shines, our parent project.  The mmap is
> needed
> > for the hand made asm code that emulates the NES, there is a C based
> > emulator try using it for win32.  Currently the nes memory image MUST
> be
> > found at a [1]logical addess knowen by the person making the [2]asm
> code.
> > 
> > [1] The mmap makes the unix process see the same physical ram twice,
> at
> > two diffrent addresses we only use the mmaped one.
> > [2] In table.x86, the code in emulator_x86_asm.S is only used as a
> > fallback for self modifying code.
> 
> Ouch.
> 
> Given that computer speeds are continually advancing while the NES 
> emulation requirements remain constant, I would think C-based emulation 
> would be the way to go.
> 
That's what I think is going to have to happen.  Maby you could find a
port of nestra to win32?

> jason


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

Re: [Tuxnes-devel] compiling tuxnes for win32

[Mike M. <che...@ya...>]

Jason:
  I have commited your patch, with a fue changes.  I put AC_FUNC_MALLOC
back, I don't think it hurts to have it thought maby I just don't know why
it was removed.  And I went crasy on renderer_x11.c that byte order stuff
is just the way I would want it.

Hope it hits the public CVS soon, can't get a patch.


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools