nesdev.org

hex_usr wrote:bsnes-mcfly v106r06 has been released. It is based on bsnes v106r44, but some bugs in icarus have been fixed in order to allow Tengai Makyou Zero's English translation to work (it won't work in bsnes's public beta).

This release also adds high-level emulation of the Cx4 that will only be activated when using the performance profile. This enables Mega Man X2 and Mega Man X3 to work in the performance profile, and they will run faster because they don't have to emulate the HG51BS169 chip. The accuracy and compatibility profiles will use low-level emulation as usual.

Note that this does not give you an excuse to omit the Cx4 data ROM from the firmware/ directory! I tweaked the HLE's checksum routine to actually take a checksum of the data ROM instead of returning a constant. If you remove the Cx4 data ROM, the game will report an “IMMEDIATE ROM ERROR”, but it will probably still work (not tested) after pressing the A button on the error screen.

If, in the future, I add high-level emulation of the DSP# series chips and the ST010, I will do the same thing. I'll even use the SHA256 hash of the supplied firmware in order to select which DSP is active rather than hardcoding it based on the game's internal header. One bsnes-mercury is already too much, I won't make another.

byuu wrote:○ Accuracy
System Requirements: A super-computer cooled by LN₂.
Maximum accuracy, no matter the cost.
Use this mode for development or research purposes.

auto PPU::Line::renderMode7(PPU::IO::Background& self, uint source) -> void {
  //...

  for(int X : range(256)) {
    int x = !io.mode7.hflip ? X : 255 - X;  //This line is correct. However...
  
    //...

    if(self.aboveEnable && !windowAbove[x]) plotAbove(x, source, mosaicPriority, mosaicColor);  //Lowercase x? This should be uppercase.
    if(self.belowEnable && !windowBelow[x]) plotBelow(x, source, mosaicPriority, mosaicColor);  //Same here.
  }
}

hex_usr wrote:In case anyone does not know what 007 is talking about, you can find the following description on the the Settings window's Profiles tab:

byuu wrote:○ Accuracy
System Requirements: A super-computer cooled by LN₂.
Maximum accuracy, no matter the cost.
Use this mode for development or research purposes.

It was byuu who wrote this description for bsnes v073, not me. It is also in bsnes-classic and bsnes-plus. I could change it, but I wonder if fans of the compatibility and performance profiles wouldn't be disappointed to not have their snark bait anymore?

Wait, that's a terrible reason to keep the description. To give users ammo to use when making fun of the accuracy profile's high system requirements?

Okay, I'll change the description for now. Would “Intel Core i7 or AMD FX processor” be a suitable replacement? My Intel Core i7 860 (Lynnfield, I think) can just barely run Super Mario World at 60 FPS.

================================

byuu, you might be interested to know that I found out what was causing the Fast PPU to not honor the Mode 7 horizontal flip flag:

higan/sfc/ppu-fast/mode7.cpp

Code: Select all

auto PPU::Line::renderMode7(PPU::IO::Background& self, uint source) -> void {
  //...

  for(int X : range(256)) {
    int x = !io.mode7.hflip ? X : 255 - X;  //This line is correct. However...
  
    //...

    if(self.aboveEnable && !windowAbove[x]) plotAbove(x, source, mosaicPriority, mosaicColor);  //Lowercase x? This should be uppercase.
    if(self.belowEnable && !windowBelow[x]) plotBelow(x, source, mosaicPriority, mosaicColor);  //Same here.
  }
}

By using the lowercase x on those 2 lines instead of the uppercase X, the PPU effectively performs the horizontal mirroring twice. This is why the SNES Test Program only vertically flips the Super Mario Bros. 3 box art and not also horizontally.

With this bug fix, I think it just might be possible for me to start offering the Fast PPU in bsnes-mcfly.

hex_usr wrote:007, can you not quote my entire post each time? The second half of my post wasn't meant for you, so there was no need to include it in the

block. And it bloats the page, making for longer scrolling.

As for games that won't run 60 FPS on the i5-4570, try Yoshi's Island. That game's title screen is a frequent benchmark for emulator performance, as it is one of the most Super FX-intensive parts of the game. If even that runs at 60 FPS, try Hayazashi Nidan Morita Shougi 2 instead; it is the one game in the entire library that includes an ARM coprocessor for shougi AI, and you will need the ST018 firmware in order to run it.

In addition, icarus's checks for the SPC7110 when determining the sizes of the program ROM, data ROM, and expansion ROM don't work if the board name begins with “EXSPC7110” instead of just “SPC7110”. It just assumes a 7 MiB program ROM and 0 MiB data and expansion ROMs.

This happens even if the game is a game pak (cartridge folder); for some reason, icarus overrides the physical sizes of each ROM by concatenating all 3 ROMs together and recalculating their sizes.

For example, if you have a 2 MiB program ROM and a 4 MiB data ROM, icarus will forcefully reinterpret a 1 MiB program ROM and a 5 MiB data ROM.

By using the lowercase x on those 2 lines instead of the uppercase X, the PPU effectively performs the horizontal mirroring twice.

Sorry. Ill trim quotes. Yoshis island on i5-4570 runs 60 fps title screen or gameplay. Hayazashi Nidan Morita Shougi 2 I loaded it let attract mode run 15 min 60 to 61 fps the whole time.

• Prevents bsnes-classic, and XML manifests with it, from having an advantage over bsnes-mcfly
• Allows the use of gamepaks (cartridge folders) on lower-tier hardware, which Snes9x can't do
• Performance profile can't actually compete in speed with Snes9x and the new emulator, no need to worry about competition on low-end ARMs

• One less competitor for byuu's upcoming commercial alternative to Snes9x
• Less work when porting newer higan/bsnes versions

However, Snes9x has absolutely no support for cartridge folders or manifests whatsoever

Without manifest support, every time someone makes a new memory map not yet supported in Snes9x, Snes9x needs to be manually changed in order to support it, like what was done with Tengai Makyou Zero's English translation.

I just know that AWJ and Revenant will take full advantage of it to promote the continued existence of XML manifests.

Does anyone have any thoughts to contribute?

hex_usr wrote:
Reasons why bsnes-mcfly should keep the performance profile:

• Prevents bsnes-classic, and XML manifests with it, from having an advantage over bsnes-mcfly
• Allows the use of gamepaks (cartridge folders) on lower-tier hardware, which Snes9x can't do
• Performance profile can't actually compete in speed with Snes9x and the new emulator, no need to worry about competition on low-end ARMs

Reasons why bsnes-mcfly should remove the performance profile:

• One less competitor for byuu's upcoming commercial alternative to Snes9x
• Less work when porting newer higan/bsnes versions

Does anyone have any thoughts to contribute?

007 wrote:bsnes-classic and bsnes-plus are usually offered in accuracy and compatibly mode they already dont offer performance so that is irrelevant.

007 wrote:As for competing with the new bsnes.

• Accuracy
• Compatibility: OpenMP
• Compatibility: Legacy
• Performance

I just hope that the new bsnes from byuu will still exist for windows when he goes commercial. it looks very promising.