Re: [Xmame] Front End for SDLMame?
Frank Cox wrote : On Tue, 17 Oct 2006 17:34:52 -0400 c.s.h. [EMAIL PROTECTED] wrote: Do any of the linux mame front ends work with SDLMame? http://it.geocities.com/pinguinogoloso/ A frontend in tcl/tk hosted on geocities!? Ugh :-) And The web site you are trying to access has exceeded its allocated data transfer. now it seems. It would seem so trivial to make a simple yet powerful frontend in some nicer looking scripting language, in pygtk for instance. Unfortunately, it's way passed my basic skills :-p Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] ready to check out sdlmame, but how?
theGREENzebra wrote : So, recently (a few minutes ago?) I wanted to check out sdlmame and hans' patches, but I 404 on all of the urls in his email. Is there a new spot I should be looking? The machine that hosts R. Belmont's page, where the sdlmame sources are, was apparently being upgraded during the past day or so. Everything seems to be back now, just go to : http://rbelmont.mameworld.info/?page_id=163 Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] sdlmame and Xv
Trent Piepho wrote : On Thu, 21 Sep 2006, Simon Roby wrote: On 9/21/06, Trent Piepho [EMAIL PROTECTED] wrote: Is there any accelerated opengl for nvidia cards without using the binary drivers? The x.org open source nvidia driver has support for Xv, but not opengl. No, not really. What's the point of using an nVidia card if you're not going to use their drivers? Their drivers don't work with all system and all kernels. Unless you want opengl or xvmc, the open source drivers work fine. Yeah, I also run the free driver. There isn't really any point in doing so... I had the choice between an ATI card and an NVidia card... both of which only support OpenGL with their respective proprietary drivers. I tried the NVidia ones, but I get weird problems with fonts not showing up in some places (Fedora Core development), and as I plan on switching to the Xen kernel soon, and have seem that this is a problem with the proprietary driver, especially on x86_64... well... :-( I really love xmame's xv support. The day Hans hacked it in changed my mame'ing experience! It was now easy and trivial to get just about any (not too recent) game running full screen and fast with proper aspect ratio etc. on any hardware. And I'm also part of those who think that xmame's OpenGL display doesn't look as nice as the Xv one. But I guess this can probably be fixed. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] Fw: Freshrpm's xmess includes xmame's man page
Hi, I just got this report, and after checking, it appears that in the xmame 0.105 sources, the xmess.6 man page is actually an old version of the xmame.6 man page. Not sure how, when or why that happened, but it might be worth fixing or removing the xmess man page altogether until a proper one is available. Matthias -- Begin forwarded message: Date: Tue, 09 May 2006 02:19:06 -0400 From: Andre Robatino To: matthias at rpmforge.net Subject: Freshrpm's xmess includes xmame's man page Even though the Freshrpms xmess RPM includes /usr/share/man/man6/xmess.6.gz upon inspection this turns out to be the man page for xmame. The man page for xmess is nowhere to be found. -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] X-Arcade and Linux
Benjamin FRANCOIS wrote : My only concern is, I haven't been able to find so many feedback on the WWW about the X-Arcade and Linux. Has anyone around here been successful in having it working ? Is it recognized as a standard USB controller by the HID input layer support ? With USB, I couldn't say since it requires the additional adapter (which I don't have), but in the default configuration, which is plugged in between your computer and your keyboard on the PS/2 port, it works great with any xmame version, since it simply sends key presses! I've even used it on my laptop (which doesn't have PS/2) by plugging it into another computer on the LAN, and sharing the keyboard with synergy (synergy2.sf.net), and it worked great :-) It's overall a really great joystick, which enhances the overall arcade experience ;-) Oh, I see you're in France : I bought mine through LDLC last christmas, they almost certainly still import/sell it. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] dynarec cores crash
Julian Sikorski wrote : I am using up-to-date fedora core 4 on x86 (P4 3.0E). I think that it is a problem with one of fedora updates, but I may be wrong. Do you thnk that cpu/memory problem may cause a segfault of xmame every time and no other problems? I've just tested kinst with xmame 0.102 on a fully updated FC4 x86 system, and it works fine for me. FWIW, I don't have selinux enabled. Maybe you'd like to try the binary package I'm using, to rule out the possibility of a broken build on your machine? http://freshrpms.net/rpm/xmame You can see the spec file used here : http://svn.rpmforge.net/svn/trunk/rpms/xmame/ It should give you an idea of the options that were set, which the build log might complete if needed : http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/4/xmame/ Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Re: dynarec cores crash
Julian Sikorski wrote : Yes, I am using selinux but there is no such thing here as se and non-se kernels :(. I may just try to disable selinux. Yeah, just pass selinux=off to the kernel through grub, or edit /etc/sysconfig/selinux to make it permanent. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess 0.100
Lawrence Gold wrote : xmame and xmess 0.100 are now available. Thanks a lot Lawrence! :-) - Using make install no longer strips debug symbols from the executables. But it seems the default LD with -s still strips the binaries you get from the compilation, so in practice this change doesn't do anything. Removing -s from the default LD works for me to get the debug symbols at last (66MB uncompressed, 22MB debuginfo rpm package). I've also set ASM_STRIP = true (which isn't the default), although I'm not 100% sure it's necessary. I think being able to easily enable debugging symbols to be kept is a good thing (i.e. not needing to change 3 different settings to get them), but as it REALLY bloats the resulting binary, it definitely shouldn't be the default. Should a comment be added to the default makefile next to Normal linking. to explain the needed change to LD? Another thing is that I now get this : error: unknown option history_file, on line 46 of file: /home/dude/.xmame/xmamerc ignoring line error: unknown option mameinfo_file, on line 47 of file: /home/dude/.xmame/xmamerc ignoring line I've double checked, and 0.99 doesn't give those errors. Have these options been removed or are those errors that didn't get reported before? Setting cheat_file and hiscore_file still works. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] xmame 0.100?
So... it's been a little while since MAME 0.100 came out, and I'll be the first to dare ask Lawrence : When might we expect xmame 0.100 to be released? Obviously without the current work from Hans which is now on hold, but still, a plain update would be really nice ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame 0.100?
Lawrence Gold wrote : On Sep 21, 2005, at 4:58 PM, Matthias Saou wrote: So... it's been a little while since MAME 0.100 came out, and I'll be the first to dare ask Lawrence : When might we expect xmame 0.100 to be released? Obviously without the current work from Hans which is now on hold, but still, a plain update would be really nice ;-) It should be just a few minutes. There are actually files already available on the website, but I'm overwriting them now because of a last-minute change. :-) Woohoo, thanks a lot! :-D Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] XMame version?
Lawrence Gold wrote : On Aug 8, 2005, at 1:56 PM, Synergist wrote: When is any new XMame version coming out? Are you guys going to skip 0.98 and just do 0.99? xmame and xmess 0.99 should be out very soon, shortly after MESS 0.99 comes out. I just saw on the MESS home page that 0.99 was out... so let us know when you get 'round to releasing xmame 0.99 :-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Fwd: Xmame on amd64
Hi maybe left enabled some of the X86_* optimisations, that don't work on
x86_64 from the testing I had done. Maybe this will change soon since Hans
bought an x86_64 machine :-)
From my rpm spec file, in the x86_64 section :
# If you enable X86_MIPS3_DRC, you'll get Segmentation fault (0.88)
#{!?_without_mips3drc: export X86_MIPS3_DRC=1}
# If you enable EFFECT_MMX_ASM, you'll get Illegal instruction for
# the 6tap2x effect (0.88)
Matthias
Lawrence Gold wrote :
Any comments from AMD64 users?
Begin forwarded message:
From: v0n0 [EMAIL PROTECTED]
Date: July 18, 2005 3:46:39 PM MDT
To: [EMAIL PROTECTED]
Subject: Xmame on amd64
I wanted to report you that I successfully compiled xmame 0.97(July 18
2005) on 64 bit version Debian unstable with gcc 4.0.1. It gives only
some warnings about conversions from pointer to int of different size.
I can play gridlee rom, but with every other game I try exits with
Illegal instruction error (after accepting disclamer). Maybe this
will
be of help for further development.
Thanks for your work, bye!
--
Matthias SaouWorld Trade Center
-Edificio Norte 4 Planta
System and Network Engineer 08039 Barcelona, Spain
Electronic Group Interactive Phone : +34 936 00 23 23
___
Xmame mailing list
Xmame@toybox.twisted.org.uk
http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Compile error of current CVS on Fedora Core 4
Lawrence Gold wrote : I just tried to recompile a current CVS checkout on Fedora Core 4 i386 and got this error : [...] mkdir -p xmame.obj/vidhrdw Compiling src/machine/segacrpt.c ... In file included from src/driver.h:57, from src/machine/segacrpt.c:171: src/mamecore.h:55: error: conflicting types for 'PAIR' src/unix/osd_cpu.h:99: error: previous declaration of 'PAIR' was here make: *** [xmame.obj/machine/segacrpt.o] Error 1 The CVS version should build again. Yup, just built fine for me on Fedora Core 4 i386, thanks a lot! Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
x86_64 fixes (was: Re: [Xmame] xmame/xmess 0.94)
F.J. McCloud wrote : Sorry for the umpteenth reply. Maybe the fix is as simple as 2 lines. I will propose this to the mame testers forum. Meanwhile, try this patch on src/vidhrdw/seibuspi.c. It works for me on 64-bit and 32-bit. http://www.anthrofox.org/code/mame/64bitclean/seibuspi_64bit_patch.txt Thanks. My main xmame box is an AMD64, so I'll definitely be including your two last patches in my rpm packages ;-) I've got a quick question for you : Have you looked into the X86_MIPS3_DRC on x86_64? The last time I tried enabling it, xmame just segfaulted. Is it something that should be fixed and work also for x86_64, or is it really too x86 specific? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Compile error of 0.92 on ppc
Lawrence Gold wrote : On Feb 28, 2005, at 3:55 AM, Matthias Saou wrote: Yes, I did enable -mlongcall. I just got a spec file change from a Yellow Dog Linux 4.0 user, and apparently only setting LDFLAGS=-Wl,--relax is enough to fix this. I can't be sure for now, as the build will take another few hours, though ;-) The linker section of the makefile lists this for Linux/PowerPC. Perhaps I can rearrange things a bit to make this stand out more. Actually, I skimmed through the makefile but missed it. I'm not sure it'll solve the problem on the long term for me, since what I basically do is follow the list for changes, read the changes in the release mail you send out carefully, but just drop in the new sources to rebuild my packages when a new release comes out... and sometimes miss changes :-( Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] Testing Fedora Core 3 packages of current CVS (0.91)
Hi, Since I wanted the xml listinfo for 0.91, I've built some packages for Fedora Core 3 of the current CVS code for wider testing. For anyone interested, they're available here : http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/testing/3/ As usual, with the build log and the spec file. My x86_64 machine is down at the moment, so there are only i386 packages for now. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] suplup, and a new feature idea
Frank Cox wrote : SUPLUP -- On my desktop computer, suplup runs fine. On my game machine, I get this: loading rom 0: rom1.bin loading rom 1: rom2.bin loading rom 2: roml00.bin loading rom 3: romu00.bin loading rom 4: roml01.bin loading rom 5: romu01.bin loading rom 6: vrom1.bin done Killed There is a pause of several seconds between the done and the killed. What just happened? My guess would be that the xmame binary used up all your RAM and got killed. Open another terminal, run top and press m to sort by memory usage and try to see if it grows and grows before it stops ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] CVS usage question
Nicos Panayides wrote : cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/gxmame co -r Next-Version-0.40 gxmame The branch works for browsing and running your roms (even with 0.88) and that's about it for the moment. Make that Next-Version-0-40, with a dash, not a dot. I'll try it out right away! BTW, seems like current xmame CVS has a game list of 0.89u1 and not plain 0.89 (vf3, srally2...), is this intended, or will it be reverted back to the main 0.89 one for the release? Just wondering :-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] CVS usage question
Matthias Saou wrote : Nicos Panayides wrote : cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/gxmame co -r Next-Version-0.40 gxmame The branch works for browsing and running your roms (even with 0.88) and that's about it for the moment. Make that Next-Version-0-40, with a dash, not a dot. I'll try it out right away! Two problems : - The configure script is missing a check for expat development files, as expat.h is required later on. - There seems to be a problem with the mkinstalldirs call from the po/ directory : make[1]: Entering directory `/usr/src/rpm/BUILD/gxmame-0.35cvs/po' /bin/sh `case ./mkinstalldirs in /*) echo ./mkinstalldirs ;; *) echo .././mkinstalldirs ;; esac` /var/tmp/gxmame-0.35-0.20041129.1.1.fc3.fr-root/usr/share/bin/sh: .././mkinstalldirs: No such file or directory make[1]: *** [install-data-yes] Error 127 make[1]: Leaving directory `/usr/src/rpm/BUILD/gxmame-0.35cvs/po' I remember having the exact same issue with the gentoo file manager's po Makefiles... seems like the setup-gettext script does something funny on Fedora Core 3. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Time for xmame 0.88? And the usual frontend question...
Lawrence Gold wrote : On Nov 4, 2004, at 2:23 PM, Matthias Saou wrote The list has been very silent for the last few days... the reason for me is that _all_ the bugs and problems I had are now fixed, everything works great, so, if that's also the reason for most of the other, isn't it time to release 0.88 at last? :-) I just need to finish updating the documentation, and I should be ready to release 0.88 any time after that. The only caveat is that X11 may be the only fully working display target for this release, but it's also the most-used. Indeed, it may only have the x11 target working, but now that is also includes the OpenGL and the 3Dfx ones, it means that three work, including the two most used (x11 dga/xv xgl), so it's probably not as alarming as your phrase puts it ;-) I'll wait to hear from Hans, since he was in the middle of converting the a few of the other targets, such as SDL. OK... indeed it would be nice to have SDL working again. Does anyone have an idea of the most used targets? Just wondering, as from the other xmame users I know and the feedback on this list, SDL and svgalib seem very little used for example. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] Time for xmame 0.88? And the usual frontend question...
Hi, The list has been very silent for the last few days... the reason for me is that _all_ the bugs and problems I had are now fixed, everything works great, so, if that's also the reason for most of the other, isn't it time to release 0.88 at last? :-) Another thing is to now use xmame in a user-friendly way... I'm used to using gxmame, and if I specify to use the default xmame options (thus bypassing all the nice graphical options settings), I can still do so by making sure I have everything set in ~/.xmame/xmamerc, but that's far from end-user friendly IMHO. I sent an email to Shadow Walker (the author) not long ago, but didn't get any reply. I also contacted the two persons who had already contributed patches to my gxmame rpm package, but one didn't answer and the other said he'd try to have a look last week-end without getting back to me since... so... seems like gxmame will go the way of gRustibus, which is really too bad! Isn't anyone interested in hacking up gxmame to keep up with the option changes in xmame? Seems to me that the most important chunk of the work is there, so it's quite a shame to leave it broken as it is now. BTW, if anyone is interested in my latest rpm spec file for xmame : http://svn.rpmforge.net/svn/trunk/rpms/xmame/ Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] stunrun, ym2151.c on X86-64
Lawrence Gold wrote : On Nov 2, 2004, at 1:32 AM, Matthias Saou wrote: Seems like it now works with the default yuv mode, yeah! This is great since forcing YV12 didn't allow me to apply any effects. Still a problem, though : When I press Ctrl+Pgdn, I get Black scanlines 2x2 fine, but when I do it a second time, it bombs out with Illegal instruction :-( With Pgup, they all work up to an including high quality filter (2x2), but after, I get the same error. So it seems 6tap2x is broken for me. Right before the Illegal instruction message, I can indeed see Initialized 6-tap filter scanlines: bitmap depth = 15, color format = YUY2. Any ideas? I'm guessing the answer to this is no: Do you have EFFECT_MMX_ASM = 1 enabled in the makefile? Hmmm, yes, I probably have that still enabled for x86_64, silly me. I'll change that... which means that _all_ the issues I've ever had are fixed in the CVS code! Too bad though that none of the MMX optimizations work on x86_64 for now. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] stunrun, ym2151.c on X86-64
Alastair M. Robinson wrote : It seems that with x11-mode 1, when I force yuv to mode 2 (as I've actually always been required to on this computer), it works great!!! The thing is, games with artwork don't seem to require me to force yuv to display properly. It sounds as though your video driver might have broken or incomplete support for RGB overlays (XMAME is the only program I know that uses them, so they're not well tested...) What type of video card do you have, and what does xvinfo give you? It's a Radeon 9200 w/ 128MB on an x86_64 Shuttle barebone. The system is Fedora Core 2. Attached is my xvinfo output. MatthiasX-Video Extension version 2.2 screen #0 Adaptor #0: ATI Radeon Video Overlay number of ports: 1 port base: 69 operations supported: PutImage supported visuals: depth 24, visualID 0x23 depth 24, visualID 0x24 depth 24, visualID 0x25 depth 24, visualID 0x26 depth 24, visualID 0x27 depth 24, visualID 0x28 depth 24, visualID 0x29 depth 24, visualID 0x2a depth 24, visualID 0x2b depth 24, visualID 0x2c depth 24, visualID 0x2d depth 24, visualID 0x2e depth 24, visualID 0x2f depth 24, visualID 0x30 depth 24, visualID 0x31 depth 24, visualID 0x32 number of attributes: 12 XV_SET_DEFAULTS (range 0 to 1) client settable attribute XV_AUTOPAINT_COLORKEY (range 0 to 1) client settable attribute client gettable attribute (current value is 1) XV_COLORKEY (range 0 to -1) client settable attribute client gettable attribute (current value is 30) XV_DOUBLE_BUFFER (range 0 to 1) client settable attribute client gettable attribute (current value is 1) XV_BRIGHTNESS (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) XV_CONTRAST (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) XV_SATURATION (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) XV_COLOR (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) XV_HUE (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) XV_RED_INTENSITY (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) XV_GREEN_INTENSITY (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) XV_BLUE_INTENSITY (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 2048 x 2048 Number of image formats: 4 id: 0x32595559 (YUY2) guid: 59555932--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x59565955 (UYVY) guid: 55595659--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar)
Re: [Xmame] stunrun, ym2151.c on X86-64
Hans de Goede wrote : More on my x86_64 problem! It seems that with x11-mode 1, when I force yuv to mode 2 (as I've actually always been required to on this computer), it works great!!! The thing is, games with artwork don't seem to require me to force yuv to display properly. If you need any more details, please let me know. Matthias So, with -force-yuv 2 (YV12) it works ok both with and without artwork? That places the blame at a piece of code about 20 lines big :) So I should be able to fix things. Right now I'm booted into windows (work) but as soon as I'm done I'll take a look. Seems like it now works with the default yuv mode, yeah! This is great since forcing YV12 didn't allow me to apply any effects. Still a problem, though : When I press Ctrl+Pgdn, I get Black scanlines 2x2 fine, but when I do it a second time, it bombs out with Illegal instruction :-( With Pgup, they all work up to an including high quality filter (2x2), but after, I get the same error. So it seems 6tap2x is broken for me. Right before the Illegal instruction message, I can indeed see Initialized 6-tap filter scanlines: bitmap depth = 15, color format = YUY2. Any ideas? Thanks a lot for fixing the xv defaults for me! ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] stunrun, ym2151.c on X86-64
Hans de Goede wrote : p.s. A few days ago we also received this report: --- I've just recompiled a CVS snapshot on my x86_64 system, and am having problems with the x11/xv target. [...] --- That would be me :-) Could you take a look at that? I don't have a x86_64 machine. Mailing me an mb + cpu is also an option :) I just tested, and things seem to have definitely improved! With x11-mode 1, games with artwork work great (tried pacman mario), but the artwork _must_ be enabled. Without, a similar problem than before happens : I get the display inside the window stretched horizontally, so I can see only the left half of the display inside a window which seems to have the right size and aspect ratio. This is what also seems to happen with all other games (tested sf2, spang, xmvsf, 1943). There is also a greenish touch most of the time. The other things worth noting as that : I don't need to force the yuv mode anymore (when using artwork, the only working config right now), and when games exhibit the problem described above, all games, even the ones which can have artwork but have it disabled, segfault when I exit xmame. Actually, or this, or (1943) a free() : invalid pointer 0x2a95e28010! message. A third option is setting me up with remote access to an x86_64 machine with a CVS xmame binary and a core file, err dang it doesn't crash does it h. Well, it does (when I exit), so maybe it could give you a valuable clue about where the problem lies. OpenGL through x11-mode 2 still works great btw :-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] stunrun, ym2151.c on X86-64
Hi, More on my x86_64 problem! It seems that with x11-mode 1, when I force yuv to mode 2 (as I've actually always been required to on this computer), it works great!!! The thing is, games with artwork don't seem to require me to force yuv to display properly. If you need any more details, please let me know. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] CVS needs some more testing
I just tried a rebuild with the current CVS code, xmame built fine, but xmess didn't. I got this error : Linking xmess.x11 ... xmess.obj/mess/system.o(.data+0x680): undefined reference to `driver_tx0_64kw' xmess.obj/mess/system.o(.data+0x684): undefined reference to `driver_tx0_8kw' xmess.obj/pdp1.a(pdp1.o)(.text+0x341b): In function `construct_pdp1': mess/systems/pdp1.c:447: undefined reference to `video_eof_pdp1' xmess.obj/pdp1.a(pdp1.o)(.text+0x34b): In function `video_start_pdp1': mess/vidhrdw/pdp1.c:69: undefined reference to `video_start_crt' xmess.obj/pdp1.a(pdp1.o)(.text+0x3d6): In function `video_update_pdp1': mess/vidhrdw/pdp1.c:94: undefined reference to `video_update_crt' xmess.obj/pdp1.a(pdp1.o)(.text+0x3b7): In function `pdp1_plot': mess/vidhrdw/pdp1.c:84: undefined reference to `crt_plot' collect2: ld returned 1 exit status make: *** [xmess.x11] Error 1 This is from a clean checkout. CVS code from last week didn't give me this error, using the exact same build options and environment. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] CVS needs some more testing
Cool, that seems to be it. Lawrence, can you make sure this change is made before 0.88 is released? Matthias Christopher Stone wrote : I got this email from Raphael: The problem is MacMESS is not using Makefile but custom project files; I can but guess the necessary changes to the Makefile when I add new files, so I not commit them but rely on other to do so. Maybe I should systematically post a note to MESSDEV when I add such new files. If you want to add the files to the Makefile, the new files are: vidhrdw/crt.c vidhrdw/crt.h systems/tx0.c machine/tx0.c vidhrdw/tx0.c includes/tx0.h cpu/tx0/tx0.c cpu/tx0/tx0.h cpu/tx0/tx0dasm.c And you need to enable two new switches: HAS_TX0_64KW and HAS_TX0_8KW for the new CPU cores to be enabled. On Fri, 29 Oct 2004 22:06:31 +0200, Matthias Saou [EMAIL PROTECTED] wrote: I just tried a rebuild with the current CVS code, xmame built fine, but xmess didn't. I got this error : Linking xmess.x11 ... xmess.obj/mess/system.o(.data+0x680): undefined reference to `driver_tx0_64kw' xmess.obj/mess/system.o(.data+0x684): undefined reference to `driver_tx0_8kw' xmess.obj/pdp1.a(pdp1.o)(.text+0x341b): In function `construct_pdp1': mess/systems/pdp1.c:447: undefined reference to `video_eof_pdp1' xmess.obj/pdp1.a(pdp1.o)(.text+0x34b): In function `video_start_pdp1': mess/vidhrdw/pdp1.c:69: undefined reference to `video_start_crt' xmess.obj/pdp1.a(pdp1.o)(.text+0x3d6): In function `video_update_pdp1': mess/vidhrdw/pdp1.c:94: undefined reference to `video_update_crt' xmess.obj/pdp1.a(pdp1.o)(.text+0x3b7): In function `pdp1_plot': mess/vidhrdw/pdp1.c:84: undefined reference to `crt_plot' collect2: ld returned 1 exit status make: *** [xmess.x11] Error 1 This is from a clean checkout. CVS code from last week didn't give me this error, using the exact same build options and environment. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] Default screen aspect ratio
Hi, I've got a 1680x1050 (16/10th) display on my laptop, and by default xmame stretches, thus flattens a little, all the 4/3rd games when run in fullscreen. I need to manually set displayaspectratio to 1.6 in order to get a proper display, where those games then appear properly, with some black vertical bars on both sides. Is this wanted? Does this mean that xmame always assumes an aspect ratio of 4/3rd? With more and more displays getting pretty weird widescreen resolutions, wouldn't it be nice to have xmame get the resolution from the X server and compute a default aspect ratio from there if it's not being manually overridden? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Default screen aspect ratio
Hans de Goede wrote : With more and more displays getting pretty weird widescreen resolutions, wouldn't it be nice to have xmame get the resolution from the X server and compute a default aspect ratio from there if it's not being manually overridden? Erm, that won't work since you also have modes like 320x200 and 640x350 on a 4/3 display which are not 4/3. There is not nescesarrilly a relation between the resolution and the aspect ratio of the screen. This all assumes that modes get stretched to fill the entire screen which is not nescesarrilly true with LCDs, but I don't even want to think about the scenarios in that case. Hmm, maybe what I wrote above should have been get the aspect ratio from the X server, then, as that seems possible. Most video players I use just get it right without me needing to do anything (except mplayer, but that one even ignores aspect ratios specified in the videos themselves!). I've just tried xdpyinfo and get : [...] dimensions:1680x1050 pixels (569x356 millimeters) resolution:75x75 dots per inch [...] So theoretically speaking, as my pixels are square (75x75dpi), the 8/5 aspect ratio can be calculated. Of course, I understand that this is an absurd thing to do for the people using funky modelines all over the place, and would lead to brain damage in such cases. But for people like me that just have a regular desktop/laptop and use everything (video, xmame, other games...) through xv hardware scaling without ever changing resolution (heck, even my framebuffer console is 1680x1050! ;-)), it does make sense, and a much better works out of the box experience. Anyway, it was just a simple question/suggestion, and I get your point :-D Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Default screen aspect ratio
Hans de Goede wrote : smf wrote: Erm, that won't work since you also have modes like 320x200 and 640x350 on a 4/3 display which are not 4/3. There is not nescesarrilly a relation between the resolution and the aspect ratio of the screen. If they fill the screen ( which they always have for me ) then they are 4:3. A 1x1 pixel screen would be 4:3 as long as it filled your 4:3 monitor. Thats exactly the point I'm trying to make, so you can't use the resolution to determine the monitor aspect. ...but resolution + dpi info, in theory, you can, right? But I have no idea about whether the correct dpi info is given with such resolutions. Aaah, if only all pixels in the world were square, interlacing didn't exist... just imagine! Huh, boring you say? ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] DGA Fullscreen Test
Hans de Goede wrote : Thanks, thats the clue I needed. If I start directly in fullscreen mode I have the bug too. Its fixed in CVS now. Please test. Seems like as soon as Hans can reproduce a problem, it gets fixed almost instantly! :-) Does anyone have a spare x86_64 computer to give him by any chance? :-D Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] MAMEd front-end V 0.7 available
Pieter Hulshoff wrote : On Tuesday 26 October 2004 07:16, Pieter Hulshoff wrote: On Tuesday 26 October 2004 00:19, Matthias Saou wrote: Christopher Stone wrote : I know that SDL is very broken in Fedora 2, I had to upgrade to SDL-1.2.7-8 to get stuff working. You might want to try: SDL_AUDIODRIVER=alsa ./mamed Indeed, that worked around the problem. Strange, I don't recall having any issues with other SDL games like frozen-bubble or lbreakout2 :-/ Anyway, now I get : No games found in the MAME list information. when mamed exits after displaying the huge window with GENERATING MAMED GAMELIST FILE. I see no errors in the output, only the usual stderr xmame output about display drivers. MAMEd checks in the dir_mame(defined in ~/.mamed/mamed.cfg)/roms directory to find your MAME games. If it cannot find your games there, it will quit with this message. Also: MAMEd expects your games to be zipped. Well, my problem then is that my roms are in : /mnt/datkside/xmame/rom Yes, note the rom, which isn't plural ;-) And all other files are also under 3 letter directories (art, fly, sam etc.). I guess my feature request will be to have the possibility to override those in the configuration. So I've gotten further, I now see the interface, but my joypad (/dev/input/js0 which works fine under xmame) doesn't do anything, nor can I close the window or Ctrl+C mamed from the terminal I ran it from... there is no special output, the last being List of games created.. Any ideas? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Problems with x11/xv on x86_64, Radeon 9600
Hans de Goede wrote : I guess the Xv code isn't 64 bit clean then, or there are problems with the radeon drivers on x64 since I have a radeon and it works fine. Thats a 9250 though which uses open source drivers. Could you try this with: -open source drivers -videos /dvds in mplayer / xine uisng xvideo. I am using the free driver that comes with Fedora Core 2's xorg. My mistake though, it's a Radeon 9200, which has great accelerated OpenGL with the free driver, unlike my laptop's Mobility 9600 :-( XV output in mplayer, ogle, xine is fine, no problems ever, which is why I've been a little surprised to have to force a yuv mode to avoid garbage. Last, when I type OK, xmame immediately exits with Illegal instruction... this happens with xmvsf and mslug2 for instance, but not with pacman or spang. Broken compilation options I could have put for something? I assume this is in all -x11-mode variants? This was caused by the 68000 asm core being enabled. The mips drc also doesn't work on x86_64 apparently (segfault with kinst2). For now, -x11-target 2 works fine, and I even no longer have the ugly thin gray line in diagonal across the whole display (from the way the screen was drawn in polygons from what I understood), so I'm already quite happy. I'd really like to get XV working though, as I'd like to use some effects. Any ideas? Testing I could do? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Problems with x11/xv on x86_64, Radeon 9600
F.J. McCloud wrote : On the R100/xmame-0.87.1/X86-64/Xorg-6.8 open-source radeon driver I get: 1500 FPS in normal windowed mode. (-x11-mode 0) 240 FPS with -x11-mode 1, but it is not fullscreen! segfault with -x11-mode 2 or -x11-mode 3 81 FPS with -x11-mode 2 -yv12 (looks OK; does not have green line problem, but X hogs CPU again!) 107 FPS with -x11-mode 3 -yv12 (looks OK; does not have green line problem) Apart from that green line problem, when it's fixed (forcing yuv mode), I can only see approx. the top left 1/4th of the screen's content in the window (or fullscreen too) that is displayed. This is why I haven't been able to test XV performance yet, as I don't have a single configuration working on that x86_64/Radeon9200. OTOH, my laptop's Radeon Mobility 9600 (Centrino 1700MHz, Fedora Core 2) has no problems whatsoever and works great. I use the free drivers too, so don't have any hardware OpenGL acceleration, but XV works great : With -xv-mode 1 -fullscreen, I get a full 100% 60/60 in kinst2. As my x86_64 is my main entertainment system, I'd love to have the same there of course ;-) Hans, is there anything we can patch/try to diagnose and debug these XV problems on x86_64? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] CVS compile errors
Hi, I've just tried to compile the current CVS code, and got plenty of errors in src/unix/mode.c, which made the build fail. I then tried with the CVS code from 2 days ago, but although it does compile all the way, xmame --help works but I get : src/drivers/pacman.c: puckman has unsorted coinage Coinage 2 Coins/1 Credit src/drivers/pacman.c: puckman has unsorted coinage Free Play Lives src/drivers/pacman.c: puckman has unsorted coinage 5 Bonus Life src/drivers/pacman.c: puckman has unsorted coinage Bonus Life 1 src/drivers/pacman.c: puckman has unsorted coinage Normal Hard [...very long output snipped...] Could it be the compiler flags I'm using? The last I've tried were : -O3 -march=i386 -mcpu=pentium4 -Wall -pipe Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] CVS compile errors
Hans de Goede wrote : Matthias Saou wrote: Hi, I've just tried to compile the current CVS code, and got plenty of errors in src/unix/mode.c, which made the build fail. I then tried with the CVS code from 2 days ago, but although it does compile all the way, xmame --help works but I get : Please report the errors you're getting. So that they can be fixed, CVS compiles fine for me. I did a new clean checkout, and compiled it with -fno-merge-constants added to my CFLAGS as suggested by Christopher, and it works fine. I had copied the errors, though, and am not sure where they came from in the first place : [OSDEPEND] Compiling src/unix/mode.c ... src/unix/mode.c: In function `sysdep_display_driver_update_keyboard': src/unix/mode.c:5: error: storage class specified for parameter `disabled_modes_count' src/unix/mode.c:5: error: parameter `disabled_modes_count' is initialized src/unix/mode.c:6: error: storage class specified for parameter `perfect_aspect'src/unix/mode.c:6: error: parameter `perfect_aspect' is initialized src/unix/mode.c:7: error: storage class specified for parameter `use_aspect_ratio' src/unix/mode.c:7: error: parameter `use_aspect_ratio' is initialized src/unix/mode.c:8: error: storage class specified for parameter `display_aspect_ratio' src/unix/mode.c:8: error: parameter `display_aspect_ratio' is initialized src/unix/mode.c:9: error: storage class specified for parameter `display_resolution_aspect_ratio' src/unix/mode.c:9: error: parameter `display_resolution_aspect_ratio' is initialized src/unix/mode.c:11: error: storage class specified for parameter `mode_disable' src/unix/mode.c:12: error: storage class specified for parameter `mode_force' src/unix/mode.c:14: error: parameter `aspect_opts' is initialized src/unix/mode.c:16: warning: braces around scalar initializer src/unix/mode.c:16: warning: (near initialization for `aspect_opts') [... many more warnings and errors ...] src/unix/mode.c:162: error: conflicting types for `perfect_aspect' src/unix/mode.c:6: error: previous declaration of `perfect_aspect' src/unix/mode.c:163: error: storage class specified for parameter `first_time' src/unix/mode.c:163: error: parameter `first_time' is initialized src/unix/mode.c:164: error: parameter `aspect' is initialized src/unix/mode.c:164: error: `width' undeclared (first use in this function) src/unix/mode.c:164: error: (Each undeclared identifier is reported only once src/unix/mode.c:164: error: for each function it appears in.) src/unix/mode.c:164: error: `height' undeclared (first use in this function) src/unix/mode.c:167: error: syntax error before if make: *** [xmame.obj/unix.x11/mode.o] Error 1 I was getting this when completely rebuilding (not using anything from a previous build), so I suspected the update or the CFLAGS first... but maybe is was my cvs update that had done something weird. When checking out older versions, I got plenty of MacMAME files, artwork .zip files etc. added, which is when I decided to do a complete checkout from scratch again. Thanks to Christopher for the work-around, and to you and Lawrence for your much appreciated work! Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] Questions regarding libglut, Glide3
Hi, Perhaps Hans will be able to enlighten me on this one ;-) I compiled the x11 target with GL and Glide added, and get the messages below on startup. I have a 3dfx someone gave me lying around, so maybe I'll try it to see if it actually works as expected as a user on Fedora Core or not (does the binary need to be suid root to use Glide3 or does console.perms take care of the /dev/3dfx preoperly?). That was the first question, the second is : Why is libglut.so dlopened like that? When libglut devel files aren't installed, the main libglut.so symlink isn't present, and it seems xmame then can't use the libglut.so.3.8.0 I have properly. Isn't it possible to cleanly link the xmame binary against libglut? I think the same applies to libGL.so and libGLU.so when xorg/XFree86 devel files aren't installed. $ xmame GLINFO: cannot access GLX library libglut.so directly ... GLERROR: dlerror() returns [libglut.so: cannot open shared object file: No such file or directory] GLINFO: loaded OpenGL library libGL.so! GLINFO: loaded GLUlibrary libGLU.so! info: using FXmame v0.5 driver for xmame, written by Mike Oliphant Glide error: couldn't open /dev/3dfx and not running as root Disabling use of Glide mode [... game info ...] Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Questions regarding libglut, Glide3
Hans de Goede wrote : Some time ago someone else who was working on the OpenGL code has modified it to use gltool, which is a tool he wrote to be able to write osindependent OpenGL code. gltool does the dlopening. But you have a good point, I'll modify the code to open the .so.version files instead. I just hope the so version is the same on all platforms. I actually like this feature of gltool. I'm planning on creating a Fedora rpm package once I'm done hacking xmame and dlopening OpenGL means that users will also be able to install a binary with opengl support without having opengl. OK, I understand. As for Fedora Core packages, I've been building some (Red Hat Linux and Yellow Dog Linux) for quite a while now, available on http://freshrpms.net/ along with gxmame. The merging of multiple display drivers in a single target is a real blessing package-wise, many thanks for that ;-) But for installing a package with OpenGL support, while not having OpenGL installed... well, this has always been possible if what you mean is not having hardware OpenGL acceleration available as the OpenGL libraries (Mesa, freeglut) are shipped with all recent rpm-based distributions I can think of, including Fedora Core. If anyone's interested, I've built a CVS snapshot which includes only the x11 target, but with XV, OpenGL and Glide3 support built in. It works great for me : http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/testing/2/ BTW, will the SDL target also get merged, or is it too different in many aspects to make that possible? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Questions regarding libglut, Glide3
Hans de Goede wrote : The idea is not needing any OpenGL libraries I'll admit that this is not really important since OpenGL will be installed on most systems, but the idea is todo the same with Glide one day. Fedore Core 3 won't install Glide by default so not having to depend on it would be a blessing. The next step is to make all the dsp and sound mixer plugins real dynamicly loaded plugings so no more deps on esd, arts, alsa libs etc. Then how much harder would it be to have the display drivers also be dynamically loadable plugins? Because once you have that, all optional ones can trivially be split into sub-packages, moving away some dependencies from the main package. Currently the SDL target is broken, I'm planning on fixing it, but not on merging it. SDL really is a different target. Thanks, that's what i wanted to know. Cheers and keep up the great work! Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Compile errors in Xmame 0.87
Lawrence Gold wrote : On Oct 25, 2004, at 5:40 AM, André Aun wrote: xmame [EMAIL PROTECTED] X-XaM3-API-Version: 4.1 (B44) X-type: 0 X-SenderIP: 204.110.170.5 Mrs, i'm getting thesse errors compiling the latest version of xmame: Try commenting out JOY_X11 in the makefile (put a # at the front of that line). The X11 joystick driver has been broken for years, so I wonder if it might just be best to remove it altogether instead of trying to patch it up so that it builds. And how about renaming the JOY_I386 at the same time, since it isn't actually i386 specific at all? :-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Compile errors in Xmame 0.87
Lawrence Gold wrote : On Oct 25, 2004, at 12:48 PM, Matthias Saou wrote: And how about renaming the JOY_I386 at the same time, since it isn't actually i386 specific at all? :-) Suggestions for a new name are welcome. I never did come up with a good one. JOY_GENERIC JOY_LINUX (is it only for Linux?) JOY_MAIN JOY_BASIC JOY_BASE JOY_USB (is it only for USB?) I'm also sort of short of good suggestions. Maybe to time to dig up the best you came up with ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] MAMEd front-end V 0.7 available
Pieter Hulshoff wrote : I've made version 0.7 of my MAMEd front-end available on my website at www.xs4all.nl/~phulshof. [...] Let me know if you run into any trouble while running it. :) Just tried trying it :-) But I got this : [...] Keys are configured. Mamed is configured. *** glibc detected *** free(): invalid pointer: 0x09753b00 *** Program received signal SIGABRT, Aborted. [Switching to Thread -153495872 (LWP 7407)] 0xf6fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) bt #0 0xf6fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xf6eb3955 in raise () from /lib/tls/libc.so.6 #2 0xf6eb5319 in abort () from /lib/tls/libc.so.6 #3 0xf6eeca1b in malloc_printerr () from /lib/tls/libc.so.6 #4 0xf6eed4ba in free () from /lib/tls/libc.so.6 #5 0x05e24445 in operator delete () from /usr/lib/libstdc++.so.6 #6 0x05e0559f in std::string::_Rep::_M_destroy () from /usr/lib/libstdc++.so.6 #7 0xf6c22ba4 in Arts::MCOPUtils::readConfigEntry () from /usr/lib/libmcop.so.1 #8 0xf6c0b33c in Arts::Dispatcher::Dispatcher () from /usr/lib/libmcop.so.1 #9 0xf6d720a4 in arts_backend_init () from /usr/lib/libartscbackend.so.0 #10 0x005372b6 in arts_init () from /usr/lib/libartsc.so.0 #11 0x0068e65a in SDL_MixAudio_MMX_S8 () from /usr/lib/libSDL-1.2.so.0 #12 0x0068a070 in SDL_AudioInit () from /usr/lib/libSDL-1.2.so.0 #13 0x00688a5a in SDL_InitSubSystem () from /usr/lib/libSDL-1.2.so.0 #14 0x00688b5b in SDL_Init () from /usr/lib/libSDL-1.2.so.0 #15 0x08053b54 in init_sdl () at gui.cpp:149 #16 0x08059ccb in main () at mamed.cpp:79 This is on Fedora Core 2, under GNOME. I use ALSA, and have esd that can run, OSS emulation available, but definitely no aRts... is this normal? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] MAMEd front-end V 0.7 available
Christopher Stone wrote : I know that SDL is very broken in Fedora 2, I had to upgrade to SDL-1.2.7-8 to get stuff working. You might want to try: SDL_AUDIODRIVER=alsa ./mamed Indeed, that worked around the problem. Strange, I don't recall having any issues with other SDL games like frozen-bubble or lbreakout2 :-/ Anyway, now I get : No games found in the MAME list information. when mamed exits after displaying the huge window with GENERATING MAMED GAMELIST FILE. I see no errors in the output, only the usual stderr xmame output about display drivers. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Problems with x11/xv on x86_64, Radeon 9600
Dan Hollis wrote : On Mon, 25 Oct 2004, Matthias Saou wrote: Dan Hollis wrote : On Mon, 25 Oct 2004, Matthias Saou wrote: Last, when I type OK, xmame immediately exits with Illegal instruction... this happens with xmvsf and mslug2 for instance, but not with pacman or spang. Broken compilation options I could have put for something? Im guessing the 68k asm core doesnt work on x86_64 ? That could be it, as I've tried enabling it (and it compiles). I'll try disabling it. What about X86_MIPS3_DRC and EFFECT_MMX_ASM? Should they be expected to work or break? I would expect those to break also. The x86 cores need to be updated for x86_64. Indeed. I've now got xmvsf working, but kinst2 segfaults immediately, so I guess it's time to disable mips3_drc on x86_64 too. Does anyone know what I can use to now test EFFECT_MMX_ASM? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess 0.87
Florent Gingat wrote : Kaf is broken too :/ snirff .. can it be possible to have a liste of added and removed options for helping modify frontends? or maybee it's already the case .. What I'd actually like to see is a frontend that doesn't assume it has an exhaustive list of all existing options, but instead offers plenty of disabled (i.e. greyed out) options representing what it knows the defaults were when it did know all the options, and allows enabling them and changing values where relevant. With some sane defaults, and an advanced options field where one could directly enter more options for the command line, this could really make things better than they currently are. Of course, something even better would be for the frontends to have a mean of extracting all existing options with all their possible values and ranges from xmame, and dynamically build options pages from there, although this may not be the best way to get an intuitive UI, unless some initial assumptions are made as above, greying out the no longer existing options, and adding dynamically generated choices for the new ones. Sorry, just thoughts and no code, but it does seem to me like something feasible and providing a much better experience to the end users. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess 0.87
Hans de Goede wrote : Matthias Saou wrote: Of course, something even better would be for the frontends to have a mean of extracting all existing options with all their possible values and ranges from xmame, and dynamically build options pages from there, although this may not be the best way to get an intuitive UI, unless some initial assumptions are made as above, greying out the no longer existing options, and adding dynamically generated choices for the new ones. This has been discussed in the past, and since xmame has al its option internally described in structs it should be easy to export this info in say xml format. Then all we need to someone brave enough to hack a --listoptions into xmame which gxmame and other frontends could use. Then gxmame would also need to be modified to store an option list per binary, and build the configuration dialogs and compute the command line arguments to be used from there :-) Sounds simple, eh? I'm sure it's challenging enough nevertheless :-D Matthias BTW: Thanks a lot Lawrence and Hans for the great release 0.87 is! -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Another gxmame problem
Lawrence Gold wrote : On Aug 26, 2004, at 5:48 AM, Julian Sikorski wrote: There is a problem with gxmame-0.34b and xmame-0.86. Frontend is unable to start any game due to unknown option -xil. Any suggestions how to fix this issue (it's somehow similar to hotrod one). See the announcement. :D I'll try to have a patch out tonight. Seems like no one has yet come up with a quick patch to fix this, and I'm probably not the only one impatient for this to happen in order to release 0.86 packages to end-users :-D Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess-0.86
Nicos Panayides wrote : I've had this error when building the SDL target (the x11 built fine) : [...] Linking xmame.SDL ... xmame.obj/unix.SDL/devices.o(.text+0x20c): In function `osd_input_initpre': src/unix/devices.c:532: undefined reference to `joy_SDL_init' collect2: ld returned 1 exit status make: *** [xmame.SDL] Error 1 Probably related to the changes mentioned below : - The SDL joystick driver works again. It should also be a bit faster. Define JOY_SDL=1 in the makefile. Thanks, that may be the problem as I've never had it enabled before. Should it be forced to be enabled for the SDL target build? (if it indeed is the cause) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: xgl target build problem (was Re: [Xmame] xmame/xmess-0.84.1)
Lawrence Gold wrote : Linking messtest... xmess.obj/mame.o(.text+0x13f5): In function `update_video_and_audio': src/mame.c:1274: undefined reference to `vector_dirty_list' This is just a problem with messtest; your xmess.xgl build should be fine. The attached patch should fix this, as well as some other problems in 0.84.1. I'm especially interested to hear people's experiences building the xgl target using the NVIDIA or Mesa headers -- you should now be able to do either. Great! With that patch, I've rebuilt all targets of both xmame and xmess fine on both i386 and x86_64. I'll still need to rebuild on ppc, later today normally ;-) Thanks a lot! Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] PPC linking problem (was: Re: xgl target build problem)
Lawrence Gold wrote : On Jul 18, 2004, at 12:57 PM, Matthias Saou wrote: Aha, that fixed it indeed... strange :-) Now, I've got another problem with xgl, with mess : [...] [OSEPEND] Compiling src/unix/frameskip-drivers/dos.c ... [OSEPEND] Compiling src/unix/frameskip-drivers/barath.c ... Compiling src/vidhrdw/vector.c ... Archiving xmess.obj/unix.xgl/osdepend.a ... Linking xmess.xgl ... Linking messtest... xmess.obj/mame.o(.text+0x13f5): In function `update_video_and_audio': src/mame.c:1274: undefined reference to `vector_dirty_list' This is just a problem with messtest; your xmess.xgl build should be fine. The attached patch should fix this, as well as some other problems in 0.84.1. I'm especially interested to hear people's experiences building the xgl target using the NVIDIA or Mesa headers -- you should now be able to do either. I have a compile problem on Yellow Dog Linux 3.0 (ppc)... the exposed path of a directory inside Dan Burcaw's home (he's the developer who compiled the glibc) makes me wonder if it's a gcc/ld/glibc bug or an xmame one. The last release I've recompiled (successfully) on that platform with the same environment was 0.79. Thoughts are welcome ;-) [...] [OSEPEND] Compiling src/unix/frameskip-drivers/dos.c ... [OSEPEND] Compiling src/unix/frameskip-drivers/barath.c ... Compiling src/vidhrdw/vector.c ... Archiving xmame.obj/unix.x11/osdepend.a ... Linking xmame.x11 ... /usr/lib/gcc-lib/ppc-yellowdog-linux/3.2.2/../../../crt1.o(.text+0x20): In function `_start': : relocation truncated to fit: R_PPC_REL24 __libc_start_main@@GLIBC_2.0 /usr/lib/gcc-lib/ppc-yellowdog-linux/3.2.2/../../../crti.o(.text+0x10): In function `call_gmon_start': /home/dburcaw/BUILD/glibc/BUILD/glibc-2.3.1-20030220/build-ppc-linux/csu/c rti.S:16: relocation truncated to fit: R_PPC_LOCAL24PC _GLOBAL_OFFSET_TABLE_ xmame.obj/mame.o(.text+0xd4): In function `run_game': : relocation truncated to fit: R_PPC_REL24 strlen@@GLIBC_2.0 xmame.obj/mame.o(.text+0x12c): In function `run_game': : relocation truncated to fit: R_PPC_REL24 puts@@GLIBC_2.0 [... etc, many many many of those relocation truncated lines ...] If it can help, I'm compiling with MY_CPU=risc and CFLAGS=-O3 -Wall -g -fsigned-char, the rest of the cc/ld stuff is the default. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] PPC linking problem (was: Re: xgl target build problem)
Eric Deveaud wrote : and for the linking problem, see my post about [Xmame] xmame/xmess-0.84.1 Message-ID: [EMAIL PROTECTED] there's a patch for the makefile, that correct the problem. the original solution was found by Christian Groessler If it can help, I'm compiling with MY_CPU=risc and CFLAGS=-O3 -Wall -g -fsigned-char, the rest of the cc/ld stuff is the default. it may be faster to patch by hand add -mlongcall to the CFLAGS --relaxto the LDFLAGS The latest patch Lawrence posted to the list already adds the --relax to ld. Unfortunately for me, the -mlongcall options doesn't seem to be known to my gcc version... gcc version 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a) [...] mkdir -p xmame.obj/unix.x11/video-drivers mkdir -p xmame.obj/vidhrdw Compiling src/version.c ... cc1: invalid option `longcall' make: *** [xmame.obj/version.o] Error 1 I also tried with -flongcall (just in case), it's different, but no better : cc1: unrecognized option `-flongcall' I'm confused, now :-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] PPC linking problem (was: Re: xgl target build problem)
Eric Deveaud wrote : your gcc is too new ;-) Nope, too old. I have 3.2.2, which indeed doesn't mention -mlongcall in the gcc man page, whereas you have 3.3.2. On Fedora Core, with 3.3.3, I also have it in the man page. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] -vrs problem
c.s.h. wrote : Could some kind soul tell me what rom comes after batmanfr when verifying a rom set? Currently, when I do a -vrs switch, it gets through batmanfr, then stops and proceeds to use up ALL my ram unitl I ctrl-C... so I'm wondering what the offending romset is. My guess : sfish2. I've always had the same problem, it seems that for the .bin CD image, verifying it requires putting it entirely in RAM or something :-( Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Frontend question
Nicos Panayides wrote : I can't speak for the rest of the gxmame developers but I don't have the time right now to fix it. If you want to see this fixed ASAP, send us patches. If you are gonna use an xml library please use libxml2 which is used by gtk anyway. Give us a couple of weeks and it will be fixed (at least in CVS). Promise :) Well, xmame 0.84 isn't out yet, so I guess the real bugging hasn't surfaced yet... I know I'll also be lost and miserable when gxmame will stop working ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
xgl target build problem (was Re: [Xmame] xmame/xmess-0.84.1)
Lawrence Gold wrote : xmame/xmess-0.84.1 is now available. Is the xgl target broken? I get this when trying to recompile my packages. + /usr/bin/make DISPLAY_METHOD=xgl TARGET=mame mkdir -p xmame.obj/unix.xgl mkdir -p xmame.obj/unix.xgl/frameskip-drivers mkdir -p xmame.obj/unix.xgl/joystick-drivers mkdir -p xmame.obj/unix.xgl/sysdep mkdir -p xmame.obj/unix.xgl/sysdep/dsp-drivers mkdir -p xmame.obj/unix.xgl/sysdep/mixer-drivers mkdir -p xmame.obj/unix.xgl/video-drivers [OSEPEND] Compiling src/unix/main.c ... command line:194:14: missing terminating character make: *** [xmame.obj/unix.xgl/main.o] Error 1 Both x11 and SDL targets compile fine. I'm confused as to where that 194th lines is... Matthias Here is the actual complete command without QUIET : [...] mkdir -p xmame.obj/unix.xgl/video-drivers # @echo '[OSEPEND] Compiling src/unix/main.c ...' gcc -O2 -g -pipe -O3 -Wall '-DINLINE=static __inline__' -DLSB_FIRST -DALIGN_INTS -DALIGN_SHORTS -D__LP64__ -D__ARCH_linux -D__CPU_amd64 -Dxgl -Dstricmp=strcasecmp -Dstrnicmp=strncasecmp -DPI=M_PI -DXMAME -DUNIX -DSIGNED_SAMPLES -DCLIB_DECL= -DHAS_CDDA=1 -DHAS_CUSTOM=1 -DHAS_SAMPLES=1 -DHAS_DAC=1 -DHAS_DMADAC=1 -DHAS_DISCRETE=1 -DHAS_AY8910=1 -DHAS_YM2203=1 -DHAS_YM2151=0 -DHAS_YM2151_ALT=1 -DHAS_YM2608=1 -DHAS_YM2610=1 -DHAS_YM2610B=1 -DHAS_YM2612=1 -DHAS_YM3438=1 -DHAS_YM2413=1 -DHAS_YM3812=1 -DHAS_YM3526=1 -DHAS_YMZ280B=1 -DHAS_Y8950=1 -DHAS_SN76477=1 -DHAS_SN76496=1 -DHAS_POKEY=1 -DHAS_TIA=1 -DHAS_NES=1 -DHAS_ASTROCADE=1 -DHAS_NAMCO=1 -DHAS_NAMCO_15XX=1 -DHAS_NAMCO_CUS30=1 -DHAS_NAMCO_52XX=1 -DHAS_NAMCO_54XX=1 -DHAS_NAMCO_63701X=1 -DHAS_NAMCONA=1 -DHAS_TMS36XX=1 -DHAS_TMS5110=1 -DHAS_TMS5220=1 -DHAS_VLM5030=1 -DHAS_ADPCM=1 -DHAS_OKIM6295=1 -DHAS_MSM5205=1 -DHAS_MSM5232=1 -DHAS_UPD7759=1 -DHAS_HC55516=1 -DHAS_K005289=1 -DHAS_K007232=1 -DHAS_K051649=1 -DHAS_K053260=1 -DHAS_K054539=1 -DHAS_SEGAPCM=1 -DHAS_RF5C68=1 -DHAS_CEM3394=1 -DHAS_C140=1 -DHAS_QSOUND=1 -DHAS_SAA1099=1 -DHAS_IREMGA20=1 -DHAS_ES5505=1 -DHAS_ES5506=1 -DHAS_BSMT2000=1 -DHAS_YMF262=1 -DHAS_YMF278B=1 -DHAS_GAELCO_CG1V=1 -DHAS_GAELCO_GAE1=1 -DHAS_X1_010=1 -DHAS_MULTIPCM=1 -DHAS_C6280=1 -DHAS_SP0250=1 -DHAS_SCSP=1 -DHAS_PSXSPU=1 -DHAS_YMF271=1 -DHAS_ICS2115=1 -DHAS_ST0016=1 -DHAS_Z80=1 -DHAS_Z180=1 -DHAS_8080=1 -DHAS_8085A=1 -DHAS_M6502=1 -DHAS_M65C02=1 -DHAS_M65SC02=0 -DHAS_M65CE02=0 -DHAS_M6509=0 -DHAS_M6510=1 -DHAS_M6510T=0 -DHAS_M7501=0 -DHAS_M8502=0 -DHAS_N2A03=1 -DHAS_DECO16=1 -DHAS_M4510=0 -DHAS_H6280=1 -DHAS_I86=1 -DHAS_I88=0 -DHAS_I186=1 -DHAS_I188=0 -DHAS_I286=0 -DHAS_I386=1 -DHAS_V20=1 -DHAS_V30=1 -DHAS_V33=1 -DHAS_V60=1 -DHAS_V70=1 -DHAS_I8035=1 -DHAS_I8039=1 -DHAS_I8048=1 -DHAS_N7751=1 -DHAS_I8X41=1 -DHAS_M6800=1 -DHAS_M6801=1 -DHAS_M6802=1 -DHAS_M6803=1 -DHAS_M6808=1 -DHAS_HD63701=1 -DHAS_NSC8105=1 -DHAS_M6805=1 -DHAS_M68705=1 -DHAS_HD63705=1 -DHAS_HD6309=1 -DHAS_M6809=1 -DHAS_M6809E=1 -DHAS_KONAMI=1 -DHAS_M68000=1 -DHAS_M68008=0 -DHAS_M68010=1 -DHAS_M68EC020=1 -DHAS_M68020=1 -DHAS_T11=1 -DHAS_S2650=1 -DHAS_TMS34010=1 -DHAS_TMS34020=1 -DHAS_TMS9900=0 -DHAS_TMS9940=0 -DHAS_TMS9980=1 -DHAS_TMS9985=0 -DHAS_TMS9989=0 -DHAS_TMS9995=1 -DHAS_TMS99000=0 -DHAS_TI990_10=0 -DHAS_TMS99105A=0 -DHAS_TMS99110A=0 -DHAS_Z8000=1 -DHAS_TMS32010=1 -DHAS_TMS32025=1 -DHAS_TMS32026=1 -DHAS_TMS32031=1 -DHAS_CCPU=1 -DHAS_ADSP2100=1 -DHAS_ADSP2101=1 -DHAS_ADSP2104=1 -DHAS_ADSP2105=1 -DHAS_ADSP2115=1 -DHAS_ADSP2181=1 -DHAS_PSXCPU=1 -DHAS_ASAP=1 -DHAS_UPD7810=1 -DHAS_UPD7807=1 -DHAS_ARM=1 -DHAS_JAGUAR=1 -DHAS_R3000=1 -DHAS_R4600=1 -DHAS_R4700=1 -DHAS_R5000=1 -DHAS_QED5271=1 -DHAS_RM7000=1 -DHAS_SH2=1 -DHAS_DSP32C=1 -DHAS_PIC16C54=0 -DHAS_PIC16C55=1 -DHAS_PIC16C56=0 -DHAS_PIC16C57=1 -DHAS_PIC16C58=0 -DHAS_G65816=1 -DHAS_SPC700=1 -DHAS_E132XS=1 -DHAS_I960=1 -I. -Isrc -Isrc/includes -Isrc/unix -Ixmame.obj/cpu/m68000 -Isrc/cpu/m68000 -DHAVE_MEMMOVE -I/usr/X11R6/include -D_X11_ -DGLXLIB_NAME='\libglut.so\' -DNAME='xmame' -DDISPLAY_METHOD='xgl' -DXMAMEROOT='/usr/share/xmame' -DSYSCONFDIR='/usr/share/xmame' -DSYSDEP_DSP_OSS -DSYSDEP_MIXER_OSS -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DHAVE_GETTIMEOFDAY -DSYSDEP_DSP_ESOUND `esd-config --cflags` -DSYSDEP_DSP_ALSA -DSYSDEP_DSP_ARTS_TEIRA `artsc-config --cflags` -DI386_JOYSTICK -o xmame.obj/unix.xgl/main.o -c src/unix/main.c command line:194:14: missing terminating character make: *** [xmame.obj/unix.xgl/main.o] Error 1 -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Offtopic: which video card to buy.
Nguyen The Toan wrote : Hi, I know this is off topic but I want to ask for some help choosing which video card to buy. I've just built an AMD64 system, and wanted everything to work out of the box with Fedora Core 2 for x86_64. For the video card, I chose a Powered by ATI (ATI chip, not well known brand) Radeon 9200 SE, which is the highest performance card which currently has 3D acceleration with the free drivers found in XFree86 and xorg-x11 (AFAIK of course, my laptop's 9600 doesn't have 3D acceleration yet for instance). It has VGA, DVI and TV out, and from what I saw using the Fedora Core default monitor setup utility, it can output on both the VGA and the DVI at the same time. All this for only 37___, which is a little more than the $25 you're thinking of spending, but for me it's definitely worth the difference! Oh, I have been having problems with xmame's xv target though, for which only a few games seem to work, so I've been using the xgl one for now, but there is this weird artifact of getting a thin grey diagonal line across the entire screen with it... I've been waiting for 0.84 to further check and report these problems, as I don't even know if they're related to the video driver or to the 64bit architecture ;-) In short, if you want good 2D _and_ 3D performance without using proprietary closed source drivers, the Radeon 9200 is certainly today's best choice. Remember that freedom is priceless, so it not having to tweak this and that after every kernel upgrade, or waiting for a vendor to fix his drivers when they become incompatible with the latest free technologies (think NVidia and 2.6 kernel, NVidia and 4k kernel stacks, ATI and its broken xv on recent cards etc.). Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] broken link on xmame site
Lawrence Gold wrote : dbd wrote: hey, don't know if this is the place to send this, but I couldn't find a better place to email. There's a broken link on the x.mame.net site in the downloads section in the xmame RPMs bit, the site we are redirected to is wrong, it should be http://shrike.freshrpms.net/rpm.html?id=1529 (rather than http://shrike.freshrpms.net/rpm.html?id=612 which it is now). Thanks, it should be fixed now. Eek. Linking directly to the ?id= is definitely not the right way for having links still working in the mid and long term. Due to laziness on my part, I still haven't rewritten the indexing engine to only have the package name in the URL, but in the meantime the preferred way of linking is : http://freshrpms.net/rpm/xmame as it will always redirect to the latest version of the distribution (currently Fedora Core 1) and the latest build of the package. It'll hopefully change some day ;-) Especially since it doesn't list the ppc builds I also make for Yellow Dog Linux 3.0. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] PPC xmame 0.78.1 build error
Hi, When trying to recompile xmame on Yellow Dog Linux 3.0, I got the following error : [...] Compiling src/drivers/supertnk.c ... Compiling src/drivers/crospang.c ... Compiling src/drivers/funybubl.c ... Archiving xmame.obj/other.a ... Compiling src/machine/neogeo.c ... Compiling src/machine/pd4990a.c ... Compiling src/machine/neocrypt.c ... Compiling src/vidhrdw/neogeo.c ... Compiling src/drivers/neogeo.c ... Archiving xmame.obj/neogeo.a ... Compiling src/vidhrdw/vector.c ... Linking xmame.x11 ... xmame.obj/cpu/z80/z80.o(.text+0x1854): In function `z80_init': : undefined reference to `osd_die' xmame.obj/cpu/z80/z80.o(.text+0x1854): In function `z80_init': : relocation truncated to fit: R_PPC_REL24 osd_die collect2: ld returned 1 exit status make: *** [xmame.x11] Error 1 I'm not quite sure what could be causing that and haven't found anything about it in the list's archives (or haven't looked enough). Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Problems on Fedora
Marcello Semboli wrote : Martin White ha scritto: Am i right in saying that 0.78.1 includes a large re-write of the memory I tried to compile xmame 0.76.1 but the problem remains :-( You could eventually try the rpm packages I build for Fedora Core 1. The few games I've played so far with 0.78.1 (x11 target using Xv) worked fine for me. http://freshrpms.net/rpm/xmame Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] xmame 0.78.1 build warnings and chd utility
Hi, I got an unusually high number of warnings when building xmame 0.78.1 on Fedora Core 1 (gcc 3.3). Quite a few in the unix spacific part, but also plenty in the drivers and machines. Is this normal? Are big chunks of code being reworked on or something? Second thing, I'll be doing some romset updating soon, but I understood that most (all?) chd files needed changing, but that a small utility taking care of that was included with mame 0.78. I couldn't seem to find it at first, as there was no mention of it in the changes.unix file or any other places I looked in... then I finally saw the chdman target inside the unix.mak file. So I'll be trying make chdman right away ;-) Maybe its existence should be better documented? Maybe it should be built automatically when the target is mame? Just thoughts. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame 0.78.1 build warnings and chd utility
Lawrence Gold wrote : On Jan 16, 2004, at 8:10 AM, Matthias Saou wrote: Second thing, I'll be doing some romset updating soon, but I understood that most (all?) chd files needed changing, but that a small utility taking care of that was included with mame 0.78. I couldn't seem to find it at first, as there was no mention of it in the changes.unix file or any other places I looked in... then I finally saw the chdman target inside the unix.mak file. So I'll be trying make chdman right away ;-) Maybe its existence should be better documented? Maybe it should be built automatically when the target is mame? Just thoughts. See doc/mame/whatsnew.txt: General Source Changes -- New CHD format and management tools [Aaron Giles] hdcomp is now chdman old chd files are _not_ compatible, they will need to be updated using chdman -update oldchd.chd newchd.chd CHD now stands for 'Compressed Hunks of Data' not 'Compressed Hard Drive' as the format is more flexible. Thanks for the pointer, that was the one place I didn't look in :-) Just FYI, I've added chdman to my Fedora Core and Yellow Dog Linux rpm packages of 0.78.1 which should be appearing on freshrpms.net shortly. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] OpenVMS Patch: xmame-0.77.1/src/unix/fileio.c
Robert Alan Byer wrote : you should remove the #if defined(__DECC) defined(VMS) since this patch is needed for unix too. Thanks, didn't know that. I'm not a programmer, but for readability and ease of understanding, isn't naming variables variable and variable2 something one should avoid? As we say in French, Mal nommer les choses c'est ajouter au malheur du Monde i.e. Badly naming things is adding to the World's problems. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] GXMame beta testers needed
Shadow Walker wrote : For those who want to try the next version of GXMame, we are at a freeze/debug stage, you can pull it from cvs I've made some Fedora 1 x86 packages available here : http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/testing/1/gxmame/ The xmame 0.77.1 packages to go with it are available from : http://yarrow.freshrpms.net/ Tip to get the Categories and Versions listings to work : cp /usr/share/doc/xmame-0.77.1/catver.ini ~/.gxmame/ The autogen.sh failed without an ABOUT-NLS file, and the whole gettext part too when cvs wasn't available (should it?). Apart from that, the build itself went fine for me, although some doc files got installed in /usr/share/doc/gxmame/ and others in /usr/share/doc/gxmame-0.34cvs. After the first start, the warning dialog The gamelist is from: was empty, and after the second it had only a strange character... From there on, the gamelist rebuild for 0.77 went fine, the audit too, and I played a quick game of 19xx without touching any of my current settings. Great work, it's looking good, thanks a lot! Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] mame.dk
Matthias Saou wrote : Does anyone know if there already exists a big listing of e2k:// links to all the files needed to get a latest romset? (replying to myself) I've just seen such a place, if can be of any help to some out there! http://www.sharereactor.com/release.php?id=2405 -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] mame.dk
Frank Cox wrote : Actually, it's my understanding that their hosting company went under. Doh :-( Does anyone know if there already exists a big listing of e2k:// links to all the files needed to get a latest romset? As xMule, aMule, mldonkey and others are really easy to use, I'd be willing to create such a page. It could even be extended to have shorter incremental listings for every new releases, containing only the new files needed for an advscan run (which is a great utility btw) : Say a single 4kB file is added to a 50MB rom archive, you only need to download a zip file with the 4kB file and advscan will merge both automatically. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess-0.74.1
Lawrence Gold wrote : xmame/xmess-0.74.1 is now available. I got these warnings about unused variables. Maybe worth commenting sections out or cleaning up the code a bit? Compiling src/unix/devices.c ... devices.c: In function `osd_customize_inputport_defaults': devices.c:1287: warning: unused variable `input' devices.c:1288: warning: unused variable `paddle' devices.c:1288: warning: unused variable `dial' devices.c:1288: warning: unused variable `trackball' devices.c:1288: warning: unused variable `adstick' devices.c:1288: warning: unused variable `pedal' devices.c:1288: warning: unused variable `lightgun' devices.c: At top level: devices.c:48: warning: `size_osd_ik' defined but not used Compiling src/unix/effect.c ... effect.c: In function `effect_rgbstripe_16_YUY2': effect.c:878: warning: unused variable `t' effect.c:878: warning: unused variable `t2' Also, probably more important, I got the impression that x11_window.c and the xf86_dga*.c files compiled much faster than before on the same build system. From the changes listed, I don't see how that would be possible, though :-/ Last but not least, the xgl target seems broken : [...] Compiling src/unix/sysdep/sysdep_mixer.c ... Compiling src/unix/video-drivers/xgl.c ... Compiling src/unix/video-drivers/gltool.c ... video-drivers/gltool.c: In function `loadGLLibrary': video-drivers/gltool.c:273: `GLXLIB_NAME' undeclared (first use in this function) video-drivers/gltool.c:273: (Each undeclared identifier is reported only once video-drivers/gltool.c:273: for each function it appears in.) video-drivers/gltool.c: In function `getGLProcAddressHelper': video-drivers/gltool.c:423: `GLXLIB_NAME' undeclared (first use in this function) make[1]: *** [../../xmame.obj/unix.xgl/video-drivers/gltool.o] Error 1 Any easy fix for this that I can try? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess-0.74.1
Lawrence Gold wrote : Also, probably more important, I got the impression that x11_window.c and the xf86_dga*.c files compiled much faster than before on the same build system. From the changes listed, I don't see how that would be possible, though :-/ I'd imagine that Shyouzou Sugitani's changes in 0.72.1 are what made the difference. Did that one seem to build faster? I didn't pay attention to 0.72.1, so that may be it. Last but not least, the xgl target seems broken : video-drivers/gltool.c:423: `GLXLIB_NAME' undeclared (first use in this function) make[1]: *** [../../xmame.obj/unix.xgl/video-drivers/gltool.o] Error 1 Any easy fix for this that I can try? You need one of the changes from makefile.unix. GLXLIB_NAME is defined in there. Yes, until now I was still overriding GLCFLAGS with -D_X11_ -DGLU_VERSION_1_2, which seems unneeded now, so the GLXLIB_NAME was getting omitted. My bad! Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess-0.72.1
Hi, Here are some minor warnings I got while compiling : effect.c: In function `effect_rgbstripe_16_YUY2': effect.c:878: warning: unused variable `t' effect.c:878: warning: unused variable `t2' And on ppc (there already were similar ones a while back IIRC) : Compiling src/cpu/hd6309/hd6309.c ... src/cpu/hd6309/hd6309.c:188:1: warning: PPC redefined src/cpu/hd6309/hd6309.c:1:1: warning: this is the location of the previous definition Also in : src/cpu/i8x41/i8x41.c:165:1 src/cpu/konami/konami.c:106:1 src/cpu/m6502/ops02.h:64:1 src/cpu/m6809/m6809.c:150:1 Apart from that, and the fact the frontends are now broken regarding XV and fullscreen, it seems to work fine. Shadowwalker : Any info about when we can expect an updated gxmame, or maybe a quick patch to be compatible with the new switches? ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess-0.72.1
Shadow Walker wrote : Matthias Saou wrote: Shadowwalker : Any info about when we can expect an updated gxmame, or maybe a quick patch to be compatible with the new switches? ;-) I'll try to see if I can make a patch this week. For an update, we need to fixe some problems introduced during the GTK2 port (you can get the latest change on the CVS but it still wont work with the new X-Mame). Oooh, so the next version will be in gtk2, sweet! :-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess-0.72.1
Great to have 0.72.1 out. Thanks Lawrence! Lawrence Gold wrote : - Xv windowed mode is now enabled with -x11-mode 2 or -x11 2, and Xv fullscreen mode is enabled with -x11-mode 3 or -x11 3. The -[no]xv and -fullscreen switches are no longer available for X11 builds. Isn't this going to break frontends? Expect more feedback as soon as I have updated rpm packages available and do some basic testing. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] make: *** [xmame.obj/vidhrdw/gaiden.o] Error 1
Phillip Pi wrote : That won't work because I use emu10k1 driver from CL's opensource team and I don't use ALSA driver: [EMAIL PROTECTED] download]# rpm --rebuild xmame-0.70.1-fr1.src.rpm Installing xmame-0.70.1-fr1.src.rpm error: failed build dependencies: alsa-lib-devel is needed by xmame-0.70.1-fr1 Well, rpmbuild --rebuild --without alsa xmame*.src.rpm :-) BTW, the 0.71.1 packages for i386 and ppc will be up in a couple of hours at most. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess-0.71.1
Lawrence Gold wrote : xmame/xmess-0.71.1 is finally out. Just dropping in the old sources in my source package and attempting a rebuild gave me the following : [...] Compiling src/cpu/m68000/m68kcpu.c ... Compiling src/cpu/m68000/m68kmame.c ... Compiling xmame.cbj/cpu/m68000/m68kopac.c... Compiling xmame.cbj/cpu/m68000/m68kopdm.c... Compiling xmame.cbj/cpu/m68000/m68kopnz.c... Compiling xmame.cbj/cpu/m68000/m68kops.c... Compiling src/cpu/m6805/m6805.c ... Compiling src/cpu/m6809/m6809.c ... Compiling src/cpu/mips/mips.c ... Compiling src/cpu/mips/mips3drc.c ... src/cpu/mips/mips3drc.c:166: redefinition of `struct pc_ptr_pair' src/cpu/mips/mips3drc.c: In function `mips3_init': src/cpu/mips/mips3drc.c:361: structure has no member named `cachesize' make: *** [xmame.obj/cpu/mips/mips3drc.o] Error 1 Doh! :-( Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame.xgl -li
Lawrence Gold wrote : On Sat, May 24, 2003 at 12:44:37PM +0200, Matthias Saou wrote: Hi, I just generated an info file using xmame.xgl, and noticed that the appended xgl target specific info is appended to it since it's outputted to stdout : GLmame v0.94 - the_peace_version , by Sven Goethel, http://www.jausoft.com, [EMAIL PROTECTED], based upon GLmame v0.6 driver for xmame, written by Mike Oliphant I think this should go to stderr, just like the info about parsing the xmamerc files. Done for 0.70.1. Cool. Now I just can't wait to get a hold of 0.70.1 ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame-0.69.1
One more strangeness, in xmess this time :-) strings /usr/bin/xmess.x11 | grep /usr /usr/local/share/xmess/bios /usr/local/share/xmess/crc /usr/local/share/xmess/ini /usr/local/share/xmess/snap /usr/local/share/xmess/ctrlr /usr/local/share/xmess/software /usr/local/share/xmess/samples /usr/local/share/xmess/artwork /usr/local/share/xmess/cheat.dat /usr/local/share/xmess/hiscore.dat /usr/local/share/xmesssysinfo.dat /usr/local/share/xmessmessinfo.dat /usr/local/share/xmess /usr/local/share/xmess/xmessrc /usr/local/share/xmess/xmess-x11rc /usr/local/share/xmess/rc/gamerc Looks like there is a missing / for sysinfo.dat and messinfo.dat which seem to be the most important dat files for xmess. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Quietly awaiting 0.68
Lawrence Gold wrote : On Wed, May 21, 2003 at 05:21:27PM +0200, Matthias Saou wrote: Hi, I've noticed yesterday that Mighty Pang was now supported in mame 0.68... so now I just can't wait to see xmame get updated in order to try it out! Laurence, have you had time to hack around a bit yet? ;-) I have, and it shouldn't take too much effort to get a 0.68.1 release put together. I'll try to do some work on it this evening. Hum, just tried to access http://x.mame.net/ to browse the FAQ and other sections once more and got this : ERROR The requested URL could not be retrieved While trying to retrieve the URL: http://x.mame.net/ The following error was encountered: * Access Denied. Access control configuration prevents your request from being allowed at this time. Please contact your service provider if you feel this is incorrect. Your cache administrator is root. Generated Wed, 21 May 2003 19:17:31 GMT by squid1.ztnet.com (squid/2.5.STABLE1-20021126) As my ISP isn't ztnet, I suppose it's some kind of misconfigured reverse proxy... and http://www.ztnet.com/ gives the same error! Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] Gxmame 0.31 is broken with xmame 0.66.2
Hi, I've just updated my romset, and was wanting to try out some new 0.66 games, and just noticed that gxmame can't work anymore because of some options that changed name or values. The first is the brightness, which was apparently set as a percentage before, and gxmame defaulted to 100. But now it's from 0.5 to 2.0, so setting it to 1 in gxmame works around the problem. But the second is what got me stuck: The gamma correction option changed values just like the brightness, but also name! So now, when using gxmame, xmame complains about -gamma-correction not existing, as it's now -gamma, with the same 0.5-2.0 range. Maybe there are other problematic options, but as the gamma is blocking, I can't easily know. If Shadow Walker is around: Isn't it time for a new gxmame release? :-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Gxmame 0.31 is broken with xmame 0.66.2
Frank Cox [EMAIL PROTECTED] wrote : On Sun, 23 Mar 2003 17:57:26 +0100 Matthias Saou [EMAIL PROTECTED] wrote: If Shadow Walker is around: Isn't it time for a new gxmame release? :-) He already has this noted on the front page of his website. Oops! I had checked the gxmame website on Friday, and hadn't gone back since. I'll just be patient then, and use the default xmame CLI in the meantime ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Problems compiling on ppc
Lars Jørgen Solberg [EMAIL PROTECTED] wrote : did you uncomment the line: #CFLAGS += -pipe in the makefile? when i did, my system ran out of memory and random processes was killed. If one of these processes where involved in compiling mame, the compilation would fail giving an strange error. You might want to check your logs for lines like: hostname kernel: Out of memory: Killed process 2667 (cc1) Those aren't strange errors: When you enable optimisations, more memory is usually used at compile time. I've noticed that with the current CFLAGS I use on ppc, a cc1 process groes up to 700MB or RAM when compiling x11_window.c! I had to add a temporary swap file to my system ;-) But the error I'm getting isn't related to that. It seems to me that it might be asm code that the compile doesn't like. I'm using gcc 2.96 btw. Apparently, the error is in a part of the code inside an #ifdef X86_ASM, and I'm using the makefile.unix file, where DEFS doesn't contains -DX86_ASM by default, unlike makefile.mame and makefile.mes. I don't think this is normal! I'll try to track the problem down to see why and where the X86_ASM is getting defined. Matthias On 2003.03.18 18:48 Matthias Saou wrote: Hi, I'm trying to compile xmame on GNU/Linux PPC again. I had to add a swap file to my system in order to get x11_window.c to compile (cc1 takes up to 600 or 700MB RAM!), but the build fails a bit later on some asm code it seems. I haven't set the X86_ASM_68000 option, so I don't understand why this is happening. Here is the output: [...everything fine...] Compiling src/tilemap.c ... In file included from src/tilemap.c:20: src/unix/osinline.h: In function `_vec_mult': src/unix/osinline.h:36: unknown register name `%edx' in `asm' make: *** [xmame.obj/tilemap.o] Error 1 Could some x86 only asm code have slipped into there? -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Problems compiling on ppc
Simon Roby [EMAIL PROTECTED] wrote : gcc 2.96 (RedHat's controversial, healily-patched and totally unofficial gcc version) has been known to not correctly follow some ASM rules. Maybe it's related to your problem. Nope, I found what was causing that problem: Having MY_CPU still defined as i386 in the makefile had the environment variable I had set ignored. Commenting out the MY_CPU gets the exported value taken into account. I've just run into another problem now, that I'll be investigating shortly, still about asm, but nasm this time: [...everything fine now...] Compiling src/cpu/m6502/m6502.c ... Compiling src/cpu/m6800/m6800.c ... Compiling src/cpu/m68000/make68k.c... Generating xmame.obj/cpu/m68000/68000.asm... Make68K - V0.30 - Copyright 1998, Mike Coates ([EMAIL PROTECTED]) 1999, Darren Olafson ([EMAIL PROTECTED]) 2000 Building 68000 2001 1666 Unique Opcodes Assembling xmame.obj/cpu/m68000/68000.asm... make: nasm: Command not found make: *** [xmame.obj/cpu/m68000/68000.o] Error 127 Now, I don't have nasm installed, nor is it available for YellowDog Linux in the main archives. Is nasm yet another x86 specific program? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] Problems compiling on ppc
Hi, I'm trying to compile xmame on GNU/Linux PPC again. I had to add a swap file to my system in order to get x11_window.c to compile (cc1 takes up to 600 or 700MB RAM!), but the build fails a bit later on some asm code it seems. I haven't set the X86_ASM_68000 option, so I don't understand why this is happening. Here is the output: [...everything fine...] Compiling src/tilemap.c ... In file included from src/tilemap.c:20: src/unix/osinline.h: In function `_vec_mult': src/unix/osinline.h:36: unknown register name `%edx' in `asm' make: *** [xmame.obj/tilemap.o] Error 1 Could some x86 only asm code have slipped into there? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Compiling xmame for ppc
Lawrence Gold [EMAIL PROTECTED] wrote : It's probably due to the heavy use of macros. Could you try the attached x11_window.c and see if it works any better for you? It has a change that I made last night in the upcoming 0.66.1 and it may help. Currently testing a build using it... doesn't seem to help much :-( XulChris [EMAIL PROTECTED] wrote : x11_window.c takes a really really long time to compile. It takes probably over five minutes on my machine... Well, it's been running for at least that... and it taking up 100% of the CPU and over 300MB of memory (the machine has only 192MB of physical RAM). I'll wait a bit longer, but my hopes are quite limited ;-) Boom! [...] Compiling src/unix/video-drivers/x11_window.c ... gcc: Internal error: Killed (program cc1) Please submit a full bug report. See URL:http://bugzilla.redhat.com/bugzilla/ for instructions. make[1]: *** [../../xmame.obj/unix.x11/video-drivers/x11_window.o] Error 1 make[1]: Leaving directory `/home/dude/redhat/tmp/xmame-0.65.1/src/unix' make: *** [osdepend] Error 2 I think that cc1 process just filled RAM+swap (192+300) and got killed :-( Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] Gxmame and xmame.xgl
Hi, I've been trying to use gxmame with the latest xmame + xgl patch, but I haven't been able to find working settings in the xgl options. The defaults clearly don't work, so I guess gxmame would need some fixing there anyway since running xmame.xgl -fullscreen romname works great. I'll need to go tweaking some more, and I'd also like to find out where those cabinet files need to go in order to have them do something... ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Gxmame and xmame.xgl
Sven Goethel [EMAIL PROTECTED] wrote : On Wednesday 26 February 2003 16:52, Matthias Saou wrote: Hi, I've been trying to use gxmame with the latest xmame + xgl patch, yep, i am using the gxmame 0.31 either ! but I haven't been able to find working settings in the xgl options. The defaults clearly don't work, so I guess gxmame would need some fixing there anyway since running xmame.xgl -fullscreen romname works great. hmm, funny, i had no problems at all using the defaults .. you might should post the output of the used commandline, gxmame calls, plus xmame.xgl's output .. Well... I was able to reproduce it twice yesterday even after erasing ~/.gxmame, and when I decided to reproduce it today, I also erased ~/.xmame and the problem was gone! I can't seem to be able to get the cabinets to work though, when I select the glmamejau (default) cabinet within gxmame, I only get a black screen when I launch a game, and when I press esc, I see no unusual output whatsoever. My .cab files seem to always have been in the right place too, so I guess I'll do some tries with the command line when I have more time! Thanks for the great xgl patch, Sven! Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] ANNOUNCE GLMame 0.94 - patch against (0.65.1 +Sugitani's blitter)
Sven Goethel [EMAIL PROTECTED] wrote : patch against (0.65.1 + Sugitani's blitter) please add xgl or opengl in the subject line, so i can read it ;-) happy gaming Right now it's compiling for me. Just a quick note to say that there's a compilation warning now, the only one in the entire process :-) Compiling src/unix/video.c ... video.c:91: warning: `adjust_bitmap_and_update_display' used but never defined Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] ANNOUNCE GLMame 0.94 - patch against (0.65.1 +Sugitani's blitter)
Matthias Saou [EMAIL PROTECTED] wrote : Sven Goethel [EMAIL PROTECTED] wrote : patch against (0.65.1 + Sugitani's blitter) please add xgl or opengl in the subject line, so i can read it ;-) happy gaming Right now it's compiling for me. Just a quick note to say that there's a compilation warning now, the only one in the entire process :-) Compiling src/unix/video.c ... video.c:91: warning: `adjust_bitmap_and_update_display' used but never defined Actually, looks like the linking fails because of this too : Linking xmame.x11 ... xmame.obj/unix.x11/osdepend.a(video.o): In function `osd_update_video_and_audio': video.o(.text+0x12f5): undefined reference to `adjust_bitmap_and_update_display'collect2: ld returned 1 exit status This is with 0.65.1 and the following patches : blit_core-all2.diff.gz blit_core-8.diff.gz xmame_0.65.1_SugitanisBlit-GL0.94.diff.bz2 Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] ANNOUNCE GLMame 0.94 - patch against (0.65.1 +Sugitani's blitter)
Sven Goethel [EMAIL PROTECTED] wrote : funny .. just recompiled the stuff, but i do not have this error .. gcc 2.95.3 video.c:91: is deactivated, cause of the define xgl ! funny message .. That message (and the linking error) is when building the x11 target with both XV and DGA enabled, as I always rebuild all three targets sequencially (x11 the SDL then xgl) in order to get a binary package of each. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] ANNOUNCE GLMame 0.94 - patch against (0.65.1 +Sugitani's blitter)
Sven Goethel [EMAIL PROTECTED] wrote : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 22 February 2003 21:58, Matthias Saou wrote: Compiling src/unix/video.c ... video.c:91: warning: `adjust_bitmap_and_update_display' used but never defined Actually, looks like the linking fails because of this too : Linking xmame.x11 ... xmame.obj/unix.x11/osdepend.a(video.o): In function `osd_update_video_and_audio': video.o(.text+0x12f5): undefined reference to `adjust_bitmap_and_update_display'collect2: ld returned 1 exit status this is my src/unix/video.c 89 #ifndef xgl 90 static void adjust_bitmap_and_update_display(struct mame_bitmap *srcbitmap, 91 struct mame_bitmap *dest_bitmap, struct rectangle bounds); 92 #endif so .. no usage at all ... Well, I have exactly the same lines in video.c :-/ I get the error when compiling on Red Hat Linux 8.0 (gcc 3.2) with : make 'CFLAGS=-O2 -march=i386 -mcpu=i686 -O2 -Wall -Wno-unused -fomit-frame-pointer -fstrict-aliasing -fstrength-reduce -ffast-math -pipe -funroll-loops -fexpensive-optimizations' DISPLAY_METHOD=x11 X11_DGA=1 X11_XV=1 I don't seem to get the warning with the same CFLAGS as above but with DISPLAY_METHOD=xgl 'GLCFLAGS=-D_X11_ -DGLU_VERSION_1_2'. For the linking error, I'll know soon as the xgl target is still compiling... Could it be that your changes break the x11 target? A problem with the xgl #define? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] asm cores for ARM?
Dan Hollis [EMAIL PROTECTED] wrote : I would like to see xmame run 100% speed galaga on Zaurus SL-5500. Currently it runs maybe 30%-40% speed. Would ASM cpu core help? Does anyone know ASM cpu cores for ARM? Hi, Where could I find xmame compiled for the Zaurus? I also own an SL-5500! Last I searched, I only found a binary apparently of AdvanceMAME which the person who ported it said that it was better suited for the Zaurus because if the scaling capabilities. As there was no doc with it, and after rebooting quite a few times because of system freezes, I finally gave up on using MAME on my Zaurus, but I'd really like to try again, hoping it'll work better ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess-0.65.1
Lawrence Gold [EMAIL PROTECTED] wrote : On Tue, Feb 11, 2003 at 11:34:27PM -0800, XulChris wrote: In unix.mak, INST.x11 should be suid: because DGA requires it. And DGA is still _extremely_ useful considering how much faster it is compared to Xv. I believe it was decided in Hans's day that xmame should not install itself by default with the suid bit set, for security reasons. I tend to agree with that. Me too, especially since more and more people are using the x11 target without DGA since xv has become available. Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] xmame-0.65.1 rpm packages for Red Hat Linux 8.0
Hi, I've updated my Red Hat Linux 8.0 xmame packages to 0.65.1 : http://psyche.freshrpms.net/ The major change is that I've moved all data files into /usr/share/xmame instead of the old weird path, and cleaned up the spec file to match the reworked upstream makefile. A lot of other changes occured, but all along my successive pre-versions repackagings since 0.62.2 ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess-0.64.1-rc2
Lawrence Gold [EMAIL PROTECTED] wrote : I'd especially like feedback about the makefile.unix changes. The CFLAGS settings were inspired/ripped off from the XviD project's makefile, and should be easier to tweak. I like it, but have a suggestion : Would it be possible to use something like $(INSTALL_USER) and $(INSTALL_GROUP) and define them earlier, instead of hard-coding root and bin for the install? That would make packager's life easier since packages should never be built as root, thus fail with these default values. Up to now I had a patch to fix this, but now seems the right time to ask for the change to occur upstream ;-) The second thing, I'm less sure about : Shouldn't the MANDIR be $(PREFIX)/share/man/man6 instead of $(PREFIX)/man/man6? For at least a year or two, all GNU/Linux systems have been moving their man pages that way (to be FHS compliant IIRC)... but I don't know about other *n?x systems. For the rest, it looks good, except maybe as mentionned by someone else, having the default gcc options for x86 optimized that much (defaults to work only on i686 or higher). Maybe putting -march=i386 -mcpu=i686 instead to have the binary optimized for i686 but still able to run archs as low as the i386 would be a better choice? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Verification of games with chd files (solved)
Matthias Saou [EMAIL PROTECTED] wrote : Hmmm... then could it be because I use symbolic links? I've got in my rom path : chd/game1.chd chd/game2.chd etc. game1/game1.chd - ../chd/game1.chd game2/game2.chd - ../chd/game2.chd etc. With the chd subdirectory being nfs mounted from another host for disk space reasons. Well, I checked again... with my eyes open this time I guess, as I realized that since I was mounting my roms through nfs, and that the chd directory was in turn, on the nfs server, a link to an nfs mount from another host... the chd link was pointing outside of the roms nfs export, doh! All is good now, enjoying a few new games :-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] Verification of games with chd files
Hi, I've updated my romset for 0.64, and although now xmame doesn't go crazy when trying to verify the games that have their .chd hard drive images present, it systematically reports them as being incorrect. I've got the .chd images in the right place for vcircle, maxforce and area51, and haven't got the ones for kinst, kinst2 and wargods, but all 6 games are reported as being incorrect. Is this a known problem or is it a bug? Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Verification of games with chd files
Sam Yeung [EMAIL PROTECTED] wrote : --verifyroms works okay for me. Each chd file is in its own sub directory in the roms directory. Hmmm... then could it be because I use symbolic links? I've got in my rom path : chd/game1.chd chd/game2.chd etc. game1/game1.chd - ../chd/game1.chd game2/game2.chd - ../chd/game2.chd etc. With the chd subdirectory being nfs mounted from another host for disk space reasons. Maybe the check doesn't work when the files are actually symlinks? But the games in xmame work doing this, or at least did in 0.62 (haven't tested with 0.64 but I didn't touch anything in my dir/symlink structure). BTW, what's with this one directory with one single file per hard drive image? Wouldn't it have been easier to either add a path where all chd files reside (like for the roms), or to have them simply put in the same directory as the roms? Is it because some soon-to-be-emulated games have more than a single hard drive? Just out of curiosity... Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Verification of games with chd files
Paul Priest [EMAIL PROTECTED] wrote : Because then the chd's are at the same level as the roms, samples etc. i.e roms can reside in: gamename.zip\rom1 or gamename\rom1 Alright, now I understand. I hadn't made the connection with the fact that having a game's files in gamename.zip or in a directory gamename/ was the same thing, as (nearly?) everyone uses zip files... until now, now that hard drive images are appearing. Thanks for that info ;-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Failed build of 0.64-rc1 for both x11 and xgl
Lawrence Gold [EMAIL PROTECTED] wrote : On Wed, Jan 29, 2003 at 01:04:06PM +0100, Matthias Saou wrote: make DISPLAY_METHOD=x11 X11_DGA=1 X11_XV=1 [...] Compiling src/cpu/jaguar/jaguar.c ... Compiling src/cpu/konami/konami.c ... Compiling src/cpu/m6502/m6502.c ... Compiling src/cpu/m6800/m6800.c ... make: *** No rule to make target `src/cpu/m68000/make68k.c', needed by `xmame.obj/cpu/m68000/68000.asm'. Stop. Looks like a Makefile problem somewhere. I'm using the same options in my(patched) makefile as I always do. I remember hearing something about removing support for the asm 68k core, since it can't be placed under (L)GPL if the mamedevs decide to change the license. This may have nothing to do with it, though. I'll see what I can find this evening. Indeed, I just realized I'm using X86_ASM_68000=1... so I'll try disabling it and see if it builds ok (I'm rebuilding xmame on a test machine, a P2 400MHz... looong ;-)) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Failed build of 0.64-rc1 for both x11 and xgl
Caleb Shay [EMAIL PROTECTED] wrote : I found that the asm cores still build fine. Are you trying to do a parallel make (-j2)? I've found that this breaks the xmame build. Not at all, I'm building it as I always built it :-( Furthermore, without X86_ASM_68000=1 it builds fine for me now. For Red Hat 8.x users, I've put up my packages here (no xgl as the build fails) : http://ftp.freshrpms.net/pub/freshrpms/testing/xmame/ Matthias On Wed, 2003-01-29 at 10:52, Lawrence Gold wrote: On Wed, Jan 29, 2003 at 01:04:06PM +0100, Matthias Saou wrote: make DISPLAY_METHOD=x11 X11_DGA=1 X11_XV=1 [...] Compiling src/cpu/jaguar/jaguar.c ... Compiling src/cpu/konami/konami.c ... Compiling src/cpu/m6502/m6502.c ... Compiling src/cpu/m6800/m6800.c ... make: *** No rule to make target `src/cpu/m68000/make68k.c', needed by`xmame.obj/cpu/m68000/68000.asm'. Stop. Looks like a Makefile problem somewhere. I'm using the same options in my(patched) makefile as I always do. I remember hearing something about removing support for the asm 68k core, since it can't be placed under (L)GPL if the mamedevs decide to change the license. This may have nothing to do with it, though. I'll see what I can find this evening. -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Romset verification (was: Re: [Xmame] gridle: [MAME] Fw:historydat062gre correction])
Lawrence Gold [EMAIL PROTECTED] wrote : For those having problems verifying their roms, here's a quick fix. I plan to carry the more sophisticated fix from 0.62.2 forward to 0.63.1. Hi, I've had a problem verifying a complete 0.62 romset with xmame 0.62.2. Either using gxmame to audit all ROMs or directly xmame -rompath /foo -vr, whenever I put all .chd files int the correct locations, I get at one point an xmame occurence which starts to grow and grow... until I either kill -9 it or until it eats up all my RAM and brings my computer to its knees :-/ Is this a known problem? I thought verivying the .chd files was broken in the sens it always reported them being wrong (all mine have been md5 checked manually and are fine) but I didn't know xmame was trying to load them entirely to RAM in order to verify them (hum, just a guess actually). When moving the .chd files out of the way, the complete romset is found to be 100% fine, and putting them back gives the same problem :-( Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: Romset verification (was: Re: [Xmame] gridle: [MAME] Fw:historydat062gre correction])
Lawrence Gold [EMAIL PROTECTED] wrote : On Fri, Jan 17, 2003 at 04:54:07PM +0100, Matthias Saou wrote: Is this a known problem? I thought verivying the .chd files was broken in the sens it always reported them being wrong (all mine have been md5 checked manually and are fine) but I didn't know xmame was trying to load them entirely to RAM in order to verify them (hum, just a guess actually). When moving the .chd files out of the way, the complete romset is found to be 100% fine, and putting them back gives the same problem :-( It's a known core problem that should be fixed in 0.63. Good to know, I'll just keep patient then :-) Matthias -- Matthias SaouWorld Trade Center -Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23 ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
