bsnes-mcfly: The v073 and bsnes-classic killer

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

hex_usr wrote:bsnes-mcfly v106r11 has been released. This version is based on higan/bsnes v106r52... sort of. nall is based on v106r53 and has a new header that has something to do with SIMD. I don't know exactly what it does, but if you have an Intel Core Haswell or later (I have the ancient Lynnfield), and you compile bsnes-mcfly from source (which requires Qt 5 to be in your PATH), it might influence bsnes-mcfly's performance somehow.

This version, to the best of my knowledge, fixes the crash on exit that 007 and I both experienced. Not deconstructing ruby's drivers was indeed the cause of the crash... and then there was another crash on exit. And another one. And another one! My Qt windows weren't deconstructing their widgets (and menus in the case of the presentation window) properly! So I wrote custom deconstructors to handle that properly, and I replaced every Qt slot with a C++11 lambda. Only 1 file in the entire source still requires moc to compile, and it's a template class for the file loader that defines custom events.

I may have missed a window somewhere, but for now, I'm not getting any crashes on exit anymore. Let me know if you still have a crash on exit. If you do, don't delete your settings this time; they might be crucial in reproducing the crash.

And finally, there was an order of operations issue with saving your configuration settings and deconstructing ruby's drivers, so that's been taken care of.

Aside from crash on exit fixes, this version also makes a slight adjustment to the way frame skipping works in the Compatibility and Performance profiles; previously, a bug meant that instead of skipping frames, it was skipping scanlines. The symptom was that when using fast forward in the Compatibility or Performance profile, sometimes only part of the screen would be updated, divided into horizontal bars. It was most noticeable during fades to black. Now, it skips frames like it's supposed to. Note that the Accuracy profile doesn't have frame skip, so it was not affected.
I dont know how to compile this but if you want me to compile on my Haswell and submit/test Im willing to learn.


Thanks for another build.
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

@hex_usr

so tested this. cant make it crash anymore. even switching filters. build feels very stable.

I have one suggestion, the description of compatible core states to switch to accuracy for the few problematic games. however the new bsnes core this is has no known problematic games. maybe reword along the lines to switch to accuracy if you believe you found a incompatible game.
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

007 wrote:I dont know how to compile this but if you want me to compile on my Haswell and submit/test Im willing to learn.
You will need MinGW-w64 and the source code to Qt 5; Visual Studio probably won't work because it has historically been incompatible with the C++14 standard that higan and bsnes use. I use Qt 5.10.1, but bsnes-mcfly has been tested as far back as Qt 5.7.

Once you have extracted both of those, make sure you have the directories “<qt-install-dir>\qtbase” “<qt-install-dir>\qtbase\bin” and “<mingw-install-dir>\bin” in your PATH. If you install MinGW-w64 with an installer, the latter directory should be automatically handled for you.

Then, navigate to where you installed bsnes-mcfly's source code and run cc.bat. I designed cc.bat to run the “pause” command if it detects that compilation failed, so it won't automatically close and prevent you from seeing any important error messages like most batch files do. cc.bat will compile the Accuracy and Compatibility profiles into bsnes\out\bsnes-mcfly.exe, so if you want the Performance profile, you'll have to go into the command prompt and run “mingw32-make profile=performance” from within the bsnes\ directory.
007 wrote:even switching filters
Crashing on switching filters was an unrelated bug, caused by me being overzealous with optimizations and rendering directly into ruby's video buffer instead of using an intermediate buffer. I think I fixed that already in bsnes-mcfly v106r10, didn't I?
007 wrote:I have one suggestion, the description of compatible core states to switch to accuracy for the few problematic games.
The “few problematic games” mentioned in that description refer to Air Strike Patrol, which requires the Accuracy profile's PPU in order to draw a shadow under your plane, and Koushien 2 and Rendering Ranger R2, which both require cycle-based DSP timing (the Compatibility profile uses sample-based timing). Go ahead and try to run those games in the Compatibility profile; you'll find that Air Strike Patrol will slow down the emulator to just barely faster than the Accuracy profile, because bsnes-mcfly looks up the internal ROM header's name (“AIR STRIKE PATROL” or “DESERT FIGHTER” for the NTSC-J region) and automatically activates the Accuracy profile's PPU, though it still uses the Compatibility profile's sample-based DSP timing. Similarly, Koushien 2 and Rendering Ranger R2 will automatically activate the cycle-based DSP timing while still using the OpenMP-based PPU in the Compatibility profile. The speed hit will be pretty minor compared to Air Strike Patrol.

Note that the Performance profile does not automatically activate parts of other profiles like this. If you run Air Strike Patrol in the Performance profile, the plane shadow will be invisible.

I could name those games directly in the description, but would that be legally safe? Could Nintendo or SETA find a reason to sue me for mentioning which games won't work with certain features? I already have a tooltip for the Double VRAM option that mentions that Yoshi's Island will look like a garbled mess with 128 KB VRAM (hover your mouse cursor over the checkbox to see it), and I'm a little iffy on that, too.

EDIT: Corrected the PATH for Qt.

EDIT 2: Whoops, forgot that I disabled automatic profile switching because of a crashing bug.
Last edited by hex_usr on Mon Aug 06, 2018 4:10 am, edited 2 times in total.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

@hex_usr

am going to try and compile now.

I re read the descriptions makes sense to leave as is.

Ill come back on with what I compile. Using i5-4570.
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

having trouble. Will try again.

Ill figure it out.

https://drive.google.com/file/d/1FHLrjy ... sp=sharing
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

Oops, I knew I forgot something. I had hoped that you could just use the precompiled Qt DLLs that I included in the ZIP download, and maybe that's technically true, but you still need to have moc (Qt's meta object compiler) and rcc (Qt's resource compiler) in order to compile bsnes-mcfly. And in order to get those, you'll need to compile Qt yourself.

And the PATH isn't supposed to point to “<qt-install-dir>\qtbase”, it's supposed to point to “<qt-install-dir>\qtbase\bin” instead. Sorry about that.

Did you read the included README.txt by any chance? I included directions for compiling Qt in there. I'll include the relevant section below:

If you wish to compile Qt yourself on Windows, you will need MinGW-w64 SEH.
TDM-GCC has not been updated since 2015 and will not work.

Open qtbase/mkspecs/win32-g++/qmake.conf and change the following properties:

Code: Select all

QMAKE_LINK   = $${CROSS_COMPILE}g++ -static-libgcc -static-libstdc++
QMAKE_LINK_C = $${CROSS_COMPILE}gcc -static-libgcc -static-libstdc++
Navigate to Qt's root directory and run the following command with no line breaks:

Code: Select all

configure -prefix %CD%\qtbase -release -opensource -confirm-license -nomake tests -nomake examples -no-opengl -no-zlib -skip qt3d -skip activeqt -skip qtandroidextras -skip qtcanvas3d -skip qtcharts -skip qtconnectivity -skip qtdatavis3d -skip qtgamepad -skip qtlocation -skip qtmacextras -skip qtnetworkauth -skip qtpurchasing -skip qtserialbus -skip qtspeech -skip qtwebglplugin -skip qtx11extras
Navigate to qtbase/ and run “mingw32-make”. This can take a while. You can optionally add a “-j#” option, where # is the number of simultaneous compilation jobs. The number of CPU cores you have minus 1 is a good number.

When it is done, you will find some DLLs in the directory where you installed Qt's source. Here's where each one needs to be copied:
  • qtbase/lib/Qt5Core.dll → <bsnes-mcfly>/
  • qtbase/lib/Qt5Gui.dll → <bsnes-mcfly>/
  • qtbase/lib/Qt5Widgets.dll → <bsnes-mcfly>/
  • qtbase/plugins/platforms/qwindows.dll → <bsnes-mcfly>/platforms/
  • qtbase/plugins/styles/qwindowsvistastyle.dll → <bsnes-mcfly>/styles/
If you need to recompile Qt, run “mingw32-make distclean -j#” first. (substitute # with the number of simultaneous jobs)
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

hex_usr wrote:Go ahead and try to run those games in the Compatibility profile; you'll find that Air Strike Patrol will slow down the emulator to just barely faster than the Accuracy profile, because bsnes-mcfly looks up the internal ROM header's name (“AIR STRIKE PATROL” or “DESERT FIGHTER” for the NTSC-J region) and automatically activates the Accuracy profile's PPU, though it still uses the Compatibility profile's sample-based DSP timing. Similarly, Koushien 2 and Rendering Ranger R2 will automatically activate the cycle-based DSP timing while still using the OpenMP-based PPU in the Compatibility profile. The speed hit will be pretty minor compared to Air Strike Patrol.
Oops, I forgot... I disabled automatic profile switching because of a crashing bug. When enabled, if you load a game in the Accuracy profile, and then load the same game again in the Compatibility profile without a full restart first, bsnes-mcfly will crash.

This bug affects the official bsnes as well (using the Fast PPU checkbox), and it even affects the latest v106r56 WIP release. I know byuu previously attempted a fix to work around the 1-game lag in calculating the save state size, but I guess it doesn't work as expected.

The PPU and DSP are selected within SuperFamicom::System::load(), and serializeInit() is also called within the same function. But in bsnes, hackCompatibility() is called after emulator->load() has already been called... which means that it doesn't even have the intended effect and will run Air Strike Patrol with no visible shadow.

I had a fix for the save state size's 1-game lag, but I dropped it because I thought byuu's fix would work. This was what I used:

sfc/system/system.cpp

Code: Select all

auto System::load(Emulator::Interface* interface) -> bool {
  //...
  bus.reset();
  if(!cartridge.load()) return false;

  hacks.fastPPU = settings.fastPPU;
  hacks.fastDSP = settings.fastDSP;

  if(!cpu.load(system)) return false;
  if(!smp.load(system)) return false;
  if(!ppu.load(system)) return false;
  if(!dsp.load(system)) return false;
  //...
  serializeInit();
  this->interface = interface;
  return information.loaded = true;
}
I loaded the cartridge first. This was required in order to read the ROM header. Then I set the hack settings, and loaded the PPU and DSP afterwards.

...but even that doesn't fix this crash bug now. And GDB doesn't help, it just says that the crash happened in a Windows DLL.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
angrylion
Posts: 13
Joined: Thu Jul 24, 2008 3:23 pm
Location: Moscow, Russia

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by angrylion »

I would enjoy being able to load things like the DSP-1 tech demo and Bad Apple demo by Ladida from plain .sfc files. If it's not too difficult to implement in bsnes-mcfly, that is.
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

If the ROM header is not properly formatted, bsnes-mcfly won't be able to figure out that a DSP1 is required. The same is true of the official bsnes, and when importing the ROM in icarus for use in higan. You will need to either supply a manifest, or edit the ROM in a hex editor.

If you choose to supply a manifest, place the manifest in the same directory as the ROM and name it the same as the ROM but with the “.bml” extension. Here's the manifest:

Code: Select all

game
  sha256:   42ff54a03c2c8f42daa1d4e342464abde303df4e90dcf17173f36ec01702e887
  label:    DSP1 Prototype
  name:     DSP1 Prototype
  //serial:   SN-10
  region:   NTSC
  revision: 1.0
  //board:    SHVC-2Q5B-03
  board:    NEC-LOROM
    memory
      type: ROM
      size: 0x20000
      content: Program
    memory
      type: ROM
      size: 0x1800
      content: Program
      manufacturer: NEC
      architecture: uPD7725
      identifier: DSP1
    memory
      type: ROM
      size: 0x800
      content: Data
      manufacturer: NEC
      architecture: uPD7725
      identifier: DSP1
    memory
      type: RAM
      size: 0x200
      content: Data
      manufacturer: NEC
      architecture: uPD7725
      identifier: DSP1
      volatile
If you choose the hex editor route, you will need to go to $7FB0, and overwrite the 48 bytes of FF that you find there with the following:

Code: Select all

30 30 44 53 50 31 00 00 00 00 00 00 00 00 00 00
44 53 50 31 20 50 72 6F 74 6F 74 79 70 65 20 20
20 20 20 20 20 20 03 07 00 0E 33 00 12 07 ED F8
Also, I don't think I need to say this, but make sure you have the DSP1 firmware in little endian format. The preferred form is to concatenate the firmware directly to the end of the ROM that uses it, but you can also put it in the firmware/ directory where bsnes-mcfly is installed. Even though the performance profile has high-level emulation of the DSP1, it requires the firmware in order to validate the DSP program. I made it that way in order to not relieve any pressure on No-Intro to bundle the firmwares with the ROMs that use them.

As for Bad Apple, bsnes-mcfly does recognize that the ROM is an ExHiROM, but unfortunately, the Board database that is borrowed from higan does not define a board for ExHiROM without any cartridge RAM (both Tales of Phantasia and Daikaijuu Monogatari II have cartridge RAM), so Bad Apple won't work without a manifest, or unless you edit the header to indicate the presence of cartridge RAM. For the latter, change byte $40FFD8 from 0x00 to 0x05.

You could ask byuu to add an entry to the Boards database for ExHiROM without RAM, but because no commercial game was ever released using it, I doubt he will agree to add it for you.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by creaothceann »

ROM hacks / PD ROMs are exactly what manifest support was created for (ROMs shouldn't have to be edited to make them work in certain emulators).
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

angrylion asked about loading both games as “plain .sfc files”. I just provided an option that would avoid creating manifests, because those are primarily associated with cartridge folders, and I can't assume that angrylion has no opposition to placing a manifest right next to the ROM, even if it technically doesn't need to be in a .sfc folder.

...oh, but Bad Apple works in bsnes v073 without a manifest, doesn't it? Dang, I don't really like the idea, but I did say that I would “take any legal means to replace bsnes v073”, so...

I will create a supplemental boards database in order to fill in the gaps that byuu has left in his boards database. Its first entry will be “EXHIROM” without a “-RAM” suffix, so that Bad Apple will work without the need to edit the ROM or supply a manifest. Unfortunately, there is no way to also support the DSP1 prototype in the same way. Even if the firmware is concatenated, it's either supply a manifest, or edit the ROM. I don't think bsnes v073 supports it manfest-free either (although bsnes v072 and earlier have high-level emulation, bsnes-classic was not forked from those versions), so I shouldn't have to worry about that one, at least.

Annoying reminder: bsnes-mcfly tries to compete with bsnes v073 and bsnes-classic. It does not try to compete with the official bsnes v107. If you are satisfied with bsnes v107, I recommend that you continue to use it so that you don't have to suffer the bug's nest that is Qt.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by Near »

angrylion wrote:I would enjoy being able to load things like the DSP-1 tech demo and Bad Apple demo by Ladida from plain .sfc files. If it's not too difficult to implement in bsnes-mcfly, that is.
Do you really expect us to maintain databases of mappings for every quirky unlicensed game out there?

Frankly, it's severely pushing it that I'm even including one for the Tengai Makyou Zero fan translation and Powerfest '94 / Campus Challenge '92.
ROM hacks / PD ROMs are exactly what manifest support was created for (ROMs shouldn't have to be edited to make them work in certain emulators).
I just really wish we could have created a standard that wouldn't be subject to constant change.

But even if it were set in stone, it's not a standard if only my emulator supports it.
User avatar
FitzRoy
Posts: 144
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by FitzRoy »

byuu wrote:Do you really expect us to maintain databases of mappings for every quirky unlicensed game out there?
How many are there, like 20? The NES is the only system that has a lot of this.

So on one hand, we have a 20-entry unl db. On the other, we have fights and drama and regret and confusion over legacy formats and their tendency to persist, as featured in this thread.
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by creaothceann »

FitzRoy wrote:How many are there, like 20?
I'd guess it's a bit more...
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
User avatar
FitzRoy
Posts: 144
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by FitzRoy »

creaothceann wrote:I guess it's a bit more...
Are we even talking about the same thing? 99.9% of unl games work with heuristics. I thought we were talking about mappings that go outside the boundaries of licensed boards.
Post Reply