Thread: [Tuxnes-devel] Re: tuxnes patch
Brought to you by:
tmmm
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-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: 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: Jason D. S. <jd...@us...> - 2004-05-10 19:09:15
Attachments:
zlib.diff
|
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 |