More PCM driver stuff

Here’s a working, assemble-able version. I changed quite a bit and fixed a bunch of bugs (that’s what I get for writing code and not testing it). I also modified the code and made it more flexible. Now, it can loaded anywhere from rom. Address calculation is done as assemble time, so it doesn’t matter where it is in rom – as long you define some designation address in ram (be it a BSS label already defined or a specific address). It still needs a few more things, but as least you can hear all 4 channels (I hard panned them to left/right). And they all play at their own speed.

🙂

Update: Man, this is getting annoying. Magic Engine, Ootake, and Turbo Engine emulators play this simple rom… incorrectly. ME and TE have a weird speed issue (which should be impossible since this is synced to a TIMER!). Ootake is just grainy. Mednafen, YAME, and real hardware play it fine.

Advertisements

6 Responses to “More PCM driver stuff”

  1. Wahou, very very impressive ..

    but the size of the .pce 😉 …

    • It has all the WF files in assembled into the rom, even though they’re not playing in that demo. But yeah, waves take up a bit of memory 😉

  2. There’s also the issue that these are 5bit waveforms, but stored in 8bit format. So 3bits per sample is wasted space. If someone was clever, they could put speed “insensitive” data interleaved into that part of the sample space. The DAC ignores the upper 3 bits, so it doesn’t matter what’s there. Bit packing or offsetting the MSbit into a separate file, will really slow down the frequency scaler. So packing it as 5bit for this driver, isn’t an option unfortunately.

  3. Weird, my Ootake plays it as well as Mednafen.

    so that means either both are being grainy, or my Ootake is being nice?

  4. If you look at this pic, you’ll see the output of four emulators: http://alexandria66.2mhost.com/~pcengine//sound/emus_output.png

    In order of left to right; mednafen, ootake, yame, magic engine. Notice that mednafen and yame look very similar in waveform. Yet, ootake has this weird disproportion. The bottom peak seems to have more depth than the top trough to peak. Magic Engine.. well, I’m not sure WTF is going on there. The volume cuts down almost immediately and one of the long sample channels ends way earlier than it should. That’s impossible! They all run at the same speed. So, WTF Magic Engine!? Can’t say I’m too surprised. ME consistently does weird stuff for non-already-existing-game… code.

    If you look at the sample closer: http://alexandria66.2mhost.com/~pcengine//sound/emus_output.wav (right click to save. Sorry, but the site doesn’t allow streaming of audio files for some reason). You can see the artifacts more clearly. But you can also see the band limited step synthesis Ootake is using. But at that low of a frequency, it looks wrong. 7khz is pretty far below 44khz and yet some of the waveform peaks have high balancing throws. That just seems too much for that low of a sample res. It could be causing the some noise in the sample too, but I *don’t* think it’s the major reason. I do think this might be the “crunchness” I’ve been hearing in Ootake even for normal WSG channels. More than it should be. (I’m going to do some test sample of Blarggs HES player with the same band limited step synthesis and compare it to Ootakes implementation of it).

    And you can see to some degree “return to zero” in all the emu outputs. (not really important in this, but just an observation).

    From the looks of it, it appears that ootake is either missing sample writes or has something internally very wrong with the sound core. And it isn’t just a visual artifact of zoomed out view of the audio. Zooming in still reveals a totally different waveform that what should be, consistent with the zoomed out view.

    NOTE: I tried both Ootake 2.33 and 2.38. That waveform was recorded using 2.38. Also recorded on the highest quality, but I tested on all settings and it makes no audible difference.

    Edited:

    • Also, see that sharp output on the mednafen one? That’s mednafen emulating the DAC “popping” of the real PCE. The A revisions of the CPUs pretty much fix this, but all other CPUs have this DAC bug (included in Duo units too). All the SGX units I’ve seen and one CoreGrafx I unit I’ve read of, have the A revision CPU. I saw that Old Man was trying to use the PCE channel waveform buffer as a small DMA buffer. Been there, tried that. Worked great on the SGX (easily got 45khz to playback on 1 channel with 7khz timer and 32khz with a 1khz timer). But all other systems, nasty DAC bug showed its face 😦 I think this is why even Bloody Wolf keeps its fancy waveform updating engine for timbre and other effects, to slower than a single frame (like 3-4 frames inbetween updates as the fastest).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: