Question: Wave-phasing on the PC engine, how feasible is that?

[Arkhan]

I think the trumpets in the first example sound kind of bad, honestly.      The steeldrums are good, thought.

It sounds like what happens when theres too much going on in FruityLoops and everything starts clipping.

[Michirin9801]

Allright, here's an example of a song using just the wave-phased steel drums, the rest is just regular waves for the baselines, but I also wanted to throw in some sampled drums just to make the song really sound more advanced! Don't worry though, it's just 6 short 8 KHz samples (Deflemask doesn't support 7 KHz)
http://sta.sh/0wwnrqn721w
It's a cover of the first stage theme from Cratermaze (I love that game and its soundtrack♥) In it you can hear just how the steel drums sound on their own, without a not-very-good trumpet getting in the way, it has a little more popping than the other song, but that's probably because I'm using the steel drums on 3 channels...

Here's the .dmf file just in case:
http://sta.sh/074vzxbo5bk

These steel drums only use these 4 waves:
18 20 22 24 26 26 26 26 26 26 24 22 20 18 16 14 10 08 04 02 02 00 02 04 06 10 12 16 18 20 20 22
28 24 24 26 26 22 16 10 08 08 10 16 18 20 18 16 14 14 12 12 10 04 00 02 04 08 10 14 20 26 28 28
18 14 14 14 14 12 12 12 12 14 18 22 24 26 24 20 12 10 08 06 06 08 10 10 10 12 16 20 24 28 26 20
06 04 08 12 18 22 20 18 18 18 20 24 26 24 16 08 04 02 02 10 16 18 16 12 12 16 22 26 28 24 16 10

And every time you play a new note you switch between the four of them in that order on each tick and hold on the 4th one, simple as that!

[elmer]

So, about that popping sound, I've just started using Mednafen because you guys seem to agree that it's the more accurate PC engine emulator out there (although I've been using Wii Mednafen for a while, which btw is MUCH more user-friendly to my experience) and I've loaded up some .hes exports from Deflemask, and I came out with 2 impressions:
1 - Mednafen runs Deflemask's .hes exports much better than pretty much anything else I've used thus far...
2 - Yeah, I can definitely hear the popping sound you've mentioned, but how bad it sounds depends a lot on the pitch of the note and the instrument being used, for example, in higher pitched notes the popping is much less noticeable than in lower pitched notes, and instruments that change the wavetable more quickly and/or fewer times sound much better than instruments that change the wavetable more slowly and/or more times...

Here's the .dmf file just in case:
http://sta.sh/074vzxbo5bk

These steel drums only use these 4 waves:
18 20 22 24 26 26 26 26 26 26 24 22 20 18 16 14 10 08 04 02 02 00 02 04 06 10 12 16 18 20 20 22
28 24 24 26 26 22 16 10 08 08 10 16 18 20 18 16 14 14 12 12 10 04 00 02 04 08 10 14 20 26 28 28
18 14 14 14 14 12 12 12 12 14 18 22 24 26 24 20 12 10 08 06 06 08 10 10 10 12 16 20 24 28 26 20
06 04 08 12 18 22 20 18 18 18 20 24 26 24 16 08 04 02 02 10 16 18 16 12 12 16 22 26 28 24 16 10

And every time you play a new note you switch between the four of them in that order on each tick and hold on the 4th one, simple as that!

Thanks for the .dmf! 

Including that allowed me to easily blank-out all the extra channels except for the steel drum and then export a .hes to look at.

The popping occurs because of a misunderstanding/bug in deflemask.

As bonknuts said, the pop happens when there is a large change in the channel's main volume.

When you upload a new waveform to the PSG, you're supposed to keep the volume the same as it was, and just change the bits that switch the mode into the upload-mode.

So, in your example, whenever the waveform is changed, the HES that deflemask spits out sets the volume+mode register to $00 (volume $00), then uploads the new waveform, then sets it back to $9F (volume $1F).

That causes an audible pop ... particularly with the lousy-and-slow upload code that's probably used in the .hes (assembly-language programmer-types can do a waveform upload a *lot* faster).

They should set the register to $1F, then upload the waveform, then set it back to $9F (or whatever the current volume is).

You *could* make an argument that they should set it to $5F, then $1F, then upload the waveform, and then set it back to $9F ... it depends upon whether you want to reset the waveform address back to 0 before you upload the new waveform.

[Michirin9801]

So, about that popping sound, I've just started using Mednafen because you guys seem to agree that it's the more accurate PC engine emulator out there (although I've been using Wii Mednafen for a while, which btw is MUCH more user-friendly to my experience) and I've loaded up some .hes exports from Deflemask, and I came out with 2 impressions:
1 - Mednafen runs Deflemask's .hes exports much better than pretty much anything else I've used thus far...
2 - Yeah, I can definitely hear the popping sound you've mentioned, but how bad it sounds depends a lot on the pitch of the note and the instrument being used, for example, in higher pitched notes the popping is much less noticeable than in lower pitched notes, and instruments that change the wavetable more quickly and/or fewer times sound much better than instruments that change the wavetable more slowly and/or more times...

Here's the .dmf file just in case:
http://sta.sh/074vzxbo5bk

These steel drums only use these 4 waves:
18 20 22 24 26 26 26 26 26 26 24 22 20 18 16 14 10 08 04 02 02 00 02 04 06 10 12 16 18 20 20 22
28 24 24 26 26 22 16 10 08 08 10 16 18 20 18 16 14 14 12 12 10 04 00 02 04 08 10 14 20 26 28 28
18 14 14 14 14 12 12 12 12 14 18 22 24 26 24 20 12 10 08 06 06 08 10 10 10 12 16 20 24 28 26 20
06 04 08 12 18 22 20 18 18 18 20 24 26 24 16 08 04 02 02 10 16 18 16 12 12 16 22 26 28 24 16 10

And every time you play a new note you switch between the four of them in that order on each tick and hold on the 4th one, simple as that!

Thanks for the .dmf! 

Including that allowed me to easily blank-out all the extra channels except for the steel drum and then export a .hes to look at.

The popping occurs because of a misunderstanding/bug in deflemask.

As bonknuts said, the pop happens when there is a large change in the channel's main volume.

When you upload a new waveform to the PSG, you're supposed to keep the volume the same as it was, and just change the bits that switch the mode into the upload-mode.

So, in your example, whenever the waveform is changed, the HES that deflemask spits out sets the volume+mode register to $00 (volume $00), then uploads the new waveform, then sets it back to $9F (volume $1F).

That causes an audible pop ... particularly with the lousy-and-slow upload code that's probably used in the .hes (assembly-language programmer-types can do a waveform upload a *lot* faster).

They should set the register to $1F, then upload the waveform, then set it back to $9F (or whatever the current volume is).

You *could* make an argument that they should set it to $5F, then $1F, then upload the waveform, and then set it back to $9F ... it depends upon whether you want to reset the waveform address back to 0 before you upload the new waveform.

Oh I see... So is it possible to do a work-around on that that diminishes or preferably eliminates the popping sounds? If you could make it work on Huzak it would be great!

[elmer]

Oh I see... So is it possible to do a work-around on that that diminishes or preferably eliminates the popping sounds? If you could make it work on Huzak it would be great!

Yes, you should write it up as a bug on the deflemask forum, and point them back here if Delek or DeadFish (the ROM-builder programmer) want any more details.

I suspect that it'll be better coming from you, rather than me, because you already have an established presence over there.

And "nope", Huzak won't suffer from that mistake ... but I'm not guaranteeing that that's going to 100% eliminate the pop.

<edit>

Or you can point them to Mednafen's forums. Mednafen's author can tell them all about it, and they might trust her more than us.

[Bonknuts]

They should set the register to $1F, then upload the waveform, then set it back to $9F (or whatever the current volume is).

 Pretty sure that's not going to fix it. I did a bunch of tests, and putting the channel into waveform update mode is the same as silencing the channel (zero volume).

[elmer]

Pretty sure that's not going to fix it. I did a bunch of tests, and putting the channel into waveform update mode is the same as silencing the channel (zero volume).

Ah ... cr*p ... I must have misunderstood what you said when we were talking about this a few weeks ago.    :oops:

One thing ... even if there's a voltage-spike in the circuit that causes the click, the effect of that on the physical speaker movement should be considerably-less with a 200-cycle TIN update of the waveform rather than the slow software-loop that the System Card Player uses, or the simplistic-and-horribly-slow naive software loop that a .hes player probably uses on real-hardware. 

[Bonknuts]

Leave the channel waveform on, set the channel frequency to a specific matched state and TIN to it while it's playing?

[ccovell]

Too bad you can't have the PCE HW play in DDA mode while simultaneously filling the waveform memory with new data... 

[elmer]

Leave the channel waveform on, set the channel frequency to a specific matched state and TIN to it while it's playing?

Is that a question, or a suggestion??? 

At 6-cycles-per byte, what frequency setting would that be?

And then you'd get each byte output to the DAC when you wrote it ... which would provide another (but different) audible glitch, wouldn't it?

[Bonknuts]

...which would provide another (but different) audible glitch, wouldn't it?

Yup. But might not be so harsh. Dunno.

[Bonknuts]

Too bad you can't have the PCE HW play in DDA mode while simultaneously filling the waveform memory with new data... 

You can. (leave the channel in waveform mode -> write to the DDA port, DDA sample gets both output and written to the waveform memory. Not sure what you'd want to do with it though)

[elmer]

Leave the channel waveform on, set the channel frequency to a specific matched state and TIN to it while it's playing?

Is that a question, or a suggestion??? 

At 6-cycles-per byte, what frequency setting would that be?

And then you'd get each byte output to the DAC when you wrote it ... which would provide another (but different) audible glitch, wouldn't it?

OK, so it *might* be technically possible to do this, but the idea fills me with dread over the unknowns, and the potential dependence upon undocumented internal hardware behavior that could have changed between revisions of the chipset. 

If you set the channel's period/frequency to "3", then the documentation says that's exactly 6-cycles per value that's output.

So a TIN instruction to write the waveform (at 6-cycles-per-write) would sync up with the channel's internal address register.

BUT ... when you change the period to "3" ... how do we know when that clocking gets written to the internal counter?

Is it when you write the lo-byte of the period ... or the hi-byte ... or when the current counter hits zero (which could be anytime)?

This sounds, to me, like the perfect kind of experiment for bonknuts! 

BTW ... I really, really, really, wouldn't expect Mednafen to emulate this kind of nasty hardware trick.

[Mednafen]

http://mednafen.fobby.net/junk/pcmplay-neo-noheader.zip

Old demo from 2008 that uses a 6-cycles-per-sample+TIN trick to try to get > 5-bit PCM resolution from one channel by using dithering.  Sounds ok in Mednafen, not so great on a real HuC6280, as I recall(think it sounded like data was being ANDed with other data)...

Don't think we ever tested to see if the corruption was occurring in the latched 5-bit sample, or in the sample memory.

[ccovell]

I wrote this one up quickly... It alternates every second between a square wave and sawtooth wave, and you can adjust the "copying frequency" setting that goes into $0802/3 with L/R on the joypad.  No good results on the real hardware, tho.  It just keeps the square wave and corrupts it slightly.

http://chrismcovell.com/data/TIN_SndTest.zip

An example of the main switching code; perhaps I'm being too methodical?  I tried with and without NOPs, just a stab in the dark.

Code: [Select]

.do_saw:
stz $0800
stw <Copy_Freq,$0802
nop
TIN wave_saw,$0806,32
nop
stw #DEF_FREQ,$0802 ;Write default frequency
rts
Mednafen: your sound example sounds pretty nice on the real HW, but far too quiet.  Is that normal?