It is currently Sun Oct 22, 2017 2:13 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Mon Dec 19, 2016 7:51 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
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:
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.


Top
 Profile  
 
PostPosted: Mon Dec 19, 2016 8:21 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
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.


Top
 Profile  
 
PostPosted: Mon Dec 19, 2016 8:36 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6296
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Mon Dec 19, 2016 8:57 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
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.


Top
 Profile  
 
PostPosted: Fri Dec 23, 2016 1:45 am 
Offline
User avatar

Joined: Sat Apr 18, 2009 4:36 am
Posts: 257
Location: Russia
Xubuntu 14.04.5 LTS (x86), lastest -master:

Code:
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$


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:
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>



Last edited by Eugene.S on Fri Dec 23, 2016 2:05 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri Dec 23, 2016 2:04 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6296
Location: Seattle
Unfortunately, gcc ≥v5.3 (or whatever corresponding version of clang) is a firm requirement, due to using C++14 constructs.


Top
 Profile  
 
PostPosted: Fri Dec 23, 2016 6:46 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 285
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)


Top
 Profile  
 
PostPosted: Fri Dec 23, 2016 12:49 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
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:
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group