MAMEWorld Forums - EmuChat - Re: I found this thread today on byuu's message board.

Remind me about this thread when you guys are asking me for my help again.

The reason I am concatenating the firmware onto ROMs is because I am personally redumping the entire SNES library. The "HiROM"/"LoROM" maps are incorrect, as the real PCB maps are a lot more interesting and varied. Se http://byuu.org/snes/database/ to see for yourself.

It is substantially quicker for me to do this if I can have one unique file per game, and so that I can test a dumped/mapped game by loading it and only it into my emulator, without having to keep firmware files in my game dump folder. There are a few games where they were released with DSP-1 firmware, and then with DSP-1B firmware. By hashing the firmware as well, this gives each game a unique hash for each. It also lets me verify the correct firmware was used once a game was loaded. It's part of the ROM data inside the cart. Just like PRG+CHR ROM are in NES carts, and PRG+DAT ROMs are in SNES SPC7110 carts. Nobody's ever complained about concatenating SPC7110 images.

I am not trying to force anyone to append firmware onto their ROMs. My emulator natively loads files that have been split apart by ROM purpose/type in a folder. It's basically like an uncompressed ZIP that allows me to write data without rebuilding the archive. I am also not trying to force people to distribute game folders in "my" format.

Why is it a big deal when I make a new format, but MAME making the NSS format different from every other emulator is perfectly acceptable?

How you load games into the emulator has not changed. I've always provided tools to do as many loading types as possible.

These merged ROMs exist only on my hard drive, and I do *not* give out game ROMs to anyone, ever, period. If people want to copy my format they can; if they don't want to, they don't have to.

If a "bsnes ROM set" is made, it won't be my doing.

> SNES in MESS with HLSL >> bsnes

I have HLSL shader support (had it before MESS), and also GLSL shader support. The latter works on more than just Windows. Which seems important for an emulator, at least to me. Seems to also be true for others as 95% of shaders made for my project are in GLSL format.

And personally, I think emulating more games with less bugs is more important than pretty filters, but to each his own.

> Bundling the dsp dumps in with the game rom is just going to cause complications, it wastes space & is bad documentation.

Including all regions and revisions, multiplied by the firmware size, this "wastes" less than 200KB of space (over storing one copy of each) in return for not failing when the user doesn't obtain firmware files separately and put them in the right place. DSP firmware is 8KB in size. Cx4 is 3KB. Only one game each for ST011 and ST018 anyway.

Speaking of wasting space, why does MAME/MESS include the DSP1B firmware with NSS games like Contra 3 that don't have those chips on them? And why is the SPC700 firmware, which exists on the SNES mainboard, in there?

> He's going to make you download the spc rom separately still

The SPC700 IPLROM does not exist inside the cartridges like the DSP firmware does. However, it's not copyrightable as per Lexmark v Static Control Components. So it's included with my emulator.

> The funniest bit is he's tried before...

Nothing I've promoted was meant to be exclusive to bsnes. I just don't give a shit if others aren't interested in it.

You can stick with iNES and incorrect SNES memory maps, it doesn't matter to me.

I've always gone out of my way to offer a way to load standard SMC images in ZIP files with copier headers. You can associate them with the current release of bsnes and they'll just work.

> byuu needs to start writing bmegadrive instead of messing around with this crap

I'll let you know when I'm taking requests =)
PS - please don't delete my post again, they take up too much space on my website.

> OK so his database has the dsp appended anyway, he doesn't even listen to the last of his fanbase, and now I will need to concate the roms in order to calculate the checksum of the unmodified rom images, lovely.

Do you think Mozart asked his fans how he should write his music? Did Einstein ask John Q Public how relativity worked? I'm not comparing myself to geniuses, just making a point.

Why would I take design advice from people who have little to no experience? "A little knowledge is a dangerous thing."

When I solicit advice, I weigh its importance based on the person saying it; not on the number of people saying it.

> I needed to figure out what he appended to what since it's not really documented.

It is completely documented.

http:/byuu.org/snes/database/

> Even though neither MESS nor byuu's dumps can be called perfect at this time, I would really love to know how MESS ended with what it has now.

Like bsnes, MESS does whatever it wants, regardless of external criticism. We're actually very much alike in that regard. Strong programs need strong leaders who don't cave to peer pressure like this thread.

The DSP files have no observable endianness. You cannot perform 8-bit reads, only full 24-bit (program) and 16-bit (data) reads. You may say otherwise based on some die photo arrangement, we will agree to disagree.

Dr. Decapitator made the images with <24-bit big endian> + <8-bit 0xFF padding> and <16-bit big endian>

I removed the padding and combined the files to make the original .bin files. Later I reversed the endian to make the .rom files. Presently, I split them into two separate files. Call it indecisiveness if you want, I call it refinement and willingness to admit past mistakes.

The endian swap was because there is no actual endian, and 100% of other SNES data is little endian -- in fact, so is all NES, GB, GBC, GBA, NDS stuff as well. This allowed me to use a shared N-bit array reader function for all data. No implied knowledge of a file's endianness is needed, just remember that it's all LE and you're good.

So long as the end result is 100% identical, I prefer consistency. MESS favors staying true to perceived notions of how things are. See Super A'can ROMs for instance. Nothing wrong with either approach, but you'll always have fanboys cheering for one or the other.

> that's it, from now on I'm calling it higgins

Nightcrawler calls it higan/buddhist holiday.

You can do better than that: you guys were more creative with "BullShitNES"

If anyone does care, it's pronounced closer to "he gone", without the pause. Perhaps you can make a funny joke with "he gone"? Don't disappoint me =)