So I was wondering, is there an accurate Genesis/Mega Drive emulator akin to the SNES emulator BSNES? Bonus points if its an Open Source emulator because you can easily check if there's hacks to let certain games run.
The closest we have right now are the discontinued closed-source Regen and the closed-source Kega (whose author seems to have disappeared). GerbilSoft is working to increase the accuracy of Gens/GS II but is presently busy with an IRL job. Somebody rebooted dgen; we have to wait to see where that goes. Nemesis is working on one, Exodus, and has posted code snippets, but I have no idea how he wants to release it (and won't until it's done). There's also somebody working on an FPGA implementation of the Genesis; judging by various SpritesMind thread I think he's aiming for accuracy there. As for something ground-uip like bsnes, my current project is the YM2612 portion, which is based on Nemesis's reasearch. Unlike bsnes, it uses coroutines to try to behave like the orignal hardware. The 68000 side should not be hard either; according to Nemesis, the full operation of the chip (or at least just the microcode portion) is described in patents.
Question, how can you be certain a closed source emulator is really accurate or just using hacks depending on the game? Also I read the 68000 emulation, from what I read it seems quite an engineering task to say the least, it said that there's timing problems and what not. In theory it seems doable but seems quite difficult. Who ever ends up making a completely accurate 68000 emulator will have more than bragging rights to gain from it IMO.
If the emulator is enabling hacks based on a ROM checksum, modifying the ROM would cause the checksum to be different and thus prevent the hack from being enabled. Kega Fusion used such a hack to enable a certain timing option for Knuckles' Chaotix, which caused problems after the Feb. 2008 prototype dump, since that hack wasn't enabled for the prototype ROMs. I don't think it uses any other game-specific hacks, though. In some cases, game-specific hacks are the only way to implement something without extended metadata, such as support for EEPROM saving. Sega never specified a way to indicate EEPROM in ROM headers, and many games with EEPROM either indicate that it's save RAM with one or two addresses, or don't indicate that the EEPROM exists at all. Hence, the only way to handle this is to implement a database of "known-good" ROMs. (Either that, or require a special container format for ROMs with identifying information, but that's problematic.)
But the Genesis does not have any sort good roms table. If an emulator replicates a real genesis then how would you implement that? Or are you saying that many games run the EEPROM as a separate chip independently of the system itself? Like how SNES games had expansion chips that ran independently from the SNES itself.
The emulator maintains its own list of ROMs that require EEPROM emulation. The EEPROM chip is a separate chip, like SRAM. However, Sega never specified how EEPROM is supposed to be indicated in the ROM header (whereas there's a defined format for SRAM), so no one does it the same way. Thankfully, there's only ~30 titles that use EEPROM instead of SRAM, so this list isn't too big. There are a few titles that use SRAM but have invalid SRAM headers. Gens/GS II has a few game-specific hacks for some games that have completely berserk headers (e.g. Psy-O-Blade), and a hack to disable SRAM for one game that shows an anti-piracy message if SRAM is present (Puggsy). In general, if Gens can't identify the SRAM type, it applies a "default" SRAM mapper: 0x200000 with SRAM always-enabled if the ROM is less than 2 MB, and 0x200000 with a register at 0xA130F1 if the ROM is >=2MB. This handles most cases, including Sonic 3 standalone (first case) and Sonic 3 & Knuckles (second case).
Noob question: And how does the hardware acts correctly if it doesn't have the function preprogrammed or a database of games?
It claims 100% compatibility with all games on the systems it supports, not 100% accuracy. That being said, it is probably the most accurate open source one. He used some clever tricks to get Sega CD running full speed on the Gamecube and Wii though, such as the CPU's being allowed to get out of sync where it doesn't break things. The cartridge is hardware too. A dump only contains the data on the cart's ROM chip, not the rest of the functionality of the cart. The console uses the pins on the cartridge to send and receive data. If you only have the data on the cartridge itself, you have no way of knowing what other things the cart can do besides give you data back. For example, Virtua Racing had a separate processor right inside the cart that would need to be emulated. But you can't tell from just the ROM data that the cart had that functionality. (Unless the ROM header specifies it, and as mentioned above, that information isn't always correct.)
It's worth noting for the curious that the YM2612 has been decapsulated, like the project byuu led with bsnes (now named higan), and as is being done for MAME. http://byuu.org/articles/emulation/decap http://byuu.org/articles/emulation/snes-coprocessors One way is to use homebrew ROMs built specifically for testing the processors by comparing how they run on the emulator and on the original hardware (by using a flash cart, etc). I don't know the names of any offhand. edit: There are some here.
Is he still working on that? I remember he was trying to make is as accurate as possible, but I haven't heard anything about it in some years.
Still If you are making an emulator as accurate as possible it should be open source IMO. An accurate emulator is not useful not only because of its accuracy but because it could serve as an educational tool in knowing how that certain hardware worked. By making the code proprietary you remove the education part of the emulator. Besides in this day and age software wants to be free. There's nothing worse than someone that got bored with his project and never released the source code so others could continue the work.
Some people just don't want to share their work. Sounds selfish but I can understand why someone wouldn't want to open source their project.
er oops Code (Text): [18:15] <AamirM> andlabs, Fuck you. [18:16] <AamirM> Regen is not discontinued. [18:16] <AamirM> :P
I don't get this line of thought. I mean, I understand if you want to make a profit of your work and you think the best way to do so is to keep your software proprietary. I don't agree with it but I certainly understand the motivation of software developers to do so. But if you are working on something that has no monetization involved I cant understand why don't you share your code with others. I mean its the right thing to do. Not only does the software benefits from it but you can do much more by making your code public than by letting it rot in your hard drive chained to your whim. Many times had a proprietary closed source project been lost because the developer's hard drive died or something. This rarely happens with free software because you tend to update your public repository more often more than one individual has a copy of your code.
That sounds like entitlement to me. This is someone's hard work. Maybe they don't want to just give it away?
That word. :v: But seriously, you are not giving away your work by making your software free. You are doing a great service to your users by letting them see the code and know the ins and out of your work. You turn a personal project into something more. Something that can grow and mature into something everybody can help build. A work that will live on beyond your lifetime. Thats the best kind of work IMO. I don't get why wouldn't you want this.
I understand all that. What you have to understand is some people don't want to give others all the answers to a problem. They worked hard on it and it's their solution. Still others are embarrassed of their shitty coding, and don't want it to be scrutinized. Still others may have reverse engineered code (or something else) that doesn't allow them to redistribute it under an open source license (this can especially true of emulators). There's many reasons why someone may choose not to open source their work.
