|
| |
Credits :
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by Flex on 18 November 2020
| Cool stuff here. Not much heard from this guy since.. |
User Comment
Submitted by andym00 on 13 March 2012
| There's a discussion thread for this with the pertinent parts of the code since the code speaks better than my explanations ;) |
User Comment
Submitted by Yogibear on 13 March 2012
User Comment
Submitted by 6R6 on 12 March 2012
User Comment
Submitted by ruk on 11 March 2012
User Comment
Submitted by Radiant on 10 March 2012
User Comment
Submitted by Mixer on 10 March 2012
Way to go Andy! Plenty of things still to be done with c-64 audio.
|
User Comment
Submitted by andym00 on 10 March 2012
I did originally, and then on the Vic-20 as well, because I really didn't think the 64 would work with it at 15.6KHz due to badlines and things, but it actually does.. Only after doing the VIC version did I think it might just work with only 1Mhz of cpu..
One of the mental things to come out of this, if this isn't mental enough, is that using the chained timers and the idea of storing a byte with a 4bit sample and a 4bit length is that you can playback compressed samples very easily.. My tests show that everything I've tried comes out less than storing it as 2 packed 4bit samples in one byte, and also you get the benefit of way less interrupts as well.. Again, 15.6Khz sample playback works well with that system and the screen on..
Plus you can alter the sample rates still playing back RLE compressed samples by just altering the base timer values.. No messy computations required.. Timer-A holds the base sample rate, Timer-B the time till the next sample.. It's a win-win-win.. Less memory, less interrupts and less cpu power required..
And some sounds, for instances a set of TR606 samples compress to stupid amounts once quantised to 4 bits..
Anyway.. That's a whole different kettle of fish :) |
User Comment
Submitted by Mr. SID on 10 March 2012
| Very cool! Did you think about using this for Atari POKEY music? |
User Comment
Submitted by andym00 on 10 March 2012
It's actually very simple.. And for the record I totally forgot about your NES stuff until I was well into this stuff..
The idea is simply that instead of generating every single sample that since we're synthesising pulse waves, that we know exactly where the next transition will occur, so we simply mark those in a buffer.. And since its alternates between high/low we simply set one bit for this voice.. Each voice having one unique bit..
After that's done, and that's not a lot of work for typical frequencies, we do it for all the other voices..
So now you have an array with a bunch of bits set here and there..
Then the magic :) We eor fill the array, sort of, well only when the array has a non-zero value.. The new value then holds the state of all the voices, still with one bit per voice..
Magic part 2, is that each audio frame we look at all the volumes for all the voices and then create all the possible combinations, in the case of 3 voices, there's only 8 values to compute, although this is fairly optimal even when it has to do 64 in the case of 6 voices because only one value need to change in each step as we work our way through all the combinations..
Magic part 3 is that as we're eor'filling the buffer we also store the distance since the last non-zero value.. In effect we generate a RLE version of the output samples..
Magic part 4 is that since the VIAs are like little magic pixies, we set Timer-A to count the base sample rate, 63 cycles, and then chain Timer-B to count underflows.. Then each in NMI we pull out the next sample value, and then just stuff Timer-B with the time till the next sample should play..
And that's about it really..
The eor'filler is unrolled here, about 6K worth of code, although I've a rolled version that's 10's of bytes and isn't much slower really..
So the voices themselves are full 16bit frequency control, well actually 2 frequencies, one for the low step, one for the high step which gives us our proper 16bit Pulse width control..
The volumes for each voice are summed each audio frame, and then reduced if we exceed the total amount.. It's not clever, but it does the job and allows a nice dynamic range, well as much as I could hope for when throwing this all out through a 4bit DAC..
I don't think there's any other voodoo going on..
The NSF stuff isn't in anyway based on yours, I totally forgot you did the NSF player last year.. I don't synthesise a triangle wave, everything here is square/pulse waves, the whole NSF thing was simply a way to work on the stuff without having to create a decent music player at the same time.. It was never meant to be an APU emulator, hence it doesn't do the envelopes or sweeps..
I do have stuff playing MMC5/MRC6 tunes though ;) All 6/7 voices coming out of this method, although it's a bit silly, and quite frankly it needs a little more puff than the 64 has..
Wanna bolt it on to your NSF stuff ? I could imagine SID doing the triangle, saw and noise channels of MMC5/VRC6, and this doing the 4 pulse/square channels..
There's more performance in there though that it appears.. The NSF player is so slow it's unreal at times, and is quite happy to eat 25% of the CPU doing something not very impressive.. Which is sad when it's taking that to often do the synthesise side of things itself.. |
User Comment
Submitted by Mr. SID on 10 March 2012
| Hey Andy! This is is very intriguing. Could you give some more info on how you made this? It's the idea I've never tried... Amazing! |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
