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.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Is AWJ still in the scene? Regarding bsnes-classic

Post by Near »

It's pointless to debate the game folders thing any longer.

bsnes v107 won't require game folders, and won't import them behind the scenes. It's all done in memory. You can also control the paths for saves, states, cheats, patches, etc. Your games can be SFC or SMC, with or without copier headers, inside ZIP archives or not, with firmware appended or not, pre-patched or not.

If that's what you want, that's why I'm making it. I do sincerely hope you'll like it, but if not, Snes9X is an outstanding emulator these days as well.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Is AWJ still in the scene? Regarding bsnes-classic

Post by calima »

I probably will like it, though I also need a debugger. Nowadays my SNES playing is on an Everdrive and emulators are only for dev, but in any case I appreciate the new direction.
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: Is AWJ still in the scene? Regarding bsnes-classic

Post by hex_usr »

I just made my first release under a new name. For now, I'm using “bsnes-mcfly”, but the name won't become final until higan and bsnes v107 are released.

The release thread is on byuu's message board.

AWJ has made his choice final and will continue pushing for XML manifests and fighting against BML manifests, so I'll have to push ever harder to make my project into something anyone will choose over bsnes v073 or bsnes-classic. If anyone has any reason whatsoever to switch back to bsnes v073 or AWJ's bsnes-classic after trying my emulator, please let me know. I will rectify that situation as soon as I can. Even if I have to convert Olympian Magic into a library so that XML manifests are converted internally to BML. It's either this, or XML manifests continue existing forevermore, just like ZSNES and Internet Explorer 6.

That said, if byuu's upcoming bsnes revival is enough for you, I encourage you to use it instead because of its choice to use the much more stable hiro toolkit instead of the bug's nest that is Qt. It's only people switching back to bsnes v073 or bsnes-classic that I'm worried about.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
syboxez
Posts: 32
Joined: Tue Mar 01, 2016 8:22 pm

Re: Is AWJ still in the scene? Regarding bsnes-classic

Post by syboxez »

byuu wrote:It's pointless to debate the game folders thing any longer.

bsnes v107 won't require game folders, and won't import them behind the scenes. It's all done in memory. You can also control the paths for saves, states, cheats, patches, etc. Your games can be SFC or SMC, with or without copier headers, inside ZIP archives or not, with firmware appended or not, pre-patched or not.

If that's what you want, that's why I'm making it. I do sincerely hope you'll like it, but if not, Snes9X is an outstanding emulator these days as well.
That sounds like exactly what I am looking for, although I have a couple of questions.

From what I heard, you are developing a new multithreaded scanline-based PPU renderer for bsnes. Will it be possible to use the more accurate, slower PPU renderer that is already in higan? And will the new bsnes continue to (optionally) support existing game folders and manifests for those that do like them?
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Is AWJ still in the scene? Regarding bsnes-classic

Post by Near »

Will it be possible to use the more accurate, slower PPU renderer that is already in higan?
Yes, but I'm worried about shipping it pre-compiled. A problem when I had the profiles, was everyone only ever specified the system requirements of the accuracy profile. I don't want people to think of bsnes as (horrifyingly) slow. The idea is to differentiate the two products. bsnes is more than twice as fast as higan currently.
And will the new bsnes continue to (optionally) support existing game folders and manifests for those that do like them?
It doesn't yet support it, but I intend to do so.
User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Is AWJ still in the scene? Regarding bsnes-classic

Post by HihiDanni »

byuu wrote:* advanced CPU overclocking (it's too tightly bound to the other components like the PPU)
How about being able to adjust the memory timings? I'm especially curious about the effect of RAM accesses only taking 6 master cycles.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: Is AWJ still in the scene? Regarding bsnes-classic

Post by hex_usr »

If you want to alter the CPU's timing to permanent FastROM, edit higan/sfc/cpu/memory.cpp and compile from source (for Windows users, I recommend either TDM-GCC or MinGW-w64). That feature wasn't in bsnes v073, and the only reason it was in ZSNES was as a workaround for the many timing issues that plagued the emulator.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: Is AWJ still in the scene? Regarding bsnes-classic

Post by hex_usr »

Hmmm, I think it would be better to announce new releases in as many places as I can instead of only releasing them on byuu's message board. With that said...

bsnes-mcfly v106r05 has been released.

This version of the Qt GUI has the following features:
  • Compatibility with higan v106r34, including v107-style gamepaks (cartridge folders)
    • Low-level emulation of the HG51BS169 (Cx4) and ARM6 (ST018)
    • Newer MSU1 features such as audio resume
  • Concatenated firmware in game ROMs, as well as a firmware/ fallback directory.
    • No cartridge folders are created within the user's home directory. It is all handled in memory.
  • Database lookup of SNES and Super Famicom cartridges. The database is embedded right into the application along with heuristics for games not in it, so icarus is not required.
    • Compressed archives: Zip, GZip, BZip2
    • Support for Zip and GZip available without having to use snesreader
    • BZip2 support by Rob Landley under the zero-clause BSD license
  • Copier extensions: SMC, SWC, FIG, UFO, GD3, GD7, DX2, MGD, MGH, 048, 058, 068, 078, BIN, USA, EUR, JPN, AUS
    • All of these extensions are also available for use with BS Memory and Sufami Turbo slot cartridges.
  • Optional 512-byte copier header
  • WASAPI and ASIO audio drivers
  • Exclusive mode for Direct3D and WASAPI
  • Separate directories for save RAM, save states, and other mutable game files
  • Turbo buttons
  • asciiPad (more advanced turbo switches with Off, Turbo, and Auto settings)
  • Simultaneous up/down and left/right (must be enabled in the settings file)
    • I needed to use a really evil compilation trick to enable this feature without modifying higan directly.
  • IPS, UPS, and BPS soft-patching
    • IPS and UPS patches are applied before removing the FuSoYa header, and BPS patches are applied after.
  • Movie recording and playback
  • Cheats
    • Pro Action Replay (AAAAAA:DD, AAAAAADD, AAAAAA/DD)
      • Can omit the address/data separator or use a colon, when higan mandates the use of an equals sign.
    • Game Genie (GGGG-GGGG)
      • Will remember that you inputted the code in Game Genie format instead of converting it to Pro Action Replay on save and reload.
  • Cheat search (works only on WRAM at 7e-7f:0000-ffff)
  • Software filters
    • 2xSaI, Super 2xSaI, Super Eagle
    • HQ2x, LQ2x, Scale2x
    • Pixellate2x
    • blargg's snes_ntsc (with 15-bit precision instead of 13-bit precision)
    • Phosphor3x (was included in some bsnes v08x versions)
  • OpenGL shaders
    • Curvature and Edge Detection from higan v092
    • HQ2x, Pixellate, Scale2x
    • HDR-TV, Watercolor (these were marked “Archive” in bsnes v083 and not restored when bsnes v085 went back to XML from BML)
    • Sepia (converted from Direct3D)
  • Only 1 copy of nall for the overall project instead of a separate copy each for bsnes, snesfilter, and snesreader
Features missing from bsnes v073:
  • Compressed archives: Z (compress), 7z, RAR, JMA
    • Most of these have restrictive licenses. Need to think carefully on how to implement them...
  • Selecting one of multiple files in a single Zip archive
  • snes_ntsc configuration dialog
    • Because the palette size was increased from 32768 to 524288, changing a setting causes bsnes-mcfly to freeze while it recreates the palette. This dialog had to go.
  • Binding the Pause/Break key to an input
  • Direct3D shaders
    • As consolation, the Sepia shader was converted to OpenGL
I said this before, and I'll say it again: If anyone has any reason whatsoever to switch back to bsnes v073 or bsnes-classic after trying my emulator, please let me know. I will rectify that situation as soon as I can. My goal is to kill XML manifests, and anything that causes bsnes-classic to remain popular is also something that keeps XML manifests alive, so I will take any legal means necessary to stop that from happening.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Is AWJ still in the scene? Regarding bsnes-classic

Post by tepples »

hex_usr wrote:I said this before, and I'll say it again: If anyone has any reason whatsoever to switch back to bsnes v073 or bsnes-classic after trying my emulator, please let me know.

Does this include -plus?
creaothceann
Posts: 610
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Is AWJ still in the scene? Regarding bsnes-classic

Post by creaothceann »

hex_usr wrote:Hmmm, I think it would be better to announce new releases in as many places as I can instead of only releasing them on byuu's message board.
/r/emulation/
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 »

I do plan on beginning to replace bsnes-plus once higan v107 is released. I could start earlier, and years of maintaining a laevateinn fork have taught me that it is doable, but I want to wait until higan and bsnes v107 are released first.

Right now, I want to migrate to the recently-released higan v106r40, which compiles both the accurate and fast profiles into a single executable without a performance penalty and allows automatic selection of profiles when running Air Strike Patrol and Koushien 2. After that, I will try and make it run the English version of Tengai Makyou Zero (whose team put actual effort into hacking up an XML manifest and drove me to create bsnes-mcfly in the first place, as I've said before).

As for the suggestion to post to Reddit, didn't someone post about it already? Is there any danger of my post being removed because of redundancy?
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
creaothceann
Posts: 610
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

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

Post by creaothceann »

hex_usr wrote:Is there any danger of my post being removed because of redundancy?
Well, I don't think so. Especially if it's a status update.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

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

Post by 007 »

nevermind tested on 3 other systems seems unique to my office desk setup.
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

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

Post by 007 »

Could you possibly add the ability to set config full screen resolution?


Helpful on some setups.
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 »

I think there are some fullscreen config options already, aren't there? You will have to use keyboard shortcuts though, especially if you use Direct3D's exclusive mode.

By default, pressing Shift+6 (not the keypad, the horizontal number key) will set either square pixels or 8:7 rectangular pixels* depending on whether you have Correct Aspect Ratio turned on. Either way, this leaves black bars on the left and right sides of the screen. I don't mind the black bars at all, but I heard they really bother a few users, so...

Pressing Shift+7 will completely ignore the console's native pixel aspect ratio and horizontally stretch the emulated screen to fill the entire monitor. I find this horizontal stretching to be really ugly, but it does cover up the black bars if that's what you truly want.

Pressing Shift+8 will chop off parts of the top and bottom to minimize horizontal stretching while still filling the entire screen. Depending on the game, this could chop off important info. In Super Mario World, the HUD is still visible, but a small portion of the top is cut off.

You can also press Shift+1, Shift+2, Shift+3, Shift+4, or Shift+5 to set the resolution to 256×239, 512×478, 768×717, 1024×956, or 1280×1195 respectively. Depending on your monitor, not only will this create black bars on the left and right sides, it also creates them on the top and bottom as well.

*Important note: 8:7 is the pixel aspect ratio of the SNES, or the ratio of a single pixel's width to its height. The overall display aspect ratio is 64:49 when displaying 224 scanlines and 2048:1673 when displaying 239 scanlines. The display aspect ratio of the NES (240 scanlines) is 128:105.

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

As for Mega Man X2 not loading the first time and loading the second time instead (yes, I saw your pre-edit post): I cannot reproduce this bug, and it sounds like the other computers you tried cannot reproduce it either? In the current development version on my computer, I made a slight change to the load/unload program code to cover up a possible source of bugs, which will appear in bsnes-mcfly v106r06. If it does come up again, be sure to check the firmware/ folder and make sure that cx4.data.rom is intact.

However, the preferred form is to concatenate this firmware directly to the game ROM and make a 1,575,936 byte ROM that still works in ZSNES and Snes9x. If you do that, bsnes-mcfly (and bsnes v107) will ignore the firmware/ folder and use the concatenated ROM instead, which is currently the only way to use a custom firmware if one gets created in the future. byuu has been pushing for concatenated firmware for many years now, yet No-Intro has strongly opposed it for fear of not being able to distinguish where the main program ROM ends and where the firmware begins. Something that icarus proves is a piece of cake, no harder than detecting copier headers.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
Post Reply