PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: Bonknuts on November 25, 2016, 09:54:45 AM
Title: PCE PCM
Post by: Bonknuts on November 25, 2016, 09:54:45 AM
I was digging through my PCM code from over the summer, and looked at an unfinished project; 15.3khz @ four 8bit PCM channels using just 2 hardware channels, for a total of 8 channels.
It has no frequency scaling or "mod" type sample-based synth, just regular sample playback. I had problems mixing in the last channel of the 4. So yesterday, I fixed it and it's all working. There's software volume for each mixed channel too. I use the video scanline interrupt to playback a buffer of mixed samples to a paired channel 10bit output. I added up all the numbers, and it's 47% cpu resource to do this. Probably not attractive enough number for some projects, but it's a working example of a proof of concept.
So I started modifying it for 7khz output (no video interrupt required). I'm looking at ~24% cpu resource for the same thing, but at 7khz. So 8channels on PCE, 4 are PCM at 8bit res. I think someone was interested in this (touko maybe?). I dunno, but considering Air Zonk eats up that same amount for its music engine with just one channel - I thought that was pretty good. It's possible to mix more software channels in, but it doesn't seem worth it. I mean, what are you going to do with something like 8 PCM channel anyway???
I might be able to drop the resource down a couple of percentage points on the 7khz 4 channel version with some optimization. I'll have to see what I can do.
Update: Here's my batch of 7khz sample scaling vs 14khz sample scaling demo roms. On the real system, the 14khz performs better than on emulators thanks to the analog filtering. It's still not a difference, or as much as I expected, going with double the frequency. But there is more 'punch' to some of the samples. Or at least on my stereo system. http://www.pcedev.net/HuPCMDriver/7khz_and_14khz.zip <- try them out on the real system (not emulator).
Title: Re: PCE PCM
Post by: Bonknuts on November 25, 2016, 05:18:26 PM
http://www.pcedev.net/HuPCMDriver/8bitmixer_test1.zip That's just two 8bit samples mixed at a time. Anyone have any good 4 sample mix set they can think of to demo this driver?
Title: Re: PCE PCM
Post by: touko on November 25, 2016, 09:11:39 PM
Quote
So 8channels on PCE, 4 are PCM at 8bit res. I think someone was interested in this (touko maybe?)
Yes of course,even if i have already a 2 channel PCM with compression .
Title: Re: PCE PCM
Post by: elmer on November 26, 2016, 04:19:29 AM
http://www.pcedev.net/HuPCMDriver/8bitmixer_test1.zip That's just two 8bit samples mixed at a time. Anyone have any good 4 sample mix set they can think of to demo this driver?
Cool, I really look forward to studying this! :D
But there's no way that I'd give a music driver 25% or more of the frame time ... that's for graphics! :wink:
Now ... if I can cut it down to 2 channels of 8-bit sound, then that seems good to me.
If the sample channels can't be tuned, then they're limited (in practice) to percussion and speech/sound-effects anyway.
BTW ... do you have an estimate of the CPU time taken for 2 5-bit channels with volume control?
As far as a "new" driver goes ... I'm curious about using the ADPCM hardware for a drum channel. :-k
<EDIT>
Whoops ... I thought that you'd released source code rather than a ROM demo. :oops:
Sure ... it sounds good!
There's a little audible crackling in mednafen, but that could easily just be mednafen.
Title: Re: PCE PCM
Post by: Bonknuts on November 26, 2016, 05:51:17 AM
So here's a basic 4 PCM playing at the same time; a long stream followed by 3 other "FX" type samples playing shortly into (voice one, gate of thunder explosion, and a gate of thunder voice).
So this is how I'm handling this: The 4 channels are actually a set of paired soft mixed channels. Each pair reads in an 8bit sample, used a volume table to adjust the sample, and then adds them together. But.. I don't store this as 9bit. I store it as 8bit, which means I saturate on overflow. I do the same for the next pair, but this time the output is 9bit. Using a table, which is precalculated as multiplying all samples by 2 (so 9bit becomes 10bit) and divided into upper 5bits and lower 5bits (it's a split table) to be store in a set of buffers.
So while the H-int PCM Driver is always outputting 10bit audio (in this 15.3khz version), the "mixer" can do all kinds of things, with all kinds of configurations (as well as the resource it takes to do whatever). You can use different mixers as long as they output to that specific buffer.
Ok, so the buffer: 256 bytes each for high and low. The display has 262 or 263 scanlines depending on mode you choose, but I only output 256 samples regardless. So ever so many scanlines, a sample is not output ( I think this is something like 30 or 40 lines, I forget). Since the rate is so high, you won't hear the this.
There's a couple of reasons I did this: both on the mixer side and the Hint PCM driver side, it makes things much easier. I also, with my conversion util, make sure samples all have a multiple length of 256byte blocks. Silence is appended to the sample block if the original sample ends premature of the 256 block boundary. This isn't an issue, because you don't need to start another sample MID frame.. only on frame boundaries. It makes mixing and play so much faster and at the MOST, your sample will be 255bytes longer than normal. What this translates into on the mixer side, is that you don't need to check EOF for every byte that you read. Multiply that check by 256, and then multiply that by 4, and you'll see that it quickly adds up.
As for the mixer, why don't I just mix 8:8 to 9bit, and 8:8 9bit, and then 9:9 to 10bit. I could, and that's all in the whatever mixer module I choose to use with the Hint PCM driver. But for now, I'm looking speed.
In the current driver that I'm using (8:8->8, 8:8->8, 8:8->9, 9*2), you might notice that I'm mixing beyond my capable resolution. But cause two 8bit samples added together really need 9bit to represent it. So in cases where it overflows, I saturate it at #$ff. You might be thinking, that's got to sound horrible. It can, if your samples are near max amplitude as an average. In this next example, I boosted the amplitude of all samples to be really loud. But to avoid to distortion, I set the volume of all channels using 8bit samples to 11 bout of 15. This is roughly equivalent to 7.5 bit resolution. There is less occurrence of "clipping", they sound loud enough, and resolution is pretty good.
On more thing to add: the mixer and current samples, mixes unsigned samples. This is done for speed (the clipping thing). It sound fine, but there's a catch for any samples that start with a length of silence (though there shouldn't be, that's wasteful), and end with silence - there's going to be a pop. The way this works, is that the lower sample amplitude is 00. An unsigned 8bit sample center lines at $80. So a string of $80 is silence. If a sample trails with this, and is removed, you go from $80 down to $00 for that channel. That's going to result in a pop. So a small ramp to 0 is required to remove the pop. The same could be said of samples that have larges parts of silence - ramp down to 00, then ramp back up 00 at the end of the section - but this isn't for popping, but giving back the other mixed in channel of the pair its resolution.
If this unsigned mixing sound convoluted in design, it kinda is. But it's surprisingly easy to work with. And it sounds great. The issue when working with higher rate playback, is that it affects a lot of things. The 65x is a faster processor for tight data sets, once you start to move outside this range - performance starts to really drop off. There are ways to handle it, such as subdividing the data set into smaller chunks but with lots of multiple code paths - results in code bloat and some complex code that can be difficult to follow (debug or understand). Any, my point is - is that something has to give and I chose to change the mixing approach as my main approach.
Here's an example of the tail end of a sample ramp down to avoid popping the output: (http://www.pcedev.net/HuPCMDriver/hypercocoon.png) Pretty simple stuff.
And here's a example output; all 8bit samples played at volume 11 (out of 15; linear volume scale). So you can judge the results for yourself:
http://www.pcedev.net/HuPCMDriver/8bitmixer_test1.zip That's just two 8bit samples mixed at a time. Anyone have any good 4 sample mix set they can think of to demo this driver?
Cool, I really look forward to studying this! :D
But there's no way that I'd give a music driver 25% or more of the frame time ... that's for graphics! :wink:
I understand. There's always a trade off for something. Honestly, shmups tend to be the most active in the sound FX department IMO. This was primarily my idea for this mixer; when the big explosions samples happen in Blazing Lazers, the drum samples and some other samples immediately drop out. When playing something like GOT or LOT, that have CD audio and loud FX - it's not as noticeable. But even then, you can't have a loud creative death scream and explosion sounds at the same time with single channel ADPCM. What I envisioned was something along those lines. Of course, it works with chip music too: 2 channels reserved for drum kit and other music related samples, and two channels for awesome FX. I would give up 25% resource for that in a shmup no sweat.
Quote
Now ... if I can cut it down to 2 channels of 8-bit sound, then that seems good to me.
If the sample channels can't be tuned, then they're limited (in practice) to percussion and speech/sound-effects anyway.
Pretty much. There's no frequency scaling here. It's you basic sample playback of PCE, but with more channels without using more hardware channels, and greater bit resolution. The 7khz version is less modular at the moment, so you can't just change out mixers. I might change that and make it like the 15.3khz version, but still using the TIRQ. I'll have to play around with the numbers. If I did the modular version, then they PCM driver doesn't care how many mixed channels there are because it always outputs a buffer to a paired hardware channel set. The downside of the modular version, is that you need two sets of paired buffers (4 x 117 bytes total). Most flexible, but eats up some ram.
Quote
BTW ... do you have an estimate of the CPU time taken for 2 5-bit channels with volume control?
At 7khz? At fixed frequency? Uncompressed? It looks pretty much like this:
.ch1.on lda #01 sta $800 .ch1.bank lda #00 tam #nn .ch1 lda $0000 bmi .ch1_control sta $806 inc .ch1+1 beq .msb_ch1 pla tam pla stz <PCM_In_Progress rti Sits in ram. Self modifying code. Plays nice with the Hsync interrupts. If Hsync interrupts for whatever reason takes too long, this interrupt has protection so it can't be called more than once. The self modifying labels ".ch1.on" would replace the opcodes with BRA $nn if the channel was disabled. This allows you to use both samples and regular use; the channel wouldn't be just reserved for sample use. Since it's hardware channels, independent, volume only needs to be handled on a 60hz or less basis and not in the driver itself. And since it's hardware, no soft volume translation needed. You'll have to count those cycles to see what it comes out to, ignoring bank adjustment cases. I tend to either do 116 samples a frame by resyncing the TIRQ in Vblank int, or 117 as the same as 116 +sync, but I make a fake INT call to the routine inside vblank. Though I really can't tell the difference between 7000hz and 6960hz.
Quote
As far as a "new" driver goes ... I'm curious about using the ADPCM hardware for a drum channel. :-k
I can give you the source to a PCE soft ADPCM player. Though it handles saturation in the player itself, but it would be faster to handle those cases outside the player.
Title: Re: PCE PCM
Post by: Bonknuts on November 26, 2016, 05:53:22 AM
bcc .skip00 ;4:6 lda #$ff clc .skip00 sta <D0.l I just realized something.. this is the mixing code for paired channels.. unsigned. Specifically the lda #$ff and clc are needed for overflow.
But.. if I did signed 2's complement method with clamping..
bvc .skip00 lda #$7f adc #$00 .skip00 It's like the 65x was made for this.. lol! I can't believe I missed this. Same amount of cycles, and it handles both overflow cases for signed addition.
Ok.. I'm gonna have to change this whole thing over to signed mixing. Dammit.. I'll have to re-order my 10bit conversion tables.
Title: Re: PCE PCM
Post by: elmer on November 26, 2016, 10:57:15 AM
So here's a basic 4 PCM playing at the same time; a long stream followed by 3 other "FX" type samples playing shortly into (voice one, gate of thunder explosion, and a gate of thunder voice).
So this is how I'm handling this:
Thanks for the detailed explanation ... that's really nice and clever! :clap:
You've put a lot of thought into the implementation details. :D
But there's no way that I'd give a music driver 25% or more of the frame time ... that's for graphics! :wink:
I understand. There's always a trade off for something. ... I would give up 25% resource for that in a shmup no sweat.
Absolutely ... the 4th-gen is all about finding creative solutions to problems, and to designing your game to fit within the bounds of the hardware.
For me, in that example, I'd have the CD music, 1 channel of ADPCM (12-bit samples), and either 1 channel of 7KHz 8-bit samples on the PSG, or 2 channels of 7KHz 5-bit samples (probably the latter).
That would keep the CPU cost low, and the memory cost low, and give decent results without compromising the rest of the game.
But that's just me! :roll:
Quote
At 7khz? At fixed frequency? Uncompressed? It looks pretty much like this:
Thanks, that's nice and simple and fast ... I really like the "fast" part.
Quote
Though I really can't tell the difference between 7000hz and 6960hz.
Yeah, not worth the bother of rsyncing, you won't notice a 1% playback difference.
Even then, you can just resample to 6960Hz in SOX instead of 7000Hz.
Quote
I can give you the source to a PCE soft ADPCM player. Though it handles saturation in the player itself, but it would be faster to handle those cases outside the player.
Hahaha ... you misunderstand me!
I don't want to do realtime ADPCM conversion, either to read or write, it's way too slow for game use.
What I'm talking about would be to incorporate the PCE CD ADPCM playback into the sound driver as another channel.
That way it could be used for high-quality drums/percussion/voice whenever sound effects aren't using it.
It would just be another tool in the sound designer's arsenal, rather than a separate programmer-controlled feature, the way that it is now.
Title: Re: PCE PCM
Post by: Bonknuts on November 26, 2016, 01:53:56 PM
What I'm talking about would be to incorporate the PCE CD ADPCM playback into the sound driver as another channel.
That way it could be used for high-quality drums/percussion/voice whenever sound effects aren't using it.
It would just be another tool in the sound designer's arsenal, rather than a separate programmer-controlled feature, the way that it is now.
What sound driver though? The PSG player? It's been some years since I looked at it, but I suspect (and remember) you need a piece of code that spies/monitors some PSG player attributes as it's parsing other track data, to sync with it and then make its own calls to the ADPCM hardware to play whatever samples in sync. That also means either and outside channel parser that reads the mml byte converted code of the system player, but parse it itself (to keep the compiler happy), or modify whatever compiler to handle as special ADPCM track of code (mml or not - whatever). The easiest way might be to write your own Vbl or TIRQ routine so you can write a hook that executes first before the call to the PSG player.
I dunno. Interfacing it with the unmodified PSG player of the sys card is going to be hack-y. Probably doable, but still hack-y. And probably ugly hack-y too.
Title: Re: PCE PCM
Post by: elmer on November 26, 2016, 03:07:40 PM
We've already identified that the SquirrelPlayer is a disassembled version of the System Card PSG player ... and therefore "tainted" in copyright terms.
Easier to just replace it with a new command-stream-per-channel player.
It could even accept the same bytecodes as the PSG player, if that made any kind of sense.
As Arkhan found out with the SquirrelCompiler ... the System Card PSG player is just a processed form of MML, with some extra bells-and-whistles.
FYI, the sound driver that I wrote back in the 1980s is also based on similar ideas ... it was custom-specified (by the musician) to replace the driver that he'd written for the C64 ... which was MML-based.
The biggest differences are in the byte-coding, and not in the background theory.
Processing a MIDI file, or possibly a Deflemask file, into some bytestream format isn't exactly rocket-science.
Arkhan was concerned with 100%-compatibility with the System Card PSG Player.
I don't see that as a useful/interesting/desirable goal for a new sound driver.
The most-important criteria, if a new driver is to be made at all, would be to make sure that there are usable tools surrounding it.
It's mostly a question of desire, and priorities.
Remember ... Arkhan wrote Squirrel for his own use, because he needed something.
TailChao wrote HuSound for similar reasons.
I'm perfectly-capable of doing the same if I decide that it's in my own self-interest.
Oh ... and we need a sound driver for the PC-FX, anyway. :wink:
Title: Re: PCE PCM
Post by: elmer on November 27, 2016, 04:27:36 AM
I dunno. Interfacing it with the unmodified PSG player of the sys card is going to be hack-y. Probably doable, but still hack-y. And probably ugly hack-y too.
BTW ... If someone actually wanted to make changes to the PSG player, then you wouldn't hack it at a binary level, just modify the source-code and assemble a new version.
After all, the player is available in source-code form, as the "SquirrelPlayer", with TheOldMan's excellent commented disassembly.
Heck, there's the old 2001 disassembly by zeograd and whoever-else that could be cleaned up back into fully-assemblable source.
But ... then you've still got the issue of the modifying the toolchain surrounding it in order to support your new features, and at this point, that means modifying Squirrel.
It's all about the toolchain, and less about the driver.
Title: Re: PCE PCM
Post by: Bonknuts on December 04, 2016, 01:52:24 PM
In the 7khz resampler driver (XM/MOD style frequency scaling), I was curious of how to handle the issue of samples being crush when they were played at higher playback rates but at 7khz output. Initially, and not included in any of the demos I released, some samples would need to be resampled to a low base frequency (something better than nearest neighbor method), and then transposed.
But I got to thinking, what would it sound like if the 7khz XM driver did 14khz instead of 7khz? How would it sound for crushed samples? Did I redid the driver, and the resource surprisingly isn't that bad. The original one, if you played all 4 XM channels AND 2 regular sample channels (6 total) all at the same time - it would take 35.7% cpu resource. I decided, just to move the 4 XM channels into double frequency and keep the 2 fixed channels at 7khz (I was thinking sound FX for them). So 14khz 4 XM channels and 7khz 2 fixed channel = 61.3% cpu resource. That's pretty good. Again, that's all 6 channels playing samples. I could further reduce that if I moved one of the XM frequency channels to the 7khz domain (3x 14khz XM channels, 1x 7khz XM channel, 2x fixed 7khz channels) = 55.9% cpu resource.
Title: Re: PCE PCM
Post by: Bonknuts on December 05, 2016, 02:36:27 PM
I haven't tested the 14khz version on the real system yet, but under mednafen - there really isn't a huge difference. The crushing of some samples, is only alleviated somewhat. Drum/snare/etc are more crisp, but I was expecting a much bigger difference for twice the frequency output. I'm beginning to think maybe it's the 5bit resolution paired with the higher frequency (sample skipping) that is the issue.
I'm gonna do a 7khz 4 channel 8bits and see what that sounds like. I have a feeling it going to sound better than the 14khz one..
Title: Re: PCE PCM
Post by: elmer on December 12, 2016, 05:15:44 PM
Continued on from the MML thread in order to stop Arkhan from getting unhappy ...
On your 2nd channel one. I would add a cli, nop, sei right after .channel4. Your worst case scenario for each channel is 68 cycle delay for H-int, which would probably be fine, but I wouldn't push it with twice that in a worse case scenario.
Why? It's not needed.
You have 455 cycles per scanline.
In your hsync-interrupt planning you already have to make allowances for a 32-byte TIA instruction that disables interrupts for 241 cycles.
I allow any already-triggered hsync interrupts to run at the start of the timer IRQ with the "cli" instruction.
The max time taken in the timer IRQ after interrupts are disabled again is far less than 241 cycles.
Where is the problem? :-k
Quote
Also, by not having a busy flag system (have interrupts open for the whole thing)- you're setup is going to be little less friendly with code using small Txx in 32byte segments during active display - and worse case scenarios in all settings (H-int and TIRQ). Just something to note. Might want to recommend or write block transfers with 16byte or 8byte segments with Txx.
Errr ... now I could be missing something ... but "nope".
My maximum IRQ-disable is far-shorter than a 32-byte TIA.
If another hsync/vync IRQ happens during the 3-instructions that IRQs are enabled, then there is no problem.
If it's another timer-IRQ, then it means that I should have output 2 samples during this time-period ... and I do! I've eliminated the "jitter"!
As-far-as-I-can-see, there is no way that something "bad" can happen here in a single-processor system.
Now, if you go multi-core ... then this whole construct falls apart. :-k
But that's not a problem on the PC Engine.
Quote
Something I'm curious about: Why channel's 3 and 4? Why not channels 0 and 1? Channel 0 saves you 2 cycles. And leaving channels 4 and 5 free allow noise mode for both of those while samples are playing.
No massively earth-shaking reason, just practicality.
Channel 3 for a sampled sound-effect, and channel 4 for a sampled drum.
That leaves channel 5 for a regular drum, and the channels 0,1,2 for regular tune data.
It's just the most-likely usage from my POV. I could be wrong.
Title: Re: PCE PCM
Post by: Bonknuts on December 12, 2016, 06:03:37 PM
Hmm.. let me think about this for a sec..
Txx happens and delays all interrupts by 241 cycles. Lets assume H-int and TIRQ fire near the exact same time, and at the very start of Txx. So, both are delayed by 241 cycles. Actually, I have no idea which IRQ has higher priority.. VDC or TIRQ. Anyway, whatever. Lets assume TIRQ has high priority on the CPU and gets called first. Your TIRQ routine re-enables interrupts 15 cycles after the call. So worse case, H-int is only stalled by 241+15. And 15 is only from the TIRQ routine.
Yeah, that works out pretty decent. Nevermind.
But what I was going to tell you, is that you can leave the channel in waveform mode and write to it like it was DDA. If you set the channel frequency really close to your TIRQ output, you can get weird overlay type of effects. Depending on the sample itself, it can sound interesting or not. I don't have a video to show though.
Or, if you did an 8bit phase accumulator (overflow increments pointer) on a 32byte waveform in memory, you would do rough timing to 'distort' a single channel's instrument waveform over time - giving somewhat predictable timbre changing effects. Like this: But better because this one is waveform updating a single sample at 60hz, not 6960/tick hz. You could make up for the phase accumulator overhead by not having overhead for bank, eof, or msb checks. Why have a phase accumulator? So you can roughly scaling the frequency of the distortion with the scale of the note (based on octave and note).
Title: Re: PCE PCM
Post by: Arkhan on December 12, 2016, 06:09:39 PM
Continued on from the MML thread in order to stop Arkhan from getting unhappy ...
It's not really me getting unhappy. It's the thread being 50+% non-MML discussion that will cause people looking for MML to lose interest in as they sift through the walls of text and technobabble that they don't want to read because MML/music making and balls deep engine code are not really samey.
Title: Re: PCE PCM
Post by: elmer on December 12, 2016, 06:15:41 PM
Actually, I have no idea which IRQ has higher priority.. VDC or TIRQ. Anyway, whatever. Lets assume TIRQ has high priority on the CPU and gets called first. ... Yeah, that works out pretty decent. Nevermind.
The order is ... RESET > NMI > BRK > TIMER > IRQ1 > IRQ2.
I have no idea why Hudson decided that "TIMER > IRQ1", but the cli at the start of the timer handler lets the hsync take priority, if it's already queued-up. :wink:
Title: Re: PCE PCM
Post by: elmer on December 14, 2016, 12:54:21 PM
But what I was going to tell you, is that you can leave the channel in waveform mode and write to it like it was DDA. If you set the channel frequency really close to your TIRQ output, you can get weird overlay type of effects. Depending on the sample itself, it can sound interesting or not. I don't have a video to show though.
Or, if you did an 8bit phase accumulator (overflow increments pointer) on a 32byte waveform in memory, you would do rough timing to 'distort' a single channel's instrument waveform over time - giving somewhat predictable timbre changing effects.
Continued on from the MML thread in order to stop Arkhan from getting unhappy ...
It's not really me getting unhappy.
I know, I was teasing you! :wink:
I like it when threads can organically follow interesting thoughts, and go off-topic for a while ... but, "yeah", we'd gone so far off that we needed to take it somewhere else.
Title: Re: PCE PCM
Post by: Arkhan on December 15, 2016, 04:11:06 PM
Yeah, maybe SOMEONE
NAMED NECROMANCER
CAN MOVE THE OTHER POSTS TO THIS THREAD INSTEAD.
MAYBE.
;) lol
Title: Re: PCE PCM
Post by: Bonknuts on December 15, 2016, 04:42:17 PM
Just create a thread called "the dump" and places off topic musings in there.
Title: Re: PCE PCM
Post by: Necromancer on December 16, 2016, 01:22:21 AM
Tell me exactly which ones to move and I can indeed merge 'em with this thread, but I'm not going to guess which ones don't belong. I'm too dumb to understand what the f*ck y'all are talking about, so I can't really tell which ones need moving.
Title: Re: PCE PCM
Post by: Bonknuts on December 16, 2016, 06:57:31 AM
Just delete my posts in that thread. I mean, I didn't post anything related to MML, midi, squirrel - whatever. No need to move it here. Just delete it.
Title: Re: PCE PCM
Post by: Arkhan on December 16, 2016, 02:55:46 PM
It was useful rambling though.. so I don't know if deleting it is the best move if it can just be merged here, lol
Title: Re: PCE PCM
Post by: elmer on December 16, 2016, 03:16:14 PM
It was useful rambling though.. so I don't know if deleting it is the best move if it can just be merged here, lol
Yeah ... but who *really* wants the source-code examples for playing back samples? :wink:
BTW ... it looks like it'll be safe to play back up to 3 channels of samples with my code before you get to the timing-limit imposed by needing to keep servicing hsync interrupts.
You haven't weighed-in yet upon the channel-selection for the samples, and you're the guy with the most-recent experience of actually creating a game with both music and sound-effect running.
From Chris Covell's YouTube video dissecting the normal channel usage, I'm thinking that the channels 1 and 2 are normally used for the main synth leads.
That leaves three channels out of the remaining four to make sample-capable. But which three? ... And why? :-k
Title: Re: PCE PCM
Post by: Arkhan on December 16, 2016, 03:17:58 PM
It was useful rambling though.. so I don't know if deleting it is the best move if it can just be merged here, lol
Yeah ... but who *really* wants the source-code examples for playing back samples? :wink:
BTW ... it looks like it'll be safe to play back up to 3 channels of samples with my code before you get to the timing-limit imposed by needing to keep servicing hsync interrupts.
You haven't weighed-in yet upon the channel-selection for the samples, and you're the guy with the most-recent experience of actually creating a game with both music and sound-effect running.
From Chris Covell's YouTube video dissecting the normal channel usage, I'm thinking that the channels 1 and 2 are normally used for the main synth leads.
That leaves three channels out of the remaining four to make sample-capable. But which three? ... And why? :-k
the last 3 probably. 5 and 6 can be turned to noise channels. It's likely people will already want percussion there, and that's what the samples are probably for.
I don't think sampling on the first two is a good idea incase you want to use LFO (leads).
Title: Re: PCE PCM
Post by: Windcharger on December 16, 2016, 03:57:23 PM
the last 3 probably. 5 and 6 can be turned to noise channels. It's likely people will already want percussion there, and that's what the samples are probably for.
Having noise for sound effects is important too though. :-k I would think using as many channels that don't have other capabilities as possible would be better as the remaining channels could then use their other capabilities if needed. So maybe using 3, 4, and 5 would be effective leaving 1 and 2 still free for LFO (if wanted) and 6 for percussive noise freedom for sound effects? Just a thought...
Title: Re: PCE PCM
Post by: Bonknuts on December 16, 2016, 04:50:56 PM
I don't think sampling on the first two is a good idea incase you want to use LFO (leads).
Are you talking about hardware LFO? Lol nobody.. nobody should be using hardware LFO to do... regular LFO stuffs. If you want to do non-musical screetchy stuff, kinda like what ccovell showed, then I guess. But I personally think it's a huge waste of a channel, for a system that already should have had a couple more, when you can do so much more interesting sounds with pairing the channels in phase, etc.
I though this was general knowledge, but if not: Every PCE channel is capable of software LFO, and isn't plagued like the master system, or triangle channel on nes, and other systems of that era where you get frequency artifacts when you change the high and low ports of the period system. PCE doesn't have any of those problems with any of its channels, making hardware LFO useless 99.9999% of the time.
Title: Re: PCE PCM
Post by: Bonknuts on December 16, 2016, 04:55:59 PM
the last 3 probably. 5 and 6 can be turned to noise channels. It's likely people will already want percussion there, and that's what the samples are probably for.
Having noise for sound effects is important too though. :-k I would think using as many channels that don't have other capabilities as possible would be better as the remaining channels could then use their other capabilities if needed. So maybe using 3, 4, and 5 would be effective leaving 1 and 2 still free for LFO (if wanted) and 6 for percussive noise freedom for sound effects? Just a thought...
You can easily do LFSR noise in software at 7khz via DDA mode. But that aside, there the philosophy that you use all channels for music, then reserve some lesser sounds of the music for SFX overlay - so the majority of the music is still heard. If you play samples on any channel, just like regular mode - you stop outputting that sample and use the channel for whatever sound FX that occupies it. I.e. if a SFX was made from noise mode, you can stop sample streaming to play the noise SFX just like you would if the channel is in waveform mode. Matter of fact, you can mix and match of any modes at any time, as much as you want.
Title: Re: PCE PCM
Post by: Windcharger on December 17, 2016, 02:26:15 PM
the last 3 probably. 5 and 6 can be turned to noise channels. It's likely people will already want percussion there, and that's what the samples are probably for.
Having noise for sound effects is important too though. :-k I would think using as many channels that don't have other capabilities as possible would be better as the remaining channels could then use their other capabilities if needed. So maybe using 3, 4, and 5 would be effective leaving 1 and 2 still free for LFO (if wanted) and 6 for percussive noise freedom for sound effects? Just a thought...
You can easily do LFSR noise in software at 7khz via DDA mode. But that aside, there the philosophy that you use all channels for music, then reserve some lesser sounds of the music for SFX overlay - so the majority of the music is still heard. If you play samples on any channel, just like regular mode - you stop outputting that sample and use the channel for whatever sound FX that occupies it. I.e. if a SFX was made from noise mode, you can stop sample streaming to play the noise SFX just like you would if the channel is in waveform mode. Matter of fact, you can mix and match of any modes at any time, as much as you want.
I sure am glad we have you here Tom to set the record straight. :)
With that logic it sounds like having them as channels 2, 3, and 4 would be good then as you don't want to put all of your channel abilities in one basket in a manner of speaking. This way choosing to use samples isn't a trade off of any kind on a channel vs using noise mode on 5 and 6 since they are separate, no? Although I suppose this really depends on what types of things the samples would be used for (for example just percussion).
Title: Re: PCE PCM
Post by: Bonknuts on December 18, 2016, 03:46:17 AM
Windcharger: Maybe I should make page 3 of the PCE Cribsheets; audio stuffs. Sometimes it's a lot to keep track of, especially if you're not always working with the hardware directly.
I gave my old analog oscilloscope to me brother.. arrr!. I need to buy a new (used one) in the $400-$500 range. There are certain things I want to document, such as the volume regs not taking updates immediately (the have a frequency range of something like 2khz - from testing with mednafen author). There's also a filtering effect starting around.. IIRC 6khz, which actually makes sample streaming sound a little better on the real system than emulators. Stuff like that.
Title: Re: PCE PCM
Post by: elmer on December 18, 2016, 05:07:30 AM
There are certain things I want to document, such as the volume regs not taking update immediately (the have a frequency range of something like 2khz - from testing with mednafen author). There's also a filtering effect starting around.. IIRC 6khz, which actually makes sample streaming sound a little better on the real system than emulators. Stuff like that.
The more information that's available, the better! :)
BTW ... can you tell me if accessing the PSG registers has the same 1-cycle-extra delay as the VDC registers? :-k
In my new driver, I'm using a TIN instruction to update a channel's waveform, and would like to know if that's going to cause a 17+32*6 or 17+32*7 interrupt delay (it makes a difference, because I need to specifically disable interrupts during the update).
Title: Re: PCE PCM
Post by: Bonknuts on December 18, 2016, 06:05:44 AM
From memory, anything from $000-7ff range in bank $FF has the extra cycle delay (no matter where it's mapped). So from memory, yes 17+32*7. I'll see if I can retest it today to verify.
Title: Re: PCE PCM
Post by: elmer on December 18, 2016, 06:16:43 AM
From memory, anything from $000-7ff range in bank $FF has the extra cycle delay (no matter where it's mapped). So from memory, yes 17+32*7. I'll see if I can retest it today to verify.
OK, thanks!
If so, then I'll have to change the cycle-timings for the sample-playback interrupts, too. #-o
<EDIT>
Hold on a second ... the PSG is at $0800, and reading Charles MacDonald's pcetech.txt seems to suggest that the extra-cycle only applies to the VDC and VCE ($0000-$07FF).
I *may* be OK. :pray:
Title: Re: PCE PCM
Post by: elmer on December 18, 2016, 07:42:00 AM
Here is what the timings are looking like at-the-moment.
Writing to VDC ...
tia $0000,VDC_DATA,32 ; 241 Self-modifying TIN instruction.
Delay 241 cycles.
Writing to PSG ...
mz_update_wave: sei ; 2 No interrupts while writing PSG. stx PSG_R0 ; 5 Select PSG hardware channel. sta PSG_R4 ; 5 Reset this channel's read/write stz PSG_R4 ; 5 address. jsr mz_tin ; 7 Transfer waveform & enable IRQ. ...
mz_tin: tin $0000,PSG_R6,32 ; 209 Self-modifying TIN instruction. cli ; 2 Allow an hsync/timer IRQ to run. rts
Delay 235 cycles.
Additional sample-playback delay ...
tirq_ch234: ;;; ; 8 (cycles for the INT) stz $1403 ; 5 Acknowledge TIMER IRQ. cli ; 2 Allow HSYNC to interrupt.
Delay 15 cycles.
Maximum hsync delay 256 cycles.
********************
And bonknuts (or anyone else), is there some reason why the System Card IRQ1 handler delays processing the hsync interrupt by checking for a vsync interrupt first, and then delays things even more by doing 2 dummy BSR+RTS calls before changing a VDC register?
Has anyone looked at the timing of the hsync interrupt in relation to the VDC's latching of the scroll registers for the next display line? :-k
Title: Re: PCE PCM
Post by: Bonknuts on December 18, 2016, 07:54:35 AM
Hahaha. Sorry, I was thinking of the VCE for some reason :oops:
Title: Re: PCE PCM
Post by: Bonknuts on December 18, 2016, 08:02:51 AM
About the sys card VDC handling routine; I dunno. But I never use it. I opt to use custom handling myself for everything VDC related (which is one jmp indirection, and.. maybe one BBx involved?). Or just straight out replacing the bank in MPR7 with something of my own.
Yeah, checking vsync first is totally ass backwards. The VDC interrupt handler should be optimized for hsync routine - who care about vsync and whatever small delay it gets. But then again, nothing in the sys card lib is really "optimal".
Title: Re: PCE PCM
Post by: touko on December 20, 2016, 09:23:54 PM
i think if you want to decrease the CPU load when you're playing samples, a little buffer can do the job very well . It's the banking which take the most cycles, and reduce it to 1 mapping for 4 samples(4 bytes) for exemple, help a lot .
Title: Re: PCE PCM
Post by: Bonknuts on December 21, 2016, 04:22:06 AM
Quote
and reduce it to 1 mapping for 4 samples(4 bytes)
If switched to a buffer system, there would no mapping (the buffer should be in fixed system ram).
Doing a buffer system is faster, but it also has some requirements. It's going to require a two buffers in ram for all channels; a timer is 1024cycles between interrupt - you're going to copy 4x116bytes in 1024 cycles? Not gonna happen. Even just one channel gets too close for comfort (713cycles via Txx).
It's not just the bank mapping that the buffer system reduces. There's no MSB check on the buffer inside the TIRQ routine. Though that only saves you +2 cycles per sample, per channel. You could remove the EOF marker, and simply have all samples trail out zeros or $0f - both work (any value works, actually). So there's another +2 cycles per sample per channel saved.
Don't get me wrong; I use the double buffer system for my own stuff. But sometimes it's easier when you give other people functionality - to keep the interface a little more simple, and just eat a little overhead.
For a single channel buffer system; you'd save ~1.8% cpu overhead. For two channel buffer, you save ~2.2%. For four channel buffer, you save ~2.7%. It's not a whole lot. The reason being, is that mapping in a channel is only 9 cycles (lda <zp: tam #$nn). The larger overhead is from the tma #n:pha and pla:tam for saving the MPR. That's 16 cycles overhead, but that overheard basically gets divide down as more channels are output inside the routine. So the biggest cost savings is single channel use, relative to per channel savings.
Maybe I should be more clear; if you have 4 samples to stream - you don't map them into 4 individual banks. There's no reason to. You map them in sequential order, to the same MPR reg, as you use them. That way you only need to save/restore one bank for <n> number of channels to stream from. My above overhead savings assumes this. If it didn't, then you'd take the 1.8% and multiple that by the number of channels used as your total savings. But that shouldn't be the case.
What I do like about the buffer system, over the slight savings, is the flexibility of it. You can support both compressed samples and uncompressed samples. You could also support half frequency samples (3.5khz instead of 7khz; some sound FX actually sound decent at this playback rate. There are some PCE games that do this; playback samples at both rates). Do all kinds of stuff, and the main TIMER routine wouldn't have to know anything, other than what's in the buffer.
Title: Re: PCE PCM
Post by: elmer on December 21, 2016, 04:54:15 AM
i think if you want to decrease the CPU load when you're playing samples, a little buffer can do the job very well . It's the banking which take the most cycles, and reduce it to 1 mapping for 4 samples(4 bytes) for exemple, help a lot .
That's an interesting idea, there does seem to be quite a few cycles spent in the banking.
I'd like to have seen an example of how you'd actually accomplish that in practice.
You'd be adding some overhead in creating that buffer every 4th interrupt (and some extra instructions in *not* creating it for the other 3 interrupts).
So it's all going to be in the details, and in how you ensure that you don't keep interrupts disabled for too long.
Here's an example that I came up with that shows the *maximum* benefit that you could obtain by dropping *all* the banking from the interrupts, and just buffering up an entire frame's worth of samples in three 116-sample buffers in RAM. ; Three Channel Sample Playback. ; ; Time (normal 0 channel): 71 * 116 calls = 8236 cycles (6.91%) ; Time (normal 1 channel): 107 * 116 calls = 12412 cycles (10.41%) ; Time (normal 2 channel): 143 * 116 calls = 16588 cycles (13.91%) ; Time (normal 3 channel): 179 * 116 calls = 20764 cycles (17.42%) ; Time (worst 3 channel): 179 * 115 calls + ; 251 * 1 calls = 20836 cycles (17.48%)
OK, here's the first part, and the gain looks good! :)
But you've then got to add the overhead for creating the RAM buffers. :-k
When I do that, with the fastest TII code that I can think of, I get ... ; Three Channel Sample Playback with creating RAM buffer. ; ; Time (normal 0 channel): 6380 + 63 cycles = 6443 (5.40%) ; Time (normal 1 channel): 9280 + 924 cycles = 10204 (8.56%) ; Time (normal 2 channel): 12180 + 1785 cycles = 13965 (11.71%) ; Time (normal 3 channel): 15080 + 2646 cycles = 17726 (14.87%) ; Time (worst 3 channel): 15101 + 2646 cycles = 17747 (14.89%)
That's a 2.6% frame-time improvement at *best*, and I've not dealt with the issue of how to create those buffers safely without delaying the timer interrupt and causing an audio problem.
I'm not sure (yet) that the benefit is worth the cost.
Doing a buffer system is faster, but it also has some requirements. It's going to require a two buffers in ram for all channels; a timer is 1024cycles between interrupt - you're going to copy 4x116bytes in 1024 cycles? Not gonna happen.
Yeah, I was trying to avoid the double-buffer, but I'm not sure that I can easily do so.
You *could* interleave the buffer updates, i.e. update the 1st 16-bytes of each channel within a single TIRQ time-period, and then update the rest ... but your code is getting *excessively* timing-dependant at that point.
Quote
Don't get me wrong; I use the double buffer system for my own stuff. But sometimes it's easier when you give other people functionality - to keep the interface a little more simple, and just eat a little overhead.
Ahhh ... OK, so that's why you're so keen on keeping a consistent 116 interrupts-per frame and resyncing the timer every vsync! :wink:
The simple code doesn't really care whether there are 116 or 117 interrupts in a frame, or the exact synchronization.
Yeah ... the more that I think about it, if the target is a generic sound driver that could be used in HuC as a replacement for the System Card Player, then I'd prefer to keep things simple-but-reliable, and accept the 2..3% CPU hit. :-k
Quote
What I do like about the buffer system, over the slight savings, is the flexibility of it. You can support both compressed samples and uncompressed samples. You could also support half frequency samples (3.5khz instead of 7khz; some sound FX actually sound decent at this playback rate. There are some PCE games that do this; playback samples at both rates). Do all kinds of stuff, and the main TIMER routine wouldn't have to know anything, other than what's in the buffer.
All good points ... but I'll leave that for the "advanced" developers like you! :wink:
Title: Re: PCE PCM
Post by: touko on December 21, 2016, 05:33:13 AM
No needs a big buffer, a 4 bytes buffer /voice is enough,you need to map datas only 1 time for 4 samples . Banking datas each time is 50/60 cycles / sample, it's 100/120 cycles /sample for 2 voices . For 8 samples (4 samples/voice) you lost 400/480 cycles vs only 100/120 with banking. You can reduce drastically the CPU load in your frame .
you can also doing a bit packing to reduce the need of mapping(and also reduce the sample size by 1/3), 3 samples in 2 bytes .
Title: Re: PCE PCM
Post by: elmer on December 21, 2016, 06:11:36 AM
No needs a big buffer, a 4 bytes buffer /voice is enough,you need to map datas only 1 time for 4 samples.
Show a code example, please.
Quote
Banking datas each time is 50/60 cycles / sample, it's 100/120 cycles /sample for 2 voices . For 8 samples (4 samples/voice) you lost 400/480 cycles vs only 100/120 with banking. You can reduce drastically the CPU load in your frame .
You're not making any sense.
Please show some code example of why you think this is so.
The code that I posted earlier has a banking overhead of ... 1 channel sample playback = 27 cycles per timer interrupt 2 channel sample playback = 38 cycles per timer interrupt 3 channel sample playback = 49 cycles per timer interrupt
And 3 channels is the maximum before I'd have to re-enable interrupts or risk delaying an hsync too much.
Are you seeing something wrong in the code that I posted?
Quote
you can also doing a bit packing to reduce the need of mapping(and also reduce the sample size by 1/3), 3 samples in 2 bytes .
Yes, you can, at the cost of more overhead, and more cycles.
Again ... please show a code example of how you're doing all of this without overhead, or provide some timing calculations to show the cost.
<edit>
OK, my code was actually in the MML thread, so here's the latest 3 channel version for reference ... ;**************************************************************************** ; ; Three Channel Sample Playback. ; ; Time (normal 0 channel): 71 * 116 calls = 8236 cycles (6.91%) ; Time (normal 1 channel): 107 * 116 calls = 12412 cycles (10.41%) ; Time (normal 2 channel): 143 * 116 calls = 16588 cycles (13.91%) ; Time (normal 3 channel): 179 * 116 calls = 20764 cycles (17.42%) ; Time (worst 3 channel): 179 * 115 calls + ; 251 * 1 calls = 20836 cycles (17.48%) ; ; Maximum hsync delay: 251 - 25 = 226 cycles
tirq_ch234: ;;; ; 8 (cycles for the INT) stz $1403 ; 5 Acknowledge TIMER IRQ. cli ; 2 Allow HSYNC to interrupt. pha ; 3 tma3 ; 4 pha ; 3 sei ; 2 Disable interrupts.
Title: Re: PCE PCM
Post by: Bonknuts on December 21, 2016, 06:26:52 AM
Ahh ok - I think know what Touko is talking about now. Touko can you post your code example?
Title: Re: PCE PCM
Post by: Bonknuts on December 21, 2016, 06:39:23 AM
I forgot how much better the PCE/SGX sounds through a stereo system. So much more bass-y-er and less tinny than emulation through TV or even earphones on the laptop. And the analog filtering makes is a bit softer on the real system too. I wish emulators could emulate that.
Anyway, here's my batch of 7khz sample scaling vs 14khz sample scaling. On the real system, the 14khz performs better than on emulators thanks to the analog filtering. It's still not a big difference, or as much as I expected, going with double the frequency. But there is more 'punch' to some of the samples. Or at least on my stereo system. http://www.pcedev.net/HuPCMDriver/7khz_and_14khz.zip <- try them out on the real system (not emulator).
Title: Re: PCE PCM
Post by: elmer on December 21, 2016, 09:37:55 AM
I forgot how much better the PCE/SGX sounds through a stereo system. So much more bass-y-er and less tinny than emulation through TV or even earphones on the laptop. And the analog filtering makes is a bit softer on the real system too. I wish emulators could emulate that.
Yes, absolutely. :)
Now, some games, like the venerable China Warrior, have awesome bass (in main tune)... now, imagine how ridiculously awesome the bass is with SUBWOOFER.
:)
Title: Re: PCE PCM
Post by: touko on December 21, 2016, 08:08:53 PM
; // On decale le compteur de sample pour la voix 1 .octet_suiv_voix1: lsr <test_octet_voix1 ; Right shift of the sample to send
.transfert_data_sample_voix1: sta $806
.fin_sample_voix1: ply plx pla
rti
There is 1 voice here,and i use a 2 bytes(3 samples because bits packed) buffer only . After banking i 'am sending the first sample, next interrupt the second, and the next, i depacking and sending the third sample .
Title: Re: PCE PCM
Post by: elmer on December 22, 2016, 05:29:11 AM
Sorry but the comments are in french (some english comments added )
Your English is far better than my French! :wink:
I'm sure that we can manage with a bit of help from Google Translate.
Thanks!
*************************
OK, so now I'm outputting some real music data to the PSG, and it's obvious that the 5-bit volume in PSG register 4 is not linear ... it drops off very, very quickly.
Does anyone have a calibrated liner-volume to PSG-volume lookup table to share?
I can earball it and come up with a rough approximation ... but I don't have an oscilloscope to create a proper one.
Title: Re: PCE PCM
Post by: Gredler on December 22, 2016, 05:36:53 AM
Sorry but the comments are in french (some english comments added )
Your English is far better than my French! :wink:
I'm sure that we can manage with a bit of help from Google Translate.
Thanks!
*************************
OK, so now I'm outputting some real music data to the PSG, and it's obvious that the 5-bit volume in PSG register 4 is not linear ... it drops off very, very quickly.
Does anyone have a calibrated liner-volume to PSG-volume lookup table to share?
I can earball it and come up with a rough approximation ... but I don't have an oscilloscope to create a proper one.
For channel volume, it's 1.5 dB drop per integer. For pan, it's 3.0 dB drop per integer. For main channel volume, 0 is -infinity but that's not true for pan! 0 for pan is not true silence.
Here's a chart I made for Amiga/XM linear to PCE: http://www.pcedev.net/blog/files/XM_volume_tables.txt
Title: Re: PCE PCM
Post by: elmer on December 22, 2016, 06:30:34 AM
For channel volume, it's 1.5 dB drop per integer. For pan, it's 3.0 dB drop per integer. For main channel volume, 0 is -infinity but that's not true for pan! 0 for pan is not true silence.
Here's a chart I made for Amiga/XM linear to PCE: http://www.pcedev.net/blog/files/XM_volume_tables.txt
Thanks! :D
Title: Re: PCE PCM
Post by: touko on December 22, 2016, 07:14:06 AM
Quote
Your English is far better than my French! :wink:
:lol: Easy, but thanks :wink:
Title: Re: PCE PCM
Post by: Bonknuts on December 22, 2016, 08:52:19 AM
Just looking through your code touko:
stz $804 ; // Son à 0 sur la voix 1 ^- I wouldn't do this. If you're trying to silence the channel in DDA mode, simply don't write anything to it (also, writing the same sample value over and over in a row also have the same effect as silence). Otherwise this is going to give you a pop/click on the DAC at the end of a sample, on non SGX systems. It might not be noticeable in loud samples (that have a large amplitude pattern at the end), but ones that end with a built in fade (ending with a soft part) will make this pop/click more noticeable.
EDIT Ok, I understand your compression scheme now. I hadn't seen that one before. It's pretty decent. A nice trade off between size and speed.
Title: Re: PCE PCM
Post by: Bonknuts on December 22, 2016, 11:46:39 AM
Ok. So I mapped out your routine, hopefully with no errors, and I came up with this:
Reload takes 168 cycles -> first sample Second sample takes 86 cycles Third sample takes 102 cycles
There is ~116 calls per frame. And there are three phases to each sample: the lengths shown above. Each phase is a complete path from interrupt call, to output sample, to exit routine.
38.667 = 1/3rd. So 6,496 + 3,325 + 3,944 = 13,765 cycles. or 11.5% cpu resource. That's not bad.
There's a different compression scheme that's a little tighter: it's 5 bytes long. First byte is the MSbit of all 5bit samples. Next 4bytes are pairs of 4bit samples.
Your scheme does 3 samples per every 2 bytes - with a 1 bit throw away, which is a division of 1.5. So 7000 samples, or 1 second, is 4,666bytes in length. The above compression scheme is 8 samples for 5bytes, which is a division of 1.6. So 7,000 samples or 1 second is 4,375bytes. Saves about 291bytes a second over the 3/2 method.
Is it faster or slower? I rewrote your decompression routine from scratch, using the same idea but just that I did a buffer of six samples instead of 3, and the total resource was 9.4%. Not really much lower than yours. So, just to be clear - I didn't use any long double buffer system. Just buffered 6 samples instead of 3, every 6th call.
For the alt compression scheme, 8 samples to 5 bytes, I did a sample buffer of 8 samples. So every 8th call in the TIMER would have to refill it. That ended up being 9.6% cpu resource. So 0.2% slower, but a slightly better compression ratio.
If I have time, I'll see how a double buffer system stacks up to those numbers.
Title: Re: PCE PCM
Post by: elmer on December 22, 2016, 04:27:13 PM
Ok. So I mapped out your routine, hopefully with no errors, and I came up with this:
Reload takes 168 cycles -> first sample Second sample takes 86 cycles Third sample takes 102 cycles
There is ~116 calls per frame. And there are three phases to each sample: the lengths shown above. Each phase is a complete path from interrupt call, to output sample, to exit routine.
38.667 = 1/3rd. So 6,496 + 3,325 + 3,944 = 13,765 cycles. or 11.5% cpu resource. That's not bad.
OK, I've had time to look at the problem now.
First, it's just my personal opinion, but while the 8x1+8x4 (5 byte) scheme that bonknuts mentioned is very clever, it's not worth the tiny 1/16 space-savings, and the complication that it adds, particularly when dealing with the end-of-sample condition.
From there, it's back to Touko's code ...
Mapping stuff into TAM #4 isn't needed, because Touko is already relying on his sample data being aligned on an even boundary, so I removed it, and got rid of the X and Y registers which were wasting cycles.
Then I rearranged the data format a bit to pack the current-state flags into the sample cache for a bit more speed, and used an end-of-sample marker in bit 15 of the sample word, which could also be used for sample-looping ...
... and the result is a 30% speed improvement where the banking takes an insignificant amount of the overall time. ; Three 5-bit Samples in 2-bytes (packet located on an even address boundary) ; ; 2-Byte Packed Data Format Packet + 0 : E332 2222 (sample 3 hi-bits) ; 2-Byte Packed Data Format Packet + 1 : 3331 1111 (sample 3 lo-bits) ; ; E = 1 if end-of-sample. ; ; Timing for sample 1 (122 cycles) if page-overflow ; Timing for sample 1 (110 cycles) if normal ; Timing for sample 2 ( 67 cycles) ; Timing for sample 3 ( 73 cycles) ; ; Time (normal 1 channel): 122 * 1 calls + ; 110 * 38 calls + ; 67 * 39 calls + ; 73 * 39 calls = 9762 cycles (8.2%)
Here's the code, but be warned ... it takes some concentration to follow the data flow and see that it should work ...
.byte3: lda <cache_memory_voix1 + 0 ; 4 A=%033xxxxx and #$60 ; 2 A=%03300000 ora <cache_memory_voix1 + 1 ; 4 A=%133333xx sta <cache_memory_voix1 + 0 ; 4 Set bit 7 to reload data next time. lsr a ; 2 lsr a ; 2 sta $806 ; 5
pla ; 4 rti ; 7
.page: inc <sample_base_voix1 + 1 ; 6 Deal with bank overflow. bpl .end ; 4
Title: Re: PCE PCM
Post by: touko on December 22, 2016, 08:03:44 PM
Quote
I wouldn't do this. If you're trying to silence the channel in DDA mode, simply don't write anything to it (also, writing the same sample value over and over in a row also have the same effect as silence). Otherwise this is going to give you a pop/click on the DAC at the end of a sample, on non SGX systems. It might not be noticeable in loud samples (that have a large amplitude pattern at the end), but ones that end with a built in fade (ending with a soft part) will make this pop/click more noticeable.
Yes i know, but i have not tested on a real PCE, only SGX,and i hesitate with muting balance (i don't know if pop is present with balance )
Quote
Ok, I understand your compression scheme now. I hadn't seen that one before. It's pretty decent. A nice trade off between size and speed.
Oh, I thought it was obvious to do like that .. :-k It's organised like that
you loose 1 bit for 3 samples AAAAACCC ; byte 1 BBBBBCC0; byte 2
sampe A & B are send without any treatment,only sample C is shifted to a correct 5 bits sample . It's fast (30 cycles) with a compression of 33%.
Quote
Mapping stuff into TAM #4 isn't needed, because Touko is already relying on his sample data being aligned on an even boundary, so I removed it, and got rid of the X and Y registers which were wasting cycles.
Hum i see the trick, but it's more complicated to see if you have reached the end of your sample .
Quote
I didn't use any long double buffer system. Just buffered 6 samples instead of 3, every 6th call.
Of course,long buffer is not my goal too and out of question, a 6 bytes can be descent, but no more .
Quote
Then I rearranged the data format a bit to pack the current-state flags into the sample cache for a bit more speed, and used an end-of-sample marker in bit 15 of the sample word, which could also be used for sample-looping ...
Clever ,and your bank overflow deal is clever too ..:P
Quote
Timing for sample 1 (122 cycles) if page-overflow ; Timing for sample 1 (110 cycles) if normal ; Timing for sample 2 ( 67 cycles) ; Timing for sample 3 ( 73 cycles)
The bonknut's results and yours show that i said :P A little buffer decrease the need of mapping and by the way the average of CPU cycles .. :wink:
8.2% is really good, and there are some good ideas here to improve sample playing.
EDIT: I modified my PCM routine a little bit, now the sample finish with the bit 7 of the second byte (if 1), the mapping is now only on MPR3, and remap if a page overflow occur . Thanks elmer, it's mush faster now ;-)
First, it's just my personal opinion, but while the 8x1+8x4 (5 byte) scheme that bonknuts mentioned is very clever, it's not worth the tiny 1/16 space-savings, and the complication that it adds, particularly when dealing with the end-of-sample condition.
I found a few hucards games doing it, but specifically Street Fighter 2 (does it for two sample channels). It's faster than normal bitpacked sample that other PCE games tend to use. I've never seen the scheme touko used.
End of sample is convenient if you have the free bit for it, but it's not necessary. But that is awesome that you fitted it in there. I still like the padded end of sample block method (whatever that block is - 116 samples is the block in this case), where you check in vsync int.
I honestly thought the SF2 method would be faster. It looks simpler IMO (less steps/shifts).
Quote
Mapping stuff into TAM #4 isn't needed, because Touko is already relying on his sample data being aligned on an even boundary, so I removed it, and got rid of the X and Y registers which were wasting cycles.
I didn't catch that he was doing that. I shaved the 6 sample buffer method down to 8.9%, but buffer difference isn't big enough for the overhead (have a pointer of playback buffer) to over come the non pointer method you did with a 3 sample cache system.
Quote
Here's the code, but be warned ... it takes some concentration to follow the data flow and see that it should work ...
A block comment in assembly! I never seen anyone do that - haha. Your code is clean, clear, and and easy to understand. And fast. I'm impressed :D
Title: Re: PCE PCM
Post by: Bonknuts on December 23, 2016, 03:56:24 AM
Touko: Do you need compression? Or are you just using compression on the samples because it's a waste not to? In other words, you expressed interest in the soft mix player I made - the only with 4 channels on two PCE channels. That wouldn't use any compression, because the sample depth is higher than 5bit. Would that mean you're not interested in it?
Title: Re: PCE PCM
Post by: elmer on December 23, 2016, 05:46:45 AM
I calculated the timings for your code vs mine and it comes out as ... ; Timing for sample 1 (130 cycles) if page-overflow ; Timing for sample 1 (122 cycles) if normal ; Timing for sample 2 ( 67 cycles) ; Timing for sample 3 ( 93 cycles) ; ; Timing for finished ( 35 cycles) ; ; Time (normal 1 channel): 130 * 1 calls + ; 122 * 38 calls + ; 67 * 39 calls + ; 93 * 39 calls = 11006 cycles (9.2%)
So you're 1244 cycles-per-frame slower than me, but your code is a bit clearer to follow.
Hum i see the trick, but it's more complicated to see if you have reached the end of your sample .
My point was that you don't need to waste 6 cycles by doing a test for sample-still-playing at the start of every one of the 116/117 interrupts ... it wastes 696/702 cycles-per-frame during normal playback.
It's easy to change my code to set a flag that your main loop can test ... ... lda [ sample_base_voix1 ] ; 7 Read byte 0 of packed data. sta <cache_memory_voix1 + 0 ; 4 bmi .finish ; 2 Test "E" bit for end-of-sample. ...
.finish:stz <sample_playing ; 4
pla ; 4 tam3 ; 5 pla ; 4 rti ; 7
While it looks like my code wastes a lot of time re-reading the end-of-sample marker ... the point is that it doesn't matter in practice!
It takes no more time to do that than it does to actually play the sample ... which you already have to allow for in your game design.
The important thing to do, however you play back the sample, is to disable the timer interrupt entirely if you're not playing back any samples at all.
Of course,long buffer is not my goal too and out of question, a 6 bytes can be descent, but no more .
It would save you a few more cycles in the banking, but you may lose a lot of the time-savings in the extra code/branches to figure out which sample to output.
Title: Re: PCE PCM
Post by: Bonknuts on December 23, 2016, 06:20:42 AM
It takes no more time to do that than it does to actually play the sample ... which you already have to allow for in your game design.
^This. Worst case is what matters. Specifically when the occurrence is kinda random (you'd don't know when you're going to play a sample), so any resource in between 0 and expected ceiling - doesn't matter much IMO. Only the ceiling.
Title: Re: PCE PCM
Post by: elmer on December 23, 2016, 06:33:44 AM
I found a few hucards games doing it, but specifically Street Fighter 2 (does it for two sample channels). It's faster than normal bitpacked sample that other PCE games tend to use. I've never seen the scheme touko used.
End of sample is convenient if you have the free bit for it, but it's not necessary. But that is awesome that you fitted it in there. I still like the padded end of sample block method (whatever that block is - 116 samples is the block in this case), where you check in vsync int.
I honestly thought the SF2 method would be faster. It looks simpler IMO (less steps/shifts).
Does SF2 do the unpacking during the TIRQ, of does it buffer up an entire 116-byte frame? :-k
One of the things that I liked about the 3-in-2-bytes scheme was that it avoided the need to check for bank-overflow in the middle of a packet. With 8-samples-in-5-bytes, I don't think that you can do that.
That's not a problem if you're mapping in 2 banks to build the 116-byte buffer during vblank, but it's expensive to do in a TIRQ.
Plus ... I kinda like having that bit in there to mark the end-of-sample, or to signal a loop-point. :wink:
Your double-buffered scheme is something that I'll need to look at seriously and compare the timings.
Quote
Quote
Mapping stuff into TAM #4 isn't needed, because Touko is already relying on his sample data being aligned on an even boundary, so I removed it, and got rid of the X and Y registers which were wasting cycles.
I didn't catch that he was doing that. I shaved the 6 sample buffer method down to 8.9%, but buffer difference isn't big enough for the overhead (have a pointer of playback buffer) to over come the non pointer method you did with a 3 sample cache system.
Ahhh ... I missed that you'd already tried the 6-sample-at-once method.
Yep, I was afraid that the overhead from keeping track of which sample you're playing would outweigh the savings in the bank switching.
Quote
A block comment in assembly! I never seen anyone do that - haha. Your code is clean, clear, and and easy to understand. And fast. I'm impressed :D
Thanks, that means something, coming from you! :D
And Touko was right ... the overhead of the banking for every sample in the simple playback code that I posted earlier really *was* significant.
I'm very surprised to see it, but the packed playback code is actually a tiny bit faster than simple playback code.
Now I'm not sure if that will extend to multi-channel playback, but the idea of getting a 30% space-savings on sample size for no CPU playback cost is pretty amazing!
In other words, you expressed interest in the soft mix player I made - the only with 4 channels on two PCE channels. That wouldn't use any compression, because the sample depth is higher than 5bit. Would that mean you're not interested in it?
Well, *I'm* certainly interested in seeing the code. :)
Having a high-quality sample alternative for use on Title Screens and places like that would be nice.
It all depends upon the CPU and memory costs.
The only thing that I don't overly like it losing stereo panning.
Having a drum-roll pan across the stereo field, or having a effect come from the left or right, are both common occurrences in games.
Title: Re: PCE PCM
Post by: Arkhan on December 23, 2016, 12:49:25 PM
You could also just limit it to three channels or so, and let the user pick based off their own needs, really.
Id likely only need one channel for drum samples, leaving another noise channel open for crunchy sfx. i cant imagine needing to tie both noise channels up. Three channels of sampled percussion seems excessive, since even Amiga tunes dont really do that.
it would be easy to throw errors at compile time if there is a non possible configuration.
The reason we suggest five and six is that they already support mode switching.
I wouldnt use channel one, because its the only channel that supports lfo, as useless as some say it is.
Again, this is why maybe supporting three, and letting users pick is best.
Personally, the way i set tunes up, i like putting rhythm at the bottom, or far right, depending on if were talking mml, piano rolls, or trackers.
Sticking drums in the middle of a piano roll setup or a tracker tune column thing bugs me personally, lol
Sent from my D6708 using Tapatalk
Title: Re: PCE PCM
Post by: Arkhan on December 23, 2016, 02:56:58 PM
Windcharger: Maybe I should make page 3 of the PCE Cribsheets; audio stuffs. Sometimes it's a lot to keep track of, especially if you're not always working with the hardware directly.
Yep, that would be useful.
Sorry for late response. Holidays in full swing. :)
Title: Re: PCE PCM
Post by: touko on December 23, 2016, 09:49:59 PM
Quote
Touko: Do you need compression?
Not really!
Quote
Or are you just using compression on the samples because it's a waste not to?
Yes, i think 33% lesser with only 30 cycles is not negligible :wink: Of course, without compression, the code is faster and well suited IMO for SCD-rom .
Quote
Would that mean you're not interested in it?
for now i have only hucard project, this why space is important, but i'll try with no compression to see how fast it is vs compression.
Quote
but your code is a bit clearer to follow.
Yes :P
Quote
My point was that you don't need to waste 6 cycles by doing a test for sample-still-playing at the start of every one of the 116/117 interrupts ... it wastes 696/702 cycles-per-frame during normal playback.
It's a first try, i'll see now with a better code organisation if i can do it better . May be without compression .
Title: Re: PCE PCM
Post by: elmer on December 25, 2016, 05:30:07 AM
You could also just limit it to three channels or so, and let the user pick based off their own needs, really.
Id likely only need one channel for drum samples, leaving another noise channel open for crunchy sfx. i cant imagine needing to tie both noise channels up. Three channels of sampled percussion seems excessive, since even Amiga tunes dont really do that.
Yeah, I can't really see the practical *need* for more than 3 channels of samples, and honestly, 2 would probably be enough.
What you're saying is why I was suggesting putting the samples on channels 4 & 5, and leaving channel 6 open for regular PSG-drums or PSG-sfx.
The question is mainly one of "freedom", and programmers don't like it ... flexibility costs CPU cycles.
The sound driver itself doesn't care, and I suppose that it would be possible to provide a couple of different interrupt handlers for different channel selections.
Really? .... block comments are... pretty normal lol. Im surprised youve not seen them in asm code before...
Theyre all over Atlantean, Inferno, and Squirrel stuff!
Yep, I'm originally used to them from things like the FigForth source code and the Atari 400/800 ROM listings.
I don't always put them in my own code when I'm just hacking something up, but it's important (IMHO) to document utility code and functions that might be used by someone else, or that you expect to use for a long time (because you'll forget how it works and why you made certain choices).
So, for these "public" displays of code, which is something that I'd like to see more of here, I believe that it's good to take a bit of extra time.
for now i have only hucard project, this why space is important, but i'll try with no compression to see how fast it is vs compression.
...
It's a first try, i'll see now with a better code organisation if i can do it better . May be without compression.
I look forward to seeing your results! :)
If you drop that initial test, and optimize the flow for the most-common case, then I suspect that you'll get to very-close-to or faster-than my example.
Title: Re: PCE PCM
Post by: Arkhan on December 25, 2016, 08:19:39 AM
I always put block comments. They make me hard.
Id see about just letting users define which channels. Im not sure how youll be writing it, but you should be able to make it a bit dynamic and error out if someone sets up 4+ sample channels.
Sent from my D6708 using Tapatalk
Title: Re: PCE PCM
Post by: touko on December 27, 2016, 04:39:10 AM
Error .., i solved my sound problem 8)
Title: Re: PCE PCM
Post by: touko on January 05, 2017, 10:39:27 PM
Quote
The clicking, if you play the second example, is just me not initializing the driver before sending anything to it (I just haven't got around to it).
How really avoiding the clicking ??
Title: Re: PCE PCM
Post by: Michirin9801 on January 07, 2017, 03:12:29 PM
Umm, sorry for butting in the conversation of experts, a lot of what you've said went way over my head but let me see how much I understand: You're taking 2 of the PCE's hardware channels, which are 5 bit, and putting them together to get a single 10 bit PCM, right? And then you're soft-mixing 4 8 bit samples into that single 10 bit channel... But apparently, the PCE can't natively do different pitches for the same sample, right? But those examples you've shown have the PCE doing different sampled notes... First question: Are those different notes all different samples or are they pitch-shifted notes? And if the latter is the case, how much freedom do you have for pitch-shifting?
When I fire up one of your example ROMs I see the names "XM file" and "MilkyTracker" so apparently I could use OpenMPT to make music for this sound driver, I mean, OpenMPT is XM compatible, in fact, that's the format I use by default because that's the format I can export SNES samples to... Second question: Do you have any idea of when and how will I be able to make music for this sound driver and take advantage of all 8 sound channels? I mean, just the thought of having 8 channels on the PCE already fills me with ideas! I know I'll have my sample-usage limited because of the low memory and all, but Batman did sampled bass, orch-hits and drums on a HuCard, and I'd want to have at least those things sampled, the rest of the instruments can be (and would probably be better off as) regular wavetables, but having a deeper and more dynamic bass sampled from FM playing alongside 2 channels of good'ol sampled drums to make more interesting drums, and still have 4 channels worth of wavetables to compose my melody and harmony and one more PCM for sound effects on top of that would be very welcome!
Title: Re: PCE PCM
Post by: Bonknuts on January 07, 2017, 05:50:44 PM
The rom link that shows XM and milkytracker; that's playing modified XM files. In those files, you have full note range from octave 0 to octave 6, and fine-stepping of 32 units in between each note (XM files only do 16 IIRC). The fine-steps are linear, not period base, so they are the same "weight" regardless of the octave (the opposite case is something that always bothered me with period based systems; nes, pce (native), amiga, etc).
So yeah. It's doing frequency scaling in software, and not a set of prescaled notes. Think SNES, but nearest neighbor instead of filtered. And at 7kz (or 14khz, or 16khz.. depending on the driver). The demo roms that show "xm", are not 8bit samples mixed in 10bit mode. They are just normal 5bit samples. I haven't made a public mixture for the 10bit mode one that does realtime frequency scaling. heh - I worked on this stuff at my leisure because I know the probably of people using the PCM driver, in support of their own music engine or homebrew stuff.. is about null.
The "driver" just gives a programmer an interface/capability to a pseudo hardware function. It's not the music engine itself. The example roms with music, is just a quick hack job to play XM files (it only supports a few FX) - to demo the driver.
What you were trying to do with wave-form phasing, you could just do normally like in an XM file, on the PCE with this driver. But like I stated earlier in the thread; there are different flavors and versions of the driver. The fastest version is the 5bit version @7khz. The 5bit @ 14khz didn't really improve much at all over the 7khz version. So I'm working on setting up a 8bit @ 7khz version (4 channels mixed into 10bit output.. but all those channels will be mono).
Title: Re: PCE PCM
Post by: Michirin9801 on January 08, 2017, 04:17:18 AM
The rom link that shows XM and milkytracker; that's playing modified XM files. In those files, you have full note range from octave 0 to octave 6, and fine-stepping of 32 units in between each note (XM files only do 16 IIRC). The fine-steps are linear, not period base, so they are the same "weight" regardless of the octave (the opposite case is something that always bothered me with period based systems; nes, pce (native), amiga, etc).
So yeah. It's doing frequency scaling in software, and not a set of prescaled notes. Think SNES, but nearest neighbor instead of filtered. And at 7kz (or 14khz, or 16khz.. depending on the driver). The demo roms that show "xm", are not 8bit samples mixed in 10bit mode. They are just normal 5bit samples. I haven't made a public mixture for the 10bit mode one that does realtime frequency scaling. heh - I worked on this stuff at my leisure because I know the probably of people using the PCM driver, in support of their own music engine or homebrew stuff.. is about null.
The "driver" just gives a programmer an interface/capability to a pseudo hardware function. It's not the music engine itself. The example roms with music, is just a quick hack job to play XM files (it only supports a few FX) - to demo the driver.
What you were trying to do with wave-form phasing, you could just do normally like in an XM file, on the PCE with this driver. But like I stated earlier in the thread; there are different flavors and versions of the driver. The fastest version is the 5bit version @7khz. The 5bit @ 14khz didn't really improve much at all over the 7khz version. So I'm working on setting up a 8bit @ 7khz version (4 channels mixed into 10bit output.. but all those channels will be mono).
Oh I see... Being 5 bit explains why the samples sound so delightfully scratchy, kinda like they came from the GBA or something, (which is something I've been wanting actually) And honestly, I'd rather have Mono than the Amiga-style hard-panning... (Btw, was that a limitation or was it intentional?)
To be honest, if I were to make a soundtrack for a real PCE game I wouldn't really use any samples... Well actually, I'd have 2 versions of the soundtrack, one for the regular PCE/TG16 units without the CD add-on, with just the 6 regular channels and wave + noise percussion, and the other for the units with the CD add-on, which would play sampled drums on the ADPCM channel of the CD unit (on a HuCard game btw) and free up an extra channel to play something like another chord note or a delay/reverb effect... I'd want the music to take as little CPU time as possible so that more of it would be available to cram as much parallax scrolling on the backgrounds as humanly possible! ;3
But still, I'd love to use this driver when it's 'ready' to see just how much I can get out of the PC engine's sound, heck, I'd totally port over some GBA songs to the system using the PCM channels to emulate the GBA's direct audio and the remaining wavetable channels to emulate the Game Boy soundchip! Or something like that... If anything, this driver could be used to make a really awesome demo kinda like the ones people do for the C64 and stuff!
Title: Re: PCE PCM
Post by: Bonknuts on January 08, 2017, 06:22:03 AM
Oh I see... Being 5 bit explains why the samples sound so delightfully scratchy, kinda like they came from the GBA or something, (which is something I've been wanting actually) And honestly, I'd rather have Mono than the Amiga-style hard-panning... (Btw, was that a limitation or was it intentional?)
Honestly, it was kind of an experiment to see what kind of samples sounded fine in 5bit. Some sound great, and some not so great. The hard panning was just from the songs I pulled; 5bit sample mode has full stereo space as normal PCE channels. There's a trick that can clean up some "lead" style samples in 5bit mode though - pairing the sample with a normal PCE channel helps mask the lower resolution artifacts. The human ear can't hear "noise" artifacts in loud sounds like it can in lower amplitude waveforms (one of the reasons why old telephone systems would use non linear compression for audio over lines; analog versions a-law and u-law). Blazing Lazers samples for voices on power ups sound horrible by themselves (4bit audio), but in game while the music is playing - they sound more clear. Loudness is key.
Quote
I'd want the music to take as little CPU time as possible so that more of it would be available to cram as much parallax scrolling on the backgrounds as humanly possible! ;3
Who's doing the programming? Parallax tricks, in assembly, aren't very cpu resource hungry if done right. I could see maybe if you're going to extreme ends for parallax (wasting 50% cpu or more for insane stuffs), but I doubt it'd have much impact on a typical PCE game, in assembly, with samples. The HuPCM driver is customizable: if you only need 1 or 2 channels with "frequency scaling" (aka sample-based synth), then the rest as fixed frequency (1 or 2) won't eat up as much as doing all 4 using software sample-based synth. Stuff like that.
I just want an expansion of the PCE sound. I don't want to necessarily replace the PCE sound, but something that works with it. 8bit mixing allows some bass to the PCE (thump/bump), and software samplebased synth gives it much more range with bass style instruments - as well as others (imagine using that orch hit in batman, but at any note/octave).
To give an idea on the 5bit sample-based synth one:
Quote
The original one, if you played all 4 XM channels AND 2 regular sample channels (6 total) all at the same time - it would take 35.7% cpu resource.
Air Zonk sound engine takes up 30% and that's just one sample. So 6% more, and you have all 6 channels playing samples (4 with frequency scaling!). The less channels you want to do for sample-based synth, the less cpu resource you would need.
Title: Re: PCE PCM
Post by: Michirin9801 on January 08, 2017, 08:58:04 AM
I'd want the music to take as little CPU time as possible so that more of it would be available to cram as much parallax scrolling on the backgrounds as humanly possible! ;3
Who's doing the programming? Parallax tricks, in assembly, aren't very cpu resource hungry if done right. I could see maybe if you're going to extreme ends for parallax (wasting 50% cpu or more for insane stuffs), but I doubt it'd have much impact on a typical PCE game, in assembly, with samples. The HuPCM driver is customizable: if you only need 1 or 2 channels with "frequency scaling" (aka sample-based synth), then the rest as fixed frequency (1 or 2) won't eat up as much as doing all 4 using software sample-based synth. Stuff like that.
Umm, nobody, It's a hypothetical situation in case I'd end up working on a PCE game >w> Which I really want to, but first I need to finish this Mega Drive game that I've started before I got into PCE music, after that I have no further plans to work on the MD, it took a really long time to get the system sounding the way I want to, and now that I did get it sounding the way I like I can't change the songs that were already done because the programmer doesn't want them to change... Oh well, all of my future ideas are for the PC engine, the Super Nintendo and the PC-98, but the PC-98 has pretty much no English-speaking market and even fewer dedicated devs than the PCE, so I'll probably end up making just a regular PC game that runs at 640 x 400 at 16 colours and has an OPN/OPNA soundtrack... (Btw, I'm also the one doing the grafx and the level design...)
I just want an expansion of the PCE sound. I don't want to necessarily replace the PCE sound, but something that works with it.
So do I! I'd never want to replace the PCE sound, I couldn't live without dem 5 bit waves~ But I welcome the idea of expansion, especially if it means that I can use sampled basses, drums and orch hits!
Title: Re: PCE PCM
Post by: Arkhan on January 08, 2017, 05:51:43 PM
Paula is hard panned L/R out of stupidity, kind of like how they voluntarily picked that shit tier palette for the C64. They chose those colors willingly. Someone sat down and said "yes, we need two shades of olive, and 3 shades of gray. that is what will make this f*cker look great!"
Amiga music with headphones SUCKED: https://www.youtube.com/watch?v=K0FaAs4M3d0
What kind of MD game are you making? That sounds interesting.
I don't even think the PC-98 really has a Japanese speaking market for anything other than music, last I checked. I think people just realize you could do a PC game, as you've mentioned. It's kind of like trying to make a DOS game now. Just pretend. It's all supposed to be compatible (ish)
There's PC 6001 stuff, and MSX, though.
I can't imagine you'd want to make PC-6001 tunes. Maybe MSX, though.
There's trackers on MSX
https://www.youtube.com/watch?v=tPLXPswbj6A
Suck on that shit, Amiga.
lol.
Title: Re: PCE PCM
Post by: Michirin9801 on January 09, 2017, 04:04:18 AM
Paula is hard panned L/R out of stupidity, kind of like how they voluntarily picked that shit tier palette for the C64. They chose those colors willingly. Someone sat down and said "yes, we need two shades of olive, and 3 shades of gray. that is what will make this f*cker look great!"
Amiga music with headphones SUCKED: https://www.youtube.com/watch?v=K0FaAs4M3d0
Agreed, it just seems like Commodore had a habit of making s*** design choices for their computers, even if the computers themselves turned out good in the end... Kinda like how the Nintendo had technically 64 colours in its palette, but 10 of them are black and 2 shades of grey and white are pretty hard to distinguish from one another, and thus could have been replaced with different colours (Maybe more yellows?)
But to some people those s*** design choices are what gives the respective systems their charm, which I understand even if I don't agree... (Seriously, I hate that hard-panning on the Amiga)
What kind of MD game are you making? That sounds interesting.
I'll talk about it when I have something more presentable to show... I'm currently in the process of remaking all the background graphics pretty much from scratch in order to squeeze some very needed extra colour and detail out of the limited palettes on the MD... But since I'm too lazy and get distracted too easily and grow more of a distaste for the MD the more I work with it I'm doing PC engine music, playing Galaxy Fraulein Yuna and drawing fanart of Yuna on my 3DS instead of actually working on the game... Shame on me I guess...
Title: Re: PCE PCM
Post by: TailChao on January 09, 2017, 04:46:09 AM
I just want an expansion of the PCE sound. I don't want to necessarily replace the PCE sound, but something that works with it. 8bit mixing allows some bass to the PCE (thump/bump), and software samplebased synth gives it much more range with bass style instruments - as well as others (imagine using that orch hit in batman, but at any note/octave).
The AUDIO_IN pin is ready whenever you are. :wink:
Title: Re: PCE PCM
Post by: elmer on January 09, 2017, 05:58:05 AM
The AUDIO_IN pin is ready whenever you are. :wink:
Wow ... bonknuts is going to make a Yamaha FM add-on for the PCE, and you heard it here, first! :wink: :lol: :^o
<edit>
C'mon ... you can get a YMF262 OPL3 FM chip + YAC512 DAC for $1.60 on fleabay ... we could totally blow-away all of those scummy MSX and Genesis guys! :wink: :lol:
Title: Re: PCE PCM
Post by: Michirin9801 on January 09, 2017, 02:51:42 PM
C'mon ... you can get a YMF262 OPL3 FM chip + YAC512 DAC for $1.60 on fleabay ... we could totally blow-away all of those scummy MSX and Genesis guys! :wink: :lol:
Oh I think we'll already blow them away by turning the PCE into a sampler without any extra hardware ;3
Title: Re: PCE PCM
Post by: Arkhan on January 10, 2017, 04:34:41 AM
You're not turning the PCE into a sampler without any extra hardware. It already is one, and always has been, lol. I don't imagine this will really blow away MSX users. Genesis maybe, but probably not.
I get that Elmer's remark was a bit tongue in cheek but, really, MSX's secret weapon is the ability to combine PSG, SCC, and FM together, assuming you want to be that mental and support 3 sound chips simultaneously. Easy with an emulator, but doing a real game requires an SCC cartridge (and SCC chips if you want to make a real cartridge), and the assumption (a fair one) that users have FM.
It's pretty great, and offers a kind of sound PCE can't get to. Micro Cabin's use of FM+PSG confuses me. Their MSX soundtracks were better than the PCE ones, even though PCE was using CD audio for alot of it.
I've not heard anyone else ever replicate what they did.
Title: Re: PCE PCM
Post by: Michirin9801 on January 10, 2017, 04:55:25 AM
You're not turning the PCE into a sampler without any extra hardware. It already is one, and always has been, lol. I don't imagine this will really blow away MSX users. Genesis maybe, but probably not.
Well, I think the ability to play PCM samples doesn't exactly make the system a 'sampler', when I say "Sampler" I mean something more along the lines of the Super Nintendo, with sample looping and pitch-shifting and all, which the PCE cannot do natively (as far as I'm aware at least), but Bonkonuts pulled off in software which is really amazing! Yeah I know Batman pulled off sample looping in software too, but not pitch-shifting, much less software mixing of 4 sampler channels on 2 hardware channels, it had a different sample for each note of the bass and the orch hits...
Title: Re: PCE PCM
Post by: Arkhan on January 10, 2017, 05:10:30 AM
side note: speaking technically here, a "sampler" is the thing that grabs the samples and creates them. Like the goony thing I used to plug into my Amiga to get samples onto it.
I can't say I've heard the term applied to the actual act of sample based synthesis.
It's cool that there's a thing happening to mix/shift/loop samples, but, these sort of things just drive the sound away from sounding like a PCE (assuming you do 6 channels of random shit you sampled).
losing PCE style leads sucks even if the thing replacing it is technically more advanced/better. That's something to always be careful of when getting excited about having something do something it doesn't typically get used for. That's why I'd personally ever only use sampling for percussion, or orchestra hits maybe.
lol "Bonkonuts". another great typo. There's also been "Bonknauts".
Title: Re: PCE PCM
Post by: Black Tiger on January 10, 2017, 05:38:22 AM
I think that full sample shifting bgms should be restricted to stuff like a title screen, menu or stage select screen. It would sound best mixed with chip sounds like many arcades were doing at the time. 4 sample shifting channels with 2 chip sound channels could still sound great and authentic if done right. I think that the key is only using samples, whether pitch shifted or not, for the right kinds of instruments.
Title: Re: PCE PCM
Post by: elmer on January 10, 2017, 06:00:13 AM
C'mon ... you can get a YMF262 OPL3 FM chip + YAC512 DAC for $1.60 on fleabay ... we could totally blow-away all of those scummy MSX and Genesis guys! :wink: :lol:
Well, on 2nd look, I think that we'd actually need a YMF289B OPL3 FM chip + YAC513 DAC, in order to meet the fast memory access timings of the PCE, and those cost a little bit more ... approx $6 per pair. :-k
Oh I think we'll already blow them away by turning the PCE into a sampler without any extra hardware ;3
Errr ... not at that CPU-cost, you won't! :shock:
You're just creating a CPU-pumped soft-synth rompler, in the same way that you can on any old hardware that supports a DAC output and a reasonable memory layout for the samples.
It could be done on an Amiga just as well.
Now ... as I've said, the 4-channel fixed-rate playback into a 10-bit output using 2 PSG channels ... *that* interests me. That may well be practical for in-game usage.
Either way, whatever the cost/performance tradeoff a particular developer/musician team is willing to make, it should be easy to modify Huzak so that it'll use the Deflemask data for whichever channels you wish, and let some other code handle the mixing for the other channels ... or just build the capability into Huzak itself as optional choices at build-time.
The whole point is to have the dmf2pce converter and the driver itself both be Open Source so that anyone can abuse them as much as they desire.
I get that Elmer's remark was a bit tongue in cheek but, really, MSX's secret weapon is the ability to combine PSG, SCC, and FM together, assuming you want to be that mental and support 3 sound chips simultaneously.
Yep, totally tongue-in-cheek. :wink:
I can't see anyone being interested-enough to produce an FM HuCard, even though it would (theoretically) be a fairly easy thing to do on a DUO/SuperCDROM.
From my personal POV, the MSX's base AY-3-8910 PSG is a total piece-of-sh*t (I've used it before), and Konami's SCC is pretty-close to our PCE PSG, so the only real extra that the MSX has (if you buy the add-on) is the Yamaha 8950 9-channel, 2-operator OPL1 FM chip.
So, if we added a Yamaha 289B 18-channel, 4-operator OPL3 FM chip, then we'd totally blow-away the MSX hardware, and actually beat the Sharp X68000's 8-channel, 4-operator YM2151 (which, yes, was also available as an MSX add-on)! :wink:
BTW ... I absolutely *love* the sound of Yamaha's 4-operator FM synths. :dance:
Title: Re: PCE PCM
Post by: elmer on January 10, 2017, 06:24:28 AM
Well, I think the ability to play PCM samples doesn't exactly make the system a 'sampler', when I say "Sampler" I mean something more along the lines of the Super Nintendo, with sample looping and pitch-shifting and all, which the PCE cannot do natively (as far as I'm aware at least), but Bonkonuts pulled off in software which is really amazing!
Well, the sample-looping part is totally trivial.
I have absolutely no idea why Deflemask doesn't support it.
It's only a few lines of extra code, and has no noticeable CPU cost.
Heck ... an attack-sustain-release sample isn't much more code, and still has negligible cost.
It's the frequency-scaling, and then mixing that adds the cost (and the need for buffering).
Title: Re: PCE PCM
Post by: Arkhan on January 10, 2017, 06:41:10 AM
The way you can combine the chips on MSX is what makes it particularly nice. You don't get the OPL4 sound, but what you get is still nice.
Title: Re: PCE PCM
Post by: Michirin9801 on January 10, 2017, 08:04:52 AM
Now ... as I've said, the 4-channel fixed-rate playback into a 10-bit output using 2 PSG channels ... *that* interests me. That may well be practical for in-game usage.
That's exactly what I'm talking about! Giving the PC engine 8 channels, 4 of which are soft-mixed PCM onto 2 hardware channels playing pitch-shifting samples!
It's cool that there's a thing happening to mix/shift/loop samples, but, these sort of things just drive the sound away from sounding like a PCE (assuming you do 6 channels of random shit you sampled).
losing PCE style leads sucks even if the thing replacing it is technically more advanced/better. That's something to always be careful of when getting excited about having something do something it doesn't typically get used for. That's why I'd personally ever only use sampling for percussion, or orchestra hits maybe.
Which is why my idea is to use the sampler channels for a sampled bass, percussion and maybe orch hits and strings, and play the lead and harmonic support in the remaining 4 hardware channels! We could use this driver to combine a sampled MD-style FM bass with SNES style drums, strings and orch hits and the PCE style leads! BLAM! Tenouttaten Tenouttaten Best Sound Best Sound!
Either way, whatever the cost/performance tradeoff a particular developer/musician team is willing to make, it should be easy to modify Huzak so that it'll use the Deflemask data for whichever channels you wish, and let some other code handle the mixing for the other channels ... or just build the capability into Huzak itself as optional choices at build-time.
Here's a suggestion, If Huzak is gonna support Bonknuts' PCM driver that you said you're interested in, why not support both the .dmf and .xi formats? I mean, he can already play .xi files on the PC engine with what he's currently got, and assuming you'll be able to use 4 sampler channels and 4 PSG channels at once you could load the two files and put out a single .hes or .pce file with the song using all 8 channels! As for figuring out which two channels you're gonna soft-mix, well, I suggest channels 3 and 4 so that anyone wanting to use noise mode on channels 5 and 6 would be free to do so, and anyone who would be mental enough to use the hardware LFO would also be free to do so... (I mean no offense to LFO users, but seriously, that thing is useless)
The way I see it working is to use Deflemask for the 4 PSG channels (1, 2, 5 and 6) and then OpenMPT (or whichever mod tracker you prefer) with a 4 channel .xi file... Yeah it would be complicated on the musicians, but at least they'd be able to do 'something' with this driver...
But don't worry too much about that right now, one thing at a time, you first need to get Huzak running and doing its thing right?
That's exactly what I'm talking about! Giving the PC engine 8 channels, 4 of which are soft-mixed PCM onto 2 hardware channels playing pitch-shifting samples!
Avoiding any pitch-shifting is precisely what I'd want to do! #-o
But ... once you've got a version of the driver and IRQ code that uses a sample buffer, then it's trivial (from a driver POV) to choose whether you allow pitch-shifting or not, and see exactly what the cost is.
It's the UI and getting the musician's data into the right format that's the real PITA.
I'm not sure SNES style echo-percussion (TM), and a shitty sampled FM bass will really be best-sound-best-sound.. lol
I have some stuff that would probably make nice samples though.
A Roland or Yamaha drum machine from the 80s has some pretty good percussion samples that would fit in well with PCE style music.
We'll see about that when we actually get to using the sound driver, but for my taste, FM makes the best basses, samples make the best drums, orch hits and strings, and the PCE PSG makes the best leads ;3
Title: Re: PCE PCM
Post by: Arkhan on January 10, 2017, 09:45:51 AM
Yes, but FM synth style bass, when sampled, won't sound quite as good as it should, as we've already discussed multiple times.
For *my* taste, I want the synth style bass to actually sound right. Retriggering is probably going to make it sound off, to me.
Title: Re: PCE PCM
Post by: Bonknuts on January 10, 2017, 01:11:03 PM
Well, screw you haters haha. There's potential in the "sampler" driver. I'm just going to refer to it as that, because I'm sick of typing out sample based synth. "Samplers" is the word used to describe sample based standalone synths in the 90s. So it works for me.
I don't get this whole "for title screens and menus" mentality. If it was that bad, I would even bother (maybe..lol). What NES did with 25% (actually closer to 20% because of the sprite metatile decoding the NES has to do for smaller sprites) is pretty damn good. SMB3 totally plays like a 16bit game. The current driver with all 6 channel eating 36% is nothing! Leaving 64% for game stuffs. Tile screen my ass ;>_> Even if it got fancy or whatever -> went up to 60% cpu resource. That still has potential way beyond "title screens". Maybe not for HuC, but assembly (and for games, not demos) - it's doable. RPGs with SNES sampler style string leads on the PCE? Not interested? I am.
What's with all this MSX stuff? I thought this was a PCE forum. I like MSX as much as I like Speccy - from a distance. It's great fun to watch all the achievements on the systems, but beyond that I don't care. It's a curiosity to me and nothing more.
Title: Re: PCE PCM
Post by: Michirin9801 on January 10, 2017, 01:15:41 PM
Yes, but FM synth style bass, when sampled, won't sound quite as good as it should, as we've already discussed multiple times.
For *my* taste, I want the synth style bass to actually sound right. Retriggering is probably going to make it sound off, to me.
I know it won't sound 'as good' but that doesn't mean it won't sound 'good'... I've sampled an FM bass to use with famitracker on the DPCM channel, kinda like what Sunsoft did with some of their games, and the DPCM is 1 bit whereas the PCE PCM is 5 bit and doesn't support sample looping (not to a useful extent at least), but at least you can pitch-shift the samples in hardware, but you can only down-pitch them at uneven intervals so you need 5 samples with different notes (A#, B, C, C# and D) to get the full scale of notes... All that said, the sampled FM bass sounded pretty good! Albeit too loud, the triangle channel can't even be heard while it plays... Yeah the Triangle sucks for basses, but put together with the Noise channel it can make some pretty good drums! It's all a matter of me editing the samples so that they can be quieter and then re-importing them and remaking the instrument, which I'm too lazy to do and too busy making PCE music instead, which is much better...
Title: Re: PCE PCM
Post by: elmer on January 10, 2017, 02:22:40 PM
Well, screw you haters haha. There's potential in the "sampler" driver. I'm just going to refer to it as that, because I'm sick of typing out sample based synth. "Samplers" is the word used to describe sample based standalone synths in the 90s. So it works for me.
Sure ... you're right, and Akai pretty-much had the market cornered with them, BITD.
The terminology doesn't worry me, in the least.
Quote
Maybe not for HuC, but assembly (and for games, not demos) - it's doable. RPGs with SNES sampler style string leads on the PCE? Not interested? I am.
Then do it! :)
You've found a musician who's raring to go ... get on with it! :D
Let's all stop the "talking", and start more of the "doing" around here ... that's what I've been acting as the sand in the oyster and irritating folks for, for a while now ... :wink:
Show us how darned good it can sound! :dance:
Quote
What's with all this MSX stuff? I thought this was a PCE forum.
'cmon, you know it's not possible to talk to Arkhan about music for more than 60 seconds without the superiority of the MSX coming up. :lol:
(But ... I really do like the sound of Yamaha FM synths, I've certainly bought enough of them.)
Title: Re: PCE PCM
Post by: Arkhan on January 10, 2017, 02:28:04 PM
Let's all stop the "talking", and start more of the "doing" around here ... that's what I've been acting as the sand in the oyster and irritating folks for, for a while now ... :wink:
Agreed. Though, often, the doing tends to taper off and then more talking comes, and then, you get the idea.
Quote
'cmon, you know it's not possible to talk to Arkhan about music for more than 60 seconds without the superiority of the MSX coming up. :lol:
(But ... I really do like the sound of Yamaha FM synths, I've certainly bought enough of them.)
You're the knob that brought it up, lol.
I also don't think it's really superior. It's just different, and has something PCE doesn't, which is 3 different main chips to work with.
But, everyone over there is actually quite jealous that the PCE can pan the f*ckin' sound. SCC can't do that. At all.
and, to be fair, it's a completely relevant topic in this thread. Why single out and bitch about the MSX when MD and SNES are also coming up in this thread?
and Amiga.
just because you, Bonknuts, don't care about it, doesn't mean it's taboo.
We're talking about sound sampling, while comparing and contrasting stuff. Seems OK to me.
I'm genuinely curious if we can get a good FM synth bass sample that is convincing. I have doubts. So, if someone else can get one that doesn't make me go "yeahno", show me.
Title: Re: PCE PCM
Post by: Bonknuts on January 10, 2017, 02:57:12 PM
just because you, Bonknuts, don't care about it, doesn't mean it's taboo.
We're talking about sound sampling, while comparing and contrasting stuff. Seems OK to me.
Dude. I'm just giving you some shit. No worries. It's like, every time MSX is mentioned - it's always by arkhan lol. It's more weird to mention it here on PCE forums because its user base seems to have a pretty big disconnect from PCE (and everything else; it's its own thing).
Title: Re: PCE PCM
Post by: Michirin9801 on January 10, 2017, 03:30:37 PM
The thing about the MSX is that it needs expansion soundchips to really sound 'good'... Don't get me wrong the MSX PSG can put out good music if used right (USAS anyone?) But that's some "Not as good as NES" kind of good, and I'm the kind of person who doesn't even think the NES is THAT good... (Game Boy though is MUCH better because DAC) In my personal opinion, expansion soundchips cheapen the value of the soundtrack while at the same time making the game more expensive... Yeah, the soundtrack is gonna be better with an expansion, but the system couldn't do that soundtrack without the expansion...
Personally, I'm more interested in what the system can do out of the box, which is why one of my Famitracker rules is "No expansions! Raw NES only!" and I'm all for pushing the limits of the system which is why I'm such a big fan of the Sunsoft DPCM bass and why I'm that much more impressed when I see parallax scrolling on the PC engine, the NES and the GB/GBC than when I see it on the SNES or on the MD for example... Those systems already have 2 or more BG layers out of the box, parallax for them is like, no sweat, in fact, all the more reason to be disappointed with them when they don't do it (except on top-down games, those don't really need parallax other than some very specific instances) And that's also why I asked about wave-phasing, that was meant to be an easy-on-the-CPU way to get sample-like instruments on the PC engine! (Kind of)
With all that in mind it's no wonder I'm so excited about Bonknuts' sampler driver, it's gonna pretty much break the limits of the PCE without the need for any expansions! Now don't get me wrong, it's not like there aren't any exceptions, I was the one wanting to use the CD ADPCM to play percussion samples and free up a PSG channel to play something else on a HuCard game, and I've made it no secret that I'm a huge fan of the SNES, and the system uses a f***ton of expansion chips! (But you know, none of them are 'sound expansions', the SNES didn't need any sound expansions because it already sounds better than real life ;3)
Maybe not for HuC, but assembly (and for games, not demos) - it's doable. RPGs with SNES sampler style string leads on the PCE? Not interested? I am.
Then do it! :)
You've found a musician who's raring to go ... get on with it! :D
If you're talking about me, you're absolutely correct ;3 I am VERY interested... (But first I gotta finish dat gaem...)
P.S. I also make Grafx in case someone didn't catch it, check out this example I did within the MD's limitations: (http://orig04.deviantart.net/68dd/f/2016/175/e/b/retile_3_by_michiharuruko-da6unbz.png) There's 3 overlapping layers, the tree in the middle layer is a sprite, I think you get how it works from just looking...
Title: Re: PCE PCM
Post by: Arkhan on January 10, 2017, 04:17:17 PM
Msx2+ has onboard fm, and FM is part of the MSX standard, so, its not really an expansion at that point.
A large portion of the library uses it. So, calling it an expansion is a bit limp.
Are you coding the MD game, or just art and tunes?
@bonknuts, oh, couldnt tell.
The msx scene has a good handle on PCE, though. They just dont come here.
Dunno why its weird to mention it here. No wierder than any other computer. Like Amiga, lol.
Sent from my D6708 using Tapatalk
Title: Re: PCE PCM
Post by: Michirin9801 on January 10, 2017, 04:43:48 PM
Are you coding the MD game, or just art and tunes?
I can't code for s***, I'm strictly an artist >w>'; I'm having help from 2 programmers, and we're making the game for the PC first, 'after' the PC version is completed THEN the MD version will be made... That said though, we're thoroughly respecting the limitations of the MD on the PC version (with the exception of sprite flickering, not like there's gonna be much of it) so both versions should be pretty much identical (hopefully)
Title: Re: PCE PCM
Post by: TailChao on January 10, 2017, 05:08:03 PM
C'mon ... you can get a YMF262 OPL3 FM chip + YAC512 DAC for $1.60 on fleabay ... we could totally blow-away all of those scummy MSX and Genesis guys! :wink: :lol:
Well, on 2nd look, I think that we'd actually need a YMF289B OPL3 FM chip + YAC513 DAC, in order to meet the fast memory access timings of the PCE, and those cost a little bit more ... approx $6 per pair. :-k
You also need an oscillator and will only get mono audio anyway.
Those great 5V ARM microcontrollers from Cypress you brought up over a year ago are still the best solution here. Analog out is included, and if you add some sort of bidirectional comms in a mapper you can use it as a Cypress FX.
I ended up going with the FM3 family for my current project (specifically the MB9BF524K) and ported over my Windows softsynth without any huge issues. But this is a full music player, and I think in the case of the PCE it would be more useful to just complement what's already in the box.
BTW ... I absolutely *love* the sound of Yamaha's 4-operator FM synths. :dance:
Fantastic sound, whole OPN family is really cool.
Although if you're just looking for chips to mess with the YM2608 is pretty well rounded compared to the others. I did start building a HuCard with an MC-Genjin + YM2612 on it a few years ago but never finished it for the sourcing reasons above.
Dude. I'm just giving you some shit. No worries. It's like, every time MSX is mentioned - it's always by arkhan lol. It's more weird to mention it here on PCE forums because its user base seems to have a pretty big disconnect from PCE (and everything else; it's its own thing).
We're just lucky nobody needs to complain about shitty scrolling in PCE games, otherwise the MSX would get invoked every 4th post!
Title: Re: PCE PCM
Post by: Arkhan on January 10, 2017, 05:24:34 PM
Ah, thats pretty cool. Im curious to see what it is when the game is done.
Msx though, is like pc88 and 98... the fm wasnt originally in them. They added it later as an expansion card, as it didnt exist when the computer was originally released.
( ‘-^ )b
Thats one perk to computers! You can stay with the hardware as it arrives, way easier than a console, lol.
Sent from my D6708 using Tapatalk
Title: Re: PCE PCM
Post by: Arkhan on January 10, 2017, 09:45:58 PM
Dude. I'm just giving you some shit. No worries. It's like, every time MSX is mentioned - it's always by arkhan lol. It's more weird to mention it here on PCE forums because its user base seems to have a pretty big disconnect from PCE (and everything else; it's its own thing).
We're just lucky nobody needs to complain about shitty scrolling in PCE games, otherwise the MSX would get invoked every 4th post!
Lolol just saw this.
I have to laugh when people use that as their way to dismiss msx, citing youtube and never actually playing one.
Thats a good example of real hardware or at least ok emulation mattering. Youtube drops frames and makes the chunk scroll look worse than it is.
And even so, it doesnt really ruin the games. Id take msx gall force over fds!
Sent from my D6708 using Tapatalk
Title: Re: PCE PCM
Post by: ccovell on January 11, 2017, 11:22:20 AM
Dude. I'm just giving you some shit. No worries. It's like, every time MSX is mentioned - it's always by arkhan lol. It's more weird to mention it here on PCE forums because its user base seems to have a pretty big disconnect from PCE (and everything else; it's its own thing).
We're just lucky nobody needs to complain about shitty scrolling in PCE games, otherwise the MSX would get invoked every 4th post!
Lolol just saw this.
I have to laugh when people use that as their way to dismiss msx, citing youtube and never actually playing one.
I would never dis the hardware having never played on the real thing; that would make me look like an idiot. No, I've played games on real MSX computers, and after 10 minutes the shake & bake scrolling made my eyes hurt. Even ZX Spectrum games often did a better job.
Title: Re: PCE PCM
Post by: elmer on January 11, 2017, 02:06:17 PM
P.S. I also make Grafx in case someone didn't catch it, check out this example I did within the MD's limitations: (http://orig04.deviantart.net/68dd/f/2016/175/e/b/retile_3_by_michiharuruko-da6unbz.png) There's 3 overlapping layers, the tree in the middle layer is a sprite, I think you get how it works from just looking...
I meant to mention this before ... that looks really good, to me, nice work! :)
Title: Re: PCE PCM
Post by: Michirin9801 on January 11, 2017, 02:27:10 PM
Dude. I'm just giving you some shit. No worries. It's like, every time MSX is mentioned - it's always by arkhan lol. It's more weird to mention it here on PCE forums because its user base seems to have a pretty big disconnect from PCE (and everything else; it's its own thing).
We're just lucky nobody needs to complain about shitty scrolling in PCE games, otherwise the MSX would get invoked every 4th post!
Lolol just saw this.
I have to laugh when people use that as their way to dismiss msx, citing youtube and never actually playing one.
I would never dis the hardware having never played on the real thing; that would make me look like an idiot. No, I've played games on real MSX computers, and after 10 minutes the shake & bake scrolling made my eyes hurt. Even ZX Spectrum games often did a better job.
MSX1 is sometimes hit or miss, and the speccy ports kind of just suck. most of the good MSX1 games are single or flip screeners .
Legend of Kage on MSX1 will make your brain melt . its the worst of the jerky games.
MSX2 is where most of the good stuff is.
Title: Re: PCE PCM
Post by: elmer on January 12, 2017, 03:19:07 AM
Those great 5V ARM microcontrollers from Cypress you brought up over a year ago are still the best solution here. Analog out is included, and if you add some sort of bidirectional comms in a mapper you can use it as a Cypress FX.
I ended up going with the FM3 family for my current project (specifically the MB9BF524K) and ported over my Windows softsynth without any huge issues. But this is a full music player, and I think in the case of the PCE it would be more useful to just complement what's already in the box.
That's one heck of a lot of impressive hardware in a $5 80-pin package! Wow! :shock:
Sure ... you could run a lovely soft-synth or possibly an OPL3-emulation in that and feed it to the PCE.
I was kinda trying to keep to hardware that was actually available when the PCE was manufactured, to keep it more "authentic" in terms of something that really could have been sold as an add-on at the time ... but your way is far more practical in modern terms.
Either way, it would just be a "curiosity", and there would be no software for it, and no user demand, and I don't have the hardware skills anyway ... but it sure would have been cool! :)
I can just-about-imagine a homebrew game shipping with one as a "collector" sort of thing.
Those old FM chips had lousy stereo-positioning anyway, so I don't think that we'd be losing much by keeping it mono.
The PCE's PSG could be used for all of the stereo-panned instruments.
Gotta love that FM-sound! ... and mixing it together with the PCE PSG channels would make something seriously fun. :dance:
Still not going to happen, though, especially since the PCE already offers even-better-than-that ... full on orchestrated, engineered and effected CD-Audio! :wink:
Title: Re: PCE PCM
Post by: Michirin9801 on January 12, 2017, 03:45:45 AM
Those old FM chips had lousy stereo-positioning anyway, so I don't think that we'd be losing much by keeping it mono.
The PCE's PSG could be used for all of the stereo-panned instruments.
Gotta love that FM-sound! ... and mixing it together with the PCE PSG channels would make something seriously fun. :dance:
Still not going to happen, though, especially since the PCE already offers even-better-than-that ... full on orchestrated, engineered and effected CD-Audio! :wink:
You know, that's kinda the point, if you wanted to do FM, you're probably already working on the Mega Drive or something like that... If anyone comes to the PC engine wanting to make chiptunes, they want the PSG, they want those 5 bit waveforms, and maybe some samples to go with them... Yeah an FM expansion would be a pretty cool novelty, and I sure would use the hell out it (although personally I'd stick a YM2151 in it) But anyone wanting to work on the PC engine but wants music other than chiptunes, they're absolutely gonna use the CD...
Title: Re: PCE PCM
Post by: Arkhan on January 12, 2017, 04:27:13 AM
If anyone comes to the PC engine wanting to make chiptunes, they want the PSG, they want those 5 bit waveforms, and maybe some samples to go with them...
But anyone wanting to work on the PC engine but wants music other than chiptunes, they're absolutely gonna use the CD...
This is precisely my point when I am a bit naysayer-y about good synth bass via samples.
It's not even the PC Engine sound at that point if you go crazy dragging in sounds from elsewhere.
I'd honestly figure that super synth'd out bass in the middle of a PCE tune might sound out of place.
Percussion is about the only exception to the rule, because nobody runs to any specific chip going DAMN, IM GONNA GET ME SOME DRUMS.
They *all* suck at drums equally, :) (Except for the C64 probably). FM is totally limp with drums half the time. MSX-MUSIC (OPL2) drums are those standard FM drums you hear in toys and stuff. It works, but you only get one sound out of it.
As weak as the bass can be for PCE, the super-sharp plucked bass, or the pretty plain bass from something like Bonk fits well with the rest of the sound.
and, the reason I pushed so hard to get something working for PCE chiptunes in the first place is because this thing is my favorite sound chip, and always has been since like 1990.
https://www.youtube.com/watch?v=fVmnQRzdMZs
There's hardly anything special going on in this song technically but it sounds so good. There's sampled bongos, and some pretty standard PC Engine sounds.
It was pretty annoying that back then (2008ish), we didn't really have any option that was easily workable with a game while those asshats over in Nintendoland were jizzing all over famitracker and shit.
I'm glad there's more chiptune occurrences for PCE happening, as long as we don't get inundated with those stupid chipwank songs. They're terrible.
I like being able to mix sounds if the machine was expected to do so, as was the case with MSX. They always intended for it, being a computer, to be expandable.
https://www.youtube.com/watch?v=zTh8DIocUGw
and that's how we ended up with AKB48 on the MSX. lol
CHECK OUT THE MML IN THE VIDEO.
;) 2016.
If you want to mix shit on the PCE, just use CD. Stop dicking around. They put the CD there so you can store huge amounts of data, and add wacked out music.
Title: Re: PCE PCM
Post by: Michirin9801 on January 12, 2017, 05:37:55 AM
If anyone comes to the PC engine wanting to make chiptunes, they want the PSG, they want those 5 bit waveforms, and maybe some samples to go with them...
But anyone wanting to work on the PC engine but wants music other than chiptunes, they're absolutely gonna use the CD...
This is precisely my point when I am a bit naysayer-y about good synth bass via samples.
It's not even the PC Engine sound at that point if you go crazy dragging in sounds from elsewhere.
I'd honestly figure that super synth'd out bass in the middle of a PCE tune might sound out of place.
Percussion is about the only exception to the rule, because nobody runs to any specific chip going DAMN, IM GONNA GET ME SOME DRUMS.
They *all* suck at drums equally, :) (Except for the C64 probably). FM is totally limp with drums half the time. MSX-MUSIC (OPL2) drums are those standard FM drums you hear in toys and stuff. It works, but you only get one sound out of it.
As weak as the bass can be for PCE, the super-sharp plucked bass, or the pretty plain bass from something like Bonk fits well with the rest of the sound.
Well, there's a difference between wanting an FM bass and wanting the whole song to be FM... You know, I actually really like the basses that I can get out of the PC engine PSG, but I just think that FM makes for even better basses, and being able to use one in a PC engine song, alongside sampled drums, strings, choirs and/or orch hits and still have the PC engine leads, all without having to use the CD add-on? That's like PCE Batman but taken to the extreme! I just LOVE that idea! With that in mind, using a sampled bass isn't gonna stop the PCE from sounding like a PCE, it's just gonna make it sound a bit better than it already does... Also, it's not like I'm gonna stop making regular PCE music with no samples just because I could use an FM bass and Super Nintendo strings, choirs, orch-hits and percussion... I just welcome the ability to do that with open arms~
Oh and, I'd argue that the PCE does better drums than the C64 if you use the envelopes and the noise mode right... Also, you gotta cram the drums and the bass in the same channel on the C64 if you wanna make anything worthwhile anyway...
and, the reason I pushed so hard to get something working for PCE chiptunes in the first place is because this thing is my favorite sound chip, and always has been since like 1990.
https://www.youtube.com/watch?v=fVmnQRzdMZs
There's hardly anything special going on in this song technically but it sounds so good. There's sampled bongos, and some pretty standard PC Engine sounds.
It was pretty annoying that back then (2008ish), we didn't really have any option that was easily workable with a game while those asshats over in Nintendoland were jizzing all over famitracker and shit.
And I applaud you for that! The PCE may not be exactly my favourite-sounding soundchip, my favourite is always gonna be the Super Nintendo for several reasons including but not limited to nostalgia because I grew up with the cute little grey brick... But the PCE has earned its way into my heard and it easily sits way up there in 2nd place tied with the Game Boy Advance (No seriously! And it's for surprisingly similar reasons to the PCE)
But the thing is that the PCE is the most fun system to work with (thanks in part to Deflemask being the most intuitive, user-friendly and fun-to-use tracker EVER), to quote the composer for Devil's Crush "It's easy to make awesome music for the PC Engine" and I couldn't agree enough!
But me loving the sound of the system as it is doesn't mean I wouldn't want to experiment with a new sound driver that makes it capable of even more out-of-the box!
Title: Re: PCE PCM
Post by: Arkhan on January 12, 2017, 05:59:41 AM
Well, there's a difference between wanting an FM bass and wanting the whole song to be FM... You know, I actually really like the basses that I can get out of the PC engine PSG, but I just think that FM makes for even better basses, and being able to use one in a PC engine song, alongside sampled drums, strings, choirs and/or orch hits and still have the PC engine leads, all without having to use the CD add-on? That's like PCE Batman but taken to the extreme! I just LOVE that idea!
Yep, but, with great power comes great responsibility. People tend to overdo it. That's how that stupid arp sound got so popular.
Also, at some points, I think PCE Batman is too overpowered with the samples and that slappy bass sound. It ruins the leads in some songs especially if you listen to the one song that had an NES version. The song sounds better on NES, to me. A few volume tweaks would have been nice for the PCE one... lol. Good example of nice samples, that can inadvertently mess things up.
Quote
With that in mind, using a sampled bass isn't gonna stop the PCE from sounding like a PCE, it's just gonna make it sound a bit better than it already does...
Depends, really. Shitty sounding samples are often a thing, lol. I want to see someone do a good FM style synth bass sample on PCE. If someone can do it, I really would like to see it. I'm picky about those sounds though and would likely just prefer a standard PCE bass, because it is practically guaranteed to fit.
Quote
Oh and, I'd argue that the PCE does better drums than the C64 if you use the envelopes and the noise mode right... Also, you gotta cram the drums and the bass in the same channel on the C64 if you wanna make anything worthwhile anyway...
Eh... I don't really think so. I don't think you can do better than C64 with stock PCE drums. Samples, definitely. Chip? No.
https://www.youtube.com/watch?v=y3oKFxKQY_Y https://www.youtube.com/watch?v=pH899QpQMrA https://www.youtube.com/watch?v=JSYU4E2B6Uc&list=PLd_GzV2EFKtlf-Uz329o2J8ZWU6rtgqhO There's lots more examples.
having to cram stuff together isn't that bad either considering what these people have managed to figure out, lol.
Quote
And I applaud you for that! The PCE may not be exactly my favourite-sounding soundchip, my favourite is always gonna be the Super Nintendo for several reasons including but not limited to nostalgia because I grew up with the cute little grey brick... But the PCE has earned its way into my heard and it easily sits way up there in 2nd place tied with the Game Boy Advance (No seriously! And it's for surprisingly similar reasons to the PCE)
But the thing is that the PCE is the most fun system to work with (thanks in part to Deflemask being the most intuitive, user-friendly and fun-to-use tracker EVER), to quote the composer for Devil's Crush "It's easy to make awesome music for the PC Engine" and I couldn't agree enough!
But me loving the sound of the system as it is doesn't mean I wouldn't want to experiment with a new sound driver that makes it capable of even more out-of-the box!
I grew up with TG/SNES/MD simultaneously. Outside of Squaresoft (Secret of Mana), I go TG, MD, SNES in terms of favorite.
I think you are only a little bit behind me in terms of age.
I'm not saying don't go for a new sample driver thing, I am just stating that it shouldn't be used incorrectly. That would suck.
Title: Re: PCE PCM
Post by: elmer on January 12, 2017, 06:51:51 AM
Oh and, I'd argue that the PCE does better drums than the C64 if you use the envelopes and the noise mode right... Also, you gotta cram the drums and the bass in the same channel on the C64 if you wanna make anything worthwhile anyway...
Eh... I don't really think so. I don't think you can do better than C64 with stock PCE drums. Samples, definitely. Chip? No.
I'll go out-on-a-limb and say that you *may* well have to eat-your-words on that one when Michirin9801 finally gets the toolchain-capabilities that he's been asking for.
The ability to switch between a couple of waveforms in the 1st few frames to get the initial hit, followed by a frame-by-frame decrease in the in the noise frequency, all under a volume envelope ... should (IMHO) get some pretty-darned-nice results.
We'll have to see! :wink:
AFAIK, the sheer number of the PCE's noise-frequency settings and their fine-granularity, is pretty-darned-rare for the time.
Title: Re: PCE PCM
Post by: Arkhan on January 12, 2017, 07:01:05 AM
Yeah, I'd be happy to do so if someone actually shows it to me.
Currently, it's the usual lots-of-talking with no evidence to back it up. I'm more into the put up or shut up / believe it when I see it thing.
No offense, the PCE scene has been plagued with lots of rambling/talking/hypothetical wankery that has never actually come to fruition, lol. It's influenced my own pessimism about a lot of things.
There's certainly not been any commercially released PCE games to ever have chip drums that sound as percussive as a SID can do, mostly because they just used samples instead.
I got a good kick drum simply by using a tonal sweep, and got an OK snare, but nothing near as punchy as a C64.
Some of the C64s trick might actually be an aural illusion though. They often created kicks/snares that also played bass at the same time to save on channels. So, the mix might just inadvertently create the illusion that the drums are super thick.
Title: PCE PCM
Post by: esteban on January 12, 2017, 07:53:18 AM
INTERLUDE: Honest question: I always thought the bass in China Warrior main tune was quite nice and always wished more HuCARDs pumped out bass like that... I take it that nothing special (no samples) were used to generate the bass line.
Otherwise, please continue your friendly arguments concerning the virtues/pitfalls of FM on PCE, sampled vs. PSG drums, the tragedy that Blodia only has a couple of songs, etc.
Title: Re: PCE PCM
Post by: Arkhan on January 12, 2017, 08:23:02 AM
INTERLUDE: Honest question: I always thought the bass in China Warrior main tune was quite nice and always wished more HuCARDs pumped out bass like that... I take it that nothing special (no samples) were used to generate the bass line.
the bass in China Warrior is simple. It's just a strange envelope that gives it this bubbleup kind of effect.
It works really with the style of music. I had similar sounds for Atlantean but the music is different so it didn't have the same outcome.
So, I switched to the bass that it has now.
Title: Re: PCE PCM
Post by: sunteam_paul on January 12, 2017, 09:41:28 AM
I would say Tatsujin's unsampled drums are a great example of what the PCE can do in that respect.
City Hunter had some nice drums, I don't think any of those were samples.
Title: Re: PCE PCM
Post by: Arkhan on January 12, 2017, 09:59:10 AM
I would say Tatsujin's unsampled drums are a great example of what the PCE can do in that respect.
City Hunter had some nice drums, I don't think any of those were samples.
Yeah those might be the best examples of non sampled drumming, especially when City Hunter is belting out the tom rolls.. Even so, I don't know that I'd say these are better than the C64's drums, id say they are maybe punchier at times, but the C64 ones are thicker?
It's just too bad lots of C64 games were terrible but had nice music, lol.
Title: Re: PCE PCM
Post by: Michirin9801 on January 12, 2017, 11:19:26 AM
Oh and, I'd argue that the PCE does better drums than the C64 if you use the envelopes and the noise mode right... Also, you gotta cram the drums and the bass in the same channel on the C64 if you wanna make anything worthwhile anyway...
Eh... I don't really think so. I don't think you can do better than C64 with stock PCE drums. Samples, definitely. Chip? No.
You know, I can make better unsampled drums in Deflemask than most commercial games, not all, but most, but if I have to go for an example in a game, my go-to is always gonna be Xanadu II, particularly this song: https://www.youtube.com/watch?v=Vedj_jPdN2U
Other than this song, the drums from Xanadu are quite a bit softer than C64 drums, but personally I like them better than most C64 drums I've heard... Currently I'm basing my drums on those of Xanadu, but I'm also trying to do some original ones that are 'less soft'...
I'll go out-on-a-limb and say that you *may* well have to eat-your-words on that one when Michirin9801 finally gets the toolchain-capabilities that he's been asking for.
The ability to switch between a couple of waveforms in the 1st few frames to get the initial hit, followed by a frame-by-frame decrease in the in the noise frequency, all under a volume envelope ... should (IMHO) get some pretty-darned-nice results.
We'll have to see! :wink:
AFAIK, the sheer number of the PCE's noise-frequency settings and their fine-granularity, is pretty-darned-rare for the time.
If only I had the right wavetables and access to the other noise frequencies I'm sure I could make something really nice! Like what Kommisar did in this song: https://www.youtube.com/watch?v=PCRPJd3iDVk
Great DAC Kicks! Would make for some amazing electronic-sounding music which I'm also a fan of, and I've asked them if I could have the wavetables they used, but I haven't gotten an answer sadly... oh and, I'm not a 'he' >w>
Also, at some points, I think PCE Batman is too overpowered with the samples and that slappy bass sound. It ruins the leads in some songs especially if you listen to the one song that had an NES version. The song sounds better on NES, to me. A few volume tweaks would have been nice for the PCE one... lol. Good example of nice samples, that can inadvertently mess things up.
Well, I like the PCE version better, I just wish the PCE game was a platformer more along the lines of the NES game, but with its soundtrack intact...
I grew up with TG/SNES/MD simultaneously. Outside of Squaresoft (Secret of Mana), I go TG, MD, SNES in terms of favorite.
I think you are only a little bit behind me in terms of age.
I'm not saying don't go for a new sample driver thing, I am just stating that it shouldn't be used incorrectly. That would suck.
Umm, nah... I've said it before in another thread, but I grew up in the 2000s, I wasn't even born to experience the 4th generation, but that didn't stop me from playing on my older cousin's Super Nintendo and even borrowing it for years, and even after I had to give it back I had ZSNES to back me up and not too long after I got a Game Boy Advance, and being able to play Super Mario World during school recess was like, the best thing ever! While my classmates were playing GTA and... Uhh... Whatever else was on PS2, I was having my mind blown by Donkey Kong Country and Megaman X
I only discovered the MD and the TurboGrafx-16 through the Wii's Virtual Console, and later on emulation, and I fell in love with both systems, however I think you can guess which one I was more attracted to ;3 It does help that my first impression of the system was Rondo of Blood, I thought the game was gonna be identical to the SNES version which I grew up playing or worse, but it was so unacceptably better that it stabbed me right in the nostalgia! And I just HAD to have more of that!
And I know where you're coming from, but I can't help but to be excited about it and the possibilities it brings~ If I can make an FM bass sound good in 1 bit then I can make it sound good in 5 bit, it's just a matter of knowing which bass to sample, and the one I have in mind is neither too harsh/gritty, nor too twangy... (If you're curious, it's the bass from Valkyrie the Power Beauties on the PC-98)
Title: Re: PCE PCM
Post by: Michirin9801 on January 12, 2017, 02:20:01 PM
Okay, you wanted an example of a sampled FM bass? Here's one! http://sta.sh/0tqlyutfr4w (Mind you this song is incomplete) What I did here is sample the bass I've mentioned in the previous post (the one from Valkyrie TPB) resample the samples to 7KHz in Audacity, then import them into Famitracker to use with the DPCM... Why NES though? Because it's the closest approximation I can get right now to what the sampled FM bass might sound like on the PCE... That said though, I expect them to sound better than this on the PCE given how the DPCM is 1 bit and the PCE PCM is 5 bit and it's gonna loop the samples which I can't do on the NES... (Not to a useful extent at least)
If anything, I have plenty of other basses ripped from lots of other PC-98 and X68000 games, so if this isn't good enough I could try it with a number of other basses and see which ones work best!
Title: Re: PCE PCM
Post by: Arkhan on January 12, 2017, 06:25:16 PM
I was excited that this was going to be a cover of the Ventures' "Walk Don't Run", lol.
That FM bass doesn't sound that great to me, and gets pretty weak in the lower registers. I'm not sure if the extra-bitness is really going to help us that much. I could be wrong.
On PCE, you might as well just use a normal, punchy, enveloped bass and not waste the resources, as the timbre may not be much different. Good FM/Synthy bass is the kind of phat, thumpy/punchy sound that you can feel in your nuts while you're playing.
How old are you exactly? I mean, I was growing up playing PS2 also. We can't be that far apart really, lol. I was born in 1988.
At least you grew up with broadband basically, so downloading and experiencing all of this stuff wasn't a pain in the ass.
Technically, Batman's soundtrack is better on PCE, but the mixing could use some work, I think. The rhythm tracks shouldn't drown out the lead. That's not a good time.
I'm curious how some C64 drums would sound if you sampled them onto the PCE, actually. You can get some pretty rattly percussion out of the C64. Some of it might sound cool. The drums are also fairly wet. The reason PCE drums often sound "better" is that they're more dry, so they have a better contrast against the leads.
Those same kind of drums would probably get completely lost, or sound out of place against a SID tune, as most sid stuff is pretty wet sounding.
But, wet drums against the usual PCE sound miiiiight sound cool.
https://www.youtube.com/watch?v=cTmA1_ClxOo
I'm surprised you don't like the SID more, honestly. You like eurobeat and crap right? :D
https://www.youtube.com/watch?v=sWCYTYjvUs4
^^^ This is probably my favorite SID tune ever. It's 100% lit as f*ck. One of the rare times where the arps are doing something productive with their existence, instead of being some blaring dumpster fire that's trying to be the lead.
Title: Re: PCE PCM
Post by: ccovell on January 12, 2017, 09:18:52 PM
Technically, Batman's soundtrack is better on PCE, but the mixing could use some work, I think. The rhythm tracks shouldn't drown out the lead. That's not a good time.
Yeah, the mixing on some tracks needs some work, but the bass instrument sounds great. But that's not what's special about it; it's the fact that they did attack phase samples and sustain phase samples (with looping). Because of the looping, the whole 28 note range sample pack is pretty small. This should have been exploited more on the PCE. It's sensible and doable for programmer back then, and definitely within the means of the PCE's resource capability.
But I wanted to mention thing related to Batman: attack phase. Supposedly the most advance and complicated part of any instrument is the attack phase (I don't mean the volume, but replicating an instrument). LA synths use samples mixed in with other parts of waveform generation just for the attack phase of an instrument. That's a clever idea. Something that could be exploited on the PCE; sample attack phase and normal PSG for the rest. Why PSG for the rest and not samples? Because if you've played around with samples on the PCE, at lower rate and lower bit depth, you've come the realization that some samples just get too crushed by the reduction - especially stuff with important high frequency meat to the sample. In this respect, you don't even need soft sampler support; attack phases are short so you can have lots of presampled ranges for them with little storage space needed.
Title: Re: PCE PCM
Post by: Arkhan on January 13, 2017, 03:58:00 AM
Yeah, that sort of idea is what made Roland synths able to do some of the stuff that Yamaha (FM) stuff was already good at (percussive/woodwindy/metallic sound).
Before this, subtractive synthesis was Roland's jam, and you couldn't get realistic sounds. You just get what sounds like Rush or Journey's albums, lol.
I remember trying for hours to get my Alpha Juno 1 to sound like a real piano. It never worked. You'd almost get it, but it never sounded right.
The ironic thing is, I finally got a synth from Roland that does that, and I still end up preferring my SH-101 and crap. Go figure. I sold the D-50 for a pretty decent chunk of money. I think they are back to not being worth too much now.
It was pretty fun to use. I sort of miss it, because you could still do some of the usual rolandy sounds with it
They've actually got a D-50 card you can use with that fancy ass Roland V-Synth now.
It's probably more reliable than a real D-50.
Doing that sort of stuff right is probably how you'd get away with really, really good sounding samples.
But, this doesn't really help with that synth-bass issue I keep mentioning, lol.
Title: Re: PCE PCM
Post by: Michirin9801 on January 13, 2017, 04:02:10 AM
That FM bass doesn't sound that great to me, and gets pretty weak in the lower registers. I'm not sure if the extra-bitness is really going to help us that much. I could be wrong.
The bass isn't good enough? Perhaps it isn't, but as I've said before I have plenty of other basses to try and sample, I'm gonna try with one of the basses from Carat Magical Blocks next... As for it getting weak in the lower registers, that's more due to the DPCM than the samples themselves, I doubt the PCE would have that problem...
OR I could go the opposite route and make the PCE sound more like a GBA, and sample the Leads and drums while playing the bass and harmonic support on the PSG (the harmonic support would be square waves of course) But I'm probably not gonna do that because I need more variety in the leads than in the basses, so that would take more samples and eat up more of the system's memory...
How old are you exactly? I mean, I was growing up playing PS2 also. We can't be that far apart really, lol. I was born in 1988.
At least you grew up with broadband basically, so downloading and experiencing all of this stuff wasn't a pain in the ass.
I'm 20, gonna be 21 this summer, so I was a 90s baby and a 2000s kid... And because I'm from a poor-as-f*** family I only got access to the internet in 2007, before that I had to wait for my dad to come home from work in the weekends, where he had internet access, with a Super Nintendo Rom in a Floppy Disk so that I could play it on my Windows 98 Pentium III computer built with donated parts >w> Good times... Played lots of Super Bomberman 3 with my sis!
I'm surprised you don't like the SID more, honestly. You like eurobeat and crap right? :D
I do love me some Eurobeat ;3 But the thing is that Eurobeat can only be done justice with Samples! SID synth doesn't cut it >w> And even if I had all the right samples to use, I'm hardly skilled enough to do Eurobeat justice...
Title: Re: PCE PCM
Post by: Arkhan on January 13, 2017, 04:51:24 AM
But the thing is that Eurobeat can only be done justice with Samples! SID synth doesn't cut it >w> And even if I had all the right samples to use, I'm hardly skilled enough to do Eurobeat justice...
Samples? bitch please. :D SID is actually pretty spastically good at sampling. The SID is such an impressive soundchip overall... that's unfortunately used wrong sometimes (arparparparparparparparparpapr)
https://www.youtube.com/watch?v=qG82RMyS07Y https://www.youtube.com/watch?v=y38KIXcarKo lololol. OU OU OU OU OUTRUN.
Jeroen Tel is a f*cking genius.
and yeah, you're the exact age as I figured. I have a buddy that's your age. You guys are at that weird age gap where you guys think the library is just this building with free wifi. lol
I don't think you should ever use samples for the leads in a PCE song. The lead sounds are where the PC Engine truly shines, IMO. Taking those away is just a bad idea.
Try using the bass from Romancia:
https://www.youtube.com/watch?v=20wzm3aS3gQ
Title: Re: PCE PCM
Post by: Arkhan on January 13, 2017, 05:08:15 AM
https://www.youtube.com/watch?v=3vD9cKKxl5k shit I left out Savage. Shame on me.
Title: Re: PCE PCM
Post by: Michirin9801 on January 13, 2017, 05:16:31 AM
Samples? bitch please. :D SID is actually pretty spastically good at sampling. The SID is such an impressive soundchip overall... that's unfortunately used wrong sometimes (arparparparparparparparparpapr)
Might I add that the C64 can only handle 4 bit samples, and the PCE can do 5 bit ;3 (But yeah, 4 bit is better than the Nintendo's 1 bit DPCM) Oh hey there's that! The C64 using bass samples in the Outrun song, that's more or less the quality I'm expecting to get out of the PCE, maybe a little higher due to the 5 bits...
I don't think you should ever use samples for the leads in a PCE song. The lead sounds are where the PC Engine truly shines, IMO. Taking those away is just a bad idea.
Agreed, which is why I said I'm probably not gonna do that...
Title: Re: PCE PCM
Post by: Arkhan on January 13, 2017, 05:23:11 AM
I am wondering how that bass is going to actually sound when stacked up with PCE stuff. It might be the case that all this effort goes into a less than impressive end result because the PCE leads and such aren't exactly thick.
I always described the PCE leads as warm and chirpy. They've never been very phat.
That bass in Outrun is not my favorite though. It's more thunky and percussive but fits well with the like breakdance rapjam beat and musical style.
For the synthy/phat basses, C64 doesn't exactly *need* to sample, though. It can already just do that.
What it can't do on it's own though, is the thunky / percussive bass sounds. Which goes into what Tom was talking about with LA synthesis.
LA Synthesis sounds like a gym for musicians.
Title: Re: PCE PCM
Post by: elmer on January 13, 2017, 05:29:17 AM
I would say Tatsujin's unsampled drums are a great example of what the PCE can do in that respect.
City Hunter had some nice drums, I don't think any of those were samples.
It would probably be nice to rip-apart the .hes files for those games, and the Xanadu games, and try to see exactly what they're doing to create those drums that people like.
Yeah, the mixing on some tracks needs some work, but the bass instrument sounds great. But that's not what's special about it; it's the fact that they did attack phase samples and sustain phase samples (with looping). Because of the looping, the whole 28 note range sample pack is pretty small. This should have been exploited more on the PCE. It's sensible and doable for programmer back then, and definitely within the means of the PCE's resource capability.
Yep, this is definitely something that we could do in a new driver.
I'd love to be able to give people that option, and especially with your 4-samples-in-2-channels code (both frequency-scaled and fixed versions).
Giving folks the options, and then letting them choose which ones work for them, would seem like the best route to take.
Oh ... and the soft-mixing will, of-course, be much cheaper to implement with the fast CPU on the PC-FX! Creating a driver for that machine is definitely a goal.
But I wanted to mention thing related to Batman: attack phase. Supposedly the most advance and complicated part of any instrument is the attack phase (I don't mean the volume, but replicating an instrument). LA synths use samples mixed in with other parts of waveform generation just for the attack phase of an instrument. That's a clever idea. Something that could be exploited on the PCE; sample attack phase and normal PSG for the rest. Why PSG for the rest and not samples? Because if you've played around with samples on the PCE, at lower rate and lower bit depth, you've come the realization that some samples just get too crushed by the reduction - especially stuff with important high frequency meat to the sample. In this respect, you don't even need soft sampler support; attack phases are short so you can have lots of presampled ranges for them with little storage space needed.
Yep, this is another great idea, too, and might really allow the musician to create some interesting sounds at little cost.
Michirin9801: Both of these two capabilities that bonknuts mentions are things that seem like they could be triggered by abusing deflemask's Wave Macro and Arp Macro, again (at least for now) ... although Delek's cooperation and a bit of UI work would be my preferred long-term solution.
I suspect that having someone actually create a tune that used these features would help encourage him to make any changes ... but there's still the small roadblock of actually getting the base huzak driver written first, before we go wild with samples. :wink:
Title: Re: PCE PCM
Post by: Michirin9801 on January 13, 2017, 06:06:01 AM
Michirin9801: Both of these two capabilities that bonknuts mentions are things that seem like they could be triggered by abusing deflemask's Wave Macro and Arp Macro, again (at least for now) ... although Delek's cooperation and a bit of UI work would be my preferred long-term solution.
I suspect that having someone actually create a tune that used these features would help encourage him to make any changes ... but there's still the small roadblock of actually getting the base huzak driver written first, before we go wild with samples. :wink:
I'm kind of already doing that with that steel drum instrument you know? >w> The problem is that the Deflemask forum seems to be a little, umm... Dead... I post there and nobody answers...
My guess is that Delek is working hard on the next version of Deflemask, and thus is too busy to answer, but I don't know...
Title: Re: PCE PCM
Post by: Bonknuts on January 13, 2017, 01:28:00 PM
Title: Re: PCE PCM
Post by: Michirin9801 on January 13, 2017, 02:17:16 PM
Okay so, here's a couple more examples of sampled FM basses at 7KHz on the NES Carat Magical Blocks - BGM#5 with the bass from the exact same song on the PC-98 http://sta.sh/0i7cvoanj38
and CyberBlock Metal Orange - Stage 3 with the bass from Romancia's Opening theme http://sta.sh/09472c9hxd4
So, the Romancia bass sounds more like what I wanted the Valkyrie bass to sound like, I'd just put it on the Walk Don't Run cover, but I forgot to save the song after I exported the .nsf so all of that work is pretty much lost now >w> So I covered another song, one that I know like the back of my hand and could finish pretty quickly... Also, forgive me for the popping in the song, artifact of the DPCM channel whenever I turn it off..
Both basses sound kinda similar, but then again, it's the NES DPCM, it makes a lot of basses sound really similar... I also made these basses a bit louder than the previous one, but now I think I went a bit overboard with their volume yet again... Out of these two, personally, I'm a bit more satisfied with the sound from the Carat bass...
Another bass that I'm willing to try is actually one from Final Fight 3! Yeah I know, it's not sampled from FM, but that bass already sounds a lot like FM so... Why not? ;3 Oh and, there's yet another bass from a different Carat song that I'd like to try and sample too!
Title: Re: PCE PCM
Post by: elmer on January 13, 2017, 03:35:54 PM
Okay so, here's a couple more examples of sampled FM basses at 7KHz on the NES Carat Magical Blocks - BGM#5 with the bass from the exact same song on the PC-98 http://sta.sh/0i7cvoanj38
and CyberBlock Metal Orange - Stage 3 with the bass from Romancia's Opening theme http://sta.sh/09472c9hxd4
Errr ... this will probably sound terribly ignorant ... but what's a .nsf file, and what plays it? :oops:
Title: Re: PCE PCM
Post by: spenoza on January 13, 2017, 03:39:39 PM
.nsf is the format of NES music files.
Title: Re: PCE PCM
Post by: elmer on January 13, 2017, 03:44:13 PM
and that's how we ended up with AKB48 on the MSX. lol
CHECK OUT THE MML IN THE VIDEO.
Hahaha ... I thought that it was particuarly funny that the MSX player software crashed and random garbage text just started scrolling up the screen! :lol:
...
...
...
Oh! That was the MML? Sorry! :oops: :wink:
Title: Re: PCE PCM
Post by: Michirin9801 on January 13, 2017, 03:51:50 PM
Okay so, here's a couple more examples of sampled FM basses at 7KHz on the NES Carat Magical Blocks - BGM#5 with the bass from the exact same song on the PC-98 http://sta.sh/0i7cvoanj38
and CyberBlock Metal Orange - Stage 3 with the bass from Romancia's Opening theme http://sta.sh/09472c9hxd4
Errr ... this will probably sound terribly ignorant ... but what's a .nsf file, and what plays it? :oops:
Yeah, just try these files with your NES emulator of choice, but I had better results with FCEUX than Nestopia... Chipamp can also play them, but it adds a fake stereo that the NES doesn't really have, and I find it to be unauthentic so I never use it for NES music...
I went with NES for these examples because it's the closest approximation that I can get to what the sampled FM basses at 7KHz might sound like on the PC engine as of right now... They're most likely gonna sound noticeably better than this because the NES DPCM isn't exactly up to par with what the PCE can play sample-wise, but still, it's a rough idea of the kind of sampling I have in mind to use with Bonknuts' driver!
Title: Re: PCE PCM
Post by: elmer on January 13, 2017, 05:03:13 PM
Yeah, just try these files with your NES emulator of choice, but I had better results with FCEUX than Nestopia...
Thanks! :)
Ahhh ... OK. I *never* run NES stuff, so I had no idea.
As usual, Mednafen comes to the rescue! :clap:
BTW ... I know that you don't like command-line programs, but something like this is just a case of dragging-and-dropping the .nsf file onto the "mednafen.exe" icon in Windows Explorer and it fires right up and plays.
Mednafen is an outstanding-accurate emulator, and Rypheca and her team have done an amazing job with it.
I went with NES for these examples because it's the closest approximation that I can get to what the sampled FM basses at 7KHz might sound like on the PC engine as of right now... They're most likely gonna sound noticeably better than this because the NES DPCM isn't exactly up to par with what the PCE can play sample-wise, but still, it's a rough idea of the kind of sampling I have in mind to use with Bonknuts' driver!
Yeah ... I think that we're going to need Bonknuts' expertise here.
A 7KHz sample rate should be fine for bass frequency samples, but getting a good result is going to require the 8-bit or 10-bit output that his driver provides. 8-bit should be plenty if it's reasonably linear instead of logarithmic.
The granularity of the volume stepping in the channel's regular 5-bit output is just too harsh for a good low-frequency waveform output (IMHO).
Title: Re: PCE PCM
Post by: esteban on January 14, 2017, 12:20:21 AM
and that's how we ended up with AKB48 on the MSX. lol
CHECK OUT THE MML IN THE VIDEO.
Hahaha ... I thought that it was particuarly funny that the MSX player software crashed and random garbage text just started scrolling up the screen! :lol:
...
...
...
Oh! That was the MML? Sorry! :oops: :wink:
Hahahahahhaha.
Title: Re: PCE PCM
Post by: Bonknuts on January 14, 2017, 12:43:56 AM
A 7KHz sample rate should be fine for bass frequency samples, but getting a good result is going to require the 8-bit or 10-bit output that his driver provides. 8-bit should be plenty if it's reasonably linear instead of logarithmic.
The granularity of the volume stepping in the channel's regular 5-bit output is just too harsh for a good low-frequency waveform output (IMHO).
I can do a few driver versions (mixers). 4 channels at 7bit mixed to 9bit, scaled to 10bit is fastest. Or four channels at 8bit steams but saturation on paired streams, mixed to 9bit -> scaled 10bit. Actually, you could probably modify the mixer however you want once you see them. I did 16 steps of volume, linear, and it sounded pretty decent. You can do more, but the LUT will be bigger. 7bit streams makes the volume table twice as small as one for 8bit streams.
The idea is pretty simple: 7bit unsigned samples -> volume LUT -> becomes 8bit 2's complement value -> add all four channels -> some flag checking and branch to 10bit decode LUT -> two 5bit values (in byte form) in two different buffers for the playback driver.
I mean, I can write it - but something tells me you probably don't need me to ;)
Title: Re: PCE PCM
Post by: Michirin9801 on January 14, 2017, 02:15:24 AM
A 7KHz sample rate should be fine for bass frequency samples, but getting a good result is going to require the 8-bit or 10-bit output that his driver provides. 8-bit should be plenty if it's reasonably linear instead of logarithmic.
The granularity of the volume stepping in the channel's regular 5-bit output is just too harsh for a good low-frequency waveform output (IMHO).
I don't know, I think 5 bit would be plenty good enough >w> If these basses already sound pretty good in 1 bit, then 5 bit should be A-OK, and you know what? Being 5 bit could actually make the sampled basses fit better with the PSG sounds! Or at least that's what I imagine, but then again what do I know? I have yet to hear them playing on the actual PCE...
Title: Re: PCE PCM
Post by: Bonknuts on January 14, 2017, 03:10:17 AM
All this discussion about samples and soft drivers, reminds me of Nintendo's Sappy engine for GBA. You can find the doc on RHDN; search for "sappy" in documents section.
The driver is mixing 8bit PCM streams into a single 8bit DAC. But the driver doesn't support saturation, so too much amplitude (which translates into bit depth on a fixed system like this) causes wrap around. That means if you wanted something like 4 sampler channels, you'd have to use 6bit samples (or samples with amplitude that doesn't expand beyond 6bit levels). There are custom mixers for GBA, but a lot of games used this default Sappy engine.
I also think I might investigate using the 10.5khz mode for 10bit DAC output. 44% cpu resource on even Timer calls and ~9% on odd calls. averaging overall 26% cpu for the driver. And what, 10% for the mixer? I could use that kind of setup.
Title: Re: PCE PCM
Post by: Bonknuts on January 14, 2017, 03:11:58 AM
Or at least that's what I imagine, but then again what do I know? I have yet to hear them playing on the actual PCE...
Make me a quick XM with just the bass or whatever type sampler instrument and I'll use my XM player to test it out and record it from the real console.
Title: Re: PCE PCM
Post by: Michirin9801 on January 14, 2017, 04:14:21 AM
All this discussion about samples and soft drivers, reminds me of Nintendo's Sappy engine for GBA. You can find the doc on RHDN; search for "sappy" in documents section.
The driver is mixing 8bit PCM streams into a single 8bit DAC. But the driver doesn't support saturation, so too much amplitude (which translates into bit depth on a fixed system like this) causes wrap around. That means if you wanted something like 4 sampler channels, you'd have to use 6bit samples (or samples with amplitude that doesn't expand beyond 6bit levels). There are custom mixers for GBA, but a lot of games used this default Sappy engine.
I really wish there was like a tracker or something for the GBA which used the Sappy engine, I've been struggling to get authentic-sounding GBA music done for a while now, and the closest that I could get was to run the samples that I wanted through the PCE to lower their bit depth to 5 bit, then record the samples and do an 8 channel song on openMPT and combine it with a Game Boy tune from Deflemask, and then I put the two together and try my best to make them not go out of sync (which always happens, every single time) What I want to do with GBA audio is get a sound similar to that of Densetsu no Stafy or Mario Kart Super Circuit, which in my opinion sound absolutely gorgeous and are the perfect mix of sampled music and chiptunes~ So I have sampled leads, drums and maybe strings/choir/orch-hits, GB DAC bass, GB Noise Hi-Hats and GB Pulse harmonic support, and I think it's the lower bit depth of the GBA samples that make them blend so well with the GB chiptunes and make that perfect blend of the two~ ♥I LOVE IT♥
But unfortunately, I can't find any other way to intentionally lower the bit depth of samples to anything lower than 8 bit, much less a tracker that lets me use both a GB soundchip and an adjustable amount of sample channels at the same time with varying bit depths so I have to struggle to sync 2 songs from 2 trackers together which is a major pain in the arse...
Or at least that's what I imagine, but then again what do I know? I have yet to hear them playing on the actual PCE...
Make me a quick XM with just the bass or whatever type sampler instrument and I'll use my XM player to test it out and record it from the real console.
Right on!
Title: Re: PCE PCM
Post by: Michirin9801 on January 14, 2017, 06:32:52 AM
Okay, here's a 1 channel XM with the 4 basses I've sampled thus far: http://sta.sh/0hwn4lvw2hz The order is Valkyrie Bass -> Romancia Bass -> Final Fight 3 Bass -> Carat Bass
And here's a 4 channel XM with the Carat Bass, Jackie Chan's Action Kung Fu Drums, a random SNES Choir and occasionally a vibraphone playing Carat BGM5: http://sta.sh/02dmn2v53cvb It lacks the leads and half of the harmonics because that would play on the remaining PSG channels, but still, I wanna hear this playing in a proper PCE rom!
Title: Re: PCE PCM
Post by: Bonknuts on January 14, 2017, 02:53:34 PM
My XM player is just quick and dirty - it doesn't support finetune per instrument and doesn't support mapping multiple samples in a back to different notes (JCAKF instrument). The player was just something quick and dirty to test and show off the PCM driver. The driver does support fine tune, but I didn't implement it in the XM reader/parser for the player. It doesn't support the volume envelope format either. I literally wrote it in ~3 hours.
In other words, if I converted these they'd probably sound like ass without that support.
If you need an app to do bit depth reduction on wave files, I can adapt something I already have for that. Simple turnication of bits (shifting) - nothing fancy. (Edit) Also, Cool Edit Pro 2.1 does bitdepth reduction (though the results are still stored in 8bit or whatever format).
Title: Re: PCE PCM
Post by: Michirin9801 on January 14, 2017, 04:42:01 PM
My XM player is just quick and dirty - it doesn't support finetune per instrument and doesn't support mapping multiple samples in a back to different notes (JCAKF instrument). The player was just something quick and dirty to test and show off the PCM driver. The driver does support fine tune, but I didn't implement it in the XM reader/parser for the player. It doesn't support the volume envelope format either. I literally wrote it in ~3 hours.
In other words, if I converted these they'd probably sound like ass without that support.
If you need an app to do bit depth reduction on wave files, I can adapt something I already have for that. Simple turnication of bits (shifting) - nothing fancy. (Edit) Also, Cool Edit Pro 2.1 does bitdepth reduction (though the results are still stored in 8bit or whatever format).
I see... Well, when you can actually convert these examples into something that will play on the PCE, please let me know... Also, thanks! I'm gonna check Cool Edit Pro now, I don't mind it not actually 'being' lower bit depth, so long as it 'sounds' lower bit depth
Title: Re: PCE PCM
Post by: elmer on January 15, 2017, 05:55:23 AM
If you need an app to do bit depth reduction on wave files, I can adapt something I already have for that. Simple truncation of bits (shifting) - nothing fancy. (Edit) Also, Cool Edit Pro 2.1 does bitdepth reduction (though the results are still stored in 8bit or whatever format).
SOX is another tool that supports that kind of truncation ... I'm using it in the pre-processing stage for the PCE/PC-FX ADPCM conversion. But I know that Michirin9801 isn't a fan of command-line tools.
But ... do we know if the waveform data is in linear-space, or in logarithmic-space? :-k
The amplitude levels in R1, R4 & R5 are all logarithmic, and I was finally curious-enough to look at the volume level number in excel.
Wow! I didn't realize that we were compressing down an approx 15-bit linear audio range into only 5-bits! :shock:
If the waveform data uses a similar logarithmic-space ... then the simple bit-truncation method isn't going to give great results.
I think that you and ccovell and mednafen have already checked this kind of stuff with oscilliscopes.
The idea is pretty simple: 7bit unsigned samples -> volume LUT -> becomes 8bit 2's complement value -> add all four channels -> some flag checking and branch to 10bit decode LUT -> two 5bit values (in byte form) in two different buffers for the playback driver.
I mean, I can write it - but something tells me you probably don't need me to ;)
Ahh ... but the devil-is-in-the-details, and it's always much nicer to use tried-and-tested code rather than having to write every darned thing by myself. :wink:
I'd much rather be able to take what you've got, give you appropriate credit for all the hard work that you've done, and be able to concentrate my limited time on the other stuff that hasn't already been written! :)
I should be able to update the dmf2pce project on github with the latest code this week, and I'll be adding in the work-in-progress version of the huzak driver at the same time.
I'm hoping that it will have a solid-enough foundation by then that it'll be a matter of making improvements, rather than the large-scale reorganization that's still going on right now.
The point, once again, is to make this stuff open source (like Uli's improvements to HuC), so that any programmer can take it and modify it for their own needs.
Title: Re: PCE PCM
Post by: Bonknuts on January 15, 2017, 06:23:47 AM
But ... do we know if the waveform data is in linear-space, or in logarithmic-space? :-k
The amplitude levels in R1, R4 & R5 are all logarithmic, and I was finally curious-enough to look at the volume level number in excel.
Wow! I didn't realize that we were compressing down an approx 15-bit linear audio range into only 5-bits! :shock:
If the waveform data uses a similar logarithmic-space ... then the simple bit-truncation method isn't going to give great results.
I think that you and ccovell and mednafen have already checked this kind of stuff with oscilliscopes.
Do you know whether it is linear or logarithmic?
Volume (channel, pan, global) for all channels is log, but waveform data is linear. The 10bit waveform data for paired channels for 10bit is linear as well; the second channel volume is set to be 1/32 that of channel 1, so it all lines up. You can do 12 or 13bit with three channels I believe, but it's not really worth it.
I just ordered an Owon SDS1702 scope, so I can retest test stuff if you need. Probably gonna pickup a 100mhz 16 channel logic analyzer soon too.
Title: Re: PCE PCM
Post by: elmer on January 15, 2017, 07:49:08 AM
Volume (channel, pan, global) for all channels is log, but waveform data is linear. The 10bit waveform data for paired channels for 10bit is linear as well; the second channel volume is set to be 1/32 that of channel 1, so it all lines up. You can do 12 or 13bit with three channels I believe, but it's not really worth it.
Thanks! :D
That's cool ... so just subtract 10 from the channel volume (for 1/32 with a 1.5bdB step), and then do some bit-shifting.
That doesn't sound too nasty. :-k
Quote
I just ordered an Owon SDS1702 scope, so I can retest test stuff if you need. Probably gonna pickup a 100mhz 16 channel logic analyzer soon too.
Fun toys! Are you planning to do some hardware design work in the future to justify those? :wink:
I'm still hoping for a full SuperGrafx/SuperCDROM/ACD with HDMI in an FPGA, one day!
Title: Re: PCE PCM
Post by: ccovell on January 15, 2017, 11:15:59 AM
Volume (channel, pan, global) for all channels is log, but waveform data is linear. The 10bit waveform data for paired channels for 10bit is linear as well; the second channel volume is set to be 1/32 that of channel 1, so it all lines up. You can do 12 or 13bit with three channels I believe, but it's not really worth it.
Thanks! :D
That's cool ... so just subtract 10 from the channel volume (for 1/32 with a 1.5bdB step), and then do some bit-shifting.
That doesn't sound too nasty. :-k
Quote
I just ordered an Owon SDS1702 scope, so I can retest test stuff if you need. Probably gonna pickup a 100mhz 16 channel logic analyzer soon too.
Fun toys! Are you planning to do some hardware design work in the future to justify those? :wink:
I'm still hoping for a full SuperGrafx/SuperCDROM/ACD with HDMI in an FPGA, one day!
Nah, can't really justify the cost of it (but it wasn't too bad). Just some things I wanted to test out on the PCE, for clarity. Plus, I plan to do some micro controller stuffs in the near-ish future.