Anyone old enough to remember what a .plan file is?
I just got the idea of making a status update on what im working on, in audio form. These will not come with any explanations whatsoever. They might be current bugs, new features, tests or experiments from code im currently working on...
Here's the second one.
I'll twitter any updates to it as I go along (twitter.com/plgDavid)
Wednesday, May 26, 2010
Thursday, May 13, 2010
The one page BASIC SID Benchmark.
How do you make sure the SIDs you bought from Ebay are fully working before giving feedback?
Or, you are the seller and you want to claim "100% fully working SID all voices. All Filters guaranteed!" and double check your stuff before you send the chips?
How do you make sure the SIDs that are in the old C64 in your dad's basement works before attempting a MIDIBox SID, sammichSID or other similar project? (Or midway through the project your dodgy soldering skills makes you wonder if you just blew out your 50$ SID?)
You find certain .sid files sound ODD on your setup and you want to be sure all waveforms of all channels sound good across the entire frequency range?
You want to make sure the filters are behaving within tolerance, or you want to quickly compare its frequency response with a third party?
or...
You are a nerd that does SID research, collect SIDs like Pokemons and compare each of them with scopes and frequency analyzers?
A: Sure I'm interested, but I don't have any fancy cart, X1541 transfer hardware. I only a bare C64 and a TV!
Then welcome to the world of BASIC program retyping!
This plays a sweep of every waveform on every channel like this:
Note: (T=Triangle, S=Saw, P=Pulse, N=Noise)
Next it does a filter sweep(resonance off) from all three channels with Noise
Low Pass (voice1, voice2, voice3)
Band Pass (etc)
High Pass
To my knowledge there is no other SID benchmark that is both relatively thorough and fast to type. This however does not test Pulse Width Modulation sweeps, ring mod or hard sync, and these could be part of a more in depth Benchmark, which I could code in assembler directly, and if there is enough demand, even make a 8KB ROM image in order to quickly use it with the various EPROM carts on sale on Ebay.
Closest thing I found is referenced from here. But it doesn't test sweeps nor all waveforms.
Also Mssiah users have access to a built in "Audio Test" which tries all voices and filter modes. But again, no help to you if you dont have that cartridge.
Proper steps for non C64-literate people:
Make sure nothing previously ran on your C64, or hit run/stop restore to make sure and type the following in:
type 'run'
If the test goes through without errors, it means you've probably typed it properly. Maybe its time to SAVE it! (You don't want to type this for all your SIDs right?)
using a 1541:
Note If you want better audio quality you can add these lines which will turn off the VIC chip (thanks to Lord Nightmare's SID Filter measurement code for the tip)
Alternatively:
If you have a X1541 transfer cable, get the D64 image
If you own a Commodore datasette, you can record this WAV file onto a cassette deck and play it on your c64. (note might have to invert phase in your favorite sound editor depending on your setup).
IMHO it surely beats randomly playing a few SIDs and affirming your chip is right.
Bonus points: you can test it in your favorite emulator to see how much aliasing it adds to the normal SID waveform generation's natural aliasing. Compare the audio results of the various SID settings in your emulator, etc.
So this post would not be complete without a few reference runs from some of my own chips.
Correct chips (NOTE these are NTSC recordings, PAL will have slightly different pitch):
6581R4AR (6581R4 AR 3086 S PHILIPPINES - see picture) Notes: (Brown C64) My 6581 reference for heavy filters.
6581CBM (6581CBM AR 2485 KOREA AH224867) Notes: (Brown 250407 C64) weird amplitude modulation in _PS_ wavform (seen this a few times on R2 and R3s)
8580R5 (8580R5 4887 25 HONG KONG HH465216 HC-30 - not pictured)
) Notes: (9V C64C) typical 8580, combined waveform are all audible, smooth filter.
Faulty chips:
6581_remarked2 (see remarked sid #2 in image) Notes: (Brown 250407 C64) quiet Low Pass filter, Near pass-through BP/HP
6581_remarked3 (see remarked sid #3 in image) Notes: (Brown 250407 C64) quiet LP/HP. Near pass-through HP.
EDIT January 2013: More Tests:
http://www.lemon64.com/forum/viewtopic.php?t=45909
Sad thing those remarked SIDs, I guess a whole subject in itself. People: there are no NOS SID chips anywhere now get it? Anything you buy as such should be taken with extreme caution. Please use this benchmark as a guide.
I agree with Wilba here, if the SIDs are FULLY tested, then I don't care if they are remarked or not "new old stock" as long as they are sold as such. SIDs are getting rare, this might be the only chance for some people to get their hands on SIDs...
Well not counting cannibalizing one of the 30 million C64's sold that is...
Or, you are the seller and you want to claim "100% fully working SID all voices. All Filters guaranteed!" and double check your stuff before you send the chips?
How do you make sure the SIDs that are in the old C64 in your dad's basement works before attempting a MIDIBox SID, sammichSID or other similar project? (Or midway through the project your dodgy soldering skills makes you wonder if you just blew out your 50$ SID?)
You find certain .sid files sound ODD on your setup and you want to be sure all waveforms of all channels sound good across the entire frequency range?
You want to make sure the filters are behaving within tolerance, or you want to quickly compare its frequency response with a third party?
or...
You are a nerd that does SID research, collect SIDs like Pokemons and compare each of them with scopes and frequency analyzers?
A: Sure I'm interested, but I don't have any fancy cart, X1541 transfer hardware. I only a bare C64 and a TV!
Then welcome to the world of BASIC program retyping!
This plays a sweep of every waveform on every channel like this:
___T (voice1, voice2, voice3) __S_ (voice1, voice2, voice3) __ST (etc...) _P__ _P_T _PS_ _PST N___
Note: (T=Triangle, S=Saw, P=Pulse, N=Noise)
Next it does a filter sweep(resonance off) from all three channels with Noise
Low Pass (voice1, voice2, voice3)
Band Pass (etc)
High Pass
To my knowledge there is no other SID benchmark that is both relatively thorough and fast to type. This however does not test Pulse Width Modulation sweeps, ring mod or hard sync, and these could be part of a more in depth Benchmark, which I could code in assembler directly, and if there is enough demand, even make a 8KB ROM image in order to quickly use it with the various EPROM carts on sale on Ebay.
Closest thing I found is referenced from here. But it doesn't test sweeps nor all waveforms.
Also Mssiah users have access to a built in "Audio Test" which tries all voices and filter modes. But again, no help to you if you dont have that cartridge.
Proper steps for non C64-literate people:
Make sure nothing previously ran on your C64, or hit run/stop restore to make sure and type the following in:
120 v(0)=54272:v(1)=54279:v(2)=54286 130 poke54296,15:fori=0to2 140 pokev(i)+3,8:pokev(i)+1,0 150 pokev(i)+5,8:pokev(i)+6,198:next 160 fora=16to128step16:fori=0to2 170 if a>64 then pokev(i)+3,0 180 pokev(i)+4,a+1 190 forf=0to254step2:pokev(i)+1,f:nextf 200 pokev(i)+4,a:forw=0to200:nextw 210 pokev(i)+4,8:pokev(i)+1,0 220 nexti,a:a=1 230 fori=0to2:pokev(i)+1,255 240 poke54296,(a*16)+15:poke54295,2^i 250 pokev(i)+4,129 260 forf=0to255:poke54294,f:nextf 270 pokev(i)+4,136:nexti 280 a=a*2:if a<8 then goto 230 310 poke54295,0(note at the end of line 240, the "^" character is a arrow pointing up on a C64, check listing picture)
type 'run'
If the test goes through without errors, it means you've probably typed it properly. Maybe its time to SAVE it! (You don't want to type this for all your SIDs right?)
using a 1541:
save"sidbench1",8,1using a datasette:
save"sidbench"and follow the instructions.
Note If you want better audio quality you can add these lines which will turn off the VIC chip (thanks to Lord Nightmare's SID Filter measurement code for the tip)
100 poke53280,0: poke53281,0 110 poke53265,11 290 poke53265,27 300 poke53280,254:poke53281,246
Alternatively:
If you have a X1541 transfer cable, get the D64 image
If you own a Commodore datasette, you can record this WAV file onto a cassette deck and play it on your c64. (note might have to invert phase in your favorite sound editor depending on your setup).
IMHO it surely beats randomly playing a few SIDs and affirming your chip is right.
Bonus points: you can test it in your favorite emulator to see how much aliasing it adds to the normal SID waveform generation's natural aliasing. Compare the audio results of the various SID settings in your emulator, etc.
So this post would not be complete without a few reference runs from some of my own chips.
Correct chips (NOTE these are NTSC recordings, PAL will have slightly different pitch):
6581R4AR (6581R4 AR 3086 S PHILIPPINES - see picture) Notes: (Brown C64) My 6581 reference for heavy filters.
6581CBM (6581CBM AR 2485 KOREA AH224867) Notes: (Brown 250407 C64) weird amplitude modulation in _PS_ wavform (seen this a few times on R2 and R3s)
8580R5 (8580R5 4887 25 HONG KONG HH465216 HC-30 - not pictured)
) Notes: (9V C64C) typical 8580, combined waveform are all audible, smooth filter.
Faulty chips:
6581_remarked2 (see remarked sid #2 in image) Notes: (Brown 250407 C64) quiet Low Pass filter, Near pass-through BP/HP
6581_remarked3 (see remarked sid #3 in image) Notes: (Brown 250407 C64) quiet LP/HP. Near pass-through HP.
EDIT January 2013: More Tests:
http://www.lemon64.com/forum/viewtopic.php?t=45909
Sad thing those remarked SIDs, I guess a whole subject in itself. People: there are no NOS SID chips anywhere now get it? Anything you buy as such should be taken with extreme caution. Please use this benchmark as a guide.
I agree with Wilba here, if the SIDs are FULLY tested, then I don't care if they are remarked or not "new old stock" as long as they are sold as such. SIDs are getting rare, this might be the only chance for some people to get their hands on SIDs...
Well not counting cannibalizing one of the 30 million C64's sold that is...
Monday, April 19, 2010
BLIP 2009 Presentation now online!
Hi
Here is the presentation I made at the 2009 edition of BLIP Festival, in Brooklyn New York last December. I've tried to squeeze as much info as possible in there, so it might be a challenge to follow especially considering I didnt have a microphone, so the camera just picked lots of ambiant noise (most of which has been DSP'ed out fwiw)
Thanks a lot for Max Deland for the video editing, and of for his fabulous Prezi presentation work.
PART1:
PART2:
PART3:
PART4:
We also have a yet to edit [XC3N] presetation of chipsounds been put at test in the Renoise Tracker. We will add it to the playlist when its edited and cleaned.
Here is the presentation I made at the 2009 edition of BLIP Festival, in Brooklyn New York last December. I've tried to squeeze as much info as possible in there, so it might be a challenge to follow especially considering I didnt have a microphone, so the camera just picked lots of ambiant noise (most of which has been DSP'ed out fwiw)
Thanks a lot for Max Deland for the video editing, and of for his fabulous Prezi presentation work.
PART1:
PART2:
PART3:
PART4:
We also have a yet to edit [XC3N] presetation of chipsounds been put at test in the Renoise Tracker. We will add it to the playlist when its edited and cleaned.
Thursday, April 1, 2010
Next Bidule version has something special....
You will be able to reproduce pretty much any type of LFSR based noises and tones. From simple Atari TIA tones to the more complex Noise waveform of the SID, as documented by Marko Makela and Asger Alstrup, in an interactive way.
Friday, March 26, 2010
SID waveform captures
Well well well, I knew that the 6581 and the 8580/6582 generated different combined waveforms, but I didn't know that not only each single chip generates slightly different bits from each other, but you also wont get twice the exact same waveform on two separate playbacks on a single chip.
This is a binary diff of two OSC3 sampling runs of a combined waveform on a 6581 CBM (r3) chip:
Thanks for kevtris again for the tip (but no thanks in a way, since I had to spend lots of evenings to make the code to generate these data files on a real c64 lol.)
I took care in recording the normal triangular and saw waveforms in each session for comparisons, and they match across all chips.
You can basically think of the SID chip as a 4096 (4kb) sized wavetable synthesizer with each entry being 12bits in precision, only instead of actually indexing a table (which would have been too long to do with the tight schedule given to Yannes when working at MOS), each index in the table is given to a function that generates output "samples" ; A simple counter in the case of the SAW, a comparator for the Pulse+PW, etc. Only later did Yannes/Ensoniq actually implement this as a real wavetable in the DOC chip used in the ESQ-1.
The combined waveforms are still a matter of study as to how they are generated, (see the work of Antti Lankila) . After recording a huge bunch of very different ones however I cant help but feel that
there is no "perfect" way to go at this. As each SID will generate something different, why not add some non-deterministic aspects into the generation?
In the mean time we can reasonably emulate the combined waveforms of the SID (which are really a odd mixture of bits in the analog world) by indexing a pre recorded table such as the one I've captured using the SID's 3rd oscillator "read" functionality. As you know the C64 is an 8 bit machine so we only can read a approximation of the real result (8 most significant bits out of the 'real' 12) but it doesn't really matter, since even at 8bits, we can prove that no two reads are the same, so who cares really if we lose 4bits of precision. Those data files for those combined waveforms will be included in my new emu code and you will be able to choose the version of the chip you want. That way you could simulate a wide range of different "runs".
Note1: the waveforms are $11,$21,(...)$81,
frequency=1, CIA timer=$FFF
Note2: I don't know what is "wrong" with that r2's P_T waveform. seems like its phase starts halfway compared to R3,R4 and 6582... I'm waiting for other R2's from Ebay so I'll retry when I get them.
Note3: The 6582's noise captures are all in phase, but not with my 6581 recordings... weird
more notes to come...
Monday, March 15, 2010
SID 6581R3 ADSR tables, up close.
In the center of any SID emulation there is the bare waveform generation, and a very accurate explanation of how the this works internally has been published through an interview with its creator, which can be read here. Fascinating read for any geek head!
However some very important details are missing, including the exact maths behind the main ADSR clocking but also its pseudo exponential decay/release stages.
It was time to have a look at the SID's DIE itself!
This is exaclty what kevtris and Lord Nightmare have done here
The SID chip has two obvious ROM based lookup tables on the DIE, for each voice. Here is the bigger one, as described in kevtris's blog entry:
I basically just cropped parts of the picture of the chip, which is available here, and placed the bit values on top of it.
However the blog post doesnt mention, nor explain the purpose of the second table, which I assumed was one of the "exp" tables, as mentionned in the Yannes Interview:
Yannes: "In order to more closely model the exponential decay of sounds, another look-up table on the output of the Envelope Generator would sequentially divide the clock to the Envelope Generator by two at specific counts in the Decay and Release cycles. This created a piece-wise linear approximation of an exponential. I was particularly happy how well this worked considering the simplicity of the circuitry.".
The SID patent's figure 10 mentions the following dividers are used: 30,16,4,2,1 . Hum not quite divide by two heh? 32,16,8,4,2,1 would have been more logical!
So lets try to decode the exact table on the DIE...
Well I didnt have a big clue myself, as reading bits of a DIE is all new to me, but after discussing with Lord Nightmare and kevtris, it appears this is also a LFSR counting trick, this time with a 5bit long LFSR and taps on bits 2 and 4:
Here is that table in plain ascii:
Kevtris explained that the left hand part is a "Selector" of sorts, since there is only one bit active on each line/column. The second part seems to contain inverted pairs of bits..... hmm puzzling...
Using similar code to what they provided, this time for the second table, and only taking the 'B' bits as LSB:
the results in exptable is 8,30,4,16,2, (which mostly matches the numbers in SID patent, except for the missing 8... and the weird order.
Ok so we know that at some points in the decay of the envelope, the clock divider changes... what does that mean exaclty and what are those "points"????
Heres what we can try:
We know the SID chip has two readable registers which are tied to the 3rd voice: One for the 8bit ENV value ($D41C) and the other for the 8 most significant bits of the waveform generator (which is 12 bits internally) at $D41B
So by setting the 3rd SID Oscillator's release at longest rate ($F), and by hooking up a CIA Timer to callback at each $7a13 cycles (which comes from the phase2 counter lenght for release 'F' according to kevtris/LN), we can, in theory, get a synchronized sampling of the envelope and store the results for analysis. As im lasy and that seeing is believing, I just programmed to display the values on the screen while the note decays.
Here is a live capture of that code running on a BreadBox c64 stuffed with a 6581R4AR:
If you know your Screen Codes, you can see that the envelope goes from 255 to 0, and that some values start to repeat at certain points...
The chars to look for are:
So while I can now go on with my emu code, knowing what happens, I'm still clueless on WHERE/HOW this comparison happens on the DIE. So if you have a clue, or spot anything wrong in my logic, please add a comment!
However some very important details are missing, including the exact maths behind the main ADSR clocking but also its pseudo exponential decay/release stages.
It was time to have a look at the SID's DIE itself!
This is exaclty what kevtris and Lord Nightmare have done here
The SID chip has two obvious ROM based lookup tables on the DIE, for each voice. Here is the bigger one, as described in kevtris's blog entry:
I basically just cropped parts of the picture of the chip, which is available here, and placed the bit values on top of it.
However the blog post doesnt mention, nor explain the purpose of the second table, which I assumed was one of the "exp" tables, as mentionned in the Yannes Interview:
Yannes: "In order to more closely model the exponential decay of sounds, another look-up table on the output of the Envelope Generator would sequentially divide the clock to the Envelope Generator by two at specific counts in the Decay and Release cycles. This created a piece-wise linear approximation of an exponential. I was particularly happy how well this worked considering the simplicity of the circuitry.".
The SID patent's figure 10 mentions the following dividers are used: 30,16,4,2,1 . Hum not quite divide by two heh? 32,16,8,4,2,1 would have been more logical!
So lets try to decode the exact table on the DIE...
Well I didnt have a big clue myself, as reading bits of a DIE is all new to me, but after discussing with Lord Nightmare and kevtris, it appears this is also a LFSR counting trick, this time with a 5bit long LFSR and taps on bits 2 and 4:
Here is that table in plain ascii:
SSSSS A B A B A B A B A B 00100 0 1 0 1 1 0 0 1 0 1 00001 0 1 0 1 0 1 0 1 1 0 01000 0 1 1 0 1 0 1 0 0 1 00010 1 0 1 0 1 0 0 1 1 0 10000 1 0 1 0 0 1 0 1 0 1
Kevtris explained that the left hand part is a "Selector" of sorts, since there is only one bit active on each line/column. The second part seems to contain inverted pairs of bits..... hmm puzzling...
Using similar code to what they provided, this time for the second table, and only taking the 'B' bits as LSB:
const unsigned short exp_lfsr[5] = {
0x1B, 0x0F, 0x11 , 0x08 ,0x1C
};
for (size_t i=0;i<5;i++){
unsigned int LFSR=0x1F;
size_t c=0;
while(1){
if (LFSR == exp_lfsr[i]){
exptable[i]= c;
break;
}
else{
c++;
LFSR = ((LFSR << 1) | (((LFSR >> 2)
^ (LFSR >> 4)) & 1)) & 0x1F;
}
}
}
the results in exptable is 8,30,4,16,2, (which mostly matches the numbers in SID patent, except for the missing 8... and the weird order.
Ok so we know that at some points in the decay of the envelope, the clock divider changes... what does that mean exaclty and what are those "points"????
Heres what we can try:
We know the SID chip has two readable registers which are tied to the 3rd voice: One for the 8bit ENV value ($D41C) and the other for the 8 most significant bits of the waveform generator (which is 12 bits internally) at $D41B
So by setting the 3rd SID Oscillator's release at longest rate ($F), and by hooking up a CIA Timer to callback at each $7a13 cycles (which comes from the phase2 counter lenght for release 'F' according to kevtris/LN), we can, in theory, get a synchronized sampling of the envelope and store the results for analysis. As im lasy and that seeing is believing, I just programmed to display the values on the screen while the note decays.
Here is a live capture of that code running on a BreadBox c64 stuffed with a 6581R4AR:
If you know your Screen Codes, you can see that the envelope goes from 255 to 0, and that some values start to repeat at certain points...
The chars to look for are:
"|": (93) switches to 2 waits before a drop "6": (54) switches to 4 waits before a drop "Z": (26) switches to 8 waits before a drop "N": (14) switches to 16 waits before a drop (Thanks Frank!) "F": (06) switches to 30 waits before a drop
So while I can now go on with my emu code, knowing what happens, I'm still clueless on WHERE/HOW this comparison happens on the DIE. So if you have a clue, or spot anything wrong in my logic, please add a comment!
Sunday, March 14, 2010
MESS 0.137 is out!
Hi
I'm proud to announce my little personal contribution to the best emulator project in the world.
Since a bit after chipsounds 1.0 was released, I started contributing some of my recent research to the open source 'MESS' project on the sound front. My contributions are "without strings attached" as I feel that the research in MAME/MESS is crucial to the good preservation of the history of computing. Besides, the accumulated knowledge in there will surely outlive me :)
"0.137
New System Drivers Supported:
-----------------------------
- Casio PV-1000 [Wilbert Pol, plgDavid]
(...)
System Driver Changes:
----------------------
- [SCV] Implemented upd177c audio. [plgDavid]"
The SCV audio still needs work, so that's not the last effort I will put into it. I've also tweaked the Arcadia 2001 audio code and made it much closer to the real thing. I also plan on revisiting a few other "drivers", when I get the chance, namely the VIC-20.
The MAME/MESS Teams members are very passionate and knowledgeable. I want to take the moment to greet Wilbert Pol, kevtris and Lord Nightmare especially, and to thank them for their time and near infinite knowledge.
Get it NOW
I'm proud to announce my little personal contribution to the best emulator project in the world.
Since a bit after chipsounds 1.0 was released, I started contributing some of my recent research to the open source 'MESS' project on the sound front. My contributions are "without strings attached" as I feel that the research in MAME/MESS is crucial to the good preservation of the history of computing. Besides, the accumulated knowledge in there will surely outlive me :)
New System Drivers Supported:
-----------------------------
- Casio PV-1000 [Wilbert Pol, plgDavid]
(...)
System Driver Changes:
----------------------
- [SCV] Implemented upd177c audio. [plgDavid]"
The SCV audio still needs work, so that's not the last effort I will put into it. I've also tweaked the Arcadia 2001 audio code and made it much closer to the real thing. I also plan on revisiting a few other "drivers", when I get the chance, namely the VIC-20.
The MAME/MESS Teams members are very passionate and knowledgeable. I want to take the moment to greet Wilbert Pol, kevtris and Lord Nightmare especially, and to thank them for their time and near infinite knowledge.
Get it NOW
Subscribe to:
Posts (Atom)