bsnes v0.038 released

[FitzRoy]

Hmm, okay how about this?

Brightness / Contrast / Gamma leave "adjust" off, but display the numbers more like they were meant to: eg show %, 100 = "100%", 5 = "5%", etc. 100% = center = no adjustment. We can also modify the centered text to say "Normal" for all of these, if you'd prefer.
Frequency Skew <-???, ... None, ... +???>

Well, if you block extremities from being chosen, it would be 5-95% with 50% in the middle. I was going to suggest percentages, but my knowledge here is lacking on how the intervals for each can be accurately reflected. For example, I was afraid the real range for gamma was 0-infinity. (I always see people choosing subjective ends, 0-4.0, 0-2.0, etc.) Enlighten me here if a percentage scale can accurately reflect each option.

There's also hue, saturation and tone(?) settings ... but if I offer those, I'd rather they be available to all filters and done through the color table. Not too convinced of their usefulness, but it'd help calibrate to YUV / YIQ TV colors definitely.

The only invaluable option in that entire section is overload's gamma curve, everything else about the image can be destroyed in my video driver or monitor settings. If you keep these and add more, I fear my final suggestions won't even have the room to be possible without you adding branches in the selection area.

Lastly, there's signal quality settings. There's some nice quick presets for quality level: RGB, S-video, composite, RF, etc. Might be nicer to offer that as a drop-down rather than a bunch of sliders.

Wouldn't these just be hardware filters like NTSC that simulate the lossy characteristics of certain type of analog output?

Base processor? Obviously an SNES emulator would internally contain the S-CPU, S-SMP, etc.
....
It would certainly be nice if we could separate the cart co-processors from the emulator, it's just not practical like it is with cart mapping.

There's no fundamental difference between a coprocessor and central processor in the scheme of emulation. That the coprocessor happened to be located on what we would physically categorize as the "cartridge" is immaterial. Emulation only concerns itself with operation, when the parts all interact as a whole. Thus there is nothing "dirty" about not having as separate files from the emulator. It's silly, we may as well be talking about a controller format, too.

Cart mapping info ... I think it'd be easier to have a PCB list inside the emulator so that you only have to say "cart A uses SHVC-FOO-BAR", but that creates a rather inflexible emulator that can't handle any cart.

By externalizing the mapping info, we allow for any conceivable mapping.
Nice for things like new beta dumps or ROM hacking when you need more than 48mbits of storage.

You're right - it couldn't support endless hypothetical hardware that never existed. But you're wrong that beta dumps wouldn't be supported. Most beta boards used official prototype boards, not random-ass manufacturer boards with no name that plagued the NES. Remember, with an external db, detection is externalized to a documented board, the equivalent of a documented (dumped) rom. If the beta board was documented, it works.

Still very possible to run those hacks on hardware using devices like the Game Doctors, or through PCB mods ala d4s' fan-made carts. Very nice because supporting new titles doesn't require a new emulator release. Also very nice because I don't have to manually specify 40+ PCB maps inside the emulator directly.

First of all, most hacks used licensed board mappings. But my argument should have convinced you that that's exactly what you should do. The only imaginary mappings that would be practical enough to support (Star Ocean uncompressed upon request for RE efforts) would be so small in number that internal support would be easy and preferable. You'd be crazy to externalize all your code just to allow people to create imaginary 10ft boards with 2ghz GPUs. It's not SNES development to invent endless "what if" extensions 20 years later that are 1000x slower than coding for modern hardware directly. This is a useless feature that is going to make it 100x more annoying for normal people to use an accurate mapper system.

And realistically, no SNES emulator in at least the next ten years will be able to exist without a cart header parsing backup mechanism.

It's obvious that this is a desirable backup method since we lack complete documention. If no board is documented in the xml for the detected checksum, then the backup method is used. It's that simple, and it could be adopted by every user immediately. It requires no additional work or knowledge by the user. I could have a complete draft with all of my current documentation included in a month.

Ask d4s why he writes new games for the SNES, or ROM hackers who make completely new games through old titles (eg Dragoon X Omega). Personally, I like the portability.

They're all using licensed hardware supported by the emulator, they're immaterial to argument. You can develop a game for SHVC-1A3M-11, make an entry in the xml, and it will work. You could even put all your custom entries under a new sheet in the same xml file for better organization and faster carryover.

[Nach]

byuu: Talk to me online when you get a chance, I had a crazy idea for all of this, and can also really make it easy to lock out hard patched ROM images, while at the same time allows anyone to easily make their own hacks (and run them hard patched).

[henke37]

My only comment in this debate is: don't mix up mod_mime with mod_mime_magic. The mime system is the ideal you guys are liking, while the magic guessing of it is what you dislike.
But then, all those that cares should know this already, right?

[Nach]

My only comment in this debate is: don't mix up mod_mime with mod_mime_magic. The mime system is the ideal you guys are liking, while the magic guessing of it is what you dislike.
But then, all those that cares should know this already, right?

Do you ever know what you're talking about?
This was not a discussion about Apache modules. But since you brought it up, mod_mime does a regex on the filename, and mod_mime_magic does a regex on the contents of the file. They're both at the end of the day irrelevant to the actual type of the file, with the filename being certainly more so irrelevant. MIME in itself is a designation for a particular file type, which is just a general idea. There is no actual way of setting the type of a file on your system, making any arbitrary type designation useless. There is no ideal here.

[odditude]

My only comment in this debate is: don't mix up mod_mime with mod_mime_magic. The mime system is the ideal you guys are liking, while the magic guessing of it is what you dislike.
But then, all those that cares should know this already, right?

Do you ever know what you're talking about?
This was not a discussion about Apache modules. But since you brought it up, mod_mime does a regex on the filename, and mod_mime_magic does a regex on the contents of the file. They're both at the end of the day irrelevant to the actual type of the file, with the filename being certainly more so irrelevant. MIME in itself is a designation for a particular file type, which is just a general idea. There is no actual way of setting the type of a file on your system, making any arbitrary type designation useless. There is no ideal here.

as disturbing as it is, i'm defending henke37 here - he was using that as a metaphor for rom definition/detection, not literally. can't say anything about its relevance, though.

[henke37]

Aw, you really shouldn't. Because his points are correct.

[ShadowFX]

I am aware that any changes made to WIP releases are posted here on this forum, but maybe it's an idea to start including those as well on the WIP download page? Redundant maybe, but quite handy as I have it bookmarked and am not already visiting the forum to check upon said changes.

[byuu]

I haven't posted the new WIP, just updating on the status of it.

First, I noticed that Xorg changed the keycodes, at least for Kubuntu 8.10. belegdol, the other person at RPM fusion was mentioning that he was getting weird key mappings like page_down for left, etc -- this would be why. Didn't realize they were variable like that. I went back and made a lookup table to convert the official keysyms to keycodes, so this issue should now be fixed. Anyone packaging bsnes is free to update to the latest WIPs to fix this if they like.

Second, I added "adjust" to brightness/contrast/gamma, and they all start at 0% centered, go to -95% and +95%. Still not sure what to name "Frequency adjust", so I left that alone for now.

Third, I updated the ~400 or so %0.nx sprintf statements to %.x, so that GCC 4.2+ will shut the hell up.

Lastly, I can't come up with a good double->string conversion routine (causes subtle rounding errors with the obvious approach), so I wrapped strdouble() around snprintf. bsnes doesn't even use it yet, but at least it can now ...

How would dropdowns be better than what ZSNES is currently using?

The WIP link on Rapidshare is dead ... what are they using? If it doesn't involve tab panels, then I can do that.

Wouldn't these just be hardware filters like NTSC that simulate the lossy characteristics of certain type of analog output?

These are settings for the NTSC filter to affect its quality. They don't affect any other filters.

There's no fundamental difference between a coprocessor and central processor in the scheme of emulation. That the coprocessor happened to be located on what we would physically categorize as the "cartridge" is immaterial.

There's quite a large distinction between something inside the SNES and outside. I understand where you're coming from, but we shouldn't pretend as though the SNES contains all these chips, either.

Sheesh, I don't even know what we're discussing here anymore :P

You'd be crazy to externalize all your code just to allow people to create imaginary 10ft boards with 2ghz GPUs.

What I wouldn't give for just one person to make such a board ... :D

The only invaluable option in that entire section is overload's gamma curve, everything else about the image can be destroyed in my video driver or monitor settings.

Haven't we covered this in the past? SNES games were played with gamma, etc settings calibrated to NTSC / PAL televisions. Monitors are calibrated very differently. I doubt anyone wants to go into their driver control panels to adjust these settings every time they start and close the emulator. And cheaper drivers (especially on Linux) may not have these options at all.

Not saying we have to go crazy here ... I'm happy to leave out hue/saturation settings.

I am aware that any changes made to WIP releases are posted here on this forum, but maybe it's an idea to start including those as well on the WIP download page?

I could ... but it's easier to type things up here later on at my convenience :/

[Verdauga Greeneyes]

You could link to the appropriate forum posts, I guess. Although I personally don't think it's much trouble if we don't go off on too many tangents. (mind you, WIP news tends to redirect those anyway)

[creaothceann]

Lastly, there's signal quality settings. There's some nice quick presets for quality level: RGB, S-video, composite, RF, etc. Might be nicer to offer that as a drop-down rather than a bunch of sliders.

How would dropdowns be better than what ZSNES is currently using?

The WIP link on Rapidshare is dead ... what are they using? If it doesn't involve tab panels, then I can do that.

Maybe there's some misunderstanding here... anyway, ZSNES is using this (sliders and buttons).

[Verdauga Greeneyes]

anyway, ZSNES is using this (sliders and buttons)

Hmm, I'm not sure those settings count as 'presets', considering you can't change the values they adjust manually ... more like 'profiles' perhaps? I guess a dropdown would waste less space, but there would be only one dropdown list so good luck getting things to look symmetrical.

[Nach]

anyway, ZSNES is using this (sliders and buttons)

Hmm, I'm not sure those settings count as 'presets', considering you can't change the values they adjust manually ... more like 'profiles' perhaps? I guess a dropdown would waste less space, but there would be only one dropdown list so good luck getting things to look symmetrical.

Do they have the meanings behind presets and profiles reversed in your country?

Futhermore, after choosing a preset, you're still free to move any of the sliders after they're moved to a preset location.

[Verdauga Greeneyes]

Do they have the meanings behind presets and profiles reversed in your country?

Futhermore, after choosing a preset, you're still free to move any of the sliders after they're moved to a preset location.

A preset to me implies something that affects only the visible options, while a profile could do other things behind the scenes. Correct me if I'm wrong, but don't the various options also change things like the amount or type of artifacts the filter generates?

Edit: although I didn't notice the Adv NTSC tab before - if those options are in there then I guess it's fine. (though I'm still curious if you agree with the above if some of the values are hidden)

[Nach]

None of the values are hidden.

[FitzRoy]

There's no fundamental difference between a coprocessor and central processor in the scheme of emulation. That the coprocessor happened to be located on what we would physically categorize as the "cartridge" is immaterial.

There's quite a large distinction between something inside the SNES and outside. I understand where you're coming from, but we shouldn't pretend as though the SNES contains all these chips, either.

Special chips being emulated like another device for speed increases is an emulation debate for someone else. I'm talking about file interaction and storage, and I don't think it's desirable to be externalizing anything from the executable if legally possible. You separate chips pretty well in your source code, but I'm guessing you do no such thing for pcb boards. Maybe this is what really needs to be addressed, the lack of individual pcb representation in the source code. That way people who want fantasy boards for reverse engineering purposes can more easily construct one from within, compile the emulator, and add a spreadsheet entry capable of having it recognized.

We can also reach immediate 100% adoption with a database file. We wouldn't get to 5% in years with a pcb-per-file format. You can't convince users to spend time upgrading to something that has little to no perceivable benefit on their gameplay.

Here's an incomplete example.

http://www.file-upload.eu/download-1344105/sfc.ods.html

Notice the blank second sheet for custom entries. Many of these columns could be deleted if you wanted, this is the format I use for my dumping documentation. If I ever find a cart that has a different cart serial, make, rom serial, or pcb serial, I document it as a separate unique combination. That's why you see what appear to be duplicate entries, the same data often came on many kinds of hardware. If I know that I or someone else has already purchased and verified a combination, I know not to buy it again. And the only external submissions I accept require scans of the cart and pcb.

[Nach]

There's no fundamental difference between a coprocessor and central processor in the scheme of emulation. That the coprocessor happened to be located on what we would physically categorize as the "cartridge" is immaterial.

There's quite a large distinction between something inside the SNES and outside. I understand where you're coming from, but we shouldn't pretend as though the SNES contains all these chips, either.

Special chips being emulated like another device for speed increases is an emulation debate for someone else. I'm talking about file interaction and storage, and I don't think it's desirable to be externalizing anything from the executable if legally possible. You separate chips pretty well in your source code, but I'm guessing you do no such thing for pcb boards. Maybe this is what really needs to be addressed, the lack of individual pcb representation in the source code. That way people who want fantasy boards for reverse engineering purposes can more easily construct one from within, compile the emulator, and add a spreadsheet entry capable of having it recognized.

Please look up "data driven code" or "data driven programming". It's what should be done in virtually all cases. Although emulators are notoriously bad about that, but we're trying to change the situation.

We can also reach immediate 100% adoption with a database file. We wouldn't get to 5% in years with a pcb-per-file format. You can't convince users to spend time upgrading to something that has little to no perceivable benefit on their gameplay.

No need to convince anyone to do anything, once we're done, I plan on making ZSNES generate PCBs* alongside ROM images that don't have them, unless the user disables the feature. In which case, I'm not even sure I'll allow it to run.


*Using a special PCB library which connects to a website periodically.

[FitzRoy]

No need to convince anyone to do anything, once we're done, I plan on making ZSNES generate PCBs* alongside ROM images that don't have them, unless the user disables the feature. In which case, I'm not even sure I'll allow it to run.

*Using a special PCB library which connects to a website periodically.

I don't like this, it's just adding another layer of complexity. Instead of reading from the database directly and pointing to the proper board within the emulator, you're creating (potentially) thousands of redundant external files from the database. And instead of packaging the db with the emulator, you're keeping the database somewhere where I can't read it or modify it to conform to my verification standards, and every other user should have the same privilege. I want to use my own database, no more going through someone else's flawed and secretive system.

[Nach]

No need to convince anyone to do anything, once we're done, I plan on making ZSNES generate PCBs* alongside ROM images that don't have them, unless the user disables the feature. In which case, I'm not even sure I'll allow it to run.

*Using a special PCB library which connects to a website periodically.

I don't like this, it's just adding another layer of complexity. Instead of reading from the database directly and pointing to the proper board within the emulator, you're creating (potentially) thousands of redundant external files from the database. And instead of packaging the db with the emulator, you're keeping the database somewhere where I can't read it or modify it to conform to my verification standards, and every other user should have the same privilege. I want to use my own database, no more going through someone else's flawed and secretive system.

Don't bash the new system before you even see what it is.
I'm attempting to come up with a distributed standard, instead of the old limited one.

[tetsuo55]

No need to convince anyone to do anything, once we're done, I plan on making ZSNES generate PCBs* alongside ROM images that don't have them, unless the user disables the feature. In which case, I'm not even sure I'll allow it to run.


*Using a special PCB library which connects to a website periodically.

i would like to request, that the .pcb file can also be created inside zip and jma files.
I would like to see .zip as the default storage format for snes roms and their .pcb file. (This also helps with frontends)

[Nightcrawler]

I don't like this, it's just adding another layer of complexity. Instead of reading from the database directly and pointing to the proper board within the emulator, you're creating (potentially) thousands of redundant external files from the database. And instead of packaging the db with the emulator, you're keeping the database somewhere where I can't read it or modify it to conform to my verification standards, and every other user should have the same privilege. I want to use my own database, no more going through someone else's flawed and secretive system.

I have to say I can see where FitzRoy is coming from here and I share similar concerns. The way you guys have been talking both here and other topics related seemed to be in the direction of kind of jamming your ideals down the user's throat as the only option. Adding complexity, creating redundancy (creating the pcb files all over the user's HD), and not providing easy methods to both test new verifications standards or pcb's etc, you're both crushing user abilities and then burdening them on top of it. It seems like losing focus to push your ideals which don't even matter to 95% of the userbase who will say everything is perfectly fine as it is. I don't see see this overly harsh mentality as the best road to travel.

And the fact that we disagree here is supporting evidence. No matter how good or bad your system is, somebody somewhere will take exception, but you've crushed out all user abilities to do anything, so rather than still playing on the same team, you're throwing these people out.

[byuu]

The way you guys have been talking both here and other topics related seemed to be in the direction of kind of jamming your ideals down the user's throat as the only option.

For the sake of discussion, I was also suggesting removing IPS support. Possibly offering auto-conversion to UPS.

Nightcrawler, nobody likes forcing anyone to do anything. But the current system is broken.

IPS patches are a 50/50 split of headered vs non-headered patches, because ROM hackers can't even agree on something that simple. Emulators literally have a coin-flip chance of patching games correctly. To argue that it should remain just because people use it now is normal ... but we get what we deserve: the x86 ISA, Windows, IE6, et al.

It's broken, and we need to replace it with something better for the sake of everyone. If people don't want to upgrade, then they can cling to their 2006-edition emulators. Fine by me.

Now, as for the PCB spec ... these same arguments apply.

Sometimes drastic action is the only way to promote positive change. If all someone wants is "good enough", then they already have no reason to upgrade. All active SNES emulators have ~98%+ compatibility rates. Most run on < 500MHz systems. They're more than "good enough" already.

Those people can enjoy wondering why they get a black screen after soft-patching. They can wonder what "Always allow VRAM writes" checkbox means in the GUI. They can try and figure out what "Mute fix" and "Use Anti-Resonance decoding" means in the sound panel. They can use savestates since save RAM isn't working for them in Ys 3 for some reason. I don't care.

I'm not going to let people's complacency / apathy impede progress, however. I have no intention of keeping the equivalent of iNES for the SNES scene forever. We have a real opportunity here with such tight relationships and so few emulators in our space. The NES scene is, in all honesty, fucked forever. Too many people to ever agree on anything. So we have iNES+iNES 1.1+iNES 2.0+UNIF+XML+........

We're discussing possible options here. Nobody has said for certain that any of this stuff is going to happen.

-----

I have concerns about the emulator auto-generating the PCB files too. Nach, how is the emulator going to create PCB mappings it knows are 100% correct without a database of its own? Will it use heuristics to guess, or will it tie into an online database and/or NSRT?

The former seems fallible, and the latter seems to be just a round-about way to implement a hard-coded database.

FWIW, I don't have a problem with a PCB database. Indeed I think it's a good stop-gap measure until we can get all sites hosting ZIPs with PCBs and signed certs. I'd also like to support the old header detection, at least until the big two stop doing so, or we have ~99% of games validated and signed, and NSRT can easily generate PCB info for them all.

Worst case scenario, I'll go it alone. I've always been about preservation, not casual gaming. If it loses me half of my ~1% userbase, so be it.

The main things I want are to have a way to get valid PCBs for all commercially released games + revisions, to allow others to make their own custom PCB mappings, for a way to validate that the game image is 100% genuine, to be able to patch it and know whether or not patching succeeded and for emulators to be able to parse these PCBs with or without a database.

[FitzRoy]

For the sake of discussion, I was also suggesting removing IPS support. Possibly offering auto-conversion to UPS.

I recently modified my readme mockup to include an "Unsupported Filetype" section. I think it's a good addition, it would include the copier extensions and IPS once you're bold enough to do it. I don't really understand why the copier extensions haven't been wasted already, SFC works in all major emulators, so there's no reason why a user would dump bsnes rather than rename their files. You have more leverage here than you think.

I'm not going to let people's complacency / apathy impede progress, however. I have no intention of keeping the equivalent of iNES for the SNES scene forever. We have a real opportunity here with such tight relationships and so few emulators in our space. The NES scene is, in all honesty, fucked forever. Too many people to ever agree on anything. So we have iNES+iNES 1.1+iNES 2.0+UNIF+XML+........

That system needed a database format like the one I just constructed far more than the SNES did. The only annoying difference is that many of the boards were nameless, they'd need prison numbers, I'd probably just adopt the iNES ones.

Indeed I think it's a good stop-gap measure until we can get all sites hosting ZIPs with PCBs and signed certs.

Which is never going to happen. Even if it did, you'd have no idea how up-to-date a pcb file was that you downloaded. People would have to shotgun scan their collections with NSRT upon every db update. That's why I think Nach realized that a db was unavoidable. I'm also not sure how you guys planned on resolving the impossibility of 3 pcb files sharing the same name if indeed that rom had three documented pcbs.

[byuu]

I don't really understand why the copier extensions haven't been wasted already, SFC works in all major emulators, so there's no reason why a user would dump bsnes rather than rename their files. You have more leverage here than you think.

I removed 2/3rds of them. Wish I had as much confidence as you to drop it to just .sfc ... but with download counts of ~2,000 per release, I'm not so sure. We're dead in the water without people to test for regressions / find new bugs.

Which is never going to happen.

Yeah, true. Again, I'd be happy with a ~99% perfect database, even if its a separate download. There will never be new commercial games released, so in theory a perfect database would be universally useful and easy to sign as a whole / sync update with online.

Anything not recognized by the DB or soft-patched by UPS could just display some sort of warning message in the statusbar / show the name in red / or something.

I'm also not sure how you guys planned on resolving the impossibility of 3 pcb files sharing the same name if indeed that rom had three documented pcbs.

The back-end database, NSRT, could easily add a line for each PCB ID observed in the wild. We only need one. As for which to actually map the game to, it doesn't really matter. Sort the IDs alphabetically and pick the first one.

---

More a question of what's in the files. There may be a fixed set of ~40 PCBs, but emulators shouldn't need to know what SHVC-FUBAR-12 means. And by allowing the raw mapping approach, emu authors can support the new format much easier, and people can customize them for other uses -- however niche they may be. It's nice flexibility to have at no cost.

And best of all, it gives a way to run the game without header detection and without being in the commercial games database. Giving us the ability to kill off the old header detection method in the distant future.

[Nach]

I have concerns about the emulator auto-generating the PCB files too. Nach, how is the emulator going to create PCB mappings it knows are 100% correct without a database of its own? Will it use heuristics to guess, or will it tie into an online database and/or NSRT?

The former seems fallible, and the latter seems to be just a round-about way to implement a hard-coded database.

I haven't entirely considered which route to take for something that far off on the list of things to do.

However, I'm playing with the idea that ZSNES could talk to NSRT or the library I proposed and have it generate stuff, as an interim hack until such time as it's been deemed that such builds have been out there long enough that such support can be removed.

[Dullaron]

I like the idea not patch a rom. Just load rom and patch at the same time on bsnes without worrying about screwing up the rom.