Previous Page | Next Page

by SmartOne at 3:04 PM EST on January 28, 2010
foo_gep 1.89

"The Street of Rage"
Mute all but FM 4. You'll hear the oscillating pitches.

Zombies Ate My Neighbors:
"Konami Logo" has always been a problem in emulators, but it actually seems okay... It's a bit more scratchy than in Fusion, but that's probably due to Snake's filtering behind the scenes. Maybe Castlevania's "All Clear" scratchiness is because of this as well.

"Zombie Panic"
Listen to the lead during the first seven seconds. The distortion is obvious. It happens throughout this game and many others. Comix Zone, ToeJam and Earl "Funkotronic Beat," etc.

Thank you for fixing "Winged Fortress." Funny how the old one played fine in Fusion using a ROM builder...

Unfortunately I can't test Genesis Plus GX right now other than possibly the SDL port.

edited 3:12 PM EST January 28, 2010

A Project2612 user reported issues with the Dune: The Battle for Arrakis set. I noticed that "Opening (German)" introduces clicking that appears in subsequent tracks and progressively worsens.

edited 10:41 PM EST January 28, 2010
by blargg at 3:03 PM EST on January 29, 2010
Could some FM problems be caused by the differing timing accuracy of a Genesis emulator and the VGM format? Is there any way we can even determine this? I get the idea that lots of fixes for FM sound problems are really introduction of a second problem that cancels out the observed effect of the first, all the while creating yet another problem. Note that the original problem might be in the emulator or the FM sound core, and the fix in the other of these two.

Due to my lack of knowledge of or interest in FM, I'm having to let others work out those issues with GME (huge thanks to kode54 for his work on GME in this regard!). My goal right now is to get the GME code more understandable to others, and make sure it's really easy to swap out sound cores. Currently I'm de-optimizing all the CPU emulators :)
by mudlord at 6:08 PM EST on January 29, 2010
@Franpa: mudlord.hcs64.com/audplugins would be the best place to find them.....

The current version is in a rewrite, again, to accommodate the XMPlay port so there is at least common plugin code, leaving only Winamp/XMPlay specific implementations that are minimalist.
by SmartOne at 11:05 PM EST on January 29, 2010
Blargg, could that easy "swap-ability" of sound cores include the emulation of DAC panning? :D
by Franpa at 11:12 PM EST on January 29, 2010
You mean http://mudlord.hcs64.com/audplugins.html, right?

edited 11:13 PM EST January 29, 2010
by kode54 at 7:46 PM EST on January 30, 2010
Actually, DAC is handled outside of the FM emulator core, so DAC panning would have to be handled externally as well.

Perhaps you could also provide an example of a VGM that utilizes DAC panning to make it easier to test?
by SmartOne at 9:36 PM EST on January 30, 2010
Sonic the Hedgehog 3 "Hydrocity Zone 2"

Uh, shouldn't that be "Act 2?" I understand that DAC panning is a "GME-system" related thing. ;)
by SmartOne at 11:54 AM EST on January 31, 2010
I asked eke about the issues we have been experiencing. Maybe this information will help:

"crackling should not be related to the emulation core but to the audio backend and the way samples are mixed/output"

"yes, timings are important
basically, there are two way to emulate the chip:

1/ at a slower speed so it can output at the desired samplerate (eg. 48kHz): in this case, the samplerate and input clock passed as parameters of the Init() function are used to apply a ratio to all internal counters (FM timers, EG timer, LFO timer, frequency increments, etc) in relation with the amount of rendered samples. See OPN_SetPres function and the "frequency" variable

2/ at the original speed, which is exactly one sample each 144 m68k cycles (144*7 M-Cycles), this is what High Quality FM mode is doing. In this case, the internal frequency ratio is 1.0, which means everything run at the original rate and the frequency increment value are not altered. This makes some high-frequency sounds more accurate. In this case, however, more samples are rendered per frames (and per seconds) so resampling is required.

Another thing to get right are the timings of write to the chips (from BOTH z80 & m68k cpu) regarding to chip execution (i.e samples rendering). For example, when the chip receives a write command that could affect one internal register (and sound ouput), you should also pass the number of FM cycles that have been executed so far (based on the CPU clocks count generally) and run the FM chip up to this point BEFORE actually applying the write.

I could not think about other timing issues,I don't have distorted sound in Genesis Plus, so I don't see how changes I've made recently could have introduced that, that's why I think it has do with the audio back-end or the way writes are synced with chip execution."

"Before I forget, you can also tell them that timings of CPU reads are also important: some games actually use the internal FM timers and poll the FM status flag to synchronize their writes. Without emulating that properly (i.e running the FM chip for the correct amount of samples before processing the read), you can get some badly pitched music."
by blargg at 2:03 PM EST on January 31, 2010
See, timing's an issue that cannot be eliminated with VGM, since the file format rounds times to 1/44100 second accuracy. I'm glad you've actually confirmed that timing inaccuracies cause audible glitches. It shows that VGM is doomed to have these problems, unfortunately.

Re: PCM, I thought most of the FM sound emulators handled that as well. The two main reasons I had GME do it its own way is because FM sound emulators are really slow, so calling it much more often would only make things worse, and because of VGM's timing resolution. Doing PCM myself, I can have the sample writes at the times specified in the VGM, so there's only one level of (time) quantization noise. If done with the FM sound chip, you get an extra layer. Maybe it wouldn't matter for drum samples, being inherently full of noise anyway.

I definitely regret ever having messed with FM sound emulators. They're an endless source of problems, ugh.
by Knurek at 3:04 PM EST on January 31, 2010
Blargg, actually even the 44100 Hz in VGM is more ample than enough. Since VGM logs just the emulated reads/writes, which most of the time are happening way less frequent (say, 50 Hz or somewhere around that).
You only need to emulate the FM chip at it's native frequency to have the sounds... well, sound properly.
At least that's what helped the in_vgm beta to play the problematic songs correctly.

edited 3:05 PM EST January 31, 2010

Previous Page | Next Page
Go to Page 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Search this thread

Show all threads

Reply to this thread:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=http://www.google.com]Link[/url]

[img=https://www.hcs64.com/images/mm1.png]
Password
Subject
Message

HCS Forum Index
Halley's Comet Software
forum source