tuxnes-devel — Development discussion for the TuxNES project

[Tuxnes-devel] Re: NO LIST ARCHIVES?? for tuxnes-devel.

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

Mike Mestnik wrote:
> I could not find any arcives of the tuxnes-devel list!  Should I file a
> sfbt issue or dose some one know why?

Hmm?  See

http://sourceforge.net/mailarchive/forum.php?thread_id=3914383&forum_id=2494

[Tuxnes-devel] X and non X.

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

This lets you run GGI with no video and SDL with no input.


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

[Tuxnes-devel] NO LIST ARCHIVES?? for tuxnes-devel.

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

I could not find any arcives of the tuxnes-devel list!  Should I file a
sfbt issue or dose some one know why?

Put a return 0 at the start of HandleJoystickLinux and the like if SDL is
being used. :)

--- Jason Dorje Short <jd...@us...> wrote:
> When I use the SDL renderer, tuxnes crashes.  SDL doesn't normally give 
> a core file.  When I add the SDL_INIT_NOPARACHUTE to the SDL_Init 
> options, I get:
> 
> #0  0x401ca212 in XPending () from /usr/X11R6/lib/libX11.so.6
> (gdb) bt
> #0  0x401ca212 in XPending () from /usr/X11R6/lib/libX11.so.6
> #1  0x0806149b in HandleJoystickLinux (stick=0) at controller.c:727
> #2  0x080769f9 in DoNMIC () at emulator_c_iface.c:168
> #3  0x0807683a in nmi_shim_m6502 (addr=65415) at emulator_c_iface.c:115
> #4  0x0807718d in StartC () at emulator_c_iface.c:325
> #5  0x0804ec7c in main (argc=4, argv=0xbffff934) at emu.c:2231
> 
> jason
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Tuxnes-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxnes-devel


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

[Tuxnes-devel] sdl renderer

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

When I use the SDL renderer, tuxnes crashes.  SDL doesn't normally give 
a core file.  When I add the SDL_INIT_NOPARACHUTE to the SDL_Init 
options, I get:

#0  0x401ca212 in XPending () from /usr/X11R6/lib/libX11.so.6
(gdb) bt
#0  0x401ca212 in XPending () from /usr/X11R6/lib/libX11.so.6
#1  0x0806149b in HandleJoystickLinux (stick=0) at controller.c:727
#2  0x080769f9 in DoNMIC () at emulator_c_iface.c:168
#3  0x0807683a in nmi_shim_m6502 (addr=65415) at emulator_c_iface.c:115
#4  0x0807718d in StartC () at emulator_c_iface.c:325
#5  0x0804ec7c in main (argc=4, argv=0xbffff934) at emu.c:2231

jason

Re: [Tuxnes-devel] renderer_ggi doesn't compile

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

Mike Mestnik wrote:
> This lookes good, it's hunting for a usable output device.  I know .a
> means a.out and .so is an elf, but I'v never heard on an .la.  I guss it's
> a windows thing, do you have other GGI programs working?  I would say
> build the elf libs if you can, as a.out is older.

Sorry, I don't mean to be unclear: I'm doing this compilation on debian 
unstable, not for windows (though previously I was trying to compile 
tuxnes for windows).

.la is a simple data file that describes the .so and .a files.  I think.

It seems the .so file is not present on my system because the 
libgga-target-aa package isn't installed.  aa is ascii art, so why 
should it be?

When I install the libgga-target-x package things work a bit better. 
Now I just get a segmentation fault:

#0  0x401ca212 in XPending () from /usr/X11R6/lib/libX11.so.6
(gdb) bt
#0  0x401ca212 in XPending () from /usr/X11R6/lib/libX11.so.6
#1  0x0806149b in HandleJoystickLinux (stick=0) at controller.c:727
#2  0x080769f9 in DoNMIC () at emulator_c_iface.c:168
#3  0x0807683a in nmi_shim_m6502 (addr=65415) at emulator_c_iface.c:115
#4  0x0807718d in StartC () at emulator_c_iface.c:325
#5  0x0804ec7c in main (argc=4, argv=0xbffff934) at emu.c:2231

When I leave off the -r ggi option, the X renderer is used and things work.

jason

Re: [Tuxnes-devel] renderer_ggi doesn't compile

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

This lookes good, it's hunting for a usable output device.  I know .a
means a.out and .so is an elf, but I'v never heard on an .la.  I guss it's
a windows thing, do you have other GGI programs working?  I would say
build the elf libs if you can, as a.out is older.

--- Jason Dorje Short <jd...@us...> wrote:
> Jason Dorje Short wrote:
> > Mike Mestnik wrote:
> > 
> >> I got ggl to build and did the same with w(but I don't have libw). 
> It 
> >> ran
> >> but was only black and didn't start making sounds and did't respond. 
> My
> >> ggi setup could be non-funcional.  Sdl still crashes with a...
> >> Fatal signal: Segmentation Fault (SDL Parachute Deployed)
> >>
> >> This is what I get from ggi, lookes good.
> >> LibGGI: No explicit target specified.
> >> LibGGI: Try to use X target...
> >> GGI mode: "256x240.V256x240.F2.D1x1.[C24/32]"
> >> GGI: Truecolor scheme, depth 24, 32bpp, static colors, 2 direct
> buffers
> >>
> >> Attached is the patch, hope it workes better for you, jason.
> > 
> > 
> > I can't test right now because sourceforge cvs is acting up.
> 
> OK, it compiled.
> 
> When I tried to run it, I got:
> 
> LibGGI: No explicit target specified.
> LibGGI: Try to use X target...
> LibGG: unable to open lib: /usr/lib/ggi/display/X.so: cannot open shared
> 
> object file: No such file or directory
> LibGGI: Try to use fbdev target (framebuffer console)...
> LibGG: unable to open lib: /usr/lib/ggi/display/fbdev.so: cannot open 
> shared object file: No such file or directory
> LibGGI: Try to use svgalib target...
> LibGG: unable to open lib: /usr/lib/ggi/display/svgalib.so: cannot open 
> shared object file: No such file or directory
> LibGGI: Try to use AAlib target...
> LibGG: unable to open lib: /usr/lib/ggi/display/aa.so: cannot open 
> shared object file: No such file or directory
> 
> For some reason although the .la lib files are present the .so ones are 
> not.  I don't really know what this means.  Is it a bug in my ggi 
> installation, or the configure process?
> 
> jason
> 


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

Re: [Tuxnes-devel] renderer_ggi doesn't compile

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

Jason Dorje Short wrote:
> Mike Mestnik wrote:
> 
>> I got ggl to build and did the same with w(but I don't have libw).  It 
>> ran
>> but was only black and didn't start making sounds and did't respond.  My
>> ggi setup could be non-funcional.  Sdl still crashes with a...
>> Fatal signal: Segmentation Fault (SDL Parachute Deployed)
>>
>> This is what I get from ggi, lookes good.
>> LibGGI: No explicit target specified.
>> LibGGI: Try to use X target...
>> GGI mode: "256x240.V256x240.F2.D1x1.[C24/32]"
>> GGI: Truecolor scheme, depth 24, 32bpp, static colors, 2 direct buffers
>>
>> Attached is the patch, hope it workes better for you, jason.
> 
> 
> I can't test right now because sourceforge cvs is acting up.

OK, it compiled.

When I tried to run it, I got:

LibGGI: No explicit target specified.
LibGGI: Try to use X target...
LibGG: unable to open lib: /usr/lib/ggi/display/X.so: cannot open shared 
object file: No such file or directory
LibGGI: Try to use fbdev target (framebuffer console)...
LibGG: unable to open lib: /usr/lib/ggi/display/fbdev.so: cannot open 
shared object file: No such file or directory
LibGGI: Try to use svgalib target...
LibGG: unable to open lib: /usr/lib/ggi/display/svgalib.so: cannot open 
shared object file: No such file or directory
LibGGI: Try to use AAlib target...
LibGG: unable to open lib: /usr/lib/ggi/display/aa.so: cannot open 
shared object file: No such file or directory

For some reason although the .la lib files are present the .so ones are 
not.  I don't really know what this means.  Is it a bug in my ggi 
installation, or the configure process?

jason

[Tuxnes-devel] another compile cleanup: config.h

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

I get this problem when compiling:

sound.c:503: warning: implicit declaration of function `ioctl'

because #include <ioctl.h> is surrounded by #ifdef HAVE_IOCTL_H, but 
there is no #include <config.h> in the file.

This patch changes all files to have

   #ifdef HAVE_CONFIG_H
   # include <config.h>
   #endif /* HAVE_CONFIG_H */

in them.

Important points:

- It must be before any other #includes, even system includes.  For 
instance assert.h defines assert() differently depending on the value of 
NDEBUG, which is generally defined in config.h (see ziploader.c).

- There's no need to have #include <config.h> in .h files.  It might be 
possible that this breaks things (by including it twice); I don't know. 
  Anyway, I removed it.

- You're supposed to use <config.h>, not "config.h".  I don't know why, 
or if it matters.

- You're supposed to use #ifdef HAVE_CONFIG_H to surround it.  I don't 
know why, or if it matters.

The latter two are probably to help compilation on some bizarre systems 
that don't have autoconf.  Who knows.

jason

Re: [Tuxnes-devel] renderer_ggi doesn't compile

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

Mike Mestnik wrote:
> I got ggl to build and did the same with w(but I don't have libw).  It ran
> but was only black and didn't start making sounds and did't respond.  My
> ggi setup could be non-funcional.  Sdl still crashes with a...
> Fatal signal: Segmentation Fault (SDL Parachute Deployed)
> 
> This is what I get from ggi, lookes good.
> LibGGI: No explicit target specified.
> LibGGI: Try to use X target...
> GGI mode: "256x240.V256x240.F2.D1x1.[C24/32]"
> GGI: Truecolor scheme, depth 24, 32bpp, static colors, 2 direct buffers
> 
> Attached is the patch, hope it workes better for you, jason.

I can't test right now because sourceforge cvs is acting up.

> Here are some autogen.sh errors.
> /usr/share/aclocal/vorbis.m4:9: warning: underquoted definition of
> XIPH_PATH_VORBIS
>   run info '(automake)Extending aclocal'
>   or see
> http://sources.redhat.com/automake/automake.html#Extending%20aclocal
> /usr/share/aclocal/pkg.m4:5: warning: underquoted definition of
> PKG_CHECK_MODULES
> /usr/share/aclocal/ogg.m4:8: warning: underquoted definition of
> XIPH_PATH_OGG
> /usr/share/aclocal/gsl.m4:5: warning: underquoted definition of
> AM_PATH_GSL
> /usr/share/aclocal/avifile.m4:21: warning: underquoted definition of
> AM_PATH_AVIFILE

These are warnings generated by recent versions of automake/autoconf. 
Note that these are global files, not ones provided by tuxnes.

jason

Re: [Tuxnes-devel] renderer_ggi doesn't compile

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

I got ggl to build and did the same with w(but I don't have libw).  It ran
but was only black and didn't start making sounds and did't respond.  My
ggi setup could be non-funcional.  Sdl still crashes with a...
Fatal signal: Segmentation Fault (SDL Parachute Deployed)

This is what I get from ggi, lookes good.
LibGGI: No explicit target specified.
LibGGI: Try to use X target...
GGI mode: "256x240.V256x240.F2.D1x1.[C24/32]"
GGI: Truecolor scheme, depth 24, 32bpp, static colors, 2 direct buffers

Attached is the patch, hope it workes better for you, jason.

Here are some autogen.sh errors.
/usr/share/aclocal/vorbis.m4:9: warning: underquoted definition of
XIPH_PATH_VORBIS
  run info '(automake)Extending aclocal'
  or see
http://sources.redhat.com/automake/automake.html#Extending%20aclocal
/usr/share/aclocal/pkg.m4:5: warning: underquoted definition of
PKG_CHECK_MODULES
/usr/share/aclocal/ogg.m4:8: warning: underquoted definition of
XIPH_PATH_OGG
/usr/share/aclocal/gsl.m4:5: warning: underquoted definition of
AM_PATH_GSL
/usr/share/aclocal/avifile.m4:21: warning: underquoted definition of
AM_PATH_AVIFILE

--- Jason Dorje Short <jd...@us...> wrote:
> if gcc -DHAVE_CONFIG_H -I. -I. -I.     -O -g -pipe -Wall 
> -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include 
> -I/usr/local/include -D__USE_BSD -MT renderer_ggi.o -MD -MP -MF 
> ".deps/renderer_ggi.Tpo" -c -o renderer_ggi.o renderer_ggi.c; \
> then mv -f ".deps/renderer_ggi.Tpo" ".deps/renderer_ggi.Po"; else rm -f 
> ".deps/renderer_ggi.Tpo"; exit 1; fi
> renderer_ggi.c: In function `HandleKeyboardGGI':
> renderer_ggi.c:318: error: `coinslot' undeclared (first use in this 
> function)
> renderer_ggi.c:318: error: (Each undeclared identifier is reported only
> once
> renderer_ggi.c:318: error: for each function it appears in.)
> renderer_ggi.c:352: error: `dipswitches' undeclared (first use in this 
> function)renderer_ggi.c:399: error: `joypad' undeclared (first use in 
> this function)
> renderer_ggi.c:472: error: `joypadd' undeclared (first use in this
> function)
> renderer_ggi.c: In function `InitDisplayGGI':
> renderer_ggi.c:1046: warning: implicit declaration of function 
> `set_renderer_basetime'
> renderer_ggi.c:767: warning: unused variable `time'
> renderer_ggi.c: In function `UpdateDisplayGGI':
> renderer_ggi.c:1144: warning: implicit declaration of function 
> `resynchronize'
> renderer_ggi.c:1136: warning: unused variable `time'
> renderer_ggi.c:1138: warning: unused variable `timeframe'
> 
> -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 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

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...>]

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] renderer_ggi doesn't compile

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

I don't nkow how far I can get at fixing this.  The errors here are all
ones I can handel, but any GGI problems I run into won't be so easy for me
to fix.

I'm running debian(testing) and if I could reduplicate your build then I
could test my fixes.

-mike

--- Jason Dorje Short <jd...@us...> wrote:
> if gcc -DHAVE_CONFIG_H -I. -I. -I.     -O -g -pipe -Wall 
> -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include 
> -I/usr/local/include -D__USE_BSD -MT renderer_ggi.o -MD -MP -MF 
> ".deps/renderer_ggi.Tpo" -c -o renderer_ggi.o renderer_ggi.c; \
> then mv -f ".deps/renderer_ggi.Tpo" ".deps/renderer_ggi.Po"; else rm -f 
> ".deps/renderer_ggi.Tpo"; exit 1; fi
> renderer_ggi.c: In function `HandleKeyboardGGI':
> renderer_ggi.c:318: error: `coinslot' undeclared (first use in this 
> function)
> renderer_ggi.c:318: error: (Each undeclared identifier is reported only
> once
> renderer_ggi.c:318: error: for each function it appears in.)
> renderer_ggi.c:352: error: `dipswitches' undeclared (first use in this 
> function)renderer_ggi.c:399: error: `joypad' undeclared (first use in 
> this function)
> renderer_ggi.c:472: error: `joypadd' undeclared (first use in this
> function)
> renderer_ggi.c: In function `InitDisplayGGI':
> renderer_ggi.c:1046: warning: implicit declaration of function 
> `set_renderer_basetime'
> renderer_ggi.c:767: warning: unused variable `time'
> renderer_ggi.c: In function `UpdateDisplayGGI':
> renderer_ggi.c:1144: warning: implicit declaration of function 
> `resynchronize'
> renderer_ggi.c:1136: warning: unused variable `time'
> renderer_ggi.c:1138: warning: unused variable `timeframe'
> 
> -jason
> 


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

[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

[Tuxnes-devel] renderer_ggi doesn't compile

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

if gcc -DHAVE_CONFIG_H -I. -I. -I.     -O -g -pipe -Wall 
-I/usr/X11R6/include -I/usr/local/include -I/usr/local/include 
-I/usr/local/include -D__USE_BSD -MT renderer_ggi.o -MD -MP -MF 
".deps/renderer_ggi.Tpo" -c -o renderer_ggi.o renderer_ggi.c; \
then mv -f ".deps/renderer_ggi.Tpo" ".deps/renderer_ggi.Po"; else rm -f 
".deps/renderer_ggi.Tpo"; exit 1; fi
renderer_ggi.c: In function `HandleKeyboardGGI':
renderer_ggi.c:318: error: `coinslot' undeclared (first use in this 
function)
renderer_ggi.c:318: error: (Each undeclared identifier is reported only once
renderer_ggi.c:318: error: for each function it appears in.)
renderer_ggi.c:352: error: `dipswitches' undeclared (first use in this 
function)renderer_ggi.c:399: error: `joypad' undeclared (first use in 
this function)
renderer_ggi.c:472: error: `joypadd' undeclared (first use in this function)
renderer_ggi.c: In function `InitDisplayGGI':
renderer_ggi.c:1046: warning: implicit declaration of function 
`set_renderer_basetime'
renderer_ggi.c:767: warning: unused variable `time'
renderer_ggi.c: In function `UpdateDisplayGGI':
renderer_ggi.c:1144: warning: implicit declaration of function 
`resynchronize'
renderer_ggi.c:1136: warning: unused variable `time'
renderer_ggi.c:1138: warning: unused variable `timeframe'

-jason

[Tuxnes-devel] =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoJDRNOztxQ1ckNyReJDkbKEI=?=

[<sun...@ya...>]

<Ž–‹ÆŽÒ><‘—MŽÒ>
‡ŠƒTƒ“ƒtƒ@ƒCƒiƒ“ƒX
ƒ[ƒ‹‚Ì•K—v‚È‚¢•û‚Í
sun...@ya...
‚܂ŁB

‡ŠƒTƒ“ƒtƒ@ƒCƒiƒ“ƒX‚Å‚·B
‘S‘‘¦“úƒXƒs[ƒh—ZŽ‘B
‚P–œ‰~`‚P‚O‚O–œ‰~ˆÈã‰Â”\‚Å‚·B
Å¬ŒÀ‚Ì‹à—˜‚ʼn^—p‚Å‚«‚Ü‚·B
“Œ‹ž“s’mŽ–”F‰ÂÁ”ïŽÒ‹à—Z‚Å‚·B
‚²—ZŽ‘‚²Šó–]‚Ì•û‚Í‚±‚¿‚ç‚Ü‚Å
http://www.interq.or.jp/cool/webmail/sunfaina
HP‚ª‰{——‚Å‚«‚È‚¢ê‡‚Í‚¨“d˜b‚­‚¾‚³‚¢B
0359501686(‘ã)
•q‘¬‚ȑΉž‚ð’v‚µ‚Ü‚·B
‚¨“d˜b‚Å‚àŽó‚¯•t‚¯‚¢‚½‚µ‚Ü‚·B

Re: [Tuxnes-devel] Smoother scrolling

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

The desync variable should be renamed to framesbehind.  When it's more than one we should not call
gettime or do the usleep.  We should framesbehind-- every frame and set it acordingly after the
gettime and before the usleep(Dose not get called when were behind).

As for the last time patch it stands as is.  The measurement of 1/60 a second applies to
everything we do, including the usleep.
  The fix needed is to redo the ordering.  Putting the usleep after we draw the frame before we do
the scoring is the answer.  It's true we can't find ought how log to wait at that time but we can
guess based on how long the last frame took.  The loop itself doesn't really have a start or
end(it's a loop) this concept is only created by the line numbers and should be ignored.  This is
the best order IMHO: Scoring(running the emu) before Rendering(Video&Sound) before
Gettime&Calculation before Sleeping before Drawing&Playing.
Drawing the frame and then calling swapbuffer(if available) after the usleep is a good idea but
it's not needed we can render right to the screen.  This would mean that any given frame is
displayed for exactly 1/60 a second.  The draw back is that every frame would be one frame behind
the input.  This is the case now but it's only part a frame.  The problem with nes emulation is
that input can be handled mid frame.  I don't think we can change the frame after the vsync has
ended.

--- Jason Dorje Short <jd...@us...> wrote:
> Mike Mestnik wrote:
> 
> > I forget where you can trap keypresses, there is a select statement some-where.  Reserve a key
> for
> > saving state, I started a branch for it and it's quite close to being testable.
> 
> Looks like there's already code for this.  There's a switch in 
> controller.c.  The keypad values change speed (for instance keypad 6 
> sets 6x speed).  They also set desync to 1 and 
> renderer_data.pause_display to 0 (no idea what this means).
> 
I was thinking about putting this code in another process, a fork.  Then emulate the nes
controller, I have the frequency some where.  This would get us away from polling and allow us to
do arbitrary input stuff(A bleeding flipper and a menu :).  We can use shared memory for the nes
registers and a command pipe/socket for every thing else.  This other process would also draw the
menus and other OSDs.

> > Things I'm looking fore are docs on nesticle.sta and that other nes file format.  The docs I
> have
> > on sta are not fully complete and I would like to include a copy of the rom in the image(for
> > game-genie).  There is some open nes format but the docs just baffeld me. it seamed to be
> packet
> > based but no real docs just blerb ware.
> 
> Several years ago a tuxnes developer (Mike Melanson?) sent me a spec for 
> the common-nes-save-file-format.  I doubt that I could find it now, 
> though.  At the same time he told me that the nesticle format should be 
> ignored and only the common format implemented.
> 
A web search didn't turn anything up, http://tuxnes.sourceforge.net/features.php talks about STA
and SNSS.  I think SNSS will be vary difficult for me to understand.

> jason


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Re: [Tuxnes-devel] Smoother scrolling

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

I'd also like to point out that the desync variable is never actually 
used.  It is set in lots and lots of places, but never accessed.

What is it supposed to do???

jason

Re: [Tuxnes-devel] Smoother scrolling

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

Mike Mestnik wrote:

> I forget where you can trap keypresses, there is a select statement some-where.  Reserve a key for
> saving state, I started a branch for it and it's quite close to being testable.

Looks like there's already code for this.  There's a switch in 
controller.c.  The keypad values change speed (for instance keypad 6 
sets 6x speed).  They also set desync to 1 and 
renderer_data.pause_display to 0 (no idea what this means).

> Things I'm looking fore are docs on nesticle.sta and that other nes file format.  The docs I have
> on sta are not fully complete and I would like to include a copy of the rom in the image(for
> game-genie).  There is some open nes format but the docs just baffeld me. it seamed to be packet
> based but no real docs just blerb ware.

Several years ago a tuxnes developer (Mike Melanson?) sent me a spec for 
the common-nes-save-file-format.  I doubt that I could find it now, 
though.  At the same time he told me that the nesticle format should be 
ignored and only the common format implemented.

jason

Re: [Tuxnes-devel] Smoother scrolling

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

--- Jason Dorje Short <jd...@us...> wrote:
> I think this update needs to come *after* the usleep.
> 
>    if (frame > 1800) {
>      frame = 0;
>      renderer_data.basetime.tv_sec = now.tv_sec;
>      renderer_data.basetime.tv_usec = now.tv_usec + usec.
>    }
> 
> The time "now" is not significant.  The correct time is the time we're 
> usleeping to, which is the time of the start of the current frame (frame 0).
> 
Ohh, so that's what thay where doing with the other gettime.  I think what you have here is ok. 
I'l commit this somtime, I wana think about it some more.

> Otherwise it'll consistently be off by 1/100 of a second every 30 
> seconds :-).
> 
> The next step is probably making it possible to change 
> doublespeed/halfspeed while the game is running.  This shouldn't be too 
> hard: when the values are changed reset the frame to 0 and start 
> counting anew.
> 
I forget where you can trap keypresses, there is a select statement some-where.  Reserve a key for
saving state, I started a branch for it and it's quite close to being testable.

Things I'm looking fore are docs on nesticle.sta and that other nes file format.  The docs I have
on sta are not fully complete and I would like to include a copy of the rom in the image(for
game-genie).  There is some open nes format but the docs just baffeld me. it seamed to be packet
based but no real docs just blerb ware.

> jason
> 



__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Re: [Tuxnes-devel] Smoother scrolling

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

Ryan Jackson wrote:

> Definately!  Things look a lot smoother now.  I've noticed a couple of
> things however.  It seems to run more smoothly in some display modes
> than in others. Might this have something to do with the difference
> between the NTSC refresh rate and whatever rate my monitor is running
> at?  (I don't know too much about that stuff (yet)).

I doubt it.  Even if the monitor only updated every other frame you 
shouldn't notice the difference.

> The new behavior seems to make the emulator more sensitive to timing
> problems when sharing the CPU with another cpu-bound process. Example: I
> was testing the patch with Super Mario Brothers.  After a few minutes,
> cron started a password-cracking process in the background.  Not only
> did play slow down (as with the old behavior), but every few seconds the
> graphics would glitch.  It looked like it started to redraw the
> framebuffer, but instead of drawing it at the top of the screen it
> started in the middle.  Kind of hard to describe. :-/

This is probably because it always sleeps, instead of only sleeping when 
things get behind.  This provides better real-time behavior but makes it 
more likely that the game can't keep up with real-time.

jason

Re: [Tuxnes-devel] Smoother scrolling

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

Mike Mestnik wrote:
> Yes you are correct, how ever tuxnes takes care of counting ticks in the ASM.  Every time we draw
> a frame it's been 1/60 of a second nes time, so we just need to make the real computer emulate
> that.  In most video games timing will be constant, this way we don't get into complex
> acceleration equations and such.  Too take care of the time we spend when were not sleeping we put
> the gettime as close as posible to where we sleep.
> 
> Also I don't normally keep track of total time.  I don't know how different the 2 methods are, but
> I know my way doesn't get overflowed.  What I do is reset my tick ctr to 0 every time I sleep, I
> use the current time to populate basetime(Renamed to lasttime).  See my patch for an example that
> includes a hybrid method.  I think it would be safe to remove the "if ( frame > 1800 )", I'd like
> to here your comments.
> 
> --- digression ---
> 
> Yes you are correct, how ever video games use polling.  It's not clear what to do with a move once
> the frame(round) is over, so processing(scoring) of that move MUST wait for the next round.  We
> could take the input and differ scoring, but this would only make the usleep for this round a bit
> less.  It's ok to ignore the input until it's round is being scored.
> 
> Also the nes uses polling, so we poll when it asks us too.  It would be cool to make this script
> able for things like up-up-down-down...  Think mric type nes scripting :)
> 
> I've attached what I committed it's should hit the backup CVS server in 2 days.

> +  if (usec > 0) {
> +    if ( frame > 1800 ) /* Every 30 seconds */
> +       {
> +	  frame = 0;
> +	  renderer_data.basetime.tv_sec = now.tv_sec;
> +	  renderer_data.basetime.tv_usec = now.tv_usec;
> +       }
> +    usleep(usec);

I think this update needs to come *after* the usleep.

   if (frame > 1800) {
     frame = 0;
     renderer_data.basetime.tv_sec = now.tv_sec;
     renderer_data.basetime.tv_usec = now.tv_usec + usec.
   }

The time "now" is not significant.  The correct time is the time we're 
usleeping to, which is the time of the start of the current frame (frame 0).

Otherwise it'll consistently be off by 1/100 of a second every 30 
seconds :-).

The next step is probably making it possible to change 
doublespeed/halfspeed while the game is running.  This shouldn't be too 
hard: when the values are changed reset the frame to 0 and start 
counting anew.

jason

Re: [Tuxnes-devel] Smoother scrolling

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

--- Ryan Jackson <pro...@ya...> wrote:
> Changing the usleep() delay doesn't sound right to me either, but it's
> the only thing I've found that works.
> 
> Which gettimeofday() call did you remove: the one in set_timeframe() or
> set_frameskip()?  I tried changing set_timeframe(), but all that
> happened was the emu ran way too fast.  The scrolling was smooth though.
> :-)  What exactly was the problem you were chasing?
> 
It looked like frameskip was getting set and never reset.  Ruened my CastelVenia 2 games, I had to
reset.


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus