fceultra-discuss — General discussion for FCE Ultra users and developers.

[Fceultra-discuss] platform unification?

[Raymond J. <she...@gm...>]

Any chance a future version of FCEUX could unify the codebase across
platforms?

I am a bit frustrated that the windows and linux versions, for examples,
have completely different menus.

Also, minor suggestion:  be able to input game genie codes as raw cheats
instead of translating them first.

[Fceultra-discuss] Support for NROM/CPROM/CNROM-368

[Mark S. <ham...@ym...>]

http://wiki.nesdev.com/w/index.php/NROM-368


Can someone support this extention of Bankswitchless PRG-ROM in FCEUX by the next version?

I'd appreciate it!

-Hamtaro126

[Fceultra-discuss] HSBC Bank: Stop the eviction of horse farm therapy center for autistic children

[Robert S. <ma...@ch...>]

Hey,

I just signed the petition "HSBC Bank: Stop the eviction of horse farm therapy center for autistic children" and wanted to see if you could help by adding your name.

Our goal is to reach 150,000 signatures and we need more support. You can read more and sign the petition here:

https://www.change.org/petitions/hsbc-bank-stop-the-eviction-of-horse-farm-therapy-center-for-autistic-children?share_id=aWjZxAxeDy&utm_source=share_petition&utm_medium=email

Thanks!
Robert


You're receiving this message because Robert Stivers sent you an email through Change.org's petition sharing tool. If you believe you have received this message in error, respond directly to Robert Stivers at dar...@gm....


216 West 104th Street | Suite #130 |  New York, NY | 10025

Re: [Fceultra-discuss] FCEUX and Debian

[Lukas S. <lts...@gm...>]

On Tue, Jun 26, 2012 at 6:17 PM, Alexander Toresson <
ale...@gm...> wrote:

> On Wed, Jun 27, 2012 at 12:05 AM, Lukas Sabota <lts...@gm...>
> wrote:
> >
> >
> > On Tue, Jun 26, 2012 at 5:13 PM, Alexander Toresson
> > <ale...@gm...> wrote:
> >>
> >> On Tue, Jun 26, 2012 at 8:09 PM, Lukas Sabota <lts...@gm...>
> >> wrote:
> >> > There were a few other minor issues that he mentioned in which he
> >> > submitted
> >> > patches that were incorporated in mainline fceux.
> >> >
> >> > I hope this helps! Let me know if there is anything else I can do to
> >> > help.
> >>
> >> Hmm, one more thing. These minor issues that Joe mentioned, do you
> >> know whether they were incorporated into mainline fceux before or
> >> after 2.1.5?
> >>
> >> // Alexander
> >
> >
> > Hey Alexander,
> >
> > Honestly, I'm not quite sure.  Joe mentioned that he would file bugs in
> the
> > tracker and he was corresponding with me before the 2.1.5 release.  I
> would
> > assume that most of his changes have gotten into 2.1.5, but its
> difficult to
> > confirm especially since sourceforge oh so kindly never migrated our old
> > bugs when they performed a software stack upgrade.
> >
> > PS: I've been missing out on fceultra-discuss a lot.  Gmail likes to hide
> > the reply to all button
> >
> > Regards,
> > Lukas
> >
>
> Ok, thank you for your help, I think this has substantially improved
> my chances to get the package sponsored :)
>
> // Alexander
>

No problem!  Feel free to let us know if you have any other questions or
concerns about anything!

Thanks again for your efforts :)

Best Regards,
Lukas Sabota
sf: prg318

Re: [Fceultra-discuss] FCEUX and Debian

[Alexander T. <ale...@gm...>]

On Wed, Jun 27, 2012 at 12:05 AM, Lukas Sabota <lts...@gm...> wrote:
>
>
> On Tue, Jun 26, 2012 at 5:13 PM, Alexander Toresson
> <ale...@gm...> wrote:
>>
>> On Tue, Jun 26, 2012 at 8:09 PM, Lukas Sabota <lts...@gm...>
>> wrote:
>> > There were a few other minor issues that he mentioned in which he
>> > submitted
>> > patches that were incorporated in mainline fceux.
>> >
>> > I hope this helps! Let me know if there is anything else I can do to
>> > help.
>>
>> Hmm, one more thing. These minor issues that Joe mentioned, do you
>> know whether they were incorporated into mainline fceux before or
>> after 2.1.5?
>>
>> // Alexander
>
>
> Hey Alexander,
>
> Honestly, I'm not quite sure.  Joe mentioned that he would file bugs in the
> tracker and he was corresponding with me before the 2.1.5 release.  I would
> assume that most of his changes have gotten into 2.1.5, but its difficult to
> confirm especially since sourceforge oh so kindly never migrated our old
> bugs when they performed a software stack upgrade.
>
> PS: I've been missing out on fceultra-discuss a lot.  Gmail likes to hide
> the reply to all button
>
> Regards,
> Lukas
>

Ok, thank you for your help, I think this has substantially improved
my chances to get the package sponsored :)

// Alexander

Re: [Fceultra-discuss] FCEUX and Debian

[Lukas S. <lts...@gm...>]

On Tue, Jun 26, 2012 at 5:13 PM, Alexander Toresson <
ale...@gm...> wrote:

> On Tue, Jun 26, 2012 at 8:09 PM, Lukas Sabota <lts...@gm...>
> wrote:
> > There were a few other minor issues that he mentioned in which he
> submitted
> > patches that were incorporated in mainline fceux.
> >
> > I hope this helps! Let me know if there is anything else I can do to
> help.
>
> Hmm, one more thing. These minor issues that Joe mentioned, do you
> know whether they were incorporated into mainline fceux before or
> after 2.1.5?
>
> // Alexander
>

Hey Alexander,

Honestly, I'm not quite sure.  Joe mentioned that he would file bugs in the
tracker and he was corresponding with me before the 2.1.5 release.  I would
assume that most of his changes have gotten into 2.1.5, but its difficult
to confirm especially since sourceforge oh so kindly never migrated our old
bugs when they performed a software stack upgrade.

PS: I've been missing out on fceultra-discuss a lot.  Gmail likes to hide
the reply to all button

Regards,
Lukas

Re: [Fceultra-discuss] FCEUX and Debian

[Alexander T. <ale...@gm...>]

On Tue, Jun 26, 2012 at 9:27 PM, Alexander Toresson
<ale...@gm...> wrote:
> On Tue, Jun 26, 2012 at 8:46 PM, Lukas Sabota <lts...@gm...> wrote:
>>
>>
>> On Tue, Jun 26, 2012 at 2:40 PM, Alexander Toresson
>> <ale...@gm...> wrote:
>>>
>>> On Tue, Jun 26, 2012 at 8:09 PM, Lukas Sabota <lts...@gm...>
>>> wrote:
>>> > On Tue, Jun 26, 2012 at 1:44 PM, Alexander Toresson
>>> > <ale...@gm...> wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> As you may know, I've been trying to get FCEUX into Debian for a
>>> >> while. Joe Nahmias, the maintainer of FCEU in Debian, has filed an ITP
>>> >> (Intent To Package) for FCEUX, in February 2011:
>>> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612245 .
>>> >> I have been trying to get FCEUX into Debian and been in contact with
>>> >> Joe since 2009, as until recently I was aiming to make FCEUX an
>>> >> automatic upgrade from FCEU, and then it was logical to go through Joe
>>> >> and the already existing FCEU package, and I didn't file any ITP.
>>> >> When I learned that he had filed one, I contacted him and asked him if
>>> >> he still wanted to package FCEUX, as 1.5 years had gone with no
>>> >> updates to the ITP. His response was: "Yes, I have had discussions
>>> >> with one of the upstream authors about some changes that needed to
>>> >> happen in order to make that possible.". I replied, asking what these
>>> >> changes were, but I've received no reply from him, and now it's been
>>> >> 10 days. I'm not aware of any issues myself, but having an established
>>> >> Debian developer state that there are issues probably makes it quite
>>> >> harder for me to find a "sponsor" (a sponsor is a debian developer
>>> >> that uploads the package for you, I need one as I'm not a debian
>>> >> developer myself). I've searched the mailing list archives, but
>>> >> haven't found anything, so this discussion has probably been off-list.
>>> >>
>>> >> So, what I would like to ask you is: has Joe Nahmias been in contact
>>> >> with anyone of you regarding packaging FCEUX for Debian, and what did
>>> >> you discuss?
>>> >>
>>> >> Sorry for the wall of text. A good TL;DR is the last paragraph.
>>> >>
>>> >> // Alexander
>>> >
>>> >
>>> > Hey Alex,
>>> >
>>> > I spoke to Joe off-mailing list regarding some of his concerns.  His two
>>> > primary concerns were:
>>>
>>> Hello, and thank you yet again for the swift reply!
>>>
>>> >  a) Static compilation of lua 5.1.  In the past, the SConstruct file
>>> > statically linked lua5.1 to the fceux binary.  The scons build system
>>> > now
>>> > allows for dynamic linking of lua5.1, so this should not be an issue.
>>>
>>> Hmm. I hadn't noticed this, but I really should've had. This is
>>> actually quite serious, and I'll have to patch 2.1.5 to link
>>> dynamically to lua 5.1. Thank you for bringing this to my attention!
>>
>>
>> No problem!  We statically compile lua5.1 by default in order to keep full
>> compatibility with our lua scripts regardless of what version of lua is
>> installed.  However, I completely understand Debian's position on
>> dynamically linking all libraries so if you need any help getting fceux to
>> dynamically link with lua5.1, let me know.
>
> Unfortunately, I had some problem doing this. The code failed while
> compiling lua-engine.cpp, as lstate.h isn't included in the standard
> -dev packages included with distros. I took a look at why this was
> needed, and found something curious. lua-engine.cpp:11158-1162
> (2.1.5):
>
> 1158                         // since the scriptdata can be very
> expensive to load
> 1159                         // (e.g. the registered save function
> returned some huge tables)
> 1160                         // check the number of parameters the
> registered load function expects
> 1161                         // and don't bother loading the
> parameters it wouldn't receive anyway
> 1162                         int numParamsExpected = (L->top -
> 1)->value.gc->cl.l.p->numparams; // NOTE: if this line crashes, that
> means your Lua headers are out of sync with your Lua lib
>
> As the comment on the last line says, this will only work when the Lua
> headers are in sync with the Lua lib, and if I choose to use the
> lstate.h included with FCEUX this is exactly what I cannot guarantee.
> Neither is it possible for me to use the lstate.h included in the
> source package of Lua 5.1 in Debian. I believe I will have to patch
> FCEUX to remove this optimization, but I'm curious, how big is the
> performance hit this may incur when using Lua scripts?
>
> // Alexander

Just FYI, attached you can find the patch for FCEUX that I ended up using.

// Alexander

PS: I was scrolling through the code in src/drivers/win, and found this gem:

/*
 * ALL SYSTEMS GO!
 */
void DoTextHooker()
...

Re: [Fceultra-discuss] FCEUX and Debian

[Lukas S. <lts...@gm...>]

On Tue, Jun 26, 2012 at 3:27 PM, Alexander Toresson <
ale...@gm...> wrote:

> On Tue, Jun 26, 2012 at 8:46 PM, Lukas Sabota <lts...@gm...>
> wrote:
> >
> >
> > On Tue, Jun 26, 2012 at 2:40 PM, Alexander Toresson
> > <ale...@gm...> wrote:
> >>
> >> On Tue, Jun 26, 2012 at 8:09 PM, Lukas Sabota <lts...@gm...>
> >> wrote:
> >> > On Tue, Jun 26, 2012 at 1:44 PM, Alexander Toresson
> >> > <ale...@gm...> wrote:
> >> >>
> >> >> Hello,
> >> >>
> >> >> As you may know, I've been trying to get FCEUX into Debian for a
> >> >> while. Joe Nahmias, the maintainer of FCEU in Debian, has filed an
> ITP
> >> >> (Intent To Package) for FCEUX, in February 2011:
> >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612245 .
> >> >> I have been trying to get FCEUX into Debian and been in contact with
> >> >> Joe since 2009, as until recently I was aiming to make FCEUX an
> >> >> automatic upgrade from FCEU, and then it was logical to go through
> Joe
> >> >> and the already existing FCEU package, and I didn't file any ITP.
> >> >> When I learned that he had filed one, I contacted him and asked him
> if
> >> >> he still wanted to package FCEUX, as 1.5 years had gone with no
> >> >> updates to the ITP. His response was: "Yes, I have had discussions
> >> >> with one of the upstream authors about some changes that needed to
> >> >> happen in order to make that possible.". I replied, asking what these
> >> >> changes were, but I've received no reply from him, and now it's been
> >> >> 10 days. I'm not aware of any issues myself, but having an
> established
> >> >> Debian developer state that there are issues probably makes it quite
> >> >> harder for me to find a "sponsor" (a sponsor is a debian developer
> >> >> that uploads the package for you, I need one as I'm not a debian
> >> >> developer myself). I've searched the mailing list archives, but
> >> >> haven't found anything, so this discussion has probably been
> off-list.
> >> >>
> >> >> So, what I would like to ask you is: has Joe Nahmias been in contact
> >> >> with anyone of you regarding packaging FCEUX for Debian, and what did
> >> >> you discuss?
> >> >>
> >> >> Sorry for the wall of text. A good TL;DR is the last paragraph.
> >> >>
> >> >> // Alexander
> >> >
> >> >
> >> > Hey Alex,
> >> >
> >> > I spoke to Joe off-mailing list regarding some of his concerns.  His
> two
> >> > primary concerns were:
> >>
> >> Hello, and thank you yet again for the swift reply!
> >>
> >> >  a) Static compilation of lua 5.1.  In the past, the SConstruct file
> >> > statically linked lua5.1 to the fceux binary.  The scons build system
> >> > now
> >> > allows for dynamic linking of lua5.1, so this should not be an issue.
> >>
> >> Hmm. I hadn't noticed this, but I really should've had. This is
> >> actually quite serious, and I'll have to patch 2.1.5 to link
> >> dynamically to lua 5.1. Thank you for bringing this to my attention!
> >
> >
> > No problem!  We statically compile lua5.1 by default in order to keep
> full
> > compatibility with our lua scripts regardless of what version of lua is
> > installed.  However, I completely understand Debian's position on
> > dynamically linking all libraries so if you need any help getting fceux
> to
> > dynamically link with lua5.1, let me know.
>
> Unfortunately, I had some problem doing this. The code failed while
> compiling lua-engine.cpp, as lstate.h isn't included in the standard
> -dev packages included with distros. I took a look at why this was
> needed, and found something curious. lua-engine.cpp:11158-1162
> (2.1.5):
>
> 1158                         // since the scriptdata can be very
> expensive to load
> 1159                         // (e.g. the registered save function
> returned some huge tables)
> 1160                         // check the number of parameters the
> registered load function expects
> 1161                         // and don't bother loading the
> parameters it wouldn't receive anyway
> 1162                         int numParamsExpected = (L->top -
> 1)->value.gc->cl.l.p->numparams; // NOTE: if this line crashes, that
> means your Lua headers are out of sync with your Lua lib
>
> As the comment on the last line says, this will only work when the Lua
> headers are in sync with the Lua lib, and if I choose to use the
> lstate.h included with FCEUX this is exactly what I cannot guarantee.
> Neither is it possible for me to use the lstate.h included in the
> source package of Lua 5.1 in Debian. I believe I will have to patch
> FCEUX to remove this optimization, but I'm curious, how big is the
> performance hit this may incur when using Lua scripts?
>
> // Alexander
>

Hello Alexander,

I believe those lines in lua-engine.cpp were written by another developer
to ensure that the lua5.1 tree in fceux was utilized for the lua engine to
ensure script compatibility across operating systems.  However, I
understand the security risk that static linking imposes and feel free to
patch those lines in the Debian build so that lua5.1 is able to be
dynamically linked in.

Regards,
Lukas

[Fceultra-discuss] Fwd: FCEUX and Debian

[Alexander T. <ale...@gm...>]

And here is the reply I made to his latest message (which I trimmed
slightly from irrelevant stuff before sending, thus I couldn't just
forward this mail)-
// Alexander

---------- Forwarded message ----------
From: Alexander Toresson <ale...@gm...>
Date: Tue, Jun 26, 2012 at 9:27 PM
Subject: Re: [Fceultra-discuss] FCEUX and Debian
To: Lukas Sabota <lts...@gm...>


On Tue, Jun 26, 2012 at 8:46 PM, Lukas Sabota <lts...@gm...> wrote:
>
>
> On Tue, Jun 26, 2012 at 2:40 PM, Alexander Toresson
> <ale...@gm...> wrote:
>>
>> On Tue, Jun 26, 2012 at 8:09 PM, Lukas Sabota <lts...@gm...>
>> wrote:
>> > On Tue, Jun 26, 2012 at 1:44 PM, Alexander Toresson
>> > <ale...@gm...> wrote:
>> >>
>> >> Hello,
>> >>
>> >> As you may know, I've been trying to get FCEUX into Debian for a
>> >> while. Joe Nahmias, the maintainer of FCEU in Debian, has filed an ITP
>> >> (Intent To Package) for FCEUX, in February 2011:
>> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612245 .
>> >> I have been trying to get FCEUX into Debian and been in contact with
>> >> Joe since 2009, as until recently I was aiming to make FCEUX an
>> >> automatic upgrade from FCEU, and then it was logical to go through Joe
>> >> and the already existing FCEU package, and I didn't file any ITP.
>> >> When I learned that he had filed one, I contacted him and asked him if
>> >> he still wanted to package FCEUX, as 1.5 years had gone with no
>> >> updates to the ITP. His response was: "Yes, I have had discussions
>> >> with one of the upstream authors about some changes that needed to
>> >> happen in order to make that possible.". I replied, asking what these
>> >> changes were, but I've received no reply from him, and now it's been
>> >> 10 days. I'm not aware of any issues myself, but having an established
>> >> Debian developer state that there are issues probably makes it quite
>> >> harder for me to find a "sponsor" (a sponsor is a debian developer
>> >> that uploads the package for you, I need one as I'm not a debian
>> >> developer myself). I've searched the mailing list archives, but
>> >> haven't found anything, so this discussion has probably been off-list.
>> >>
>> >> So, what I would like to ask you is: has Joe Nahmias been in contact
>> >> with anyone of you regarding packaging FCEUX for Debian, and what did
>> >> you discuss?
>> >>
>> >> Sorry for the wall of text. A good TL;DR is the last paragraph.
>> >>
>> >> // Alexander
>> >
>> >
>> > Hey Alex,
>> >
>> > I spoke to Joe off-mailing list regarding some of his concerns.  His two
>> > primary concerns were:
>>
>> Hello, and thank you yet again for the swift reply!
>>
>> >  a) Static compilation of lua 5.1.  In the past, the SConstruct file
>> > statically linked lua5.1 to the fceux binary.  The scons build system
>> > now
>> > allows for dynamic linking of lua5.1, so this should not be an issue.
>>
>> Hmm. I hadn't noticed this, but I really should've had. This is
>> actually quite serious, and I'll have to patch 2.1.5 to link
>> dynamically to lua 5.1. Thank you for bringing this to my attention!
>
>
> No problem!  We statically compile lua5.1 by default in order to keep full
> compatibility with our lua scripts regardless of what version of lua is
> installed.  However, I completely understand Debian's position on
> dynamically linking all libraries so if you need any help getting fceux to
> dynamically link with lua5.1, let me know.

Unfortunately, I had some problem doing this. The code failed while
compiling lua-engine.cpp, as lstate.h isn't included in the standard
-dev packages included with distros. I took a look at why this was
needed, and found something curious. lua-engine.cpp:11158-1162
(2.1.5):

1158                         // since the scriptdata can be very
expensive to load
1159                         // (e.g. the registered save function
returned some huge tables)
1160                         // check the number of parameters the
registered load function expects
1161                         // and don't bother loading the
parameters it wouldn't receive anyway
1162                         int numParamsExpected = (L->top -
1)->value.gc->cl.l.p->numparams; // NOTE: if this line crashes, that
means your Lua headers are out of sync with your Lua lib

As the comment on the last line says, this will only work when the Lua
headers are in sync with the Lua lib, and if I choose to use the
lstate.h included with FCEUX this is exactly what I cannot guarantee.
Neither is it possible for me to use the lstate.h included in the
source package of Lua 5.1 in Debian. I believe I will have to patch
FCEUX to remove this optimization, but I'm curious, how big is the
performance hit this may incur when using Lua scripts?

// Alexander

[Fceultra-discuss] Fwd: FCEUX and Debian

[Alexander T. <ale...@gm...>]

I discovered that I and Lukas had been having our conversation
off-list by accident, here the conversation is, for anybody who may be
interested.
// Alexander

---------- Forwarded message ----------
From: Alexander Toresson <ale...@gm...>
Date: Tue, Jun 26, 2012 at 8:40 PM
Subject: Re: [Fceultra-discuss] FCEUX and Debian
To: Lukas Sabota <lts...@gm...>


On Tue, Jun 26, 2012 at 8:09 PM, Lukas Sabota <lts...@gm...> wrote:
> On Tue, Jun 26, 2012 at 1:44 PM, Alexander Toresson
> <ale...@gm...> wrote:
>>
>> Hello,
>>
>> As you may know, I've been trying to get FCEUX into Debian for a
>> while. Joe Nahmias, the maintainer of FCEU in Debian, has filed an ITP
>> (Intent To Package) for FCEUX, in February 2011:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612245 .
>> I have been trying to get FCEUX into Debian and been in contact with
>> Joe since 2009, as until recently I was aiming to make FCEUX an
>> automatic upgrade from FCEU, and then it was logical to go through Joe
>> and the already existing FCEU package, and I didn't file any ITP.
>> When I learned that he had filed one, I contacted him and asked him if
>> he still wanted to package FCEUX, as 1.5 years had gone with no
>> updates to the ITP. His response was: "Yes, I have had discussions
>> with one of the upstream authors about some changes that needed to
>> happen in order to make that possible.". I replied, asking what these
>> changes were, but I've received no reply from him, and now it's been
>> 10 days. I'm not aware of any issues myself, but having an established
>> Debian developer state that there are issues probably makes it quite
>> harder for me to find a "sponsor" (a sponsor is a debian developer
>> that uploads the package for you, I need one as I'm not a debian
>> developer myself). I've searched the mailing list archives, but
>> haven't found anything, so this discussion has probably been off-list.
>>
>> So, what I would like to ask you is: has Joe Nahmias been in contact
>> with anyone of you regarding packaging FCEUX for Debian, and what did
>> you discuss?
>>
>> Sorry for the wall of text. A good TL;DR is the last paragraph.
>>
>> // Alexander
>
>
> Hey Alex,
>
> I spoke to Joe off-mailing list regarding some of his concerns.  His two
> primary concerns were:

Hello, and thank you yet again for the swift reply!

>  a) Static compilation of lua 5.1.  In the past, the SConstruct file
> statically linked lua5.1 to the fceux binary.  The scons build system now
> allows for dynamic linking of lua5.1, so this should not be an issue.

Hmm. I hadn't noticed this, but I really should've had. This is
actually quite serious, and I'll have to patch 2.1.5 to link
dynamically to lua 5.1. Thank you for bringing this to my attention!

> b) Redistribution of some directx headers within "src/drivers/win".  These
> directX headers still exist within the full source tree of FCEUX.  I am not
> positive of the legal status of redistributing these files, but Joe
> was wary of the redistribution of these files.  I replied to him and let him
> know that I would be happy to upload an additional tarball of the FCEUX
> source with the directX and all win32 related files omitted (named
> fceux-src-sdl or something similar)

I do already repack the FCEUX tarball to remove
src/drivers/win/directx and vc/, and I do indeed think they're not
legal to distribute, at least for Debian. I don't think there was any
problem with the rest of src/drivers/win, but I'll re-check this. If
it's convenient to keep these files in the source tarball for people
who build FCEUX for windows (even though there probably aren't that
many people), I don't really mind them.
On the other hand, you're currently shipping lots of old cruft in
~attic, lots of built .o object files, .sconf_temp, .sconsign.dblite
and config.log. I don't see any reason to include these, and some of
them could actually cause trouble for people trying to build FCEUX.
They don't really pose any trouble for packaging for Debian, tho.
A trick to make creating release archive files in a way that makes it
more immune to for example having a bad day, and so on, would be to
create a script that automatically sees to that only what you want to
have inside the archive is there.

> There were a few other minor issues that he mentioned in which he submitted
> patches that were incorporated in mainline fceux.

This sounds great!
̈́
> I hope this helps! Let me know if there is anything else I can do to help.
>
> Best Regards,
> Lukas Sabota # prg318

// Alexander

[Fceultra-discuss] FCEUX and Debian

[Alexander T. <ale...@gm...>]

Hello,

As you may know, I've been trying to get FCEUX into Debian for a
while. Joe Nahmias, the maintainer of FCEU in Debian, has filed an ITP
(Intent To Package) for FCEUX, in February 2011:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612245 .
I have been trying to get FCEUX into Debian and been in contact with
Joe since 2009, as until recently I was aiming to make FCEUX an
automatic upgrade from FCEU, and then it was logical to go through Joe
and the already existing FCEU package, and I didn't file any ITP.
When I learned that he had filed one, I contacted him and asked him if
he still wanted to package FCEUX, as 1.5 years had gone with no
updates to the ITP. His response was: "Yes, I have had discussions
with one of the upstream authors about some changes that needed to
happen in order to make that possible.". I replied, asking what these
changes were, but I've received no reply from him, and now it's been
10 days. I'm not aware of any issues myself, but having an established
Debian developer state that there are issues probably makes it quite
harder for me to find a "sponsor" (a sponsor is a debian developer
that uploads the package for you, I need one as I'm not a debian
developer myself). I've searched the mailing list archives, but
haven't found anything, so this discussion has probably been off-list.

So, what I would like to ask you is: has Joe Nahmias been in contact
with anyone of you regarding packaging FCEUX for Debian, and what did
you discuss?

Sorry for the wall of text. A good TL;DR is the last paragraph.

// Alexander

Re: [Fceultra-discuss] Crash with recent nvidia drivers

[Alexander T. <ale...@gm...>]

In any case, it's great news that 2.1.6 is on its way! I've been
slightly worried, as it's more than a year since the last release.

Btw, I've noticed that fceux.com says that 2.1.5 was released 04 June
2010. This should be 02 June 2011, right?

// Alexander

On Sun, Jun 24, 2012 at 5:16 PM, Alexander Toresson
<ale...@gm...> wrote:
> On Sun, Jun 24, 2012 at 4:43 PM, Lukas Sabota <lts...@gm...> wrote:
>> On Sun, Jun 24, 2012 at 8:25 AM, Alexander Toresson
>> <ale...@gm...> wrote:
>>>
>>> Hello Lukas,
>>>
>>> I've managed to devise what may be a workaround for the problem. I
>>> noticed that the original source distribution worked correctly, while
>>> my packaged version crashed. I narrowed it down to that I added
>>> -Wl,--as-needed to the link flags (env.Append(LINKFLAGS=
>>> ['-Wl,--as-needed'])). The reason I add this is that otherwise, the
>>> fceux binary will link with libraries which it doesn't use directly
>>> (but which are used indirectly), like libfontconfig, and that would
>>> require a direct dependency between the fceux package and those
>>> packages.
>>> libGL was one of those libraries that were linked with, but from which
>>> no symbols were imported from. I found this strange, took a look at
>>> sdl-opengl.cpp and noticed that all GL symbols were imported at
>>> run-time. There's no need to import GL symbols at run-time, except for
>>> symbols from extensions, and you usually link against the core GL
>>> symbols at compile-time.
>>> So I modified the code to do that, and magically, the crashes I've
>>> been having disappeared. At the same time, I could remove a lot of
>>> lines from the file in question, which is never bad ;)
>>> I've attached the patch to do this.
>>>
>>> // Alexander
>>
>>
>>  Hey Alexander,
>>
>> Thank you for submitting this patch!  I have applied the patch to the
>> subversion tree (r2539), would you be able to confirm that this resolves the
>> issue for you on Debian?
>>
>> Your contribution is greatly appreciated.  This has been irking me for a
>> while but I have not had the spare time to free up some space and install
>> debian to try to reproduce.  You put the *patches* in "patches welcome".
>>  Thank you for that.
>>
>> Let me know how you make out with r2539!  Your effort in resolving this bug
>> is greatly appreciated!
>>
>> - lukas < prg318>
>
> In the same way it has been irking me, quite a lot. There's many
> potential users who would be affected by it. There's a big chance that
> the bug can be reproduced on other distros too, you could try adding
> "env.Append(LINKFLAGS=['-Wl,--as-needed'])" after the
> "env.Append(CCFLAGS..." line in SConstruct. Could you try this on
> Arch? In fact, the Ubuntu package of fceux didn't use -Wl,--as-needed,
> but after reading
> https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed it
> seems like they enable it by default, for all packages.
>
> And yes, r2539 now works here, with -Wl,--as-needed enabled. The patch
> is probably not that magical; my guess is that under some
> cicumstances, the nvidia drivers don't like when libGL isn't linked to
> a binary at compile-time, but you probably need to do something more
> than this to reproduce it, I can't imagine it would only take loading
> the library at run-time. It would be interesting to pursue this bug
> and get a smaller test-case for it, if/when I have time for it.
> Anyway, linking against the core GL functions at compile-time ensures
> that the binary links against libGL at compile-time, even with
> -Wl,--as-needed enabled, so it avoids this bug.
>
> I have a few more patches in my preliminary debian package, I will
> probably slowly trickle them upstream. We will see when I manage to
> upload the package to debian; I need a so-called sponsor for this. I
> first tried going through the debian maintainer for FCEU, but this
> hasn't proved fruitful, as he seems to be very busy, and usually
> doesn't even reply to your e-mails.
>
> // Alexander

Re: [Fceultra-discuss] Crash with recent nvidia drivers

[Alexander T. <ale...@gm...>]

On Sun, Jun 24, 2012 at 4:43 PM, Lukas Sabota <lts...@gm...> wrote:
> On Sun, Jun 24, 2012 at 8:25 AM, Alexander Toresson
> <ale...@gm...> wrote:
>>
>> Hello Lukas,
>>
>> I've managed to devise what may be a workaround for the problem. I
>> noticed that the original source distribution worked correctly, while
>> my packaged version crashed. I narrowed it down to that I added
>> -Wl,--as-needed to the link flags (env.Append(LINKFLAGS=
>> ['-Wl,--as-needed'])). The reason I add this is that otherwise, the
>> fceux binary will link with libraries which it doesn't use directly
>> (but which are used indirectly), like libfontconfig, and that would
>> require a direct dependency between the fceux package and those
>> packages.
>> libGL was one of those libraries that were linked with, but from which
>> no symbols were imported from. I found this strange, took a look at
>> sdl-opengl.cpp and noticed that all GL symbols were imported at
>> run-time. There's no need to import GL symbols at run-time, except for
>> symbols from extensions, and you usually link against the core GL
>> symbols at compile-time.
>> So I modified the code to do that, and magically, the crashes I've
>> been having disappeared. At the same time, I could remove a lot of
>> lines from the file in question, which is never bad ;)
>> I've attached the patch to do this.
>>
>> // Alexander
>
>
>  Hey Alexander,
>
> Thank you for submitting this patch!  I have applied the patch to the
> subversion tree (r2539), would you be able to confirm that this resolves the
> issue for you on Debian?
>
> Your contribution is greatly appreciated.  This has been irking me for a
> while but I have not had the spare time to free up some space and install
> debian to try to reproduce.  You put the *patches* in "patches welcome".
>  Thank you for that.
>
> Let me know how you make out with r2539!  Your effort in resolving this bug
> is greatly appreciated!
>
> - lukas < prg318>

In the same way it has been irking me, quite a lot. There's many
potential users who would be affected by it. There's a big chance that
the bug can be reproduced on other distros too, you could try adding
"env.Append(LINKFLAGS=['-Wl,--as-needed'])" after the
"env.Append(CCFLAGS..." line in SConstruct. Could you try this on
Arch? In fact, the Ubuntu package of fceux didn't use -Wl,--as-needed,
but after reading
https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed it
seems like they enable it by default, for all packages.

And yes, r2539 now works here, with -Wl,--as-needed enabled. The patch
is probably not that magical; my guess is that under some
cicumstances, the nvidia drivers don't like when libGL isn't linked to
a binary at compile-time, but you probably need to do something more
than this to reproduce it, I can't imagine it would only take loading
the library at run-time. It would be interesting to pursue this bug
and get a smaller test-case for it, if/when I have time for it.
Anyway, linking against the core GL functions at compile-time ensures
that the binary links against libGL at compile-time, even with
-Wl,--as-needed enabled, so it avoids this bug.

I have a few more patches in my preliminary debian package, I will
probably slowly trickle them upstream. We will see when I manage to
upload the package to debian; I need a so-called sponsor for this. I
first tried going through the debian maintainer for FCEU, but this
hasn't proved fruitful, as he seems to be very busy, and usually
doesn't even reply to your e-mails.

// Alexander

Re: [Fceultra-discuss] Crash with recent nvidia drivers

[Alexander T. <ale...@gm...>]

Hello Lukas,

I've managed to devise what may be a workaround for the problem. I
noticed that the original source distribution worked correctly, while
my packaged version crashed. I narrowed it down to that I added
-Wl,--as-needed to the link flags (env.Append(LINKFLAGS=
['-Wl,--as-needed'])). The reason I add this is that otherwise, the
fceux binary will link with libraries which it doesn't use directly
(but which are used indirectly), like libfontconfig, and that would
require a direct dependency between the fceux package and those
packages.
libGL was one of those libraries that were linked with, but from which
no symbols were imported from. I found this strange, took a look at
sdl-opengl.cpp and noticed that all GL symbols were imported at
run-time. There's no need to import GL symbols at run-time, except for
symbols from extensions, and you usually link against the core GL
symbols at compile-time.
So I modified the code to do that, and magically, the crashes I've
been having disappeared. At the same time, I could remove a lot of
lines from the file in question, which is never bad ;)
I've attached the patch to do this.

// Alexander

On Sun, Jun 24, 2012 at 3:36 AM, Lukas Sabota <lts...@gm...> wrote:
>
>>
>> I've been working on packaging FCEUX for Debian. Unfortunately, I've
>> been slowed by a heisenbug. I often get a segmentation fault shortly
>> after loading, less than a minute after starting, when running it
>> outside of gdb, valgrind and strace. With any of these utilities,
>> FCEUX doesn't crash anymore. Also, this was more pronounced on my
>> amd64 desktop than my i386 laptop; the crash occurred always and very
>> quickly after starting FCEUX on the former, while on the latter it
>> might take half a minute for it to crash, or sometimes it would not
>> crash at all.
>> Using ulimit -c unlimited I could produce a core dump that gdb was
>> then able to parse. On my amd64 desktop, the only usable stack frame
>> appears to be at the first instruction (push %ebp, %ebp) of
>> g_thread_proxy in glib, which makes this a not very trustworthy
>> backtrace. On my i386 laptop, there is no usable stack frame at all.
>> I noted that FCEUX ran fine within a chroot, as long as the system's
>> /proc wasn't bound inside the chroot. I noted, by using strace, that
>> the libraries that FCEUX invoked used a few files under /proc. What I
>> wanted was some indication of what libraries were using stuff under
>> /proc, and strace+ helped me do just that, by providing backtraces for
>> every system call.
>> One of the offenders was the nvidia closed source driver's libGL.so. I
>> took a wild guess that this was it, uninstalled it, ran the vesa
>> driver for a short while, and verified that yes, indeed, FCEUX ran
>> perfectly with the vesa driver. Note that you really need to uninstall
>> the glx component of nvidia's closed source driver; their libGL.so
>> will be loaded anyway even if you're using another xorg driver, like
>> vesa or nouveau. I also verified that I could make FCEUX not crash by
>> having the nvidia driver installed, starting Xorg, uninstalling the
>> nvidia glx component so that it won't be used, and then starting
>> FCEUX.
>> This crash has occurred for me with driver versions 295.53, 302.07 and
>> 302.17, and will likely occur for all versions in between.
>> I'm running Debian testing and their packaged version of the nvidia
>> driver; I haven't tried nvidia's official installer yet to verify that
>> that also has the same problem.
>> I will do some more research, and then I might submit this as a bug to
>> nvidia.
>> No other GTK or SDL applications (as far as I've tested) manage to
>> trigger this bug.
>>
>> TL;DR: Recent nvidia drivers cause FCEUX to crash shortly after start.
>> Does this occur to anybody else? Anybody have any input?
>>
>> Regards, Alexander
>
>
>  Hello Alexander,
>
> Firstly, thank you for your detailed report of this issue.  I have heard
> some vague reports of this issue, but have been unable to get a gdb
> backtrace or strace so it has been difficult to diagnose.  I currently have
> a nvidia 520 and a 220 (iirc) to test with and I have been unable to
> reproduce the issue on Arch Linux 64bit.  I have not had a debian/ubuntu
> installation on the machine with the nvidia hardware so I have not been able
> to reproduce.  I installed ubuntu 10.04 in virtualbox (which uses some other
> driver, not the nvidia driver which is what is relevant) and could not
> reproduce the issue.  The nvidia drivers in Arch Linux are essentially the
> stock unpatched drivers from nvidia -- is there any patching involved in the
> nvidia drivers packaged in ubuntu/debian?
>
> I have recently committed a minor change to the build system (r2538) that
> affects the way scons compiles in libGL -- would you be able to test the
> latest subversion version to see if you are still able to reproduce the
> issue?
>
> FYI our subversion server has changed URL due to a sourceforge stack
> upgrade, so for the sake of clarity:
>
>   svn checkout svn://svn.code.sf.net/p/fceultra/code/fceu fceultra-code
>
> I'd really like to see FCEUX inclusion in Debian, and we are also nearing a
> 2.1.6 release.  If I get a chance, I will install wheezy onto my box with
> the nvidia cards and see if I can reproduce the issue.
>
> TLDR: Are the nvidia drivers in debian patched in any way? I can't reproduce
> on Arch Linux 64 (I've been testing fceux with the latest xorg stack
> throughout with latest nvidia etc with no issues with opengl). I'd like to
> see any issues on Debian resolved and if I can reproduce the issue on my own
> hardware I can at least start to diagnose the issue.  Also, could you test
> r2538 please?
>
> Thank you for your proactive feedback!  I'd really like to get these issues
> ironed out.
>
> Best Regards,
> Lukas Sabota
> sf: punkrockguy318 (prg318)
>

Re: [Fceultra-discuss] Crash with recent nvidia drivers

[Lukas S. <lts...@gm...>]

> I've been working on packaging FCEUX for Debian. Unfortunately, I've
> been slowed by a heisenbug. I often get a segmentation fault shortly
> after loading, less than a minute after starting, when running it
> outside of gdb, valgrind and strace. With any of these utilities,
> FCEUX doesn't crash anymore. Also, this was more pronounced on my
> amd64 desktop than my i386 laptop; the crash occurred always and very
> quickly after starting FCEUX on the former, while on the latter it
> might take half a minute for it to crash, or sometimes it would not
> crash at all.
> Using ulimit -c unlimited I could produce a core dump that gdb was
> then able to parse. On my amd64 desktop, the only usable stack frame
> appears to be at the first instruction (push %ebp, %ebp) of
> g_thread_proxy in glib, which makes this a not very trustworthy
> backtrace. On my i386 laptop, there is no usable stack frame at all.
> I noted that FCEUX ran fine within a chroot, as long as the system's
> /proc wasn't bound inside the chroot. I noted, by using strace, that
> the libraries that FCEUX invoked used a few files under /proc. What I
> wanted was some indication of what libraries were using stuff under
> /proc, and strace+ helped me do just that, by providing backtraces for
> every system call.
> One of the offenders was the nvidia closed source driver's libGL.so. I
> took a wild guess that this was it, uninstalled it, ran the vesa
> driver for a short while, and verified that yes, indeed, FCEUX ran
> perfectly with the vesa driver. Note that you really need to uninstall
> the glx component of nvidia's closed source driver; their libGL.so
> will be loaded anyway even if you're using another xorg driver, like
> vesa or nouveau. I also verified that I could make FCEUX not crash by
> having the nvidia driver installed, starting Xorg, uninstalling the
> nvidia glx component so that it won't be used, and then starting
> FCEUX.
> This crash has occurred for me with driver versions 295.53, 302.07 and
> 302.17, and will likely occur for all versions in between.
> I'm running Debian testing and their packaged version of the nvidia
> driver; I haven't tried nvidia's official installer yet to verify that
> that also has the same problem.
> I will do some more research, and then I might submit this as a bug to
> nvidia.
> No other GTK or SDL applications (as far as I've tested) manage to
> trigger this bug.
>
> TL;DR: Recent nvidia drivers cause FCEUX to crash shortly after start.
> Does this occur to anybody else? Anybody have any input?
>
> Regards, Alexander
>

 Hello Alexander,

Firstly, thank you for your detailed report of this issue.  I have heard
some vague reports of this issue, but have been unable to get a gdb
backtrace or strace so it has been difficult to diagnose.  I currently have
a nvidia 520 and a 220 (iirc) to test with and I have been unable to
reproduce the issue on Arch Linux 64bit.  I have not had a debian/ubuntu
installation on the machine with the nvidia hardware so I have not been
able to reproduce.  I installed ubuntu 10.04 in virtualbox (which uses some
other driver, not the nvidia driver which is what is relevant) and could
not reproduce the issue.  The nvidia drivers in Arch Linux are essentially
the stock unpatched drivers from nvidia -- is there any patching involved
in the nvidia drivers packaged in ubuntu/debian?

I have recently committed a minor change to the build system (r2538) that
affects the way scons compiles in libGL -- would you be able to test the
latest subversion version to see if you are still able to reproduce the
issue?

FYI our subversion server has changed URL due to a sourceforge stack
upgrade, so for the sake of clarity:

  svn checkout svn://svn.code.sf.net/p/fceultra/code/fceu fceultra-code

I'd really like to see FCEUX inclusion in Debian, and we are also nearing a
2.1.6 release.  If I get a chance, I will install wheezy onto my box with
the nvidia cards and see if I can reproduce the issue.

TLDR: Are the nvidia drivers in debian patched in any way? I can't
reproduce on Arch Linux 64 (I've been testing fceux with the latest xorg
stack throughout with latest nvidia etc with no issues with opengl). I'd
like to see any issues on Debian resolved and if I can reproduce the issue
on my own hardware I can at least start to diagnose the issue.  Also, could
you test r2538 please?

Thank you for your proactive feedback!  I'd really like to get these issues
ironed out.

Best Regards,
Lukas Sabota
sf: punkrockguy318 (prg318)

Re: [Fceultra-discuss] Crash with recent nvidia drivers

[Alexander T. <ale...@gm...>]

I found a bug in launchpad, which likely describes the same crash:
https://bugs.launchpad.net/ubuntu/+source/fceux/+bug/881743

On Sat, Jun 23, 2012 at 9:47 PM, Alexander Toresson
<ale...@gm...> wrote:
> I forgot one thing: The desktop has a Geforce GTX 295, while the
> laptop has a Geforce 8400M GS. These cards have similar architectures.
> There is a possibility that newer or older cards won't experience this
> problem
>
> Regards, Alexander
>
> On Sat, Jun 23, 2012 at 9:42 PM, Alexander Toresson
> <ale...@gm...> wrote:
>> Hello all,
>>
>> I've been working on packaging FCEUX for Debian. Unfortunately, I've
>> been slowed by a heisenbug. I often get a segmentation fault shortly
>> after loading, less than a minute after starting, when running it
>> outside of gdb, valgrind and strace. With any of these utilities,
>> FCEUX doesn't crash anymore. Also, this was more pronounced on my
>> amd64 desktop than my i386 laptop; the crash occurred always and very
>> quickly after starting FCEUX on the former, while on the latter it
>> might take half a minute for it to crash, or sometimes it would not
>> crash at all.
>> Using ulimit -c unlimited I could produce a core dump that gdb was
>> then able to parse. On my amd64 desktop, the only usable stack frame
>> appears to be at the first instruction (push %ebp, %ebp) of
>> g_thread_proxy in glib, which makes this a not very trustworthy
>> backtrace. On my i386 laptop, there is no usable stack frame at all.
>> I noted that FCEUX ran fine within a chroot, as long as the system's
>> /proc wasn't bound inside the chroot. I noted, by using strace, that
>> the libraries that FCEUX invoked used a few files under /proc. What I
>> wanted was some indication of what libraries were using stuff under
>> /proc, and strace+ helped me do just that, by providing backtraces for
>> every system call.
>> One of the offenders was the nvidia closed source driver's libGL.so. I
>> took a wild guess that this was it, uninstalled it, ran the vesa
>> driver for a short while, and verified that yes, indeed, FCEUX ran
>> perfectly with the vesa driver. Note that you really need to uninstall
>> the glx component of nvidia's closed source driver; their libGL.so
>> will be loaded anyway even if you're using another xorg driver, like
>> vesa or nouveau. I also verified that I could make FCEUX not crash by
>> having the nvidia driver installed, starting Xorg, uninstalling the
>> nvidia glx component so that it won't be used, and then starting
>> FCEUX.
>> This crash has occurred for me with driver versions 295.53, 302.07 and
>> 302.17, and will likely occur for all versions in between.
>> I'm running Debian testing and their packaged version of the nvidia
>> driver; I haven't tried nvidia's official installer yet to verify that
>> that also has the same problem.
>> I will do some more research, and then I might submit this as a bug to nvidia.
>> No other GTK or SDL applications (as far as I've tested) manage to
>> trigger this bug.
>>
>> TL;DR: Recent nvidia drivers cause FCEUX to crash shortly after start.
>> Does this occur to anybody else? Anybody have any input?
>>
>> Regards, Alexander

Re: [Fceultra-discuss] Crash with recent nvidia drivers

[Alexander T. <ale...@gm...>]

I forgot one thing: The desktop has a Geforce GTX 295, while the
laptop has a Geforce 8400M GS. These cards have similar architectures.
There is a possibility that newer or older cards won't experience this
problem

Regards, Alexander

On Sat, Jun 23, 2012 at 9:42 PM, Alexander Toresson
<ale...@gm...> wrote:
> Hello all,
>
> I've been working on packaging FCEUX for Debian. Unfortunately, I've
> been slowed by a heisenbug. I often get a segmentation fault shortly
> after loading, less than a minute after starting, when running it
> outside of gdb, valgrind and strace. With any of these utilities,
> FCEUX doesn't crash anymore. Also, this was more pronounced on my
> amd64 desktop than my i386 laptop; the crash occurred always and very
> quickly after starting FCEUX on the former, while on the latter it
> might take half a minute for it to crash, or sometimes it would not
> crash at all.
> Using ulimit -c unlimited I could produce a core dump that gdb was
> then able to parse. On my amd64 desktop, the only usable stack frame
> appears to be at the first instruction (push %ebp, %ebp) of
> g_thread_proxy in glib, which makes this a not very trustworthy
> backtrace. On my i386 laptop, there is no usable stack frame at all.
> I noted that FCEUX ran fine within a chroot, as long as the system's
> /proc wasn't bound inside the chroot. I noted, by using strace, that
> the libraries that FCEUX invoked used a few files under /proc. What I
> wanted was some indication of what libraries were using stuff under
> /proc, and strace+ helped me do just that, by providing backtraces for
> every system call.
> One of the offenders was the nvidia closed source driver's libGL.so. I
> took a wild guess that this was it, uninstalled it, ran the vesa
> driver for a short while, and verified that yes, indeed, FCEUX ran
> perfectly with the vesa driver. Note that you really need to uninstall
> the glx component of nvidia's closed source driver; their libGL.so
> will be loaded anyway even if you're using another xorg driver, like
> vesa or nouveau. I also verified that I could make FCEUX not crash by
> having the nvidia driver installed, starting Xorg, uninstalling the
> nvidia glx component so that it won't be used, and then starting
> FCEUX.
> This crash has occurred for me with driver versions 295.53, 302.07 and
> 302.17, and will likely occur for all versions in between.
> I'm running Debian testing and their packaged version of the nvidia
> driver; I haven't tried nvidia's official installer yet to verify that
> that also has the same problem.
> I will do some more research, and then I might submit this as a bug to nvidia.
> No other GTK or SDL applications (as far as I've tested) manage to
> trigger this bug.
>
> TL;DR: Recent nvidia drivers cause FCEUX to crash shortly after start.
> Does this occur to anybody else? Anybody have any input?
>
> Regards, Alexander

[Fceultra-discuss] Crash with recent nvidia drivers

[Alexander T. <ale...@gm...>]

Hello all,

I've been working on packaging FCEUX for Debian. Unfortunately, I've
been slowed by a heisenbug. I often get a segmentation fault shortly
after loading, less than a minute after starting, when running it
outside of gdb, valgrind and strace. With any of these utilities,
FCEUX doesn't crash anymore. Also, this was more pronounced on my
amd64 desktop than my i386 laptop; the crash occurred always and very
quickly after starting FCEUX on the former, while on the latter it
might take half a minute for it to crash, or sometimes it would not
crash at all.
Using ulimit -c unlimited I could produce a core dump that gdb was
then able to parse. On my amd64 desktop, the only usable stack frame
appears to be at the first instruction (push %ebp, %ebp) of
g_thread_proxy in glib, which makes this a not very trustworthy
backtrace. On my i386 laptop, there is no usable stack frame at all.
I noted that FCEUX ran fine within a chroot, as long as the system's
/proc wasn't bound inside the chroot. I noted, by using strace, that
the libraries that FCEUX invoked used a few files under /proc. What I
wanted was some indication of what libraries were using stuff under
/proc, and strace+ helped me do just that, by providing backtraces for
every system call.
One of the offenders was the nvidia closed source driver's libGL.so. I
took a wild guess that this was it, uninstalled it, ran the vesa
driver for a short while, and verified that yes, indeed, FCEUX ran
perfectly with the vesa driver. Note that you really need to uninstall
the glx component of nvidia's closed source driver; their libGL.so
will be loaded anyway even if you're using another xorg driver, like
vesa or nouveau. I also verified that I could make FCEUX not crash by
having the nvidia driver installed, starting Xorg, uninstalling the
nvidia glx component so that it won't be used, and then starting
FCEUX.
This crash has occurred for me with driver versions 295.53, 302.07 and
302.17, and will likely occur for all versions in between.
I'm running Debian testing and their packaged version of the nvidia
driver; I haven't tried nvidia's official installer yet to verify that
that also has the same problem.
I will do some more research, and then I might submit this as a bug to nvidia.
No other GTK or SDL applications (as far as I've tested) manage to
trigger this bug.

TL;DR: Recent nvidia drivers cause FCEUX to crash shortly after start.
Does this occur to anybody else? Anybody have any input?

Regards, Alexander

Re: [Fceultra-discuss] Debug & Sound

[Lukas S. <lts...@gm...>]

Hello,

The debugger, memory viewer, and some of the TASing features are win32
features that have been developed and merged into the FCEUX source tree.
 Unfortunately they were developed on the win32 API and porting them to GTK
is not a priority at the moment (and would also be a very time consuming
process).  If you really want to use these features, you can run the latest
FCEUX windows binaries through WINE or in a Windows guest in a VM.  While I
agree that it would be great to have these available tools on Linux/OSX,
there other issues with the FCEUX build that take precedence over that at
the moment.

There were some sound issues with Ubuntu and FCEUX in the past.  FCEUX
2.1.4 included some bugfixes which fixed the majority of the audio issues,
but I recommend that you use the latest version of FCEUX (2.1.5).  You
might want to peruse this UbuntuForums thread for instructions/tips on
doing so:

http://ubuntuforums.org/showthread.php?t=971455&highlight=fceux

Cheers!

Regards,
Lukas Sabota

On Fri, Jun 1, 2012 at 8:34 PM, Brandon Lockaby <gbr...@gm...> wrote:

> Howdy!
>
> The web tells me fceux has a debugger, memory viewer and some other cool
> features, but I can't find anything about how to enable them, whether in
> the documentation, or in the command line switches listed when you run
> fceux.  I'm using Ubuntu 10.04 LTS, FCEUX 2.1.2.
>
> Also, the sound is bad.  I found your email address on a bug report about
> it :P
>
> Brandon
>

[Fceultra-discuss] [ fceultra-Bugs-3527722 ] Updated source code of Mapper 162

[SourceForge.net <no...@so...>]

Bugs item #3527722, was opened at 2012-05-17 16:13
Message generated for change (Comment added) made by punkrockguy318
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113536&aid=3527722&group_id=13536

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Updated source code of Mapper 162

Initial Comment:
Here's an updated source code of the mapper 162 (taken from VirtuaNESex 20111010). With that new source, FCEUX will be able to run "[ES-1085] Chong Wu Jin Hua Shi (C)".

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

>Comment By: Lukas Sabota (punkrockguy318)
Date: 2012-05-26 09:15

Message:
Hello,

Thank you for your update.  Can you provide any information about this
"updated" source code?  What has been changed?  Any additional information
you can provide would be appreciated.

I also see that you are joining IRC for periods of 5 minutes at a time and
parting -- if you may want to idle in IRC and wait for a developer to
respond

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113536&aid=3527722&group_id=13536

[Fceultra-discuss] [ fceultra-Bugs-3527722 ] Updated source code of Mapper 162

[SourceForge.net <no...@so...>]

Bugs item #3527722, was opened at 2012-05-17 16:13
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113536&aid=3527722&group_id=13536

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Updated source code of Mapper 162

Initial Comment:
Here's an updated source code of the mapper 162 (taken from VirtuaNESex 20111010). With that new source, FCEUX will be able to run "[ES-1085] Chong Wu Jin Hua Shi (C)".

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113536&aid=3527722&group_id=13536

[Fceultra-discuss] [ fceultra-Bugs-3527718 ] "WXN Decrypted" Mapper 176 games don't work properly

[SourceForge.net <no...@so...>]

Bugs item #3527718, was opened at 2012-05-17 16:03
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113536&aid=3527718&group_id=13536

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: "WXN Decrypted" Mapper 176 games don't work properly

Initial Comment:
On FCEUmm, if you run a "WXN Decrypted" ROM that runs on mapper 176, it'll run fine if you press Reset once. But on FCEUX, if you do the same thing, it won't solve the problem and the screen will stay grey. Can you guys please fix it?

PS: I left an updated source code of the mapper (from VirtuaNESex 20111010) so you can compare it with the older one.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113536&aid=3527718&group_id=13536

[Fceultra-discuss] [ fceultra-Bugs-3523150 ] Bug in cheat search menu fo SDL version

[SourceForge.net <no...@so...>]

Bugs item #3523150, was opened at 2012-05-02 18:21
Message generated for change (Comment added) made by punkrockguy318
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113536&aid=3523150&group_id=13536

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: sdl
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Lukas Sabota (punkrockguy318)
Summary: Bug in cheat search menu fo SDL version

Initial Comment:
The "Value decreased" does not work as expected, it returns only addresses with the current value 0.

This seems to happens because the menu in src/drivers/common/cheat.cpp does not correspond to the search filters defined in the function FCEUI_CheatSearchEnd in file src/cheat.cpp.

The following patch fixes the bug and adds the missing search method options in the menu.

--- cheat.cpp   2010-09-03 13:11:45.000000000 -0400
+++ cheat-fixed.cpp     2012-05-02 20:45:35.000000000 -0400
@@ -422,20 +422,42 @@
  }
 }
 
+#define ASK_NONE  0
+#define ASK_V1    1
+#define ASK_V2    2
+
 static void DoSearch(void)
 {
  static int v1=0,v2=0;
  static int method=0;
- char *m[6]={"O==V1 && C==V2","O==V1 && |O-C|==V2","|O-C|==V2","O!=C","Value decreased","Value increased"};
+ char *m[9]={"O==V1 && C==V2",
+             "O==V1 && |O-C|==V2",
+             "|O-C|==V2",
+             "O!=C",
+             "C==V1",
+             "Value increased (O<C)",
+             "Value decreased (O>C)",
+             "Value increased by V2 (|C-O|==V2)",
+             "Value decreased by V2 (|O-C|==V2)"};
+ int av[9]={ASK_V1|ASK_V2,
+            ASK_V1|ASK_V2,
+            ASK_V2,
+            ASK_NONE,
+            ASK_V1,
+            ASK_NONE,
+            ASK_NONE,
+            ASK_V2,
+            ASK_V2};
+
  printf("\nSearch Filter:\n");
 
- method=ShowShortList(m,6,method);
- if(method<=1)
+ method=ShowShortList(m,9,method);
+ if(av[method]&ASK_V1)
  {
   printf("V1 [%03d]: ",v1);
   v1=Get8(v1);
  }
- if(method<=2)
+ if(av[method]&ASK_V2)
  {
   printf("V2 [%03d]: ",v2);
   v2=Get8(v2);


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

>Comment By: Lukas Sabota (punkrockguy318)
Date: 2012-05-17 09:20

Message:
fixed in svn r2514.  thank you for bringing this to our attention!

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

Comment By: Lukas Sabota (punkrockguy318)
Date: 2012-05-17 09:09

Message:
Could you please attach a patch file for this patch?  The tabbing is lost
in the above post so the patch is malformed.

I can reproduce that the menu options are missing but it would great to try
this patch before hacking on it.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113536&aid=3523150&group_id=13536

[Fceultra-discuss] [ fceultra-Bugs-3523150 ] Bug in cheat search menu fo SDL version

[SourceForge.net <no...@so...>]

Bugs item #3523150, was opened at 2012-05-02 18:21
Message generated for change (Comment added) made by punkrockguy318
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113536&aid=3523150&group_id=13536

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: sdl
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Lukas Sabota (punkrockguy318)
Summary: Bug in cheat search menu fo SDL version

Initial Comment:
The "Value decreased" does not work as expected, it returns only addresses with the current value 0.

This seems to happens because the menu in src/drivers/common/cheat.cpp does not correspond to the search filters defined in the function FCEUI_CheatSearchEnd in file src/cheat.cpp.

The following patch fixes the bug and adds the missing search method options in the menu.

--- cheat.cpp   2010-09-03 13:11:45.000000000 -0400
+++ cheat-fixed.cpp     2012-05-02 20:45:35.000000000 -0400
@@ -422,20 +422,42 @@
  }
 }
 
+#define ASK_NONE  0
+#define ASK_V1    1
+#define ASK_V2    2
+
 static void DoSearch(void)
 {
  static int v1=0,v2=0;
  static int method=0;
- char *m[6]={"O==V1 && C==V2","O==V1 && |O-C|==V2","|O-C|==V2","O!=C","Value decreased","Value increased"};
+ char *m[9]={"O==V1 && C==V2",
+             "O==V1 && |O-C|==V2",
+             "|O-C|==V2",
+             "O!=C",
+             "C==V1",
+             "Value increased (O<C)",
+             "Value decreased (O>C)",
+             "Value increased by V2 (|C-O|==V2)",
+             "Value decreased by V2 (|O-C|==V2)"};
+ int av[9]={ASK_V1|ASK_V2,
+            ASK_V1|ASK_V2,
+            ASK_V2,
+            ASK_NONE,
+            ASK_V1,
+            ASK_NONE,
+            ASK_NONE,
+            ASK_V2,
+            ASK_V2};
+
  printf("\nSearch Filter:\n");
 
- method=ShowShortList(m,6,method);
- if(method<=1)
+ method=ShowShortList(m,9,method);
+ if(av[method]&ASK_V1)
  {
   printf("V1 [%03d]: ",v1);
   v1=Get8(v1);
  }
- if(method<=2)
+ if(av[method]&ASK_V2)
  {
   printf("V2 [%03d]: ",v2);
   v2=Get8(v2);


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

>Comment By: Lukas Sabota (punkrockguy318)
Date: 2012-05-17 09:09

Message:
Could you please attach a patch file for this patch?  The tabbing is lost
in the above post so the patch is malformed.

I can reproduce that the menu options are missing but it would great to try
this patch before hacking on it.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113536&aid=3523150&group_id=13536

[Fceultra-discuss] [ fceultra-Bugs-3525600 ] Hiryu no Ken III(Japan) is not working.

[SourceForge.net <no...@so...>]

Bugs item #3525600, was opened at 2012-05-10 12:13
Message generated for change (Tracker Item Submitted) made by deriloko1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113536&aid=3525600&group_id=13536

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Deri Loko (deriloko1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hiryu no Ken III(Japan) is not working.

Initial Comment:
When I open this file, it's not starting up.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113536&aid=3525600&group_id=13536