bsnes-mcfly: The v073 and bsnes-classic killer
Page 1 of 12

Author:  hex_usr [ Sun May 20, 2018 1:15 pm ]
Post subject:  bsnes-mcfly: The v073 and bsnes-classic killer

bsnes-mcfly seeks to port the Qt GUI of bsnes v073 upwards to modern higan/bsnes versions, so that the long list of features in this GUI are usable with the latest SNES emulation improvements, both with traditional ROM files and with higan v107-style gamepaks (cartridge folders). The goal is to get users to migrate away from bsnes v073 and bsnes-classic, so that its ancient cartridge folder format with XML manifests can finally be put to rest permanently.

What bsnes-mcfly does NOT do is compete with bsnes v107. I will not actively encourage users of bsnes v107 to migrate to bsnes-mcfly, because bsnes v107 combines the most important features with a relatively bug-free GUI, and I have no desire to harm bsnes v107 in any way.

Current release version: v106r14b (based on higan/bsnes v106r63)

This version of the Qt GUI has the following features (an ! indicates an evil hack that modifies part of the Super Famicom emulator core):

  • Compatibility with higan/bsnes v106r63, 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 archive support
    • Built-in: Zip, GZip
    • With archive-reader: 7z, BZip2
      • 7z support by Igor Pavlov's LZMA SDK, available in the public domain
      • 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)
  • IPS, UPS, and BPS soft-patching
    • IPS and UPS patches are applied before removing the copier header, and BPS patches are applied after.
  • Movie recording and playback
  • Cheats
      • Can omit the address/data separator, use an equals sign, or use a colon; higan supports the equals sign only.
    • 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)
  • !Enabling/disabling of individual PPU layers and DSP channels (the former only in the Compatibility and Performance profiles, the latter in every profile)
  • 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
  • Performance profile speed hacks (accuracy and compatibility profiles not affected)
    • High-level emulation of the DSP1, DSP2, DSP3, DSP4, ST010, and Cx4, but firmwares are still required
    • SMP and DSP are merged into a single APU class that references blargg's SPC_DSP
    • Mixed opcode/cycle timing for the SMP; slightly faster while still supporting Tales of Phantasia
    • Only the Super Scope and Justifier use cothreading instead of every single peripheral
    • JOY1/JOY2/JOY3/JOY4 registers handled on a controller-by-controller basis

Features missing from bsnes v073:

  • Compressed archives: Z (compress), RAR, JMA
    • All 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

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.

That said, the official bsnes v107 is the preferred option, so if you are satisfied with the feature set of bsnes v107, then use that instead. bsnes-mcfly is only concerned with replacing bsnes v073 and bsnes-classic, not bsnes v107.


Original post: “Is AWJ still in the scene? Regarding bsnes-classic”

Hello everyone. I was highly reluctant to come back to NesDev after a heated dispute between me and some of the forum members here on NesDev last year, but today, I will make a one-time exception.

AWJ made a fork of bsnes v073, which he called “bsnes-classic”. In it, he revived the Qt-based GUI and backported low-level emulation of the uPD96050 coprocessor used by F1 Race of Champions II and Hayazashi Nidan Morita Shougi from bsnes v074. Since then, he has backported a few of higan's emulation accuracy improvements, all to an ancient version of bsnes, all for the sake of a feature-rich GUI based on a bug-plagued toolkit. bsnes-classic was further forked into the debug-oriented bsnes-plus.

I believe that this practice is unsustainable. As higan's accuracy increases, so too does the effort needed to keep track of its changes and backport them. Most importantly, bsnes-classic preserves a badly-aged XML-based manifest format for cartridge folders; today, higan uses a slimmer syntax named “BML” for manifests, and many years of experience have shaped the syntax into what it is today, so that ROM hackers have greater control over their memory maps than they did back in the days of bsnes v073. Unfortunately, the convenience of the Qt GUI means that ROM hackers such as Tom (Far East of Eden: Tengai Makyou Zero) must force themselves to hack the older XML manifest which, given its age, is prone to errors and failure. The situation is not unlike ZSNES, by far the most popular and simultaneously the most bug-filled emulator, whose tremendous userbase holds back progress with translations and ROM hacks that won't work on real SNES hardware.

Therefore, I seek to do the exact opposite: to forwardport the Qt GUI and make it work with higan v106 and later versions. I have documented my efforts on byuu's message board. The current working name for this fork is “bsnes-classic”, exactly the same name as AWJ's fork, and that is not a coincidence.

It cannot be denied that what I am doing is predatory; I am writing a higan fork with exactly the same name as another fork and with the same goals, with the sole exception that it be based on higan v106 instead of bsnes v073 and use the former's BML manifest format both with traditional ROM files (both headered and headerless) and with cartridge folders. Therefore, I believe I owe it to AWJ to inform him of the existence of my fork named “bsnes-classic” so that he can share his opinion on whether I should keep using the name and what he will do with his fork.

And therein lies the reason for my return to NesDev, despite my better judgement: AWJ has been offline from NesDev since October, and neither has he shown any signs of life on GitHub. Even on Freenode's #retroarch channel, hunterk searched and could not find him. If I cannot get in contact with AWJ, then the future of bsnes-classic (my fork, not AWJ's) and the ideals that come with it look bleak.

I hesitate to ask NesDev about this after the way a few of its key members have treated me in the past, but for now, I will steel myself against any flames that come my way. Does anyone here on NesDev know about AWJ's current status within the emulation community as a whole?

Author:  Revenant [ Sun May 20, 2018 3:55 pm ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

I haven't had any correspondence with him in at least as long either, but I can PM you his email address if you want.

Author:  tepples [ Sun May 20, 2018 4:00 pm ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

Thanks for giving us a second chance.

Do you have a different set of initials you can use as a suffix after "bsnes-"? Several years ago, FCE Ultra was getting forked left and right, and there were FCEUD, FCEUXD, FCEU-mm, FCEUXD SP, etc., until the alphabet soup resolved itself into FCEUX.

Author:  hex_usr [ Sun May 20, 2018 5:54 pm ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

I would prefer not to use e-mail if I can help it. Perhaps you could e-mail him on my behalf, Revenant?

Regarding alternative names: I'd prefer to use “bsnes-classic” if I could be assured that it could replace AWJ's work entirely. I already have a local Git repository using the name, documenting all of my changes as I migrated to each successive version after v073. But if all else fails, I could choose to use the name “bsnes-Qt” instead. Another fork by that name exists, but its maintainer is Themaister (of RetroArch fame) who is certainly still active, and it only has a grand total of 3 commits since its creation at the end of 2010.

Author:  koitsu [ Sun May 20, 2018 6:19 pm ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

The questions asked were: 1) is AWJ still in the scene, and 2) how can I reach AWJ. The answers are 1) probably but you'd have to ask him, and 2) I'm not sure (it sounds like you've exhausted your avenues, which means you've done your due diligence in attempting the Right Thing(tm)). One thing I will mention is that sending a PM on nesdev, unless the user has changed their settings otherwise, by default will send an Email to the account holders' Email address with the subject "New private message has arrived". If you haven't tried that, I'd suggest it as a final avenue.

On the subject of project naming conflicts: meanwhile, we have other software that changed its name to avoid name conflicts. Open-source etiquette and netiquette would strongly advocate you not use the name of an existing project (it doesn't matter if it's dead or alive/active), but obviously nothing *requires* you do that. Though I will say, your choice of words ("It cannot be denied that what I am doing is predatory") will certainly not sit well with some folks. But in the end, do whatever you wish.

Author:  Nicole [ Sun May 20, 2018 7:57 pm ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

Maybe higan-classic, since the big differentiating factor is that it's based on higan rather than bsnes?

Alternatively, you could use other words that give the same effect as "classic", like bsnes-vintage, bsnes-throwback, etc.

There's plenty of names that haven't been used yet, so I don't see any benefit to using the same name as bsnes-classic. Rather than replace it, you're more likely to breed unnecessary confusion, not to mention that it just comes off as hostile.

Author:  Boo Berry [ Mon May 21, 2018 3:07 am ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

Nicole wrote:
Maybe higan-classic, since the big differentiating factor is that it's based on higan rather than bsnes?

Considering that bsnes is the name of the SNES core in higan, and this newer version is based on only higan's bsnes core, it seems appropriate. Naming issue aside, it's nice to see the Qt-based GUI running the newest higan v106 SNES core. Also nice to see the Qt5 migration is in progress as well.

Author:  tepples [ Mon May 21, 2018 6:23 am ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

Try this on for size: "bsnes-10x". It alludes to both the project's goal to put the bsnes core from the higan 100-106 series into the old bsnes GUI and the goal of replacing Snes9x.

Author:  koitsu [ Mon May 21, 2018 10:38 am ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

tepples wrote:
Try this on for size: "bsnes-10x". It alludes to both the project's goal to put the bsnes core from the higan 100-106 series into the old bsnes GUI and the goal of replacing Snes9x.

*raised eyebrow* People will read this as "10 times the bsnes" or "bsnes 10 times". Comparatively, higan-classic makes a lot more sense, and is what i'd vote for if this was a poll.

Author:  Revenant [ Mon May 21, 2018 12:42 pm ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

I'm inclined to agree with "higan-classic" as well; it's not already in use and does well enough conveying the "best of both worlds" approach behind the project.

hex_usr: I can email AWJ, but as koitsu pointed out you may want to try directly PMing him here on nesdev first, since that should notify him via email anyway (assuming he provided his address).

Author:  KungFuFurby [ Mon May 21, 2018 2:02 pm ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

Perhaps bsnes-100series will do the trick (going off of the bsnes-10x idea)?

Author:  hex_usr [ Mon May 21, 2018 5:11 pm ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

Well, I sent a PM to AWJ this morning (shortly before 09:00 PDT). As of 17:00 PDT today, he hasn't responded.

The name “higan-classic” misses the point of this fork. I am reviving the Qt GUI that bsnes v073 had, and it will only be compatible with the Super Famicom (including the Super Game Boy). Recall why byuu renamed his emulator to “higan” in the first place: in addition to the Super Famicom, he created emulators for multiple other consoles (Famicom, Game Boy, Game Boy Advance, and more recently the WonderSwan, Mega Drive, Master System, Game Gear, and PC Engine), and the name “bsnes” became increasingly inaccurate. The rename happened at v092.

I don't really like the ideas that play on Snes9x's name. It is not Snes9x that I hope to replace. Snes9x is at least as accurate as bsnes-performance yet has vastly superior speed because it is not held back by inappropriate use of libco.

There might be some merit to using names such as “bsnes-vintage” or “bsnes-legacy”, but I'll wait a little longer for AWJ's opinion before I make a decision.

You guys aren't wrong for calling this tactic hostile, but I think you deserve to know why I'm doing this. Take a look at the XML manifest for the English translation of Far East of Eden: Tengai Makyou Zero:
<?xml version='1.0' encoding='UTF-8'?>
<cartridge region="NTSC">
      <map mode='shadow' size='0x100000' address='00-0f:8000-ffff'/>
      <map mode='shadow' size='0x100000' address='80-bf:8000-ffff'/>
      <map mode='linear' size='0x100000' address='c0-cf:0000-ffff'/>
      <map mode='linear' offset='0x600000' address='40-4f:0000-ffff'/>
      <ram size='0x2000'>
         <map mode='linear' address='00:6000-7fff'/>
         <map mode='linear' address='30:6000-7fff'/>
         <map address='00-3f:4800-483f'/>
         <map address='80-bf:4800-483f'/>
      <mcu offset='0x100000'>
         <map address='d0-ff:0000-ffff' offset='0x100000' size='0x500000'/>
         <map address='50:0000-ffff'/>
         <map address='00-3f:4840-4842'/>
         <map address='80-bf:4840-4842'/>

In the manifest above, it's not immediately obvious where the program and data ROMs end and where the expansion ROM begins, and how all 3 ROMs should be mapped. The method they used to add the expansion ROM to this manifest is a blatant hack. bsnes v073's manifest format was not designed to accommodate this use case.

That Tom and his hacking team had to carefully study this ancient manifest format and come up with this hack, all for the sake of a user interface that died long ago... how else can I describe bsnes v073 other than “the ZSNES of cartridge folders”? No one should ever have to force themselves to write manifests such as the above just for the sake of a few holdouts that don't like the direction higan has taken.

And if my ZSNES comparison is not enough for you, then compare it to Internet Explorer 6, which for years was the dominant web browser (and still is in China), holding back innovations in web design until 2014 when Microsoft finally ended official support for it.

Author:  adam_smasher [ Mon May 21, 2018 5:49 pm ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

How necessary is this now that byuu is reviving bsnes?

Author:  hex_usr [ Mon May 21, 2018 6:09 pm ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

I've been aware of bsnes's revival since the day it was revealed. I'm actually looking forward to its release; bsnes will include a multithreaded PPU that has the potential to be faster than the current compatibility/balanced PPU, yet has the same compatibility. That is to say, it will not support Air Strike Patrol or the 2 Player mode of Uniracers like the accuracy profile does. If and when this is accomplished, I will replace the balanced profile's PPU with the parallel PPU in my fork.

Besides, I am not personally a fan of Qt as a GUI toolkit. More than anything, it is horribly plagued with bugs that have to be worked around, and it is very easy for some bugs to slip into public releases, which was a frequent problem with bsnes versions 040-073. Anyone who favors stability over extra features should use bsnes instead when it comes out.

The reason I persist in continuing the Qt GUI is for its many extra features, such as rewinding, movie recording/playback, screenshots, extra archival formats such as GZip (might support JMA if I can figure out its license compatibility), and obscure filename extensions such as SWC and FIG. All of which will be excluded from bsnes. If I don't do this, then the badly-aged XML manifest format will remain popular long past its expiration date (5 years in the past when v092 introduced BML and separated the SPC7110's program and data ROMs).

Also, I'm not entirely certain of this, but it looks like while my Qt fork will support both standalone ROMs and cartridge folders, bsnes will support standalone ROMs exclusively, though this is unconfirmed.

Author:  byuu [ Tue May 22, 2018 8:52 pm ]
Post subject:  Re: Is AWJ still in the scene? Regarding bsnes-classic

What I am planning to support:
* loading ZIP files
* loading SFC and SMC files
* loading BPS patches (with a load dialog option to not apply them)
* loading copier headered images
* loading coprocessor firmware appended to ROM images or from a separate firmware/ subfolder
* recently played games list
* optional per-path selections for games, patches, save files, cheat codes, and save states
* OpenGL video shaders
* dynamic rate control for smooth video+audio without the need for an adaptive sync monitor
* automatic input mapping for XInput controllers
* a parallel PPU that (hopefully) will clock in somewhere between bsnes-performance and bsnes-balanced
* cheats codes + database of cheats from mightymo

What I may support one day:
* loading gamepaks (game folders)
* loading IPS patches (will have to display a dialog asking if the patch is for a headered or unheadered ROM)
* simple SuperFX overclocking
* state manager
* simple rewind
* BMP image captures (at a fixed 512x448/512x480 resolution)

What I don't plan to support:
* software video filters
* per-layer BG/OAM toggling
* per-channel audio toggling
* movie recording and playback
* PNG screenshot captures (no encoder)
* 7zip, JMA, gzip, bzip2, rar, etc
* multi-ROM solid archives
* PPU sprite limit disable
* PPU hires mode 7
* advanced CPU overclocking (it's too tightly bound to the other components like the PPU)
* real-time rewind
* debugger
* netplay
* TAS functionality
* coprocessor HLE
* controlling the UI entirely from a gamepad (eg a raster-based GUI)
* ZSNES emulation

My goal is to make the easiest to use program possible, and I'll be omitting features that complicate the design. I also see no reason to cede ground on battles we've definitively won (nobody uses FIG/SWC/JMA anymore.) I still want to try and advocate for moving the scene forward instead of staying stagnant forever, but my activism is burning out as I get older. I hope this will be compelling to people who just want to play games, and aren't on Raspberry Pis or cell phones.

I'm sure it won't ever replace the endless forks of bsnes and Snes9X out there.

I guess we'll see what people think once it's released and supports at least all the primary desired features.

Page 1 of 12 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group