YM-2413 real vs emulated

Page 2/4
1 | | 3 | 4

Par gdx

Prophet (3837)

Portrait de gdx

20-08-2020, 18:59

MSX games with good FM music are not very numerous.

Carnivore2 is better but I don't think that's enough to justify the extra cost for what you want to do. If you already have a MegaFlashRom or MegaSram SCC (or if no need), SD mapper megaram 512Kb + an FM cartridge is sufficient for the majority of games.

If you don't mind the price, take Carnivore2.

Par Gradius2

Hero (599)

Portrait de Gradius2

21-08-2020, 08:03

There is NO perfect implementation in FPGA from real IC (*NOT* limited to just sound chip).

Nor will ever be (99,9% sure). R800 is the perfect example of this.

I would do it, but have no money for it.

Par AxelStone

Prophet (2765)

Portrait de AxelStone

21-08-2020, 09:40

Gradius2 wrote:

There is NO perfect implementation in FPGA from real IC (*NOT* limited to just sound chip).

Nor will ever be (99,9% sure). R800 is the perfect example of this.

I would do it, but have no money for it.

Not sure about this. Actually there exist several CPUs implementations that are cycle exact, like M68000 and Z80. On the other side, the most recent core of ZX Spectrum on Mist has passed EVERY test to check hardware, including the complex ULA Snow tests. The Spectrum guys has called it the first perfect clone of Spectrum performed in FPGA.

I think just the opossite: it's only matter of time that every chip count with a perfect implementation. In fact, if you have the original schematics of a chip you can replicate exactly in a FPGA. In this way, you have the exact clone.

Par msd

Paragon (1405)

Portrait de msd

21-08-2020, 09:58

I agree with axelstone. The basic way of designing chips and FPGAs is in principle the same. You could take the vhdl of a FPGA and put in a VLSI. Calling fpga emulation is in my opinion also not the correct thermally. Your fpga 'code' is directly 'executed' by gates. This is different from emulation where things are translated in runtime to the host environment. If a chip is re-implemented in FPGA and it is not 100% the sames as the original I would could this a bad clone, not bad emulation.

Par sdsnatcher73

Paragon (1212)

Portrait de sdsnatcher73

21-08-2020, 10:11

Yes I agree. FPGA is real hardware implementation, not emulation. Currently YM2413 implementation in FPGA is based on reverse engineering (probably in a way that given a known input recreate the output as closely as possible, not by examining the internal of the chip) and is not 100% identical to the Yamaha implementation. I wonder if Yamaha would ever consider producing an FPGA implementation themselves and even sell (I guess one could call) licenses. Those chips were already cheap back in the ‘90s. Licenses would not have to be expensive

Par Grauw

Ascended (9398)

Portrait de Grauw

21-08-2020, 10:30

All I care about is accuracy. Currently OPLL implementations in FPGA are behind on the state of the art (Nuked.OPLL for PC). So although FPGA has nice properties that allows for better emulation than PC (e.g. zero latency), they are currently behind as far as OPLL emulation accuracy is concerned.

And "sound better than the original" is imo a terrible goal. The originals already sound great. Accuracy is the most important. Of course a reduced noise floor or something like that is fine, but "improving" the sound by intentionally deviating from the original, please no.

E.g. consider an SCC implementation which interpolates the waveforms (I think OCM had this for a while). Not only does it make the SCC sound terrible, taking all the warmth (harmonic overtones) out of the sound, but such things can also break special techniques which rely on the stepped waveforms, like for example certain PCM playback techniques.

Par msd

Paragon (1405)

Portrait de msd

21-08-2020, 11:28

Quote:

So although FPGA has nice properties that allows for better emulation

for a better implementation Tongue

Par Grauw

Ascended (9398)

Portrait de Grauw

21-08-2020, 13:11

I disagree with the distinction that the term emulation is supposedly exclusive to processors.

The Cambridge Dictionary has a nice definition of the verb "to emulate";

"To copy something achieved by someone else and try to do it as well as they have."

FPGA OPLLs are emulations, imitations, and no need to sugar coat it because as a true real hardware fan the word emulator leaves a bad taste in your mouth :D.

But you're entitled to your own opinion just as I am to mine, therefore no need to correct me :).

Par msd

Paragon (1405)

Portrait de msd

21-08-2020, 13:12

@grauw. It is a fine line. But in this sense a opl4 emulates and opl2 and opl3 .. I do think there is a difference, which can lead to the same result. But when done with a FPGA there is no interpretation layer at runtime whatsoever.

Par Grauw

Ascended (9398)

Portrait de Grauw

21-08-2020, 13:38

Since OPL4 is built on the same code base as OPL2 and OPL3, which it is an extension of, by Yamaha, I don’t think it is an emulation (or imitation or clone). Put in the words of the Cambridge dictionary, it’s not a copy of an achievement by someone else.

Of course I don’t disagree that FPGA is capable of implementing the OPLL much more true to the original than processors can. But this is separate from the term emulation. Emulation simply indicates the origin of the product, and tells you to not expect this thing to behave exactly like the original.

The quality of the emulation is measured by how closely the original is approximated. The new Nuked.OPLL core is currently the highest quality emulation out there and it is for the PC. Even though FPGA could implement it even better, with no latency, no-one has ported Nuked.OPLL to FPGA yet. So FPGA being “real hardware” gives no guarantee at all about how accurate the emulation is. It’s determined by how complete the understanding of the inner workings of the original is, and how well this is translated into code, no matter the platform.

Try my PCM player on a real OPLL or openMSX 16.0 (with Nuked.OPLL), and then try it on the FPGA OPLL implementations in the 1chipMSX, Carnivore2 and GR8NET.

Page 2/4
1 | | 3 | 4