Mesen - Linux (preview)

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Mesen - Linux (preview)

Post by tepples »

Today I reinstalled Xubuntu on my laptop for three reasons: upgrade to an SSD, retain support even after Canonical drops i686 in favor of amd64 sometime in 2018, and remove years of cruft accumulated in the transitions from GNOME 2 through Unity to Xfce.

In the process, I found Debian's page about fontconfig, which describes a shell command to list all available monospace fonts:

Code: Select all

fc-list :spacing=mono
lidnariq wrote:- (wishlist) please let me start Mesen with a path to a NES ROM as the first argument?
Seconded. If I adopt Mesen, I need this for my workflow where make run starts the emulator.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - Linux (preview)

Post by Sour »

lidnariq wrote:This is what I see (on the left) with Driar—the code keeps moving the RTS around in RAM, so I assume that's why we end up with this fragmented thing
Ah, I see what you meant now - thought you were talking about the function list. For code in ram, Mesen keeps a cache of what instructions were run, and then invalidates that cache on subsequent writes to RAM, which would result in this if you're constantly altering only portions of it (i.e replacing NOPs with RTS and the like). And unrelated, but I think the green background maybe actually be a bug in this case, will have to check that.


PPU/CPU memory map:
They are not perfectly accurate (i.e the "work ram" segment is hardcoded) and some mappers (which require "lower-level" functionalities in the code) do not play nice with it (MMC5 and N163 are good examples of this). Most common mappers (and the vast majority of supported mappers) do not use these though, and should display accurate info for the 0x8000-0xFFFF CPU banks and the entire PPU memory.

7zip crash: Thanks, this is fixed (I just learned the hard way that wchar_t is not 2-bytes in Linux!)

Loading from command line:
This is already supported - it's how the file associations options work. ("make run" is just an easy way to run it)
e.g from the bin/x64/Release folder:
./Mesen.exe ~/Desktop/DriarNROM\(UE\)2.7z
mono Mesen.exe ~/Desktop/DriarNROM\(UE\)2.7z

Both correctly load up Mesen w/ the ROM.


Edit: About fontconfig - I kinda feel like shipping a small default font (e.g DSM like is the case at the moment) might be a better option? It helps ensure that the controls display as I'd expect (they are all custom drawn controls) so it may reduce bugs. Arguably I could also allow the user to select a font, but that seems like going a bit too far on customizations (and again, adds the possibility of some fonts not working as expected, etc.)

Edit #2: About 32-bit support - do people actually still run Linux on 32-bits environments? At the moment Mesen ships with both 32-bit & 64-bit DLLs bundled for the Windows version since a lot of people still have 32-bit OSes (no thanks to Windows 10 still shipping with a 32-bit version - despite likely not supporting any 32-bit-only processors). I could do the same for Linux, but I was hoping x64 might be good enough for just about everybody.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - Linux (preview)

Post by lidnariq »

Sour wrote:Loading from command line:
This is already supported - it's how the file associations options work. ("make run" is just an easy way to run it)
e.g from the bin/x64/Release folder:
./Mesen.exe ~/Desktop/DriarNROM\(UE\)2.7z
mono Mesen.exe ~/Desktop/DriarNROM\(UE\)2.7z

Both correctly load up Mesen w/ the ROM.
... Ah-hah. It requires an absolute path, relative paths won't work.

Sour wrote:For code in ram, Mesen keeps a cache of what instructions were run, and then invalidates that cache on subsequent writes to RAM, which would result in this if you're constantly altering only portions of it
It's been so long I'd forgotten, but the only thing I'm doing is changing the argument in LDA #imm. And alternating between whether the very first instruction in the unrolled loop (at $04E0) is LDA #imm or RTS ... no moving the RTS around.

Which would still explain what's happening.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - Linux (preview)

Post by Sour »

lidnariq wrote:... Ah-hah. It requires an absolute path, relative paths won't work.
Ah, nice catch. Actually, it does support relative paths, but since Mesen changes the working folder to ~/Mesen at startup, they're paths relative to that location (not very useful). It shouldn't be too hard to fix though.
User avatar
Eugene.S
Posts: 317
Joined: Sat Apr 18, 2009 4:36 am
Location: UTC+3
Contact:

Re: Mesen - Linux (preview)

Post by Eugene.S »

Xubuntu 14.04.5 LTS (x86), lastest -master:

Code: Select all

evgs@VirtualBox:~/Загрузки/Mesen-master$ make -j4
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../7zAlloc.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../7zArcIn.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../7zBuf.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../7zCrc.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../7zCrcOpt.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../7zDec.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../7zFile.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../7zMemBuffer.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../7zStream.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../Bcj2.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../Bra86.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../Bra.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../BraIA64.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../CpuArch.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../Delta.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../Lzma2Dec.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../LzmaDec.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../Ppmd7.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../Ppmd7Dec.c
mkdir -p SevenZip/obj.x64 && cd SevenZip/obj.x64 && clang -fPIC -Wall -O3 -m64 -c  ../Precomp.c
mkdir -p Utilities/obj.x64 && cd Utilities/obj.x64 && clang++ -fPIC -Wall --std=c++14 -O3 -m64 -c  ../ArchiveReader.cpp
mkdir -p Utilities/obj.x64 && cd Utilities/obj.x64 && clang++ -fPIC -Wall --std=c++14 -O3 -m64 -c  ../AutoResetEvent.cpp
mkdir -p Utilities/obj.x64 && cd Utilities/obj.x64 && clang++ -fPIC -Wall --std=c++14 -O3 -m64 -c  ../blip_buf.cpp
error: invalid value 'c++14' in '--std=c++14'
make: *** [Utilities/obj.x64/ArchiveReader.o] Ошибка 1
make: *** Ожидание завершения заданий…
error: invalid value 'c++14' in '--std=c++14'
make: *** [Utilities/obj.x64/AutoResetEvent.o] Ошибка 1
error: invalid value 'c++14' in '--std=c++14'
make: *** [Utilities/obj.x64/blip_buf.o] Ошибка 1
evgs@VirtualBox:~/Загрузки/Mesen-master$ 
[/size]
I tried to replace
GCCOPTIONS=-fPIC -Wall --std=c++14 -O3
to
GCCOPTIONS=-fPIC -Wall --std=c++11 -O3
in makefile and compile continues. But finally it doesn't help:

Code: Select all

mkdir -p Utilities/obj.x64 && cd Utilities/obj.x64 && clang++ -fPIC -Wall --std=c++11 -O3 -m64 -c  ../ArchiveReader.cpp
mkdir -p Utilities/obj.x64 && cd Utilities/obj.x64 && clang++ -fPIC -Wall --std=c++11 -O3 -m64 -c  ../AutoResetEvent.cpp
mkdir -p Utilities/obj.x64 && cd Utilities/obj.x64 && clang++ -fPIC -Wall --std=c++11 -O3 -m64 -c  ../blip_buf.cpp
mkdir -p Utilities/obj.x64 && cd Utilities/obj.x64 && clang++ -fPIC -Wall --std=c++11 -O3 -m64 -c  ../CRC32.cpp
mkdir -p Utilities/obj.x64 && cd Utilities/obj.x64 && clang++ -fPIC -Wall --std=c++11 -O3 -m64 -c  ../FolderUtilities.cpp
mkdir -p Utilities/obj.x64 && cd Utilities/obj.x64 && clang++ -fPIC -Wall --std=c++11 -O3 -m64 -c  ../HexUtilities.cpp
../ArchiveReader.cpp:29:9: error: call to implicitly-deleted copy constructor of 'std::stringstream' (aka 'basic_stringstream<char>')
        return ss;
               ^~
/usr/include//c++/4.8/sstream:502:32: note: copy constructor of 'basic_stringstream<char, std::char_traits<char>, std::allocator<char> >' is implicitly
      deleted because base class 'basic_iostream<char, std::char_traits<char> >' has a deleted copy constructor
    class basic_stringstream : public basic_iostream<_CharT, _Traits>
                               ^
/usr/include//c++/4.8/istream:796:7: note: copy constructor of 'basic_iostream<char, std::char_traits<char> >' is implicitly deleted because base class
      'basic_istream<char, std::char_traits<char> >' has a deleted copy constructor
    : public basic_istream<_CharT, _Traits>,
      ^
/usr/include//c++/4.8/istream:58:27: note: copy constructor of 'basic_istream<char, std::char_traits<char> >' is implicitly deleted because base class
      'basic_ios<char, std::char_traits<char> >' has a deleted copy constructor
    class basic_istream : virtual public basic_ios<_CharT, _Traits>
                          ^
/usr/include//c++/4.8/bits/basic_ios.h:66:23: note: copy constructor of 'basic_ios<char, std::char_traits<char> >' is implicitly deleted because base class
      'std::ios_base' has an inaccessible copy constructor
    class basic_ios : public ios_base
                      ^
1 error generated.
mkdir -p Utilities/obj.x64 && cd Utilities/obj.x64 && clang++ -fPIC -Wall --std=c++11 -O3 -m64 -c  ../IpsPatcher.cpp
make: *** [Utilities/obj.x64/ArchiveReader.o] Ошибка 1
make: *** Ожидание завершения заданий…
../FolderUtilities.cpp:4:10: fatal error: 'experimental/filesystem' file not found
#include <experimental/filesystem>
[/size]
Last edited by Eugene.S on Fri Dec 23, 2016 2:05 am, edited 1 time in total.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - Linux (preview)

Post by lidnariq »

Unfortunately, gcc ≥v5.3 (or whatever corresponding version of clang) is a firm requirement, due to using C++14 constructs.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - Linux (preview)

Post by Sour »

Like lidnariq said, you'll need gcc 5.3+ (not sure about clang's version, but 3.8 works fine for me)
It actually also uses some features planned for C++17 (filesystem api) - I go for standard & cross-platform APIs whenever possible, since this reduces the odds of platform-specific bugs (at the cost of not working on older compilers)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Mesen - Linux (preview)

Post by tepples »

On Xubuntu 14.04, sudo do-release-upgrade should give you Xubuntu 16.04, which has newer versions of GCC and pretty much everything else. For me it gives this:

Code: Select all

gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Post Reply