A guideline for the future

Found a bug? Please report it, but remember to follow the bug reporting guidelines.
Missing a sane feature? Let us know!
But please do NOT request ports to other systems.

Moderator: ZSNES Mods

P the retrogamer
Rookie
Posts: 11
Joined: Sun Dec 19, 2010 5:54 pm

A guideline for the future

Post by P the retrogamer »

I'm a retro gamer, I love NES, SNES and what not. They take me back to the 80's and the 90's, the golden days. Therefore I'm quite glad that some enthusiasts have taken it upon themselves to create such magnificent programs like ZSNES and FCEUX so we all can enjoy the good old games like mega man and Super mario bros. I'm am also a Linux user, since I !!!HATE!!! :evil: Microsoft and its windows crap, and I tried, today, to install the Linux version of ZSNES but came across some small, understating my case, problems. After changing the source, as described by trucmuche04 in his page which can be found by searching for Cannot install ZSENES in Linux, I was stuck because when make is run it ends up saying that i386 is not compatible with x86-64 and I don't really know how to compile for a 32-bit machine unless the machine is a native 32-bit environment. So my guideline for the future is... To everyone in the linux community, if you don't want the hassle wait for 1.60 and instead, for now, use wine and the windows, it make me nauseous just writing it, version of the code. To the developers I just want to say one thing. PLEASE PLEASE PLEASE PLEASE PLEASE rewrite the source and update the technology so its up to date with the year 2010 not 1980 otherwise you are going to loose a growing market. Other than that !!!GREAT!!! emulator

Unless someone knows a sure-fire way to get it working. Hopefully some one will read this and create a manual for installing under Linux in a 64-bit environment.
Awakened
Rookie
Posts: 33
Joined: Sun Mar 25, 2007 3:04 am

Re: A guideline for the future

Post by Awakened »

On Linux you'd probably be better off running Mednafen for SNES emulation since it actually gets updated. I tried out the Windows version of it and it ran Yoshi's Island really nicely besides some stuttering on my PC. But ZSNES and SNES9x also stutter on this, so you might not have that problem.
kode54
Zealot
Posts: 1140
Joined: Wed Jul 28, 2004 3:31 am
Contact:

Re: A guideline for the future

Post by kode54 »

If you have a machine from 2010, as you say, then you should be fine compiling bsnes.

If, on the other hand, you want to use zsnes, you could look around for an unofficial package or repository of binaries for your distribution which contains zsnes. Although, technically, if you have all the compatibility libraries installed, you should be able to build zsnes -m32 without any trouble. I know I had no trouble compiling it on my Fedora desktop. I just needed to install the necessary lib.i686 and lib-devel.i686 packages first.

By all means, make yourself sick using wine to run the Windows version, though. Or you could get a job, or consult with the source of money you already used to pay for your computer, and buy a copy of Windows to run the Windows version natively.

Oh, or if you're still insistent on using Linux, and can't be bothered to use a distribution with proper 32-bit compatibility support, then you could always install the 32-bit version. You just won't get the occasional speed boost from random computationally expensive software compiled 64-bit. You may still get support for all of your installed RAM, though, through PAE support.
badinsults
"Your thread will be crushed."
Posts: 1236
Joined: Wed Jul 28, 2004 1:49 am
Location: Not in Winnipeg
Contact:

Re: A guideline for the future

Post by badinsults »

I would recommend SNES9x 1.52 over Zsnes 1.51 at this point. Though assuming you follow the directions in other threads, you can easily get the provided binaries to run in Linux without much issue. Really, there is no problem with zsnes, just the way you have gone about trying to install it, as zsnes works perfectly fine in x86-64.
<pagefault> i'd break up with my wife if she said FF8 was awesome
P the retrogamer
Rookie
Posts: 11
Joined: Sun Dec 19, 2010 5:54 pm

Re: A guideline for the future

Post by P the retrogamer »

Here's Johnny!!!
Two points...
First thanks for the tips awakened and badinsults I'll try them out and second...
To kode54, when I wrote use tech from 2010 and not 1980 I meant the following. The first 64bit processor came out in 2004 and most operating systems are, today, native 64bit environments. I use SUSE, it might not be the best distribution but they do have the right idea. Why use 32bits when 99% of the processors are 64bit processors, perhaps it's time to start writing code for this kind of market? When it comes to microsoft and windows, I don't see the point in supporting a team which is counter productive to the free market. When I buy a car, bike, computer or a snes I expect to actually own it, be free to have it repaired when it breaks down and modify it to my needs. Microsoft does not believe in this kind of thinking. When a company makes a product or a product line, you don't expect a version released 9 years ago to be better than the last released version, they have even extended the support until 2014. In microsofts defense xp is the best version yet but the best program they have released is DOS and they didn't even make it. Xp is even better than win 7, I know because mommy bought a new computer last Christmas and it worked for two weeks and then it couldn't find the communication area on the motherboard so we had to restart it in order for us to use the internet. Isn't this quite bad for a new version of an operating system especially since microsoft claims that windows is the best OS on the market.
Hopefully this takes care of your last two statements.

For your first two statements...
I'll tryout bsnes even though my computer is one of the last mammoths, only single core but 3200+ from amd and yes it is native 64bit.
Do you know any terrific places, forums and what not, where one might find unofficial packages or repository of binaries? Perhaps someone here knows?

I quote "Although, technically, if you have all the compatibility libraries installed, you should be able to build zsnes -m32 without any trouble. I know I had no trouble compiling it on my Fedora desktop. I just needed to install the necessary lib.i686 and lib-devel.i686 packages first." This is my point exactly, why should I be forced to regress my computer in order to use a program. There are ways of ensuring 32bit and 64bit compatibility. One question. badinsults, how did you go about to get zsnes to run properly in x86-64?

Hopefully I wasn't too harsh since it doesn't promote innovative thinking.
This was my intended idea from the beginning, collect problems and solutions and to store them in one place so we don't have to search in gargantuan forums and libraries where every query results in billions of hits.
kode54
Zealot
Posts: 1140
Joined: Wed Jul 28, 2004 3:31 am
Contact:

Re: A guideline for the future

Post by kode54 »

It is not regressing your system to install 32-bit compatibility libraries for software which cannot be compiled 64-bit. ZSNES, for instance, must be compiled 32-bit because over 50% of it is 32-bit assembly code. The only way to compile this as a 64-bit binary would be to either port all of that assembly to C, or somehow convert it to 64-bit assembly code.
sweener2001
Inmate
Posts: 1751
Joined: Mon Dec 06, 2004 7:47 am
Location: WA

Re: A guideline for the future

Post by sweener2001 »

when you quote, the quote tags help read-ability a lot.
[img]http://i26.photobucket.com/albums/c128/sweener2001/StewieSIGPIC.png[/img]
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Re: A guideline for the future

Post by Gil_Hamilton »

P the retrogamer wrote: To kode54, when I wrote use tech from 2010 and not 1980 I meant the following. The first 64bit processor came out in 2004 and most operating systems are, today, native 64bit environments. I use SUSE, it might not be the best distribution but they do have the right idea. Why use 32bits when 99% of the processors are 64bit processors, perhaps it's time to start writing code for this kind of market?
Why use 64-bit code when there's no need? So they can take up twice the RAM to do the same job?

I AM aware that 8086-80286 code won't work while running in 64-bit mode, but it will be QUITE some time before the next major architecture overhaul starts killing 80386-Pentium4 code.

BTW, the 386 came out in 1985, not 1980. FURTHERMORE, the instruction set has undergone several major revisions since then, and not just in the MMX* extensions. A Pentium4 isn't just a really fast 386.
I do not know exactly what processor ZSNES targets, but I think it's safe to bet that it uses 486 instructions, which makes you off by almost a decade.

For your first two statements...
I'll tryout bsnes even though my computer is one of the last mammoths, only single core but 3200+ from amd and yes it is native 64bit.
So you're complaining about people not exclusively coding for the latest and greatest, but you haven't gone multi-proc yet? We've been trying to get people on THAT bandwagon since the 16-bit days!
I quote "Although, technically, if you have all the compatibility libraries installed, you should be able to build zsnes -m32 without any trouble. I know I had no trouble compiling it on my Fedora desktop. I just needed to install the necessary lib.i686 and lib-devel.i686 packages first." This is my point exactly, why should I be forced to regress my computer in order to use a program.
That's not regressing it. No one's removing any 64-bit functionality, just ADDING the ability to ALSO work properly with 32-bit code.


Also: Windows 2000 was better than XP. And I've had no problems with 7 at all, aside from my shitty 802.11g adapter not having 7 drivers. I've actually been VERY impressed with it. (I made the switch for TRIM support).
Squall_Leonhart wrote:
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
DirectInput represents all bits, not just powers of 2 in an axis.
KHDownloads
dfreer
Lurker
Posts: 139
Joined: Fri May 11, 2007 5:28 am

Re: A guideline for the future

Post by dfreer »

P the retrogamer wrote:I'm a retro gamer, I love NES, SNES and what not. They take me back to the 80's and the 90's, the golden days. Therefore I'm quite glad that some enthusiasts have taken it upon themselves to create such magnificent programs like ZSNES and FCEUX so we all can enjoy the good old games like mega man and Super mario bros. I'm am also a Linux user, since I !!!HATE!!! :evil: Microsoft and its windows crap, and I tried, today, to install the Linux version of ZSNES but came across some small, understating my case, problems. After changing the source, as described by trucmuche04 in his page which can be found by searching for Cannot install ZSENES in Linux, I was stuck because when make is run it ends up saying that i386 is not compatible with x86-64 and I don't really know how to compile for a 32-bit machine unless the machine is a native 32-bit environment. So my guideline for the future is... To everyone in the linux community, if you don't want the hassle wait for 1.60 and instead, for now, use wine and the windows, it make me nauseous just writing it, version of the code. To the developers I just want to say one thing. PLEASE PLEASE PLEASE PLEASE PLEASE rewrite the source and update the technology so its up to date with the year 2010 not 1980 otherwise you are going to loose a growing market. Other than that !!!GREAT!!! emulator

Unless someone knows a sure-fire way to get it working. Hopefully some one will read this and create a manual for installing under Linux in a 64-bit environment.
It would be nice, since you seem to "hate" windows so much, that you would learn how to use your own operating system of choice. Compiling code comes with using linux, along with google-fu. You would probably have come across the millions of threads concerning installing zsnes in a 64-bit enviroment, some of which I wrote myself. If I were a developer of zsnes and read this post I would purposely make my program non-compilable in linux.

ZSNES is one of the fastest emulators out there, mainly because it was written in 32-bit assembly. As suggested, if you wanted something that would compile in a native 64 bit enviroment you should be trying bsnes, oh wait you have a shitty single core processor even though you claim you have updated 2010 technology so you probably can't run bsnes.

As for compiling zsnes with what you currently have, make sure to start with zsnes1.51b. Create a 32-bit chroot and get the needed libraries installed in the chroot, or if that's too hard just pop a 32-bit ubuntu live cd in and compile from that, it's pretty simple. Or use a pre-compiled package and just make sure you have the required 32-bit libraries installed correctly (libao2 contains hard-coded paths, so if you want to use libao you'll need to work around that).

If you wanted a more helpful post, maybe you shouldn't have made your post sound like a frothy mouthed linux luser trying to guilt their way into getting other people to help them by playing the minority card.
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Re: A guideline for the future

Post by grinvader »

dfreer wrote:ZSNES is one of the fastest emulators out there, mainly because it was written by a bunch of insane doods with immense voodoo talent
fixed

seriously guys, design > language


forever
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Re: A guideline for the future

Post by Gil_Hamilton »

Holy crap!

The Athlon64 3200+ was released SEVEN YEARS ago? And mister latest-technology hasn't upgraded ONCE since then?
Squall_Leonhart wrote:
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
DirectInput represents all bits, not just powers of 2 in an axis.
KHDownloads
kode54
Zealot
Posts: 1140
Joined: Wed Jul 28, 2004 3:31 am
Contact:

Re: A guideline for the future

Post by kode54 »

Athlon64 3200+ is what I built my new machine with. In 2004. I booted it a few months ago, it even sort of runs bsnes compatibility core. Full speed in basic games like Super Mario World. Not so much with beefy coprocessors such as SuperFX or SA-1.
P the retrogamer
Rookie
Posts: 11
Joined: Sun Dec 19, 2010 5:54 pm

Re: A guideline for the future

Post by P the retrogamer »

I'm Morley Safer, I'm Steve Kroft...
Sorry for being late, I was playing Illuminati last night so I didn't have time to post a reply.
Thanks for your replies.
Interesting how some subjects can become quite heated which is nice since it stimulates creative thinking.
One last reply to kode54, you wrote that if the code was to be fully compatible with x86-64 one would have to rewrite it in an assembler that supports x86-64 well... Please check out the following page, sorry for the bad choice: http://en.wikipedia.org/wiki/List_of_assemblers and sort according to x86-64
To Gil_Hamilton, you wrote "which makes you off by almost a decade" in reply to the statement 2010 to 1980, I can only say one thing. That was overstating my case it is used for literary effect. Most modern processors work in the following fashion: If a processor has several cores then the processor takes the decision to use more than one core if it believes that it is going to take more than one core to do the job. If I'm not mistaken one also has the option to reserve more than core for the job. Which version of 2000 are you using because I could probably find at least thirty people who would say the opposite but in your defense no two computers are the same, we all have a different processor, motherboard, sound card, graphics card and so on and on your computer win2k might be better, although I doubt it. And in any case, I only wrote that I hate microsoft and windows, in some sense kode54 wanted to know more to which I gave some arguments to why. In reply to your and defreer's replies regarding comments about my computer, unfortunately at the time when I bought my computer, because I had to buy a new one due to the fact that my old one was quite slow, I wasn't able to afford a multi core computer which had just come out, being a student with only a limited amount of cash flow.
To defreer, as you say when one is using something other than windows one has to learn how to do additional tasks in order to get things working, I have done some programming in the past, but should we not strive towards being user friendly and even though some might not have a 64bit processor, I'm not sure if some of the less developed countries have the GNP per capita to be able to afford the more modern computers, but some do. Which brings me to my next point why don't we release a 16bit and a 8bit version, some might not even have 32bit computer, isn't this a little bit heartless of us to not think about the little kiddies in Africa. Are your views that when Intel and AMD have released their latest 256bit 64 core microprocessor we should still write code for a 32bit single core???
You might not believe it but I'm not trying to as you say guilt my way to get people to help me, I'm simply asking for advice so we can create a new post which has all the answers and in the future we can send this to the developers so they can write a definitive manual and perhaps, if luck would have it, rewrite the code in such a way as to make it compatible with every kind of computer. We should all strive towards perfection and in some sense having a software which has worked it's way to become the most widely used, used by all, is perfection. If we have a perfect product wouldn't we all want to share it with everyone? The Linux way...

I have now read the details in your replies and it seems that some of you do not take the trouble to read what everyone else has said and posting comments that have already been taken care of. Please don't do this otherwise we won't progress.
I'm looking for constructive advice, some wouldn't have taken time to reply to gil and defreer but being a sporting character I believe that everyone should have chance to prove themselves so in the future please follow the line above and if you want a fight we can open up a new post which is open to everyone who wants to get their knuckles dirty.

I'm still looking for advice on how to get zsnes going in a native 64bit environment.
P the retrogamer
Rookie
Posts: 11
Joined: Sun Dec 19, 2010 5:54 pm

Re: A guideline for the future

Post by P the retrogamer »

I'm baaaack!
I have turned my computer into a 32bit compatible computer and guess what.....
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libSDL.so when searching for -lSDL
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libSDL.a when searching for -lSDL
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libpng.so when searching for -lpng
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libncurses.so when searching for -lncurses
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libncurses.a when searching for -lncurses
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libGL.so when searching for -lGL
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `endmem.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `init.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `vcache.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `ztime.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/c4proc.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/dsp1proc.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/dsp2proc.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/dsp3proc.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/dsp4proc.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/fxemu2.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/fxemu2b.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/fxemu2c.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/fxtable.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/obc1proc.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/sa1proc.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/sa1regs.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/sfxproc.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/st10proc.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/7110proc.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `chips/st11proc.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `cpu/dma.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `cpu/dsp.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `cpu/dspproc.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `cpu/execute.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `cpu/irq.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `cpu/memory.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `cpu/spc700.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `cpu/stable.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `cpu/table.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `cpu/tablec.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `debugasm.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `gui/gui.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `gui/menu.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/makev16b.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/makev16t.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/makevid.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/mode716.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/mode716b.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/mode716d.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/mode716e.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/mode716t.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/mode7.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/mode7ext.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/mv16tms.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/m716text.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/newg162.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/newgfx.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/newgfx16.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/newgfx2.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/procvid.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/sw_draw.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/2xsaiw.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/hq2x16.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/hq2x32.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/hq3x16.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/hq3x32.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/hq4x16.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/hq4x32.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `video/copyvwin.o' is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `linux/sdlintrf.o' is incompatible with i386:x86-64 output
collect2: ld returned 1 exit status
gmake: *** [main] Error 1
P the retrogamer
Rookie
Posts: 11
Joined: Sun Dec 19, 2010 5:54 pm

Re: A guideline for the future

Post by P the retrogamer »

Now do you see why it's so important to write code which compatible with all systems?

Does anyone have a suggestion on how to fix this despite the fact that every kind of 32bit compatibility file has been installed. This is also why I'm using wine with the windows version.
kode54
Zealot
Posts: 1140
Joined: Wed Jul 28, 2004 3:31 am
Contact:

Re: A guideline for the future

Post by kode54 »

There is another topic on the forum where someone has posted configure scripts for building 1.51b on 64-bit systems. There's also an incomplete effort to translate various assembly source in the project to C, and the latest snapshot of that effort includes configure scripts that build a proper m32 binary on 64-bit systems. (Although the source itself supposedly doesn't even have sound when compiled for Windows, but that doesn't matter much for you, now does it?)
sweener2001
Inmate
Posts: 1751
Joined: Mon Dec 06, 2004 7:47 am
Location: WA

Re: A guideline for the future

Post by sweener2001 »

so, the enter key also helps with read-ability.
[img]http://i26.photobucket.com/albums/c128/sweener2001/StewieSIGPIC.png[/img]
P the retrogamer
Rookie
Posts: 11
Joined: Sun Dec 19, 2010 5:54 pm

Re: A guideline for the future

Post by P the retrogamer »

what's up doc...
To kode54, thanks for your advice I'll check it out. Most constructive.
This is exactly what I want to achieve.
If I'm not mistaken you're referring to page by NACH ZSNES 1.51b Experimental Linux Binaries, unfortunately even though I have libao installed it says that it cannot find libao.so.2 and this is not my fault since it wasn't me who compiled the binaries.
P the retrogamer
Rookie
Posts: 11
Joined: Sun Dec 19, 2010 5:54 pm

Re: A guideline for the future

Post by P the retrogamer »

To sweener2001, if you have seen it all then you should know that there isn't a comma after so, a sentence starts with a capital letter and you missed a question mark. From one know-it-all to another, referring of course to the previous sentence. A wild stab in the dark would be that you are from the colonies. Do you have any constructive tips on how to solve the compatibility issues?
paulguy
Zealot
Posts: 1076
Joined: Sat Jul 02, 2005 2:01 am
Contact:

Re: A guideline for the future

Post by paulguy »

He commented on the fact that your posts are a disorganized wall of text.

They're a bit unpleasant to read as a result. The abrasiveness is also rather uncalled-for. Most people who know what they're doing can get it running just fine in 64 bit, and you seem to completely miss the point about why it can't run natively 64 bit. The assembly language components, of which zsnes consists a large amount of, expect 32 bit pointers (Oversimplification but it makes the point). In 64 bit code, they're 64 bit, so they obviously don't actually fit in the space allocated to store them. Changing this would require a large rewrite, either from 32 bit to 64 bit assembly language or just to C, where the standard types are consistent, for the most part, from 32 bit to 64 bit compilers. There is currently an effort to port it to C, so your arguments are moot.
Maybe these people were born without that part of their brain that lets you try different things to see if they work better. --Retsupurae
P the retrogamer
Rookie
Posts: 11
Joined: Sun Dec 19, 2010 5:54 pm

Re: A guideline for the future

Post by P the retrogamer »

Be wery wery quiet, I'm...
To paulguy, I see your points and I can agree with you. But then a new question arises, what makes my computer so different from yours, to the community as a whole, is it the fact that my system runs opensuse and there seems to be a slight incompatibility between my os and yours or is it the fact that my computer is an oddity, one those unexplainable freaks of nature. I'm not claiming that I'm the super programmer of the universe, I simply believe that being user friendly is nice and I only want to stimulate a specific topic. You have to agree that making changes to the source just to get it working isn't considered a good programming paradigm. I don't think the emulator is bad but if there exists compatibility issues then one has to choose a language which is universal, you mentioned C but you could also choose C++, Java or Delphi and in the process don't think too much about usage of resources because availability will create excess baggage. To give an example, consider Matlab where the windows dialect differs from the Linux dialect. The function randi() is present in Linux but not in windows. So if I were to write code for a computer then I would have write two completely different codes just to be sure it would be able run on that computer.
Regarding sweener2001's comments, unfortunately this is how I write and if you think I'm abrasive then you should try, if you understand Swedish, the forum flashback where if you're suicidal then the members see it as a sport to get you to kill yourself.

Hopefully I wasn't too abrasive this time.
paulguy
Zealot
Posts: 1076
Joined: Sat Jul 02, 2005 2:01 am
Contact:

Re: A guideline for the future

Post by paulguy »

Well, the problem could either be with OpenSuse or it could be you did something wrong.

Zsnes doesn't generally require much specific attention, like modifying source code, to get it to compile on a 64 bit system, you just need to install the 32 bit libraries (Maybe use a modified configure script? Is this in the 1.51b package?) and it should just work. Problems may arise in that your distro might lack the required libraries or they may be compiled or packaged poorly.

Also, if people suggest you make a change in something you do that improves it, you should take it as constructive criticism and learn from it, rather than just claim that's "how I am/do it/write/etc".
Maybe these people were born without that part of their brain that lets you try different things to see if they work better. --Retsupurae
P the retrogamer
Rookie
Posts: 11
Joined: Sun Dec 19, 2010 5:54 pm

Re: A guideline for the future

Post by P the retrogamer »

Up up and...
Hello everybody...
I have solved one major problem and guess what, paulguy has also solved it and he is absolutely right. I didn't see his comment before I noticed the problem. First of all check out ZSNES crash on startup with libao on Linux x86-64 by NACH. Then if you're using opensuse 11.x, probably even 2, 3 and 4, your main supplier of software, which is Novell if I'm not mistaken, will not supply 32bit libraries, I searched the list and the only version of Libao I could find was x86-64. One guess would be that you should find yourself a new OS or go out and buy a 32bit processor. I on the other hand will stay with opensuse and wait for 1.6, the solution of using wine and the windows version is quite good.

It feels like it's time for the Dunce cap. Sorry for some of the things, I still believe it's time for a native x86-64 version.

So this is the problem: Your supplier does not deliver the right Libraries.
Solution: Either someone could suggest a place where this could be downloaded, the above guess or wine and windows.
Does anybody else have this problem? Does anybody else have solution?

First problem and first beta solution, eventhough it took some time and some heated arguments before we reached the goal.
kode54
Zealot
Posts: 1140
Joined: Wed Jul 28, 2004 3:31 am
Contact:

Re: A guideline for the future

Post by kode54 »

I can't find much of anything about OpenSuSE and multilib. Just some mailing list posts from 2006.

Why did you pick that particular distribution, anyway? There are many more widely discussed, documented, and supported distributions than OpenSuSE.
badinsults
"Your thread will be crushed."
Posts: 1236
Joined: Wed Jul 28, 2004 1:49 am
Location: Not in Winnipeg
Contact:

Re: A guideline for the future

Post by badinsults »

http://board.zsnes.com/phpBB3/viewtopic ... 18&t=12339

First topic in the FAQ section tells you how to get the zsnes binaries to work on a 64 bit system.


Quite frankly "P the retrogamer", I'm not really happy with your attitude. I suggest you tone it down and actually search the forum before spewing an ignorant wall of text rant. Zsnes works fine in a 64 bit environment, so any problems you are having is due to you doing something wrong. It is true that installation isn't as smooth as it could be, but you also have to consider that when the last version of zsnes came out, 64 bit operating systems were not yet in common use. Part of running a Linux system is to be adept enough to link things together if need be, and the zsnes team is not responsible for your issues. As the disclaimer on the front page of zsnes.com says:
Remember that this is a public beta so don't expect this to run on your machine.
<pagefault> i'd break up with my wife if she said FF8 was awesome
Locked