Actually, a special ROM format that contains extra hardware info seems like a good idea to me. You'd still use .bin for the majority of games. In what way would it be problematic?
Yes, but how do you ensure wide distribution and acceptance of the format? That's the question. I also consider backwards compatibility a potential issue (though, I could always see tacking on the info on the end of an otherwise standard .bin ROM working, compatibility-wise. Barring 4096kbyte games...).
BSNES is already doing it without appending extra data to the ROMs or making up new formats, by using folders that include the needed ROMs, save data, a manifest XML for certain systems, and anything else that could be related to each cartridge. I think is a nice idea, but I'd change a few things for it to be the "ultimate" and more standard cartridge/board-based format possible: Possibility of using compressed files rather than real folders (since they're basically the same thing, but handier). Besides the manifest.xml file that would tie everything together, I'd only include any stuff that came from the cartridge (any ROMs, battery saves, mapper info, specific schematics for copy protection, etc). Exclude any external stuff such as covers, cheats, etc, which would just bloat each game folder ad infinitum. When appliable, change the "program.rom" file, to the actual split ROMs with their respective names. Also rename the "save.rwm" to whatever the EEPROM is called in games that use it, etc. I think MAME is doing it almost right except that it lacks an XML for each game, and rather relies on the emulator's own database. If this system got widely implemented, we'd even be able to load the same Mega-Tech ROMs in both arcade and Genesis emus!
Your approach is more or less the MESS approach, though MAME/MESS do need to store the state in the emulator because they store so many diverse systems with different requirements (unless you want to start adding scripting language code to the ROM). The bsnes method is more suited to people who want to not only play games but also move the environemnt they play games around. Both approaches have their dvantages and disadvantages (the MAME approach more closely resembles the hardware, while the bsnes approach is easier for end users and hackers to work with). I personally would not use XML as it is not a general-purpose data store format (despite being general enough to act as one), though I'm not sure how different markup is from data for this very specific case. JSON (a dedicated data format) would probably be a better choice. In my honest opinon I would rather keep the flat folder of ROM approach for systmes like the Genesis where you only ever have one ROM when fully combined. Sonic & Knuckles is the only exception that I know if (unless Virtua Racing has an internal ROM for the DSP, but apparently that's not the case?). Why? I'm not entirely sure... partially because I ljust prefer things this way, partially to make handling ROM sets easier, partially to make searching ROMs for binary data easier. byuu does have a program which can automatically build a temporary bsnes ROM folder out of a flat ROM and store the etra data elsehwere, which also helps. Also if you're going to make a manifest file, I'm not sure how far we can go without starting to introduce game-specific hacks (or having them placed in the emulator). The only real issue is Psy-O-Blade, which has a corrupt SRAM header; not sure how to handle that. 3MB games with SRAM would not be an issue (Phantasy Star IV and The Story of Thor would be explicitly specified as using a mapper; HardBall 95 would not).
Speaking of emulator accuracy does anyone know a complete list of emulators compatible with Ultimate Mortal Kombat Trilogy? The list on the official site don't seem to be complete as they don't even list picodrive PSP.
No. Emuators right now are fine for playing games, but they SUCK (yes, every single one of them) for homebrew development. AamirM may say regen is not OFFICIALLY discontinued, but I have low hopes at this point. It's the only decent debugging emulator out there (sans the crashes *sigh*).
For what its worth, Kega is not discontinued either, Steve is just busy with real life to work on it.
Are you guys actually suggesting Headers? Yes they'd be at the back but tampering with the ROM to make it work is not a good idea. It also screws up some patches at ROM hacking sites. Some patchers such as XDelta require the exact ROM to patch. If theres headered and unheadered ROM's then finding the right ROM could be a hassle. I suppose someone would create a tool to remove and add the headers but that'd be another step that alot of noobs that wanna use your patches won't know about. I know they wouldn't be called headers since they are at the end of the ROM but I don't know what else to call it.
I was definitely not suggesting that. Making backward-compatible footered ROMs would just create a mess. My suggestion was for an archive format which contains unaltered ROMs and a text file with info on mappers or whatever. If the archive were a zip, it would still work in older emulators anyway.
For that matter do we even have a list of what carts appeared with what type of mappers / main boards / etc? Smspower has a list for some Master System games but that's it as far as I know.
I heard Genesis Plus GX (Wii) is one of the most accurate if not the most accurate genesis emulator, why it wasn't ported back to Pc/windows yet? I don't know any other emulator with support for the XE-1AP (Analog controller) and the Activator. ps. And I really like the Gui even though it's optimised to point and click/touch windows 8 anyone?
The source code includes a tiny SDL based client that easily compiles and runs on Windows, Linux and OS X. I've never used the emulator, but RetroArch has a Genesis Plus GX plug-in: http://www.libretro.org/ There are probably some other ports of it that I'm not aware of as well. It's very easy to port as far as emulators go.
Indeed but is the emulation aspect being work on? I mean it has been ported to almost any machine but how good is the emulation core? EDIT: Where could I find the latest source of the emulation core? libretro has a git repository but Im not sure if its the most up to date core. Nvm it seems the libretro core its being worked on. Gotta check how reliant is genesis plus on speed hacks. EDIT2: It seems the M68k core of Genesis Plus is not Free Software/Open Source. That's too bad.