@rezb1t Would you mind providing the md5sums for your cartridge images?

% md5sum Triple\ Play\ *
12ba891983dab9749bdaeb7dc8491de8 Triple Play - Gold Edition (USA).md
a214cbc398eb4e6962186bbd69144d9e Triple Play 96 (USA).md
% sha256sum Triple\ Play\ *
8f98a245db4a5c710469c168a5f2afe1c2f9309ef89b40942258494c61d23c68 Triple Play - Gold Edition (USA).md
d8845c027964016e3cc3503b32ed0bce2e59348c275ca0b7fe913bb6fb5a4130 Triple Play 96 (USA).md

Interesting. Neither of mine match...but mine are both confirmed dumps:

md5sum *

fb2f3c6fe0c3ba9fd55dc64e8cd8ec74 Triple Play - Gold Edition.md
02bc38b3dc1d26035f421660abbe9357 Triple Play 96.md

rezb1t wrote: ↑Tue Oct 17, 2023 7:07 pm

% md5sum Triple\ Play\ *
12ba891983dab9749bdaeb7dc8491de8 Triple Play - Gold Edition (USA).md
a214cbc398eb4e6962186bbd69144d9e Triple Play 96 (USA).md
% sha256sum Triple\ Play\ *
8f98a245db4a5c710469c168a5f2afe1c2f9309ef89b40942258494c61d23c68 Triple Play - Gold Edition (USA).md
d8845c027964016e3cc3503b32ed0bce2e59348c275ca0b7fe913bb6fb5a4130 Triple Play 96 (USA).md

These work, confirmed. Thanks!

Will work to chase down what the differences are.

EDIT: Mystery solved. Byte swapping for '96, also byte swapping for Gold but also a different rev.

For those playing along at home, the 'bad' ROMs (with the byte swaps) are from the No-Intro collection, so I wouldn't be surprised if a lot of people will find these problematic.

They were sourced for (re)testing from here:

https://ia902503.us.archive.org/view_ar ... 429%29.zip

EDIT:

Others from the No-Intro set that don't work as expected:

Outback Joey (USA) [requires specialized hardware, only works on BlastEm]

QuackShot Starring Donald Duck (World) (Rev A) [GoodGen said it was a bad dump, Sega Retro says it's correct - larger version with md5sum of 3d79d2fcc2038b140f7481b6f64a5038 works]

Sonic & Knuckles + Sonic The Hedgehog 2 (World) (Rev A) (Lock-on Combination) [last worked on an ancient version of the legacy Genesis core from 20190110, Sorg explanation here: https://www.atari-forum.com/viewtopic.p ... f9#p374647 and https://www.atari-forum.com/viewtopic.p ... f9#p374651, the SmokeMonster hack with md5sum bdd13934f4f31bf4d849ef8597d4a07c works]

Use the HTGDB rom collections on archive.org. Work like a charm and are already MiSTer curated.

neogeo81 wrote: ↑Wed Oct 18, 2023 3:53 pm

Use the HTGDB rom collections on archive.org. Work like a charm and are already MiSTer curated.

Almost. The two Triple Play games included in the most recent HTGDB collection are still busted.

rhester72 wrote: ↑Wed Oct 18, 2023 5:20 pm

neogeo81 wrote: ↑Wed Oct 18, 2023 3:53 pm

Use the HTGDB rom collections on archive.org. Work like a charm and are already MiSTer curated.

Almost. The two Triple Play games included in the most recent HTGDB collection are still busted.

which ones?

neogeo81 wrote: ↑Thu Oct 19, 2023 6:48 am

which ones?

fb2f3c6fe0c3ba9fd55dc64e8cd8ec74 Triple Play - Gold Edition (USA).md
02bc38b3dc1d26035f421660abbe9357 Triple Play 96 (USA).md

should be replaced with

12ba891983dab9749bdaeb7dc8491de8 Triple Play - Gold Edition (USA).md
a214cbc398eb4e6962186bbd69144d9e Triple Play 96 (USA).md

Are the two cores tied together somehow regarding filtering/downloading?

I use filters to only download the cores I want in downloader.ini. I have both Genesis (old one) and MegaDrive (new core) cores installed.

When I try to !genesis it removes both cores.

BDCMister wrote: ↑Mon Oct 23, 2023 11:02 pm

Are the two cores tied together somehow regarding filtering/downloading?

I use filters to only download the cores I want in downloader.ini. I have both Genesis (old one) and MegaDrive (new core) cores installed.

When I try to !genesis it removes both cores.

It's been like this since the Megadrive core was released. For now they are linked.

rhester72 wrote: ↑Sat Sep 02, 2023 5:38 am

Outside of NeoGeo, none of the other cores are replicas of original hardware at a transistor level. They replicate functionality. Cycle accuracy, just like any other form of emulation, is dependent on the relative accuracy of the implementation.

To me this is really disappointing and downgrades this kind of FPGA Cores to software emulation level.
Is there a list of cores that are actually replicas of original hardware at transistor level other than Genesis Nuke MD and NEOGEO?
What about Arcade cores?
and what about Analogue products or Mars?

Arcade cores are often translated directly from MAME source code. I can't speak for other products.

As has been discussed many times on these forums by now, the primary advantage to FPGA is massive-scale parallelism, not necessarily accuracy. In the latter sense, FPGA has no inherent advantage over software emulation.

Not to forget, amongst many other things, that on FPGA you have direct access to the HDMI encoder and direct I/O Pins for SNAC. Regular CPU based systems have to go through graphics drivers and GPU first for graphics, and sound drivers for sound, until you get to the HDMI video/audio out. Audiolag is not often discussed but very real with software emulation. Input goes through USB first, so there's no SNAC either.

There are certainly many (MANY!) latency benefits...I was referring purely to accuracy. I'm not sure who first started the trope about FPGA being more accurate "because it's hardware instead of software", but if I ever meet them in a dark alley, they shall pay. LOL

rhester72 wrote: ↑Thu Dec 07, 2023 6:03 pm

There are certainly many (MANY!) latency benefits...I was referring purely to accuracy.

I consider latency (audio, video and input) as a part of overall accuracy so, with all with other things being equal from the "emulation" side of things, I'd still consider a less laggy solution to be more accurate just because of that.

I'm not sure I can get on board with that definition of 'accuracy'...fidelity, perhaps.

If for example the sound happens 50-200 ms after the image, how is that not inaccurate?

Because nobody gives a whit about latency if the gameplay is inaccurate, which is where accuracy is normally defined.

Take Bubble Bobble, for instance. Without a proper decap of the MCU, for decades emulation of such an old game suffered to such a degree that gameplay was severely impacted.

If you took that and made it ultra low latency...would it matter? Of course not. And therein lay the critical distinction between accuracy (reproducing behavior as it was) and fidelity (reproducing the experience as it was).

rhester72 wrote: ↑Fri Dec 08, 2023 3:46 am

Because nobody gives a whit about latency if the gameplay is inaccurate, which is where accuracy is normally defined.

And that's precisely why I said "with all with other things being equal from the "emulation" side of things", which means, between two EQUALLY accurate (but even equally inaccurate) implementations, one using traditional software emulation and the other using fpga, the latter IS more accurate, since at least depicts the response time of the original hardware more accurately.

The fact they both have other SAME (again, all things being equal) issues doesn't negate the fact the less laggy solution would still be more accurate.

If you took that and made it ultra low latency...would it matter? Of course not

Of course, yes: it will still be more accurate than a software emulation that would have the SAME issues (the "equally" was a keyword in my first sentence).

You might have had a point if we were comparing two different results, like a perfectly playable software emulation with some expected lag but no issues or bugs, against a different fpga implementation that tried for total accuracy and for some reason failed, resulting in a very buggy or unplayable because of that, but with zero lag.

In that case yes, of course the software emulation is both better and more accurate, but that's NOT the case I was making. I assumed all other things being equal, with just lag being the difference: it's clear in this case the fpga IS more accurate.

And therein lay the critical distinction between accuracy (reproducing behavior as it was) and fidelity (reproducing the experience as it was).

In modeling, they are the same:

https://acqnotes.com/acqnote/tasks/fidelity

Definition: Fidelity is accuracy.

https://www.merriam-webster.com/dictionary/fidelity

Fidelity:

the degree to which an electronic device (such as a record player, radio, or television) accurately reproduces its effect (such as sound or picture)

OK, we've reached the level of full-scale pedantry, so I'll leave you to it.

Time for a Turing test for retro emulation?

rhester72 wrote: ↑Thu Dec 07, 2023 6:03 pm

There are certainly many (MANY!) latency benefits...I was referring purely to accuracy. I'm not sure who first started the trope about FPGA being more accurate "because it's hardware instead of software", but if I ever meet them in a dark alley, they shall pay. LOL

Analogue.co who still insist that what they do involves "zero emulation."

rhester72 wrote: ↑Thu Dec 07, 2023 6:03 pm

There are certainly many (MANY!) latency benefits...I was referring purely to accuracy. I'm not sure who first started the trope about FPGA being more accurate "because it's hardware instead of software", but if I ever meet them in a dark alley, they shall pay. LOL

As a broad statement this is as false as the claim that FPGA is the same as emulation.
You can do things with an FPGA simulation that need an unreasonable ammount of raw processing power in software. Within an FPGA you can let the chips run in parallel like it was on the original software. Nothing you emulate in software will run in parallel as on the original hardware and in some cases this limits the accuracy of the emulation.
You can bruteforce a fast enough execution so that the result is the same, but then you need an unreasonable ammount of computing power (and with this energy) to get a result you get on an FPGA in a more power efficient way.

Chris23235 wrote: ↑Wed Jan 03, 2024 9:41 pm

You can do things with an FPGA simulation that need an unreasonable ammount of raw processing power in software. Within an FPGA you can let the chips run in parallel like it was on the original software. Nothing you emulate in software will run in parallel as on the original hardware and in some cases this limits the accuracy of the emulation.
You can bruteforce a fast enough execution so that the result is the same, but then you need an unreasonable ammount of computing power (and with this energy) to get a result you get on an FPGA in a more power efficient way.

You can't have it both ways. It's either capable of full accuracy or it's not...and of course it is.

Yes, it requires a vast amount of compute power in many cases - 3GHz for SNES? You betcha. But that's miles away from saying "FPGA can do it and software can't".

rhester72 wrote: ↑Thu Jan 04, 2024 6:01 pm

Chris23235 wrote: ↑Wed Jan 03, 2024 9:41 pm

You can do things with an FPGA simulation that need an unreasonable ammount of raw processing power in software. Within an FPGA you can let the chips run in parallel like it was on the original software. Nothing you emulate in software will run in parallel as on the original hardware and in some cases this limits the accuracy of the emulation.
You can bruteforce a fast enough execution so that the result is the same, but then you need an unreasonable ammount of computing power (and with this energy) to get a result you get on an FPGA in a more power efficient way.

You can't have it both ways. It's either capable of full accuracy or it's not...and of course it is.

Yes, it requires a vast amount of compute power in many cases - 3GHz for SNES? You betcha. But that's miles away from saying "FPGA can do it and software can't".

Nope, software emulation is not able to do things in parallel as hardware simulation is. This is the way software emulation works. Things are done one after the other in software and not at the same time like in hardware. No way to get around this.

Does it make a difference when comparing emulation on a fast enough system to simulation on an FPGA? Most of the time it does not.

Does this mean both are on the same level when it comes to accuracy? No, it just means both come to the same results. If you mean getting to the same resulty when talking about accuracy you are right, if you mean things should happen the same way they did on the original system an FPGA impementation can be more accurate e.g. when reimplementing a chip using the original schematics.

Obviously I'm referring to the former, because quite literally nobody cares about the latter. If you read the thread on the software vs. hardware emulation topic, parallelism is the first (and basically only) advantage I give to FPGA.

mike911 wrote: ↑Tue Oct 24, 2023 2:01 am

BDCMister wrote: ↑Mon Oct 23, 2023 11:02 pm

Are the two cores tied together somehow regarding filtering/downloading?

I use filters to only download the cores I want in downloader.ini. I have both Genesis (old one) and MegaDrive (new core) cores installed.

When I try to !genesis it removes both cores.

It's been like this since the Megadrive core was released. For now they are linked.

According to theypsilon you now can add !genesis-core to your filter to remove the old genesis core.

See here:
https://github.com/theypsilon/Update_Al ... issues/108

I have 3 Megadrive cores on my Mister, can anyone enlighten me wich one does what? Also it seems that update_all does not pick the latest one for me... I deleted all 3 and this is what I get.

HerrBerzerk wrote: ↑Sun May 05, 2024 7:21 pm

I have 3 Megadrive cores on my Mister, can anyone enlighten me wich one does what? Also it seems that update_all does not pick the latest one for me... I deleted all 3 and this is what I get.

Bildschirmfoto 2024-05-05 um 21.18.06.png

Those are old, not sure how update_all would pull those but these are the current versions as of today:

MegaCD_20240408.rbf
MegaDrive_20240408.rbf