tuxnes-devel Mailing List for TuxNES (Page 9)
Brought to you by:
tmmm
Menu
▾
▴
tuxnes-devel — Development discussion for the TuxNES project
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(18) |
Mar
(32) |
Apr
(61) |
May
(3) |
Jun
(8) |
Jul
(4) |
Aug
(50) |
Sep
(9) |
Oct
(3) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(12) |
Feb
(16) |
Mar
(13) |
Apr
(5) |
May
(14) |
Jun
(1) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(7) |
Dec
(24) |
| 2004 |
Jan
(23) |
Feb
(39) |
Mar
(8) |
Apr
|
May
(54) |
Jun
|
Jul
(20) |
Aug
(17) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2005 |
Jan
(4) |
Feb
(2) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(3) |
| 2006 |
Jan
(3) |
Feb
(1) |
Mar
(5) |
Apr
(1) |
May
(6) |
Jun
(10) |
Jul
(8) |
Aug
(1) |
Sep
(2) |
Oct
(16) |
Nov
(18) |
Dec
(6) |
| 2007 |
Jan
(20) |
Feb
(9) |
Mar
(1) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
(19) |
Oct
(6) |
Nov
(4) |
Dec
(3) |
| 2008 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
(3) |
Jul
(4) |
Aug
(3) |
Sep
(13) |
Oct
(9) |
Nov
(28) |
Dec
(28) |
| 2009 |
Jan
(9) |
Feb
(14) |
Mar
(10) |
Apr
(24) |
May
(40) |
Jun
(23) |
Jul
(34) |
Aug
(7) |
Sep
(3) |
Oct
|
Nov
|
Dec
(11) |
| 2010 |
Jan
(7) |
Feb
(5) |
Mar
(3) |
Apr
|
May
(5) |
Jun
(5) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mike M. <che...@ya...> - 2004-05-11 09:10:45
|
copys or hardlinks can be made and on systems where it's an issue the old name can be removed. --- Jason Dorje Short <jd...@us...> wrote: > I still have a problem compiling for win32 whereby tuxnes's "io.h" is > included instead of the system's <io.h>. > > This is very confusing to me. > > 1. dirent.h has an '#include <io.h>'. The use of <> here should mean > system headers are included before local headers. > > 2. Of course there's a <types.h> as well as a "types.h". But we don't > seem to have problems here. > > jason > __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
|
From: Mike M. <ch...@us...> - 2004-05-11 08:19:42
|
Update of /cvsroot/tuxnes/tuxnes In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26819 Modified Files: controller.c globals.h renderer.h renderer_x11.c Log Message: Jason Dorje Short: Some systems have a function called _sleep. Naming a variable this is an awful idea. _sleep -> renderer_data.pause_display. |
|
From: Jason D. S. <jd...@us...> - 2004-05-11 06:00:59
|
The usleep() function is not portable. It's not available on win32; we
should use Sleep() instead.
Freeciv has code like
/***************************************************************
Suspend execution for the specified number of microseconds.
***************************************************************/
void myusleep(unsigned long usec)
{
#ifdef HAVE_USLEEP
usleep(usec);
#else
#ifdef HAVE_SNOOZE /* BeOS */
snooze(usec);
#else
#ifdef GENERATING_MAC
EventRecord the_event; /* dummy - always be a null event */
usec /= 16666; /* microseconds to 1/60th seconds */
if (usec < 1) usec = 1;
/* suposed to give other application processor time for the mac */
WaitNextEvent(0, &the_event, usec, 0L);
#else
#ifdef WIN32_NATIVE
Sleep(usec / 1000);
#else
struct timeval tv;
tv.tv_sec=0;
tv.tv_usec=usec;
select(0, NULL, NULL, NULL, &tv);
#endif
#endif
#endif
#endif
}
where HAVE_USLEEP, HAVE_SNOOZE, GENERATING_MAC, and WIN32_NATIVE are all
checked at configure time.
There's a similar problem with gettimeofday. ftime is more portable and
is reported to have 10ms resolution on win32 (barely adequate for tuxnes
purposes). So there is code like
#ifdef HAVE_GETTIMEOFDAY
int ret = gettimeofday(&t->start.tv, NULL);
if (ret == -1) {
report_gettimeofday_failed(t);
return;
}
#elif defined HAVE_FTIME
ftime(&t->start.tp);
#else
t->start.t = time(NULL);
if (t->start.t == (time_t) -1) {
report_time_failed(t);
return;
}
#endif
I think it would be convenient to have wrappers that take times in
seconds, as float or double values. Internally these can convert to
whatever integer form is needed by the backend.
Incidentally there is no good way to check for Sleep and other win32-api
functions because linking is done differently. I have no idea why this
is but it does seem to be the case. The solution is to check for the
win32 api in one go and define WIN32_NATIVE or WIN32_API or some such.
Then this value can be used to cover all win32-specific function calls
(which will be consistent across all windows platforms).
jason
|
|
From: Jason D. S. <jd...@us...> - 2004-05-11 05:28:40
|
I still have a problem compiling for win32 whereby tuxnes's "io.h" is included instead of the system's <io.h>. This is very confusing to me. 1. dirent.h has an '#include <io.h>'. The use of <> here should mean system headers are included before local headers. 2. Of course there's a <types.h> as well as a "types.h". But we don't seem to have problems here. jason |
|
From: Jason D. S. <jd...@us...> - 2004-05-11 04:52:58
|
Jason Dorje Short wrote: > Some systems have a function called _sleep. Naming a variable this is > an awful idea. > > This patch changes it. Crap. I didn't remove it from globals.h. jason |
|
From: Jason D. S. <jd...@us...> - 2004-05-11 04:50:34
|
Some systems have a function called _sleep. Naming a variable this is an awful idea. This patch changes it. jason |
|
From: Mike M. <ch...@us...> - 2004-05-10 19:26:10
|
Update of /cvsroot/tuxnes/tuxnes In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12816 Modified Files: Makefile.am configure.ac emu.c Log Message: Jason Dorje Short: zlib fix. |
|
From: Jason D. S. <jd...@us...> - 2004-05-10 19:09:15
|
Jason Dorje Short wrote: > Mike Mestnik wrote: > >>> - added a dirty hack in unzip.h because for some reason my system >>> seems to fail to define ZEXPORT >> >> >> Jason currently knows more about autoconf than I do. > > There is no configure-check for the presence of zip or (?) libzip. > Obviously this is bad. Heh, there's no libzip it's libz. But the file names (unzip.h) confused me. Anyway, configure does check for libz but not for libz-dev. In a distribution these are usually separate packages. This patch "fixes" that by adding a header check after the library check succeeds. Only if both checks pass will zlib be used. This means the AC_DEFINE and LIBS must be done manually. I'm not quite sure why that is. I also fixed in passing an #if HAVE_LIBZ. This should be #ifdef HAVE_LIBZ. The former shouldn't (I think) work at all since if zlib isn't present HAVE_LIBZ will be undefined. Finally I improved Makefile.am so that the zlib source files aren't compiled at all if zlib isn't being used. Currently they are compiled but because of the #ifdef HAVE_LIBZ check inside them they will be empty. So this change isn't strictly necessary but makes compilation cleaner. I left the #ifdef checks inside the zlib source files. I'm unable to test it on a system without zlib (uninstalling zlib-dev forces 10 other packages to be removed on my system). However I did manually force zlib detection to fail, and the compilation succeeded. I didn't do any other testing. Rigel: I never saw your original patch so I don't know what changes you made in it. But you should test if this patch allows tuxnes to compile without zlib. I also recommend you install zlib-dev... jason |
|
From: Jason D. S. <jd...@us...> - 2004-05-10 18:59:31
|
Jason Dorje Short wrote: > I get this compile warning: And here's another one. This may actually be an error. emulator_x86.c: In function `InitMemoryX86': emulator_x86.c:217: warning: assignment from incompatible pointer type jason |
|
From: Jason D. S. <jd...@us...> - 2004-05-10 18:35:54
|
I get this compile warning: emulator_x86_asm.S:16:17: warning: extra tokens at end of #ifdef directive probably harmless; I didn't look closer. But it would be best to fix it. jason |
|
From: Jason D. S. <jd...@us...> - 2004-05-10 16:09:07
|
Mike Mestnik wrote: >> - added a dirty hack in unzip.h because for some reason my system >> seems to fail to define ZEXPORT > > Jason currently knows more about autoconf than I do. There is no configure-check for the presence of zip or (?) libzip. Obviously this is bad. jason |
|
From: Mike M. <che...@ya...> - 2004-05-10 15:57:21
|
I have reviewed and committed this. Here are my comments. --- Rigel Freden <ri...@po...> wrote: > I found the x86 core was broken due to next_code_alloc in function > translate being erroneously assigned to a constant value. Attached is > a diff -Nru of my changes, all minor: > - removal of preproc symbol REG1 in common code; REG1 is now only > used in x86 core code It may get used in ppc and/or sparc asm targets. Aside from a slightly longer build I don't see why I'd remove it. > - defines.h now contains (only?) defines for the x86 core; this > in turn makes nasty preproc code emulator_x86_asm.S unnecessary This is x86/tuxnes specific, it can be moved too emulator_x86_asm.h or the like. defines.h is just not the place for this, if changed I don't have any problems committing this. > - added a dirty hack in unzip.h because for some reason my system > seems to fail to define ZEXPORT Jason currently knows more about autoconf than I do. > - fixed memory allocation/deallocation in InitMemoryX86 and > FreeMemoryX86; specifically fixed issue w/ ROM mem persisting Good catch, is there any reason MapperInit_X86 needs to be compiled in? At this time Mapper_X86 is compiled in for linking with emulator_x86_asm.S, I'm not skilled enuff to (re)move it. > - removed weird-ass embedded open comments in emulator_x86_asm.S > e.g. > "/* /* */ " I did this, I committed a cleaner fix. > > there are still many issues.. on my system i get mad screen flicker, > it's slooow, etc. > Really, what type of system do you have? > -- > > Mike Mestnik wrote: > > > Are you kiding... > > I'd love to know why x86 dosen't draw anything. Also on the do not > crash > > or draw list is GGI. > > > > I'm posting to "sourceforge.net tuxnes-devel" > > <tux...@li...>, hopefully Jason is still around. > > > > --- Rigel Freden <ri...@us...> wrote: > > > i have a patch that fixes the broken x86 core in cvs while breaking > > > nothing > > > > > > new. if you could use it please email me: ri...@po... > > ATTACHMENT part 2 application/bzip2 name=tuxnes.diff.bz2 __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
|
From: Mike M. <ch...@us...> - 2004-05-10 15:19:32
|
Update of /cvsroot/tuxnes/tuxnes In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14715 Modified Files: emu.c Log Message: Make x86 default core, where avalible. |
|
From: Mike M. <ch...@us...> - 2004-05-10 15:01:07
|
Update of /cvsroot/tuxnes/tuxnes In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9999 Modified Files: emulator_x86.c emulator_x86_asm.S emulator_x86_dynrec.c Log Message: "Rigel Freden" <ri...@po...> I found the x86 core was broken due to next_code_alloc in function translate being erroneously assigned to a constant value. - fixed memory allocation/deallocation in InitMemoryX86 and FreeMemoryX86; specifically fixed issue w/ ROM mem persisting |
|
From: Mike M. <ch...@us...> - 2004-05-10 14:11:07
|
Update of /cvsroot/tuxnes/tuxnes In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30463 Modified Files: emulator_x86_asm.S Log Message: First round of cleanups. - nasty preproc code emulator_x86_asm.S, normalized. defines.h dose not need to be bothered with x86 memory layouts. - removed weird-ass embedded open comments in emulator_x86_asm.S e.g. "/* /* */ " |
|
From: Mike M. <che...@ya...> - 2004-05-10 13:35:16
|
--- Rigel Freden <ri...@po...> wrote: > From: Rigel Freden <ri...@po...> > To: Mike Mestnik <che...@ya...> > Subject: Re: tuxnes patch > Date: Mon, 10 May 2004 07:22:33 +0000 > > I found the x86 core was broken due to next_code_alloc in function > translate being erroneously assigned to a constant value. Attached is > a diff -Nru of my changes, all minor: > - removal of preproc symbol REG1 in common code; REG1 is now only > used in x86 core code > - defines.h now contains (only?) defines for the x86 core; this > in turn makes nasty preproc code emulator_x86_asm.S unnecessary > - added a dirty hack in unzip.h because for some reason my system > seems to fail to define ZEXPORT > - fixed memory allocation/deallocation in InitMemoryX86 and > FreeMemoryX86; specifically fixed issue w/ ROM mem persisting > - removed weird-ass embedded open comments in emulator_x86_asm.S > e.g. > "/* /* */ " > > there are still many issues.. on my system i get mad screen flicker, > it's slooow, etc. > > -- > > Mike Mestnik wrote: > > > Are you kiding... > > I'd love to know why x86 dosen't draw anything. Also on the do not > crash > > or draw list is GGI. > > > > I'm posting to "sourceforge.net tuxnes-devel" > > <tux...@li...>, hopefully Jason is still around. > > > > --- Rigel Freden <ri...@us...> wrote: > > > i have a patch that fixes the broken x86 core in cvs while breaking > > > nothing > > > > > > new. if you could use it please email me: ri...@po... > > ATTACHMENT part 2 application/bzip2 name=tuxnes.diff.bz2 __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
|
From: Mike M. <ch...@us...> - 2004-05-08 02:07:31
|
Update of /cvsroot/tuxnes/tuxnes In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22124 Modified Files: types.h Log Message: Missing semicolon. |
|
From: Mike M. <che...@ya...> - 2004-05-08 01:39:18
|
I don't think there will ever be a replacement. There may/should be a way to build the x86 core withought it. Also you should be able to build the C core as it hase no use for mmap. --- Jason Dorje Short <jd...@us...> wrote: > Mike Mestnik wrote: > > What you should do? Listen. > > > > Since where talking, where did you leave off with the W32 port? My > plan > > for x86 core was to get it working for all *nix and then W32. > > Last I checked, tuxnes didn't compile at all. So I stopped work. > > But the fundamental problem was with mmap(), which does not seem to be > available on win32. I don't know of a replacement. > > jason __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
|
From: Jason D. S. <jd...@us...> - 2004-05-08 01:23:16
|
There's a typedef without a semicolon. See attached patch. Also the X11 bootstrap is broken; it tries to compile the X11 renderer even if X11 isn't present. I don't know if the problem is missing configure checks or missing #ifdef wrappers. jason |
|
From: Mike M. <che...@ya...> - 2004-05-08 01:01:33
|
What you should do? Listen. Since where talking, where did you leave off with the W32 port? My plan for x86 core was to get it working for all *nix and then W32. --- Jason Dorje Short <jd...@us...> wrote: > Mike Mestnik wrote: > > > I'm posting to "sourceforge.net tuxnes-devel" > > <tux...@li...>, hopefully Jason is still around. > > I'm listening but I don't really know what I should do. > > jason __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
|
From: Mike M. <che...@ya...> - 2004-05-08 00:25:07
|
Are you kiding... I'd love to know why x86 dosen't draw anything. Also on the do not crash or draw list is GGI. I'm posting to "sourceforge.net tuxnes-devel" <tux...@li...>, hopefully Jason is still around. --- Rigel Freden <ri...@us...> wrote: > i have a patch that fixes the broken x86 core in cvs while breaking > nothing > > new. if you could use it please email me: ri...@po... __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
|
From: Mike M. <che...@ya...> - 2004-03-18 03:19:44
|
I was saying that we can have make run "mv io.h tux-io.h" on systems other than myne(maby just the affected systems) and add #ifs so my system can build withought the move. --- Jason Dorje Short <jd...@us...> wrote: > Mike Mestnik wrote: > > I have thouight long and hard about this. There are some things I > don't > > like. > > > > 1. Losing history in CVS. > > This is annoying. But note it's not lost, just much harder to access. > Also note the file is only two lines long :-). > > > 2. Having to avoid names for .h files in our parent object. Listing > what > > names we can't use is just plain wrong IMHO. > > Yep. Tuxnes also has a types.h which is a header file, but this doesn't > > cause problems. I don't know why. > > > 3. _ == tuxnes == just something you append to the front to avoid > > colistion with parent objects. _ is most popular, but this calles for > > tuxnes dosen't it. > > Anything will do. It would be better just to rename. > > > To over come losing history in CVS we can have the make system move > the > > problem childern? To over come not knowing what problems we will have > we > > will just live with it and fix on fail? We shal use tn_ or tn- as our > new > > names? > > > > If this is aceptible I would requier check for my system so that cvs > > commit still workes, so the old names have to be conditionaly used. > This > > check could be a genaric one for my system or it could only use the > new > > names on systems where there is a problem. Once I have this I can > create > > commit the fix. > > I'm not quite sure what you're saying here. > > > Also we should see what we can do about fixing the source of this bug. > > > Althought I don't know anything about fixing broken build systems, so > I > > could be wrong. > > I think the build system (or maybe the global header files) must be > wrong somewhere. This *shouldn't* be a problem. But I haven't been > able to find the problem yet. > > jason > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Tuxnes-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxnes-devel __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com |
|
From: Jason D. S. <jd...@us...> - 2004-03-18 00:18:53
|
Mike Mestnik wrote: > I have thouight long and hard about this. There are some things I don't > like. > > 1. Losing history in CVS. This is annoying. But note it's not lost, just much harder to access. Also note the file is only two lines long :-). > 2. Having to avoid names for .h files in our parent object. Listing what > names we can't use is just plain wrong IMHO. Yep. Tuxnes also has a types.h which is a header file, but this doesn't cause problems. I don't know why. > 3. _ == tuxnes == just something you append to the front to avoid > colistion with parent objects. _ is most popular, but this calles for > tuxnes dosen't it. Anything will do. It would be better just to rename. > To over come losing history in CVS we can have the make system move the > problem childern? To over come not knowing what problems we will have we > will just live with it and fix on fail? We shal use tn_ or tn- as our new > names? > > If this is aceptible I would requier check for my system so that cvs > commit still workes, so the old names have to be conditionaly used. This > check could be a genaric one for my system or it could only use the new > names on systems where there is a problem. Once I have this I can create > commit the fix. I'm not quite sure what you're saying here. > Also we should see what we can do about fixing the source of this bug. > Althought I don't know anything about fixing broken build systems, so I > could be wrong. I think the build system (or maybe the global header files) must be wrong somewhere. This *shouldn't* be a problem. But I haven't been able to find the problem yet. jason |
|
From: Mike M. <che...@ya...> - 2004-03-16 03:50:52
|
I have thouight long and hard about this. There are some things I don't like. 1. Losing history in CVS. 2. Having to avoid names for .h files in our parent object. Listing what names we can't use is just plain wrong IMHO. 3. _ == tuxnes == just something you append to the front to avoid colistion with parent objects. _ is most popular, but this calles for tuxnes dosen't it. To over come losing history in CVS we can have the make system move the problem childern? To over come not knowing what problems we will have we will just live with it and fix on fail? We shal use tn_ or tn- as our new names? If this is aceptible I would requier check for my system so that cvs commit still workes, so the old names have to be conditionaly used. This check could be a genaric one for my system or it could only use the new names on systems where there is a problem. Once I have this I can create commit the fix. Also we should see what we can do about fixing the source of this bug. Althought I don't know anything about fixing broken build systems, so I could be wrong. --- Jason Dorje Short <jd...@us...> wrote: > The existance of io.h presents a problem when cross-compiling. io.h is > a needed header, and for some reason when the other headers #include > <io.h> it actually includes the local copy. Hence, compilation fails. > > I'd suggest renaming io.h to nesio.h. Maybe io.c should be renamed to > match. > > jason > __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com |
|
From: Mike M. <ch...@us...> - 2004-03-16 01:02:05
|
Update of /cvsroot/tuxnes/tuxnes In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20993 Modified Files: configure.ac emulator_c.h renderer.h renderer_util.c types.h Log Message: gettimeofday() is not present on all systems. (One such system is win32.) When it's not present we should be able to use ftime(). This is an obsolete POSIX function. (It doesn't matter that it's obsolete, since we're doing a configure check for it.) This patch makes the change. After the change we can no longer use the timeval struct; we have to track seconds and useconds manually. It would probably be quite a bit easier to do this in one variable by tracking the seconds as a double. This may not be perfectly accurate, but is probably more accurate than what we do now (which is itself very accurate). "Jason Dorje Short" |
350 messages has been excluded from this view by a project administrator.
