[Epsilonsama]

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.

This post has been edited by Epsilonsama: 02 December 2012 - 09:06 AM

[Andlabs]

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.

This post has been edited by Andlabs: 02 December 2012 - 10:26 AM

[Epsilonsama]

Andlabs, on 02 December 2012 - 10:21 AM, said:

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.

[GerbilSoft]

Epsilonsama, on 02 December 2012 - 04:10 PM, said:

Question, how can you be certain a closed source emulator is really accurate or just using hacks depending on the game?

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.)

[Epsilonsama]

GerbilSoft, on 02 December 2012 - 05:39 PM, said:

Epsilonsama, on 02 December 2012 - 04:10 PM, said:

Question, how can you be certain a closed source emulator is really accurate or just using hacks depending on the game?

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.

[GerbilSoft]

Epsilonsama, on 02 December 2012 - 06:31 PM, said:

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).

[ICEknight]

Isn't Genesis Plus GX almost 100% accurate?

[ReBirFh]

GerbilSoft, on 02 December 2012 - 05:39 PM, said:

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.)

Noob question: And how does the hardware acts correctly if it doesn't have the function preprogrammed or a database of games?

[sonicblur]

ICEknight, on 02 December 2012 - 08:53 PM, said:

Isn't Genesis Plus GX almost 100% accurate?

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.

ReBirFh, on 02 December 2012 - 09:33 PM, said:

Noob question: And how does the hardware acts correctly if it doesn't have the function preprogrammed or a database of games?

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.)

This post has been edited by sonicblur: 02 December 2012 - 09:58 PM

[Hendricks 266]

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/arti...emulation/decap
http://byuu.org/arti...es-coprocessors

Epsilonsama, on 02 December 2012 - 04:10 PM, said:

Question, how can you be certain a closed source emulator is really accurate or just using hacks depending on the game?

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.

This post has been edited by Hendricks 266: 03 December 2012 - 06:31 PM

[Rika Chou]

Andlabs, on 02 December 2012 - 10:21 AM, said:

...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)...

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.

[Epsilonsama]

Hendricks 266, on 03 December 2012 - 02:17 AM, said:

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/arti...emulation/decap
http://byuu.org/arti...es-coprocessors

Epsilonsama, on 02 December 2012 - 04:10 PM, said:

Question, how can you be certain a closed source emulator is really accurate or just using hacks depending on the game?

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.

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.

[Aerosol]

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.

[Andlabs]

er oops

[18:15] <AamirM> andlabs, Fuck you.
[18:16] <AamirM> Regen is not discontinued.
[18:16] <AamirM> :P

This post has been edited by Andlabs: 03 December 2012 - 06:54 PM

[ReBirFh]

sonicblur, on 02 December 2012 - 09:48 PM, said:

ReBirFh, on 02 December 2012 - 09:33 PM, said:

Noob question: And how does the hardware acts correctly if it doesn't have the function preprogrammed or a database of games?

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.)

Thanks, makes perfect sense.