tuxnes-devel — Development discussion for the TuxNES project

[Tuxnes-devel] =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoISEhejpfQnAkRyROJVElPSUzJXMbKEI=?= =?iso-2022-jp?B?GyRCJHI7SCRDJD8kKjtFO3YkTjBGRmIkRyQ5ISMhehsoQg==?=

[<mai...@fr...>]

                  =1B$B#F#R#E#E!!#S#T#Y#L#E!!#C#O=1B(B.,=1B$B#L#T#D=1B(B
=1B$B!!!!!!!!!!!!!!!!!!!!!!!!=1B(B
=1B$B!!!!!!!!!!!!!!!!!!El5~ETL\9u6h<+M3%v5V#2!]#1#7!]#1#1=1B(B
=1B$B!!!!!!!!!!!!!!!!!!#T#E#L!!#0#1#2#0!]#5#0#8!]#0#8#1=1B(B

 =1B$B"(!!EvJ}$+$i$N%a!<%k$,ITMW$JJ}$O!"!X<u?.5qH]!Y$HI=3D<($7$F=1B(B
=1B$B!!!!=1B(B inf...@fr... =
=1B$B$^$G%a!<%k$rAw?.$7$F2<$5$$!#=1B(B

=1B$B!!@$$NCfIT7J5$$G!"E];:$@%j%9%H%i$@$HBgJQ$G$9!#=1B(B
=1B$B6P$a$F$$$F$b5kNA$O>e$,$i$J$$$7!";D6H$,$J$$J,2<$,$C$F$$$^$9!#=1B(B
=1B$B$*6b$,$b$&>/$7!"$;$a$F#5K|$G$b!"$$$d#3K|$G$bM>J,$K2T$2$l$P!&!&=1B(B
=1B$BC/$b$,9M$($?;v$,M-$k$H;W$$$^$9!#=1B(B
=1B$B!!=1B(B
=1B$B%"%k%P%$%H$,=3DPMh$F!">/$7M>J,$K2T$2$l$P!&!&=1B(B
=1B$B$G$b!"2q<R$KCN$l$?$i!&!&!#;R6!$,>.$5$/$F2H$r6u$1$l$J$$!&!&!#=1B(B
=1B$B6a$/$K<+J,$K=3DPMh$k;E;v$,!&!&!#$J$+$J$+4uK>$N$b$N$O>/$J$$$N$G$9!*=1B=
(B

=1B$B!!$b$7!"<+Bp$G=3DPMh$F!&!&!#<+J,$N<+M3$J;~4V$K!&!&!#0BDjE*$K=3DPMh$k=
=1B(B
=1B$B$*;E;v$,=3DPMh$?$i$I$&$G$7$g$&!)=1B(B
=1B$B!!$=3D$l$b!"<+J,$G>e<j$K=3DP$-$k$h$&$K$J$l$P!">-Mh@l6H$H$7$F<+N)$7$F=
=1B(B
=1B$B9T$/$3$H$b2DG=3D$K$J$k$N$G$9!*!*=1B(B
=1B$B$4<+Bp$G%Q%=3D%3%s5;G=3D$rMxMQ$7$F!"Kh7n0BDjE*$J<}F~$r9M$($F$_$^$;$s=
$+!)=1B(B

=1B$B<gIX!&<R2q?M!&G/G[<T!&3X@8!&%"%k%P%$%?!<Ey$,8=3D:_3hLv$7$F$$$^$9!*=1B=
(B
=1B$B6HL3$O!"%G!<%?!<F~NO!&J8=3DqF~NO!&%W%m%0%i%_%s%0Ey!">\$7$/$O2<5-$K!*=
=1B(B

=1B$B%Q%=3D%3%s;q3JM-$k?M$b$J$$?M$b!"=3Di?4<T$G$b$d$k5$$,$"$l$PBg>fIW$G$9=
!*=1B(B
=1B$B%[!<%`%Z!<%8>e$G!"$"$J$?$N%l%Y%k$r%A%'%C%/$7!"$"$J$?$K9g$C$?$*;E;v$r=
=1B(B
=1B$BDs6!$$$?$7$^$9!#=1B(B


=1B$B!!!!"!!!!!!!"!!!!!!!"!!!!!!!"!!!!!!!"!!!!!!!"!!!!!!!"!!!!!!!"!!!!!!!=
"!=1B(B

=1B$B!!!!=1B(B
=1B$B!!!!!!"!>\$7$$0FFb;qNA$rL5NA$K$FAwIU$7$F$$$^$9!#=1B(B
=1B$B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!2<5-%[!<%`%Z!<%8$r$4Mw$N$&$($4@A=
5a$7$F2<$5$$!#=1B(B

=1B$B!!!!!!!!!!!!!!!!!!!!!!!!!!=1B(Bhttp://www.free-style.servehttp.com/

[Tuxnes-devel] tuxnes

[Nick P. <Npi...@um...>]

Mike -

Hope you don't mind the intrusion, there's been a short thread on the tuxnes devel list about CVS 
compile problems...  Mike Melanson suggested I contact you...  The thread kinda speaks for itself. 
If you've got the time, I'd appreciate any advice you could offer.

Thanks -

Nick Pietraniec



--------------------------------------------------------------------------------------------------

Hi everyone...  I'm trying to compile tuxnes CVS on RedHat 8 (I'd like SDL support)  Does the output 
below make sense to anyone?  This project seems kinda stagnant, has it been abandoned/put on 
hold/otherwise?

-Nick



make  all-am
make[1]: Entering directory `/mnt/linux/home/nickp/tuxnes'
source='emulator_x86.c' object='emulator_x86.o' libtool=no \
depfile='.deps/emulator_x86.Po' tmpdepfile='.deps/emulator_x86.TPo' \
depmode=gcc3 /bin/sh ./depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.     -O -g -pipe -Wall -I/usr/X11R6/include -I/usr/local/include 
-D__USE_BSD -c `test -f 'emulator_x86.c' || echo './'`emulator_x86.c
cc1: warning: changing search order for system directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-system directory
emulator_x86.c: In function `DoNMIX86':
emulator_x86.c:74: `RAM' undeclared (first use in this function)
emulator_x86.c:74: (Each undeclared identifier is reported only once
emulator_x86.c:74: for each function it appears in.)
emulator_x86.c: In function `InitMapperSubsystemX86':
emulator_x86.c:88: `MapperInit' undeclared (first use in this function)
emulator_x86.c:89: `Mapper' undeclared (first use in this function)
emulator_x86.c: In function `InitMemoryX86':
emulator_x86.c:176: `RAM' undeclared (first use in this function)
emulator_x86.c:183: warning: implicit declaration of function `exit'
emulator_x86.c:204: warning: implicit declaration of function `translate'
make[1]: *** [emulator_x86.o] Error 1
make[1]: Leaving directory `/mnt/linux/home/nickp/tuxnes'
make: *** [all] Error 2
[root@plwx0205 tuxnes]#





	Yeah, it's pretty stagnant. In fact, when you posted your error
report, it was the first time I had ever heard of emulator_x86.c. Shows
how much I have been paying attention. What version of gcc are you using?

	Thanks...
--
	-Mike Melanson



On Wed, 27 Nov 2002, Nick Pietraniec wrote:


 >> 3.2, stock redhat...  I tried on a install of RedHat 7.2 too...  I had
 >> to update autoconf and automate on it so I just installed the RH 8
 >> versions...  I think it might be that.  Any thoughts?


	We've seen problems before where code that compiled with v2.95
series gcc failed to compile with gcc 3.0+.

	Try contacting mi...@fl... and find out what version he was
using. He was the last person to hack on the CVS codebase.

	Thanks...
--
	-Mike Melanson

Re: [Tuxnes-devel] compile error

[Mike M. <mel...@pc...>]

On Wed, 27 Nov 2002, Nick Pietraniec wrote:

> Hi everyone...  I'm trying to compile tuxnes CVS on RedHat 8 (I'd like
> SDL support)  Does the output below make sense to anyone?  This project
> seems kinda stagnant, has it been abandoned/put on hold/otherwise?

	Yeah, it's pretty stagnant. In fact, when you posted your error
report, it was the first time I had ever heard of emulator_x86.c. Shows
how much I have been paying attention. What version of gcc are you using?

	Thanks...
--
	-Mike Melanson

[Tuxnes-devel] compile error

[Nick P. <npi...@um...>]

Hi everyone...  I'm trying to compile tuxnes CVS on RedHat 8 (I'd like 
SDL support)  Does the output below make sense to anyone?  This project 
seems kinda stagnant, has it been abandoned/put on hold/otherwise?

-Nick



make  all-am
make[1]: Entering directory `/mnt/linux/home/nickp/tuxnes'
source='emulator_x86.c' object='emulator_x86.o' libtool=no \
depfile='.deps/emulator_x86.Po' tmpdepfile='.deps/emulator_x86.TPo' \
depmode=gcc3 /bin/sh ./depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.     -O -g -pipe -Wall 
-I/usr/X11R6/include -I/usr/local/include -D__USE_BSD -c `test -f 
'emulator_x86.c' || echo './'`emulator_x86.c
cc1: warning: changing search order for system directory 
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system directory
emulator_x86.c: In function `DoNMIX86':
emulator_x86.c:74: `RAM' undeclared (first use in this function)
emulator_x86.c:74: (Each undeclared identifier is reported only once
emulator_x86.c:74: for each function it appears in.)
emulator_x86.c: In function `InitMapperSubsystemX86':
emulator_x86.c:88: `MapperInit' undeclared (first use in this function)
emulator_x86.c:89: `Mapper' undeclared (first use in this function)
emulator_x86.c: In function `InitMemoryX86':
emulator_x86.c:176: `RAM' undeclared (first use in this function)
emulator_x86.c:183: warning: implicit declaration of function `exit'
emulator_x86.c:204: warning: implicit declaration of function `translate'
make[1]: *** [emulator_x86.o] Error 1
make[1]: Leaving directory `/mnt/linux/home/nickp/tuxnes'
make: *** [all] Error 2
[root@plwx0205 tuxnes]#

[Tuxnes-devel] torsten howards compile problems

[BoBB <sno...@qw...>]

Hi, i am having the same problem as torsten. Sorry for the thread break
but i just subscribed. I have latest zlib, latest gzip, gcc 2.95.3 and
as far as i can tell only one version of zlib.

#~: locate zlib.h
/usr/include/bzlib.h
/usr/include/zlib.h
/usr/lib/mozilla/include/nss/zlib.h
/usr/lib/mozilla/include/zlib/zlib.h
/usr/src/linux-2.4.19-gentoo-r9/arch/ppc/boot/include/zlib.h
/usr/src/linux-2.4.19-gentoo-r9/arch/ppc64/boot/zlib.h
/usr/src/linux-2.4.19-gentoo-r9/drivers/net/zlib.h
/usr/src/linux-2.4.19-gentoo-r9/fs/jffs2/zlib.h
/usr/src/linux-2.4.19-gentoo-r9/include/zlib/zlib.h
/usr/X11R6/include/X11/extensions/lbxzlib.h
/usr/X11R6/include/zlib.h
#~: 

#~: locate zlib.h
/usr/include/bzlib.h
/usr/include/zlib.h
/usr/lib/mozilla/include/nss/zlib.h
/usr/lib/mozilla/include/zlib/zlib.h
/usr/src/linux-2.4.19-gentoo-r9/arch/ppc/boot/include/zlib.h
/usr/src/linux-2.4.19-gentoo-r9/arch/ppc64/boot/zlib.h
/usr/src/linux-2.4.19-gentoo-r9/drivers/net/zlib.h
/usr/src/linux-2.4.19-gentoo-r9/fs/jffs2/zlib.h
/usr/src/linux-2.4.19-gentoo-r9/include/zlib/zlib.h
/usr/X11R6/include/X11/extensions/lbxzlib.h
/usr/X11R6/include/zlib.h
#~: 

anyone have any ideas how i can fix this?

-- 
BoBB

Re: [Tuxnes-devel] Compile Failure

[Torsten H. <to...@in...>]

On Tue, 30 Jul 2002 21:16:39 -0600 (MDT)
Mike Melanson <mel...@pc...> wrote:

> On Tue, 30 Jul 2002, Torsten Howard wrote:
> 
> > I have version zlib-1.1.4.  You mention gzip, I have gzip 1.2.4.
> > 
> > Both are latest, except that gzip has a patch for a buffer overflow I
> > haven't installed (I don't run an ftp server).
> 
> 	I don't doubt that you have the latest zlib version installed. But
> as my last email mentioned, is it the only zlib version installed on your
> system? Run 'locate zlib.h' and 'locate libz.a' on your system to make
> sure you don't have any extra versions floating around. This stings a lot
> of users (including me).
> 
> 	The first error from your email indicated that the compiler could
> not find the symbol ZEXPORT which is defined in zconf.h which is included
> by zlib.h. Just curious, what version of gcc are you using?
>

Ok, so I like to think my self half-way intelligent.  I've been using
Linux about five years now, I hand-compile my distribution following
the linuxfromscratch website, and I'm generally keen on most things.

But I have two versions of zlib.  Apparently, there is one included in
in the development files for X.

Note that /usr/local/include/zlib.h is a symlink to
/usr/local/src/zlib/include/zlib.h
---------------------------------
~--$locate zlib.h
/usr/include/bzlib.h
/usr/local/include/zlib.h
/usr/local/src/zlib-1.1.4/include/zlib.h
/usr/src/linux-2.4.18/arch/ppc/boot/include/zlib.h
/usr/src/linux-2.4.18/drivers/net/zlib.h
/usr/src/linux-2.4.18/fs/jffs2/zlib.h
/usr/X11R6/include/X11/extensions/lbxzlib.h
/usr/X11R6/include/zlib.h
~--$locate zconf.h
/usr/local/include/zconf.h
/usr/local/src/zlib-1.1.4/include/zconf.h
/usr/src/linux-2.4.18/fs/inflate_fs/zconf.h
/usr/X11R6/include/zconf.h
~--$gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
gcc version 2.95.3 20010315 (release)
~--$

---------------------------------

So, now I feel the idiot.  Hehe.  It's good for me.
The X version of zlib only has the static version of the zlib library.

gcc is v 2.95.3, known stable (last I heard).

tuxnes compiles.  Your help is very much appreciated, Mike.
Torsten

Re: [Tuxnes-devel] Compile Failure

[Mike M. <mel...@pc...>]

On Tue, 30 Jul 2002, Torsten Howard wrote:

> I have version zlib-1.1.4.  You mention gzip, I have gzip 1.2.4.
> 
> Both are latest, except that gzip has a patch for a buffer overflow I
> haven't installed (I don't run an ftp server).

	I don't doubt that you have the latest zlib version installed. But
as my last email mentioned, is it the only zlib version installed on your
system? Run 'locate zlib.h' and 'locate libz.a' on your system to make
sure you don't have any extra versions floating around. This stings a lot
of users (including me).

	The first error from your email indicated that the compiler could
not find the symbol ZEXPORT which is defined in zconf.h which is included
by zlib.h. Just curious, what version of gcc are you using?

	Thanks...
-- 
	-Mike Melanson

Re: [Tuxnes-devel] Compile Failure

[Torsten H. <to...@in...>]

> > It appears that some functions are missing from the the unzip headers,
> > I'm not sure.  Any help appreciated.
> 
> 	It looks like the build isn't finding the symbol ZEXPORT. This is
> defined in zlib. Some questions:
> 
> 1) Do you have zlib installed? It's reasonable that you do or else the
> compiler should have thrown an error about not finding zlib.h.
Yes, zlib is installed.



> 2) Do you have the latest zlib installed? I believe it is v1.1.4. Get it
> from www.gzip.org.

I have version zlib-1.1.4.  You mention gzip, I have gzip 1.2.4.

Both are latest, except that gzip has a patch for a buffer overflow I
haven't installed (I don't run an ftp server).


Still a strange situation.  I've had a look through the zlib.h header and
the functions that are requested unz* simply are not there.  Hmmm...

Torsten

Re: [Tuxnes-devel] Compile Failure

[Mike M. <mel...@pc...>]

On Tue, 30 Jul 2002, Torsten Howard wrote:

> I'm having difficulty compiling tuxnes.  I also have some difficulty
> with other emulators, in a similar way.
> 
> It appears that some functions are missing from the the unzip headers,
> I'm not sure.  Any help appreciated.

	It looks like the build isn't finding the symbol ZEXPORT. This is
defined in zlib. Some questions:

1) Do you have zlib installed? It's reasonable that you do or else the
compiler should have thrown an error about not finding zlib.h.

2) Do you have the latest zlib installed? I believe it is v1.1.4. Get it
from www.gzip.org.

Warning: When you install a new zlib version on a system that has an
existing version, make sure that the system is using the newer version.
The new version will probably be installed in /usr/local/lib and
/usr/local/include while there was an old version in /usr/lib/ and
/usr/include. Make sure the old files get deleted and then re-run
/sbin/ldconfig.

	Good luck...
--
	-Mike Melanson

[Tuxnes-devel] Compile Failure

[Torsten H. <to...@in...>]

Hello,

I'm having difficulty compiling tuxnes.  I also have some difficulty
with other emulators, in a similar way.

It appears that some functions are missing from the the unzip headers,
I'm not sure.  Any help appreciated.

unzip-5.50
tuxnes-0.75

Linux OS.

Thanks,
Torsten


----------------------
unzip.h:114: parse error before `unzStringFileNameCompare'
unzip.h:116: warning: type defaults to `int' in declaration of `unzStringFileNameCompare'
unzip.h:116: warning: data definition has no type or storage class
unzip.h:127: parse error before `unzOpen'
unzip.h:127: warning: type defaults to `int' in declaration of `unzOpen'
unzip.h:127: warning: data definition has no type or storage class
unzip.h:138: parse error before `unzClose'
unzip.h:138: warning: type defaults to `int' in declaration of `unzClose'
unzip.h:138: warning: data definition has no type or storage class
unzip.h:145: parse error before `unzGetGlobalInfo'
unzip.h:146: warning: type defaults to `int' in declaration of `unzGetGlobalInfo'
unzip.h:146: warning: data definition has no type or storage class
unzip.h:153: parse error before `unzGetGlobalComment'
unzip.h:155: warning: type defaults to `int' in declaration of `unzGetGlobalComment'
unzip.h:155: warning: data definition has no type or storage class
unzip.h:166: parse error before `unzGoToFirstFile'
unzip.h:166: warning: type defaults to `int' in declaration of `unzGoToFirstFile'
unzip.h:166: warning: data definition has no type or storage class
unzip.h:172: parse error before `unzGoToNextFile'
unzip.h:172: warning: type defaults to `int' in declaration of `unzGoToNextFile'
unzip.h:172: warning: data definition has no type or storage class
unzip.h:179: parse error before `unzLocateFile'
unzip.h:181: warning: type defaults to `int' in declaration of `unzLocateFile'
unzip.h:181: warning: data definition has no type or storage class
unzip.h:192: parse error before `unzGetCurrentFileInfo'
unzip.h:199: warning: type defaults to `int' in declaration of `unzGetCurrentFileInfo'
unzip.h:199: warning: data definition has no type or storage class
unzip.h:218: parse error before `unzOpenCurrentFile'
unzip.h:218: warning: type defaults to `int' in declaration of `unzOpenCurrentFile'
unzip.h:218: warning: data definition has no type or storage class
unzip.h:224: parse error before `unzCloseCurrentFile'
unzip.h:224: warning: type defaults to `int' in declaration of `unzCloseCurrentFile'
unzip.h:224: warning: data definition has no type or storage class
unzip.h:231: parse error before `unzReadCurrentFile'
unzip.h:233: warning: type defaults to `int' in declaration of `unzReadCurrentFile'
unzip.h:233: warning: data definition has no type or storage class
unzip.h:245: parse error before `unztell'
unzip.h:245: warning: type defaults to `int' in declaration of `unztell'
unzip.h:245: warning: data definition has no type or storage class
unzip.h:250: parse error before `unzeof'
unzip.h:250: warning: type defaults to `int' in declaration of `unzeof'
unzip.h:250: warning: data definition has no type or storage class
unzip.h:255: parse error before `unzGetLocalExtrafield'
unzip.h:257: warning: type defaults to `int' in declaration of `unzGetLocalExtrafield'
unzip.h:257: warning: data definition has no type or storage class
emu.c: In function `main':
emu.c:1716: warning: assignment makes pointer from integer without a cast
emu.c:1187: warning: `size' might be used uninitialized in this function
make: *** [emu.o] Error 1
root:/home/torsten/src/tuxnes-0.75# 

Re: [Tuxnes-devel] Use of mmap () (fwd)

[Mike M. <mel...@pc...>]

Hi,
	It looks like Quor meant this for the entire list...

-- 
	-Mike Melanson

---------- Forwarded message ----------
Date: Thu, 6 Jun 2002 23:20:55 -0400 (EDT)
From: Quor <qu...@no...>
To: tux...@li...
Cc: mel...@pc...
Subject: Re: [Tuxnes-devel] Use of mmap ()

Mike Melanson wrote:

> On Tue, 14 May 2002, W. Michael Petullo wrote:
> 
> > The comment makes me wonder why malloc was not used.  I am not familiar
> > with the MAP_ANON option.
> > 
> > Also, in mapper.h things like _RAM point to hard-coded addresses, in
> > this case 0x10000000.  Again, why is this done?  GNU as will assume that
> > undefined variables are, to use C's syntax, extern, so _RAM could just
> > be defined as a char * in mapper.c.
> 
>       The best answer for all of your questions is: "Because that's the
> way quor originally wrote Nestra." It's the kind of thing that worked and
> no one ever really understood it or had a reason to try to change it, even
> though they had an inkling that it may not have been the most rational
> thing to do.

You're half right. :-)  The mmaps have been there since I originally
wrote the code over 4 years ago, but that particular line hasn't.

Originally, it mapped the rom file.  Then someone decided to add gzip
support, and changed the mmap to MAP_ANON, then uncompressed the rom
into this memory.  Of course this could be done with malloc, but then
you'd have to change all references to _RAM to follow a pointer instead.
extern char * and extern char [] are not the same thing!  _RAM is
treated like the latter.

The reason for the fixed addresses is to make it easier to link with
the dynrec core.  You can use different addresses.  Also these regions
are (deliberately) not contiguous; an out-of-bounds access will cause
SIGSEGV.  That was important for me to aid debugging; others may not care.

The references to ROM_BASE - 0x8000 in mapper.c are due to the rom being
mapped at 0x8000 in the 6502 address space.  So accessing address 0x8000
under such a mapping is redirected to ROM_BASE-0x8000+0x8000, which is
actually an offset of zero.  ROM_BASE - 0x8000 is unmapped; it should be
impossible to actually get such a negative offset, but if it somehow
happened, the process would immediately die with a segfault.

CODE_BASE is where the dynamic recompiler will write the translated code
that it generates.  INT_MAP is the translation address map for the 6502
in integer mode.  Since the NES CPU doesn't have a decimal mode, there
is no DEC_MAP.

Re: [Tuxnes-devel] Use of mmap ()

[Mike M. <mel...@pc...>]

On Tue, 14 May 2002, W. Michael Petullo wrote:

> The comment makes me wonder why malloc was not used.  I am not familiar
> with the MAP_ANON option.
> 
> Also, in mapper.h things like _RAM point to hard-coded addresses, in
> this case 0x10000000.  Again, why is this done?  GNU as will assume that
> undefined variables are, to use C's syntax, extern, so _RAM could just
> be defined as a char * in mapper.c.

	The best answer for all of your questions is: "Because that's the
way quor originally wrote Nestra." It's the kind of thing that worked and
no one ever really understood it or had a reason to try to change it, even
though they had an inkling that it may not have been the most rational
thing to do.

> I'm trying to get the dynrec. code to lay nicely with my new emulator
> interface.

	Do what it takes. If you haven't noticed, you're currently the
primary contributer to TuxNES...:)

	Thanks...
--
	-Mike Melanson

Re: [Tuxnes-devel] Use of mmap ()

[Jim U. <ji...@3e...>]

At 02:52pm on 2002 May 14, W. Michael Petullo did write:
> Could someone explain what mmap is being used for in emu.c: [...]
> Also, in mapper.h things like _RAM point to hard-coded addresses

I encountered this a long time ago.  (Remember when I said porting was
hard?)  As far as I remember, these issues are related.  tuxnes maps the
separate RAM, ROM, etc. arrays into a virtual address space.  That's what
the MAP_ANON (MAP_ANONYMOUS--see mmap(2)) does.  I'm not sure why this is
done.  Originally I thought it needed the regions to be contiguous, because
you'll see references to e.g. ROM_BASE - 0x4000 in mapper.c.  However,
these always ultimately resolve to addresses greater than ROM_BASE (!)
because they must be accessed with offsets greater than the negative offset
(0x4000, in this case).  My guess is the mmaps may be used to prevent seg
faults on out-of-bounds accesses, although it would be an odd way to do it. 

In tuxnes-dc I converted the ROM and RAM mmaps to use malloc().  Remember
to zero out the resulting array or you'll start doing weird things like
debugging SMB1 to find out why you always start out on level 5-1.  However,
since I discarded the dyn-rec I had no use for the CODE_BASE and INT_MAP
mmaps.  So I know you can successfully use malloc for RAM[] and ROM[] in
the interpreted core, but otherwise you're on your own.  In conclusion, let
me just say good luck. ;)

-- 
'I came to the 3-day "breatharian" seminar in Hawaii, but
without the $300 fee to attend. Wiley asked me: "If you
can't find $300, then how do you expect to find God?"' -- breatharian.com
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

[Tuxnes-devel] Use of mmap ()

[W. M. P. <mi...@fl...>]

Could someone explain what mmap is being used for in emu.c:

/* allocate space for the ROM */
if ((r = (int) mmap(ROM, 0x300000,
		    PROT_READ | PROT_WRITE | PROT_EXEC,
		    MAP_FIXED | MAP_PRIVATE | MAP_ANON, -1, 0)) < 0) {
    perror("mmap");
    exit(1);
}

?

The comment makes me wonder why malloc was not used.  I am not familiar
with the MAP_ANON option.

Also, in mapper.h things like _RAM point to hard-coded addresses, in
this case 0x10000000.  Again, why is this done?  GNU as will assume that
undefined variables are, to use C's syntax, extern, so _RAM could just
be defined as a char * in mapper.c.

I'm trying to get the dynrec. code to lay nicely with my new emulator
interface.

-- 
Mike

:wq

Re: [Tuxnes-devel] Modular emulator core

[Mike M. <mel...@pc...>]

On Sun, 12 May 2002, W. Michael Petullo wrote:

> I'd like to commit my changes into TuxNES's CVS tree.  Shall I?

	Sure, go for it. We trust you know what you're doing here.

	Thanks...
-- 
	-Mike Melanson

[Tuxnes-devel] Modular emulator core

[W. M. P. <mi...@fl...>]

I have modified TuxNES to support modular emulating cores.  For example,
nofrendo's C-based interpretor can be used instead of the traditional
dynamic recompiling code.  The nofrendo core /almost/ makes TuxNES work
on my PowerPC-based iBook, which runs Linux -- I have a feeling the
remaining problems are endian-related.

The code is developing, but is still a little ugly.  I will continue
to work on cleaning up the interfaces, reducing the amount of global
variables, fixing things I broke, etc.

I'd like to commit my changes into TuxNES's CVS tree.  Shall I?

-- 
Mike

:wq

[Tuxnes-devel] Trying out SDL

[Nick P. <Npi...@um...>]

Hello everyone, I just stumbled across the TuxNES project while looking for a NES emulator.  I 
downloaded .75 and gave it a try and it seems to work better than any emulator out there...  I was 
even more excited when I saw that there was work being done to implement fullscreen via sdl.  I've 
downloaded and compiled the CVS code, but am having a few problems...  I'm hoping someone can point 
me in the right direction.

If I use

./tuxnes --format=le16 cart.nes or ./tuxnes --renderer=diff --format=le16 Legend\ of\ Zelda.nes

everything works fine, but if I do

[nick@hydrogen tuxnes]$ ./tuxnes --renderer=sdl --format=le16 Legend\ of\ Zelda.nes
Couldn't open audio: Fragment size must be a power of two
./tuxnes: warning: failed to initialize sound playback
Error initializing joystick 0
Error initializing joystick 1

The same thing happens if I use any other audio format.

Does anyone know how I might "change my fragment size to a power ot 2?"  I'm using a SoundBlaster 
Live value on Kernel 2.4.18 if that matters...

Also, has "fullscreen" been implemented?  as far as I can tell, it seems to be using sdl...  Is 
there a fullscreen command line argument?

Thanks -

Nick

Re: [Tuxnes-devel] Portable TuxNES (was: SDL audio player)

[W. M. P. <mi...@fl...>]

> [...] 
> I would like a NES emulator which is as portable as possible, while
> remaining reasonably quick and light.  Specifically, in this case
> portable means ``able to run on a UNIX-like OS on any architecture''
> to me.  After looking around a bit more, I have a couple of options:
> 
> 1.  Clean up Jim Ursetto's Dreamcast port and re-add TuxNES's SDL, X11,
> etc. renderers.
> 
> 2.  Move Jim Ursetto's C NES interpreter into the TuxNES code tree
> (actually a little different process than step 1 -- TuxNES has changed
> a bit since the fork).
> 
> 3.  Begin working on nofrendo.
> 
> 4.  Fork my own NES emulator because my goal turns out to be incompatible
> with everyone else's.  I'd like to avoid this, of course.
> [...]

I talked to Neil Stevens, the current maintainer of nofrendo, and he
stated, ``No, Nofrendo isn't in active development.''  He went on to
say that the principle author requested a pause in development while he
works on a rewrite.

So I started tearing Jim's ported C emulator core out of TuxNES-DC and
putting it in TuxNES.  I've gotten it working...but its ugly.

I have made a flexible controller, renderer, and sounder interface (based
on Jim's code) for TuxNES.  The next step is a flexible emulator interface
which can attach to either the dynamic compiler (fast..or is it?) or
Jim/nofrendo's interpreter (portable).  This will clean up the code
immensely, but will take some time.

There are a few other problems with the TuxNES code.  It has too many
global variables and some of its functions are too big.  I hope to
clean this up as I continue to mold the controller, renderer, sounder,
and emulator interfaces.  Eventually, perhaps TuxNES will be able to
dynamically load plugins from shared objects.

I'd like to see Jim's Dreamcast code be ported to a clean interface too.

The question at this point is, should I check my current TuxNES sludge
into CVS for others to hack?  Or, should I wait until I've cleaned it up
a bit?  I vote for the former -- I could use some help and comments --
but would like to hear from the real TuxNES maintainers before I tarnish
the CVS repository.

-- 
Mike

:wq

Re: [Tuxnes-devel] SDL audio player

[Jim U. <ji...@3e...>]

At 11:14am on 2002 May 03, Mike Melanson did write:
> On Fri, 3 May 2002, W. Michael Petullo wrote:
> > Jim, why did you port the nofrendo engine to TuxNES instead of just
> > modifying nofrendo to run on the Dreamcast?
 
> 	As for why Jim did not port nofrendo, I don't believe the nofrendo
> source was generally available Jim began his effort.

Here are my reasons:

- I had worked with nestra even before TuxNES was forked.  I intended to
  produce proof-of-concept code utilizing a tile-based engine, accelerated
  with my 3dfx card.  Which I did.  Open-source NES emulators are a recent
  phenomenon; nestra was the only good one I could find at the time.
- Years later, intending to do the same on the Dreamcast, I looked for
  nestra and found TuxNES.  I knew nestra in great detail, so it seemed
  ideal.  In retrospect, it may have been faster to port another emulator.
  But even then TuxNES was the only -good- open NES emu out there.
  Nester et al were still closed source.  Nofrendo -may- have been open,
  but Matt Conte seemed to have dropped off the map.

I tried keep the Dreamcast port integrated in the original TuxNES code, but
the burden of compatibility became too large.  TuxNES's portability also
makes the code hard to follow (at least for me) and the #ifdefs for the DC
obfuscated it more.  So I scrapped code that was not sufficiently
abstracted.  But I did keep the plug-in model when possible--e.g. the DC
has two separate renderers, "dc" and "dc-tile".  I also made the sound
engine a plug-in, adding "oss", "dc", "mute", and "none" outputs.

Personally, I would try to simplify main().  It's one hell of a function,
and it needs to be broken out into smaller functions.  I did this to some
extent in tuxnes-dc.  But again, some code I replaced outright, because
abstracting it was too much work at the time.  I'd like to see, for
example, the separate renderer/palette/sample_format selection code
factored out into one reusable function.  (I tried this, and failed.)  This
would aid not only readability but portability, especially to non-POSIX
systems, although the latter perhaps does not concern you as much.

-- 
"When I was a child, I did things as a child.
 Now that I'm a man, I bust your ass and get wild." --Black Sheep/Freak Y'all
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

[Tuxnes-devel] Portable TuxNES (was: SDL audio player)

[W. M. P. <mi...@fl...>]

>> Nofrendo seems pretty nice -- I hadn't heard of that project.  At first
>> look, it appears quite portable.  It now seems to me that there are a
>> lot of competing NES emulators which are very similar.  Could someone
>> explain the reason for this?  Perhaps you could start with why TuxNES
>> forked from its parent project.  Jim, why did you port the nofrendo engine
>> to TuxNES instead of just modifying nofrendo to run on the Dreamcast?

> 	I can't fill you in on Jim's motivations, but I can tell you how
> TuxNES got its start. I needed an NES emulator that ran under Linux and
> could capture screenshots during gameplay. No available emulators fit the
> bill. But Nestra was opensource and easily modified for the task. I added
> a few more features and tried to roll them back into the main tree. But I
> feared that the Nestra maintainer no longer existed on the internet (I
> learned later that I was wrong) and so I forked a new project. That was
> almost 3 years ago.
> 
> 	One direction I had wanted to take TuxNES was to make a better,
> smarter dyn-rec core that would be easier to port to other platforms. But
> I never could get deep into that research.
> 
> 	As for why Jim did not port nofrendo, I don't believe the nofrendo
> source was generally available Jim began his effort.

I would like a NES emulator which is as portable as possible, while
remaining reasonably quick and light.  Specifically, in this case
portable means ``able to run on a UNIX-like OS on any architecture''
to me.  After looking around a bit more, I have a couple of options:

1.  Clean up Jim Ursetto's Dreamcast port and re-add TuxNES's SDL, X11,
etc. renderers.

2.  Move Jim Ursetto's C NES interpreter into the TuxNES code tree
(actually a little different process than step 1 -- TuxNES has changed
a bit since the fork).

3.  Begin working on nofrendo.

4.  Fork my own NES emulator because my goal turns out to be incompatible
with everyone else's.  I'd like to avoid this, of course.

Regardless, some dialog between the involved parties would probably
benefit all.

Comments?  Want to help?

-- 
Mike

:wq

Re: [Tuxnes-devel] SDL audio player

[Mike M. <mel...@pc...>]

On Fri, 3 May 2002, W. Michael Petullo wrote:

> Nofrendo seems pretty nice -- I hadn't heard of that project.  At first
> look, it appears quite portable.  It now seems to me that there are a
> lot of competing NES emulators which are very similar.  Could someone
> explain the reason for this?  Perhaps you could start with why TuxNES
> forked from its parent project.  Jim, why did you port the nofrendo engine
> to TuxNES instead of just modifying nofrendo to run on the Dreamcast?

	I can't fill you in on Jim's motivations, but I can tell you how
TuxNES got its start. I needed an NES emulator that ran under Linux and
could capture screenshots during gameplay. No available emulators fit the
bill. But Nestra was opensource and easily modified for the task. I added
a few more features and tried to roll them back into the main tree. But I
feared that the Nestra maintainer no longer existed on the internet (I
learned later that I was wrong) and so I forked a new project. That was
almost 3 years ago.

	One direction I had wanted to take TuxNES was to make a better,
smarter dyn-rec core that would be easier to port to other platforms. But
I never could get deep into that research.

	As for why Jim did not port nofrendo, I don't believe the nofrendo
source was generally available Jim began his effort.

--
	-Mike Melanson

Re: [Tuxnes-devel] SDL audio player

[W. M. P. <mi...@fl...>]

>>> I understand that the dynamic recompiling technique requires assembly and
>>> adding a C-based alternative would take a bit of work.  It would be nice
>>> to have TuxNES run on all the (sane) platforms supported by Linux, though.
>>> Would anyone be interested in this if I started it?

>> [...]
>> 	No need for you to start it. Jim Ursetto has already got a working
>> port for the Sega Dreamcast.
>> [...]
 
> [...]
> Yes, it's interpreted (not dynamic), based off Matt Conte's
> nosefart/nofrendo C core.  It needs cleaning up, and I believe it would
> take some vigorous thinking to integrate it properly back into TuxNES.  
> [...]

Nofrendo seems pretty nice -- I hadn't heard of that project.  At first
look, it appears quite portable.  It now seems to me that there are a
lot of competing NES emulators which are very similar.  Could someone
explain the reason for this?  Perhaps you could start with why TuxNES
forked from its parent project.  Jim, why did you port the nofrendo engine
to TuxNES instead of just modifying nofrendo to run on the Dreamcast?

-- 
Mike

:wq

Re: [Tuxnes-devel] SDL audio player

[Jim U. <ji...@3e...>]

At 04:06pm on 2002 May 02, Mike Melanson did write:
> > I understand that the dynamic recompiling technique requires assembly and
> > adding a C-based alternative would take a bit of work.  It would be nice
> > to have TuxNES run on all the (sane) platforms supported by Linux, though.
> > Would anyone be interested in this if I started it?
> 	No need for you to start it. Jim Ursetto has already got a working
> port for the Sega Dreamcast.

Yes, it's interpreted (not dynamic), based off Matt Conte's
nosefart/nofrendo C core.  It needs cleaning up, and I believe it would
take some vigorous thinking to integrate it properly back into TuxNES.  

You don't have to fully understand the dyn-rec to implement an interpreted
C core (although a good understanding helps), but you -do- have to
understand how the dyn-rec interfaces with the rest of the code, and
reimplement this interface in C.  That's the tricky part.  There are also
calculations and variable assignments done in assembly (not technically
part of the dyn-rec engine) that need to be converted.  I've already done
this, and for this reason it's a good starting point.

-- 
"When I was a child, I did things as a child.
 Now that I'm a man, I bust your ass and get wild." --Black Sheep/Freak Y'all
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710

Re: [Tuxnes-devel] SDL audio player

[Mike M. <mel...@pc...>]

On Thu, 2 May 2002, W. Michael Petullo wrote:

> >       UNIX-like, and x86-like platforms...:) Thanks for the
> > contributions.
> > [...]
> 
> Has anyone considered a C-based alternative to TuxNES's x86 assembly code?

	Yep, many people, including myself...

> I understand that the dynamic recompiling technique requires assembly and
> adding a C-based alternative would take a bit of work.  It would be nice
> to have TuxNES run on all the (sane) platforms supported by Linux, though.
> Would anyone be interested in this if I started it?

	No need for you to start it. Jim Ursetto has already got a working
port for the Sega Dreamcast. Check the trivial hacks section on his
website:
  http://www.3e8.org

	Thanks...
--
	-Mike Melanson

Re: [Tuxnes-devel] SDL audio player

[W. M. P. <mi...@fl...>]

>> [...] it should be simple to port TuxNES to any platform supported
>> by SDL.  Well, at least the UNIX-like ones.
>> [...]

>       UNIX-like, and x86-like platforms...:) Thanks for the
> contributions.
> [...]

Has anyone considered a C-based alternative to TuxNES's x86 assembly code?
I understand that the dynamic recompiling technique requires assembly and
adding a C-based alternative would take a bit of work.  It would be nice
to have TuxNES run on all the (sane) platforms supported by Linux, though.
Would anyone be interested in this if I started it?
 
-- 
Mike

:wq