bsnes v0.038 released

[tetsuo55]

If i understand you correctly blargg.

Bsnes does not have to care about the luminance because it basically emulates a snes with a RGB out(which by definition provides a 0-255 luminance image)

The way i understand luminance is that it is the hard limit between whitest white and blackest black(although you can shift them with the knobs on the tv the range will simply move higher or lower). All analogue and digital broadcast signals are in 16..235 range.

All end-user connections on consoles use this range.

The reason i know/care about this range is because the difference between the two ranges causes all kinds of problems with my display.
Now that almost all problems are fixed i decided to ask about bsnes

[byuu]

So you'd like it if I arbitrarily cut off ~14.5% of bsnes' contrast ratio for no apparent reason? Seriously? :P

Anyway, I was thinking about modifying libfilter to allow external color tables to handle sepia+grayscale+invert+whatever the hell else people want anyway, to get that code out of the library. If you want to degrade video quality for whatever reason, that'd probably be more than sufficient :D

[Nach]

So you'd like it if I arbitrarily cut off ~14.5% of bsnes' contrast ratio for no apparent reason? Seriously?

Maybe if you did that, you won't need gamma ramp any more.

Also, I like not being able to see anything, leaves more time for work and less time for games.

[FitzRoy]

Claiming security until being refuted is really the wrong way.

In the relevant pool of data, CRC32 is sufficiently preventative for collusion, overkill in fact. There are too few files being distributed and targeted as snes roms for collision to occur. That collision is more likely with all imagined combinations of data is not really important.

As for fraud, I'm only claiming sufficient fingerprinting for our needs. The difficulty in performing a spoof must be weighed against the motivating factor on a per-application basis. We can talk about making it harder and harder all day, but that's besides the point. I don't put padlocks on my leftovers in the fringe, even though it would be more secure. We need to weigh the need for additional security against a motivating factor. Let's ask ourselves:

1) how likely is it that someone is going to want to spoof files in our database and why?
2) what level of difficulty is sufficient to dissuade it?

In h4tred's example, hackers attack pay-to-play door and key systems. There is a clear motivating factor here, to get something for nothing instead of something. There is no motivator here, the files can already be gotten and used for nothing. Thus, CRC32 or MD5 would be more than sufficient for our needs. The end.

Somehow, this statement made me feel challenged. I wrote a small note explaining my thoughts on the subject. I would appreciate someone checking it and reporting typos, mistakes, or obscurities.

While a paper is interesting, it's no substitute for actually doing it, nor does its conclusions meet the conditions of my challenge. For example, are you concluding that chunks of data can be changed arbitrarily without the program showing signs of malfunction? The program would have to have a lot of useless data and you'd have to be lucky enough to change only those parts. Since the whole challenge is a fabricated motivator to justify additional security anyway, it's kind of pointless even if you had succeeded. I just thought it would have been the fastest way to end the debate.

That project64 screenshot looks almost perfect as far as a cheat screen goes.

Ugh, I hope you're kidding. bsnes' table view is far better than that disjointed mess. It doesn't even look like it gives sufficient room for names, and descriptions aren't viewable until you click on the specific listing. Every little box has h/v scrollbars to compensate for this obvious deficiency. Terrible design.

[Nightcrawler]

This is SNES ROMs we're talking about. Has anyone in the history of SNES emulation written a malware SNES ROM disguised well enough as a real ROM by today's standards? I don't know of any myself.

I laugh at the idea of people breaking MD5 sums, finding enough data to change in an SNES ROM to not obviously affect operation and try to pass it off as a verified dump. Somehow, I don't see this ever happening or anyone quite so bored. It's also very unlikely they'd get away with it even if they did.

[tetsuo55]

So you'd like it if I arbitrarily cut off ~14.5% of bsnes' contrast ratio for no apparent reason? Seriously?

Anyway, I was thinking about modifying libfilter to allow external color tables to handle sepia+grayscale+invert+whatever the hell else people want anyway, to get that code out of the library. If you want to degrade video quality for whatever reason, that'd probably be more than sufficient

No cutting involved at all, just a confirmation that the luminance we are seeing on the monitor matches what it looks like on a tv.
If it where wrong a simple conversion would fix it, the process should be near-lossless

[Nach]

Code: Select all

nsrt -genset

[tetsuo55]

That project64 screenshot looks almost perfect as far as a cheat screen goes.

Ugh, I hope you're kidding. bsnes' table view is far better than that disjointed mess. It doesn't even look like it gives sufficient room for names, and descriptions aren't viewable until you click on the specific listing. Every little box has h/v scrollbars to compensate for this obvious deficiency. Terrible design.

To be honest i like the description and the 2 pane view of it.
I agree that scrollbar's suck

[Nach]

Code: Select all

nsrt -genset

And if you're too lazy, or don't have NSRT.

For those that have forgotten.

http://rapidshare.com/files/180171586/snes.7z.html

[byuu]

Damn, absolutely loving this Aftershock I just picked up. Scary stuff -- 80 proof and it tastes like a malt beverage.

New WIP, added the cheat code editor UI changes. The cheat code class in the back-end still doesn't actually support multiple codes just yet, but it will.



Need to decide how many codes we should allow. A real Game Genie didn't allow more than five, so I think we should go with either four or six.

Also not shown, when a code you're editing is incomplete / bad, there's a grayed out text label that appears on the right to tell you that the code is invalid. It also disables the ok button during this time.

I wouldn't try entering a multi-line description just yet. I don't parse that at all. Worst case, it'll corrupt your cheat file. My plan is to only show the first text line in the listbox, but allow extra lines for more verbose comments.

I'm being lazy and disabling the add/edit/delete buttons from the main window when the sub editor window is open. Prevents abuses like deleting the code you're editing, then trying to update it.

[creaothceann]

Need to decide how many codes we should allow.

Do you? I'd just code a limitless version, but YMMV.

[byuu]

Do you? I'd just code a limitless version, but YMMV. :P

Wow, what a great idea. How's this look?



It's causing some odd memory errors when I hit previous page on page 1, though :/
Maybe I'll just disable the previous button for that page.

[Verdauga Greeneyes]

Wow, what a great idea. How's this look?

Very retro. Or is that just me/the theme? Either way I like the idea of being able to put in lots of codes for one thing - could you allow copy/pasting of multiple codes? (either separated with line breaks or commas I suppose)

[FitzRoy]

Instead of a wall of fields infinite pages long, could you just have one field and change the text above it to "Enter one or more codes below, separating multiple codes with commas:"

And place the description second, not first, with "Enter a description below:" I also think that should be a 1 line high field.

[Verdauga Greeneyes]

Instead of a wall of fields infinite pages long, could you just have one field and change the text above it to "Enter one or more codes below, separating multiple codes with commas:"

Sort of addresses my point as well. If you make it a multiline edit box then have bsnes parse the result, as long as the codes are sanely separated it should always work.

[creaothceann]

Or something like this:



EDIT: Damn, forgot to add the edit boxes for the "current byte". Or maybe they're not needed?

[bobthebuilder]

Do you? I'd just code a limitless version, but YMMV.

Wow, what a great idea. How's this look?

<let's not quote images>

It's causing some odd memory errors when I hit previous page on page 1, though :/
Maybe I'll just disable the previous button for that page.

Sarcasm is a great thing

[Nach]

Do you? I'd just code a limitless version, but YMMV.

Wow, what a great idea. How's this look?

<let's not quote images>

It's causing some odd memory errors when I hit previous page on page 1, though :/
Maybe I'll just disable the previous button for that page.

Sarcasm is a great thing

I personally subscribe to byuu's extreme sarcasm, it's so funny, I fall off my camel every time.

Seriously, he needs an RSS feed, and post new jokes daily.

[ecst]

Here is a practical example: I uploaded patches one and two. Apply them to the US localization of Super Mario World. The resulting ROMs have the following properties:

- Both have the same MD5 hash.
- Both have the same CRC32 checksum.
- Both have good internal checksum.
- Both are fully functional.

Additionally, they have the same CRC32 and internal checksum as the original ROM and differ from each other in only 194 bits.

The first ROM behaves exactly as the original.

The second ROM differs in only one way: You do not lose a life if you die.

Equivalenty, a crazy fan might have inserted his name into the credits, or whatever.

As soon as an MD5 preimage attack becomes known (and I have little doubt that will happen in the next 5 or 10 years), the modified versions can just as easily be arranged to have the same MD5 hash as the original.

When all cartridges have fallen to dust, would you really want to risk not being able to discern the original from the fakes?

What good is a database of hash validations if anyone can spoof matches in 10 years?

[byuu]

Or something like this:

That looks like a cheat code editor + individual cheat codes. So in other words, you want me to spawn a cheat code editor for each cheat code :P

It's a bit much. bsnes has never been about having the KDE sink, rather it's about presenting the most useful options in a minimalist fashion, ala Xfce. Eg you have no audio filter { linear, cubic, band-limited synthesis, Birch and Swinnerton-Dyer conjecture-based Reimann Zeta function, etc }, you've got only the best-of-class video filters (no crazy HQ4x or crap LQx), input mapping but no keyboard macro combination editor with frame timing and controller swapping, etc.

Sure, there's 1-3% of people who would like that. But for everyone else it's useless clutter. Though I'll agree we certainly disagree constantly on what is and is not useful.

------------------------------------------------------------------------------

The longest code I can find on gamegenie.com is for FF6, four parts.

I really don't see a sane point in offering more than five-part codes (and only six because it's easier to lay out on the form), and I personally find it to be more clear to have each one cleanly separated.

I can however quite easily just give the user one big textbox to put in all the codes they want:

Code: Select all

strtr(codes, "+;,&|\n", "++++++");
replace(codes, "++", "+");
replace(codes, " ", "");
replace(codes, "\t", "");
split(list, "+", codes);
foreach(code in list) { if(cheat.is_valid(code)) cheat.add(code); }

While I can parse that all very flexibly, I don't believe it comes off as clear to the end user what they're supposed to do, even though in this case they can do pretty much whatever. And that's not just a matter of some clever description like "Hey put whatever the hell you want here guys, it'll work!"

Plus we'll also have to either a) clean up and format the stuff for inclusion in the .cht file (so they lose their preferred separator and spacing), or b) transform it ala text->csv ("\n" -> "\\n", etc), and make the format a hell of a lot harder for other tools to parse compared to a fixed format like "0123-4567+89AB-CDEF+..."

Now, as for single-line or multi-line; I definitely prefer multi-line, sorry. Look at half the pages on gamegenie.com, a lot of the codes have big notes with warnings and such about where the game will freeze. I'd like to offer people a way to see that info. They can add a * or something on the first line to indicate they have more verbose comments, or I can do it for them. It doesn't really hurt anything.

- Both have the same MD5 hash.
- Both have the same CRC32 checksum.
- Both have good internal checksum.
- Both are fully functional.

Awesome. Thanks a bunch for making this.

When all cartridges have fallen to dust, would you really want to risk not being able to discern the original from the fakes?

Thank you. I'm glad at least one person here understands what I'm trying to say. Very disappointing how most don't seem to care, especially with such a clear example of what can happen with BS-X images.

[h4tred]

Thanks ecst for making a practical example of what I was talking about in regards to hash integrity.

[blargg]

Bsnes does not have to care about the luminance because it basically emulates a snes with a RGB out(which by definition provides a 0-255 luminance image)

Yes, though it really emulates a SNES with digital RGB out, not that such a thing exists.

All analogue and digital broadcast signals are in 16..235 range. All end-user connections on consoles use this range.

Analog signals aren't digital. Connectors on consoles use voltages to represent signals, usually in a small range around -1 to +1 volts.

The reason i know/care about this range is because the difference between the two ranges causes all kinds of problems with my display.

Unlikely, as PC hardware is made to work together. But if you really do have these problems, start a separate thread since it's unrelated.

So you'd like it if I arbitrarily cut off ~14.5% of bsnes' contrast ratio for no apparent reason?

Harmonization. It's the new fad. But really, systems that for example map 16 to 235 to 0.0 to 1.0 can represent values outside that range. I think the main reason is to store those slight excesses that occur between processing steps as a result of filtering. Sort of like working with 24-bit audio during production of a track, then downmixing to the final 16 bits.

Maybe if you did that, you won't need gamma ramp any more.

Now that I've read more about gamma and video signals, I can be more authoritative.

Fundamentally, gamma is a form of lossy compression for images humans will be viewing. Humans can distinguish smaller lightness changes in the darker end of the range than the lighter end. By making the darker end take more of the encoding range, the effect of noise/quantization error is made more uniform, rather than being mostly visible in the low end. Put another way, it allows the same level of visual noise over an analog channel with more interference/digital channel with fewer bits per sample. Another effect is that the minimum visible change in the encoded value will be the same across the range, so that a gray ramp will be equally smooth from light to dark, rather than having more noticeable steps in the dark end.

During video signal encoding, the linear RGB values have a gamma of about 0.5 applied to them. Then on the decoder side, a gamma of around 2.5 undoes the original gamma, almost restoring linearity. In CRTs, the phosphors themselves do this gamma change, so no extra circuitry is required. The 0.5->2.5 gamma sequence doesn't completely restore linearity, leaving a gamma of 1.25. This is because the images are usually shot in bright environments, but displayed in dimmer ones. In a dimmer environment, a viewer's eyes have a different dynamic brightness response. A gamma of about 1.25 compensates for this, allowing it to look similar to how it would have if the viewer were in the bright environment seeing the original scene firsthand.

The question for the SNES is what gamma it applies when encoding composite and s-video outputs (and perhaps RGB). If it uses none, then proper conversion to the linear RGB values of the light leaving the display's surface requires applying a 2.5 gamma. If the SNES uses 0.5, then conversion requires applying a 1.25 gamma.

A snag is that the PC itself usually applies a gamma of around 2.2 when displaying RGB data from memory. That is, RGB values on a PC are NOT linear. So if you want to display LINEAR RGB, you must apply an inverse gamma of 1/2.2=0.45 to your RGB data in memory. Why doesn't this gamma affect all images displayed by the PC? Because most images are ALREADY encoded in non-linear RGB.

Now, we can consider some possibilities for the SNES:

1. SNES applies a 0.5 gamma when encoding video. TV applies 2.5 gamma to decoded video. PC emulator is running on applies 2.2 gamma, which requires a 0.45 compensation factor. So we need to apply a 0.5*2.5*0.45 = 0.5625 gamma.

2. SNES applies a 0.4 gamma when encoding video. So we need to apply a 0.4*2.5*0.45 = 0.45 gamma.

3. SNES applies no gamma when encoding video. So we need to apply a 2.5*0.45 = 1.125 gamma.

As soon as an MD5 preimage attack becomes known (and I have little doubt that will happen in the next 5 or 10 years), the modified versions can just as easily be arranged to have the same MD5 hash as the original. When all cartridges have fallen to dust, would you really want to risk not being able to discern the original from the fakes?

The only sure way is to keep copies of the originals, and compare.

[DataPath]

Here is a practical example: I uploaded patches one and two. Apply them to the US localization of Super Mario World. The resulting ROMs have the following properties:

- Both have the same MD5 hash.
- Both have the same CRC32 checksum.
- Both have good internal checksum.
- Both are fully functional.

Additionally, they have the same CRC32 and internal checksum as the original ROM and differ from each other in only 194 bits.

The first ROM behaves exactly as the original.

The second ROM differs in only one way: You do not lose a life if you die.

Equivalenty, a crazy fan might have inserted his name into the credits, or whatever.

As soon as an MD5 preimage attack becomes known (and I have little doubt that will happen in the next 5 or 10 years), the modified versions can just as easily be arranged to have the same MD5 hash as the original.

When all cartridges have fallen to dust, would you really want to risk not being able to discern the original from the fakes?

What good is a database of hash validations if anyone can spoof matches in 10 years?

Am I doing something wrong?

---------------------Internal ROM Info----------------------
File: Super Mario World (U).SFC
Name: SUPER MARIOWORLD Company: Nintendo
Header: None Bank: LoROM
Interleaved: None SRAM: 16 Kb
Type: Normal + Batt ROM: 4 Mb
Country: USA Video: NTSC
ROM Speed: 200ns (SlowROM) Revision: 1.0
Checksum: Good 0xA0DA Game Code:
---------------------------Hashes---------------------------
CRC32: B19ED489
MD5: FE83FD994BF4B006FE0068FB65DF9D93
--------------------------Database--------------------------
ROM wasn't found in the database (possible bad dump).
You can try using -fix or -findover to see if the
file has been slightly altered in a rectifiable way.

---------------------Internal ROM Info----------------------
File: Super Mario World (U).SFC.orig
Name: SUPER MARIOWORLD Company: Nintendo
Header: None Bank: LoROM
Interleaved: None SRAM: 16 Kb
Type: Normal + Batt ROM: 4 Mb
Country: USA Video: NTSC
ROM Speed: 200ns (SlowROM) Revision: 1.0
Checksum: Good 0xA0DA Game Code:
---------------------------Hashes---------------------------
CRC32: B19ED489
MD5: CDD3C8C37322978CA8669B34BC89C804
--------------------------Database--------------------------
Name: Super Mario World
Country: USA Revision: 1.0
Port 1: Gamepad Port 2: Gamepad
Genre 1: Platform Genre 2: Side Scrolling

I'm getting different md5 sums.

[Gil_Hamilton]

The longest code I can find on gamegenie.com is for FF6, four parts.

I really don't see a sane point in offering more than five-part codes (and only six because it's easier to lay out on the form), and I personally find it to be more clear to have each one cleanly separated.

But what if they want to distribute a ROM hack in Game Genie format, so it'll be compatible with all emulators AND a real SNES(provided you stack enough 'Genies)?
They may need dozens, nay, HUNDREDS of codes!11


Semi-seriously, I still wonder how many Game Genies you can stack before things become unreliable.

When all cartridges have fallen to dust, would you really want to risk not being able to discern the original from the fakes?

Thank you. I'm glad at least one person here understands what I'm trying to say. Very disappointing how most don't seem to care, especially with such a clear example of what can happen with BS-X images.

Fairly sure there's a lot of examples of that on the PC side of things.
How many programs from the 80s were on 5.25" disks or, god forbid, audio cassettes?
How many of those disks and tapes still survive?

And of course... there's pure LOST software too.
How many of those dead floppies and tapes were dumped to the internet?
And how many of THOSE are original disk/tape images instead of cracked versions with warez group intros?


And less computer-centric...
I know for a fact that several WIP games from the Atari era are gone for good because they were stored on 8" floppies.
EPROMs if they were lucky, but that's not stable over several decades either.


And moving out from video games to the "real" world...

A lot of historical data from NASA's glory days is just gone.
Last I heard, about half the tapes were degraded beyond recovery, and the other half were unreadable because no one has the hardware to extract data from the tapes, which deteriorate further every year.
This includes the lunar photographs used to identify Apollo landing sites.

And the recordings of the Apollo 11 space walk?
No one even knows where those tapes ARE, much less if they're still readable.
http://en.wikipedia.org/wiki/Apollo_pro ... sing_tapes



Now.... if we can't even keep track of Neil Armstrong's first step, what chance does Super Noah's Ark 3D have?

[h4tred]

Now.... if we can't even keep track of Neil Armstrong's first step, what chance does Super Noah's Ark 3D have?

My question is: Is it even worth the effort to preserve titles like Super Noah's Ark 3D? To me, even the name suggests its not worth saving.