All channels, or any specific channel and any number of them, can be set to DDA mode. Or do you mean from the BIOS psg player?
Yeah, i went and looked it up. All 6 channels can do DDA. Would probably be easiest to hack in on channels 5-6, since there's already support in the player to switch modes (ie, noise mode)
...To hack in sample support, it seems that simply setting the PSG player tick to 1 and have the hook do the down counting and call the PSG player when that expires, for tempo control.
I can sort of see how that might work.
The psg player doesn't really have a 'tick'; each call, from vsync/timer is used to count down values. That's easier to explain (to musicians used to midi) as 'ticks'. Wouldn't you have to run the timer at a high rate (ie, low count) to do that though?
Yup. At full 7khz rate. By tick, I mean the interval of time between calls of the parsing routine (and control routine; envelopes, etc). Since the PSG resolution of a tick, interval, is however many TIMER values are used in the timer divider (written to TIMER interval port), those steps that make up the internal are exactly 1 point at 7khz (6991hz to be exact). When you use the timer unit in this way, you're really just letting
hardware do the down counter division for you. But if you set the timer to 0, and do the down counter yourself - the step resolution is exactly the same. The step resolution is
always 1024 cpu cycles, whether it's a hardware counter or soft counter at max frequency.
So if you wanted 108hz tempo, set the TIMER to 6991 khz, set the software down counter to 108 (instead of writing it to the TIMER counter port), and on each TIRQ call decrement it. When it reaches 00, pass control to the PSG player. Otherwise, on each call you can now write a sample to any channel you like.
Obvious you don't want the PSG player writing other stuff to it, but if the PSG player
is writing frequency control while in DDA mode - it
won't affect the output of the sample. If you can get the PSG player to play a "sound effect" on that same channel, and not touch the volume after an initial set (because volume reg is the same used to set DDA mode), then you can basically get the PSG player
not to intervene on that channel while the sample is being streamed to it.
You could probably take this one step further, by spying on the PSG player's pointer to a specific channel. And if it can read the byte code for notes, then it can interpret that note as a simple #. Even pull the volume control code value from it.
Basically Air Zonk does all of this.
Go for it. I have enough other things to do. (Like getting the player to work with the new Huc. Including timer irq support)
If you get it working, pick an unused bytecode to indicate sample playback, and I'll see about putting it in the mml compiler.
..........................
I figure if you pump out the sample values on hsync (assuming 262 hsync/frame) you could handle 12KHz at 5-bit resolution. Not exactly cd quality, but probably good enough for recognisable speech/sfx.
Also, when you re-sample for pce, are you scaling down and interpolating over time, or what?
I've read some about it, but mostly have been using sox to do it...
Some PCM demos I posted do this. It's higher than 12khz though. If you output a sample on every scanline per frame (H-int can be called on every scanline), that's 262 samples per frame or 15.73khz. I kept mine at 15.3khz output because 256 samples per frame allowed for alignment optimization (saved cycles in handling/check bank boundary crossings; it doesn't have to be done per instance of the sample fetch, but rather once per frame). I did 262 interrupts, but skipped playing a sample every so many lines (used a down counter).
The downside to this method, is that there's a good amount of overhead just to do 262 h-int calls - nothing else. It's ~20% cpu resource just for the setup of the next line. Not bad if you already need to do a scanline interrupt every active display scanline for sinewave or similar effects, but not so great if you don't.
Here's an example of 7khz vs 14khz:
http://www.pcedev.net@ftp.pcedev.net/HuPCMDriver/7khz_vs_14khz.zip
The 14khz is just the sample code being called twice inside the TIMER routine. Simple to do, but wasteful. I just wanted to see what the different in frequency would sound like. Apparently at this rare level though, bit depth matters more than sample rate.
