.plan (audio version)

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)

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:

___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,1

using 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...

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.

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.

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...

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:

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!

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

The SID's non-monotonic DAC

That picture is from a 6581R4AR. A Simple ADSR glide on a 50/50 Pulse set at highest freq.
This is going to be fun to emulate....

http://masteringelectronicsdesign.com/an-adc-and-dac-differential-non-linearity-dnl/

Ultimate 2532(or 2352) PROM MegaCart!!! ... kinda

While visiting my favorite local Electronics Surplus Store I came across this odd 24 pin fake IC to IC cable, which gave me a cool idea. One very common (and boring) tasks in my line of work is doing adapters to run ROMs (custom and whatnot) on the real hardware for analysis. This setup makes it pretty easy (and solderless) to try stuff around, especially difference in CPU<->BUS<->ROM handshaking signals like !CS !CE, !E whatever, and also configuration of adress lines.

Systems that typically use such 24pin ROMs include
VIC-20
ATARI 2600
MPT-03 - Arcadia 2001 clone(pictured)
Odyssey2

This particular breadbreadboard setup allows me to quickly "audition" up to 16 different 4KB Arcadia ROMs using DIP switches.

That big mysterious gate array

Analyse.. don't Destroy (a Casio PV-1000)

I'm not a console collector nut, I'm a audio chip collector nut. There are countless game consoles and computers out there that I dont care much about because they all contain the same chips. (AY-3-8910 is nice, but you can only have so many of them).

What I'm looking to acquire at this point are the most obscure ones which contain custom/unique sound generating chips. You've heard about the CASIO PV-1000 before?

Don't worry, only the most die hard console collectors did. And they would die for it too. There are very very few such consoles out there and I got mine a bit by chance, and it was an impulse buy.

At 300$ (ebay), you just can't afford to ruin it can you? (I'm not a movie producer). And I look forward to its resell value once im done with it. Thats where the challenge comes in... how do I take a device that comes with just a NTSC-J RF adapter and get good enough audio results with it? (the RF channels on North american and Japan dont match... dont try)

The closest I got to getting a picture/sound from the default unit as is was to use a ANALOG/DIGITAL USB TV tuner, which had by chance a NTSC-J mode:

Not that bad, but, the audio was horrendous, and really not usable for my tests. However I've hacked nearly all my consoles in order to have separate composite video/audio from RCA jacks, so on top of some test equipement, i've got a few hunches on how to solve this cleanly.

the RF box is tied to the main motherboard in a very clean way:

A few minutes with my multimeter, from top to bottom:
1)9VDC (current for the amplifiers in the RF sections i assume)
2)GND
3)Composite Video Out.. YAY!
4)GND (same as 2)
5)Audio Out...  w00t!

Connecting Aligator jumpers to truncated ends of a RCA and to the pins 3,4 and 5 did provide me with a temporary solution, but surely isnt very practical for a longer term analysis.

Oups, where did the RF box go? (in a safe place in case I resell it and the buyer really is after lots of  pain and suffering).

Much better.
 From the outside:

Enjoy the OK quality outputs:

Meet my new friend the logic analyser!

Its time to step my game up. So I've decided to acquire the immese value for money Saleae Logic Analyser. This baby will allow me to analyse and record a bunch of stuff that really cant be handled with a sound card and an oscilloscope alone. (namely serial digital audio prior to being sent to DACs)

As a test to see if everything works, and that i can get sufficient time resolution on this, ive done a simple setup which consists in a 4Mhz clock and a Hex inverter (74LS04). I done my recording test using 24Mhz on my MacBookPro's USB2 port. And im quite happy with the results. Not bad for 15 minutes of unboxing the thing!

These are not the chips you're looking for

[EDIT dec7th 2009] the wikipedia page has been corrected!Thanks!

According to wikipedia there is a VRC6 chip inside a North American Nigel Mansell "World Challenge" cartridge. Well no, there isn't. And there's no such thing as "World Challenge" either, only "World Championship" same difference.

Looks like Ill have to dig up the big bucks for a Japanese Castlevania 3 cart.

TED: The 100$ noise pattern

00000000110010000100010111111101010011100
11000111111000001011010101101111101111000
10000001001111001110110011111001011101011
00101011110100011000010100000111000110101
11000011110110110100001101110111001001000
11101001100110100100110110001010101000100
101001011  (low frequency version: audio)

Working C16's and plus/4 are HARD to come by,
and people need to pay the price for a working
MOS8501 CPU and a MOS8360 TED chip.

I needed a real machine to analyze the TED noise pattern
(and pitch ranges) for a future version of chipsound,
so I won a working plus/4 on ebay, which cost me 100$
(with shipping) to Montreal, not that bad actually.

The TED will be included in an update for completism more
than anything, because the only thing that's unique about it
is its noise pattern. Otherwise its a very simple VDC
unit that generates 2 voices. Many plus4 users actually hook
up SIDs to the machine, or just use the chip as a DAC,
which is the case for demos such as this one

Confirmed VICE plus4 emu generates the same pattern,
so all is good.

(100$/255bits = 39cent/bit)

But is it cute??

 

Hum, nah, im not cleaning that GUNK to find out!

Full AY emu prototype

Well I've talked about this before, but I'll say it again.
Designing a synthesizer that claims full chip authenticity and playability at the same time is the toughest challenge I'm faced with.

It hard to give access to powerful sound tweaking possibilities available on some chips when the synth paradigm you are basing your whole design on is of the standard
[voice0 + voice1 + voice2 + (...) + voiceN = mix]
variety

Look at this signal path for instance:

It becomes clear that something like this doesn't fit that particular mold.

The AY has five generators: 3 tones, 1 noise, and 1 envelope.
It also has three independent audio output pins, that are mixed in the analog world differently in all the AY-based systems.

Now each of the output has its own tone generator, but it can also be mixed with the lone noise pattern (either, or combined with a binary AND). On top of that each output can have its volume changed independently (16 log steps), or be amp-modulated by the LONE Envelope generator. (more in the spec)

Anyone who's messed with an AY knows that the fun comes from mixing the env/tone+noise in certain ways which can make unique drones/beats that any IDM/Experimental student would enjoy.

But you can't currently do these in chipsounds v1.0 due to voice paradigm its based on. From recent user questions on the AY matter, it surprised me how programming a straight chip emu sounds like a hard task.
But in reality, in comparison to trying to make it fit in ARIA/SFZ, making a separate module that purely emulates the chip in bit perfect manner (and with all its limitations) is really not the challenge it appears to be.

The AY is a relatively simple digital state machine

Here is a snapshot of my current prototype (made using Bidule's C++ SDK):



And the type of drones you can dynamically make by moving the sliders here:
Example A
Example B

Its currently unclear if/how this will be integrated in chipsounds, or given for free for Bidule users. Please stay tuned!

How I recorded and decoded POKEY's polynomial counters;Open Pokey Recipe for the curious

Hello

This is a "reprint" of the comments inside "POKEY.sfz", the chipsounds POKEY configuration file. (the original date is March 2009)

******************************************************************************

Was I naive to think that POKEY was just "another TIA", and I spent enough evenings to regret it. Making the breadboard and having Pokey spew some tones was the easy part, but soon realized that various frequencies gave me different patterns (sometimes after retriggereing the SAME note!)

So I tried many things, recorded GB's of tests and had a few ideas.

After lots of trials and loss of sanity:
Here is the FINAL methodology that I used to get usable data:

A)Clock a POKEY with a VERY SLOW clock (I used a +- 10Khz 50/50 PWM signal from a PIC)

B)Set Bit 6 of AUDC1 ( "1.79Mhz" or cpu clock)

C)Play the highest notes you can for each pattern: AUDF1=0 then AUDF1=1, (...), AUDF1=4

D)Record each bit pattern and pass it through our patternfinder util.

Now since the results are NOT the source pattern, but a "resampled" pattern made after skipping 4+AUDF source pulses for each destination pulse (according to the POKEY spec's "MODIFIED FORMULA"), we must derive the actual SOURCE pattern from the results.

The trivial thing to try is this:

void Shuffler(const char*in, char*out, size_t len, size_t shufsize){

    size_t cnt=0;
    for (size_t i=0;i<len;++i){

        out[i] = in[cnt];
        cnt+=shufsize;

        cnt = cnt % len;
    }
}

In this case my recorded AUDF1=0's 4, 9 and 17 bit patterns gave the exact same results as source OR destination (with added offset before looping of course), which kinda proves that AUDF1=0 can give you the full pattern, and that there is magic somewhere (try that with any other random bit pattern for fun). With this source pattern I was able to verify my own "software resampling" using AUDF1=1,2,3... and so forth from my recordings for a match.

4bit poly: 000011101100101

However, and that's where the fun ends, the 5bit pattern was a pain. Patternfinder kept giving me a 62 bit long repeated pattern:

"00000010111000011001010010011101111110100011110011010110110001"

and NOT a 31 bit pattern like I expected!

I noticed that the former 31 bit half of that pattern was always the inverse of the later (whatever point at which you start).A "hint" that the results im getting use some form of inversion. Schematics show that the source pattern passes through the same circuit logic as the "plain square" so it is used as a "please invert previous bit" matrix

SO: Inverting THAT pattern (fill/skip_4 a 31 bit pattern) gave me the following from my 62 pattern: "1101001100000111001000101011110". Which, as with the 4,9,17 case was used to test for the generation of AUDF1=1 and other frequencies.

chipsounds specific:

A few unique oscillators have been made just for this chip.
One and Two Stream AND-ers and One Stream Differentiators were required to emulate the inner process of the POKEY chip.

Invaluable help from "DeRe Atari Chapter 7", and from the official specs.
And for the various Pinouts/Skematics found online.

Last minute addition: Odyssey 2 (P824x) VDC chip!

Building a software product and analyzing hardware are two very important facets of a product like chipsounds. Do mostly the analysis and you have a very techy app that no one understands, do only the former and you miss that that hands on feeling and the smell of printed circuit boards.

So this weekend I took a little break from coding (which is very close to done anyway) And looked at the few consoles in my lot that are not fully analyzed yet (I will add more chips in updates). And decided that chipsounds 1.0 required the Odyssey2.



The interesting thing is that there is no sound-coder-friendly documentation on the P8244/P8245 online yet, so I figured might as well publish everything I've learned so far.

My research consisted in confirming Sören Gust's info from g7kbios.pdf and to go further in trying various combination of tones and timbres that would be possible on the console itself without using IRQ based resynchs and also to check on MESS's source code theory of the "OR"ING of tone and noise, and to check for their claim of a 16 bit LFSR used for the noise channel.

On top of his great commented Bios document, Gust kindly provided the community with example assembler "Hello Worlds" for the console and even an improved the BIOS sound player which I then used to run tests on the "real thing", using a ripped apart Baseball Cart and a 2732 eprom (2k code is mirrored twice)... don't have 2716's at hand yet

The available docs mention a 24 bit shift register that is clocked by only two dividers: 983Hz 3933Hz, without any concrete info on how those two frequencies are achieved by the hardware from the master clocks in the first place.

So what is the main clock divisors for this chip?

Before trying to hack in assembly/eprom, I played with the few cartridges I had, and found out that pressing (and holding) the reset button stalls the CPU, but not the VDC, which keeps playing the current tone (or noise) - very handy indeed.

Long tone segments were recorded by tapping the audio signal at the junction of the main board and the RF box. (a tad bit of LP filtering at this point but nothing heavy)

Various NTSC Recorded pitches (Bidule FFT/PVOC Loudest freq analysis)
1966.572266Hz
983.285583Hz
655.523987Hz
327.762299Hz
163.881409Hz
81.949478Hz

Assuming 1966.572266Hz came from this pattern: 101010101010101010101010 this means a high freq of would be generated from a clock of 3933.144532 (2x) Which tends to confirm the 3933 value. (note: 983 is just 3933/4)

The preliminary docs for the Intel VDC included in Arnim Läuger's
mcs-48.pdf Mentions the 3933 value comes from 15734/4 but nothing else. Looking around for the source of this frequency:

NTSC television scans 525 lines about 29.97* times a second = 15734.25)
SO -> Precise (theoretic) NTSC values would then be:
15734.25/4 = 3933.5625 (high from now on)
15734.25/16 = 983.390625 (low from now on)

(PAL television scans 625 lines * 25 times a second = 15625)
Precise (theoretic) PAL values would then be:
15625/4 = 3906.25
15625/16 = 976.5625
(would love a Videopak machine to confirm)

---------------------------------------------------

Using Gust's improved BIOS player:

We can verify that:

1)DAC is linear, from recordings of a programmed ramp of the 16 volume values

2)Noise is a LFSR-based 16383 bit long repeating pattern.
I haven't yet taken the time to find the exact LFSR formula,
but i've added it as a table.

3)We can indeed generate any looping 24 bit patterns we want:
Example: 0xFFFF00 (2/3 duty)
0x080000 (1/24 duty)
0x001403 (000000000001010000111011 or padded TIA pattern)
Byte Order check with output:
0x010203 (000000010000001000000011)
Recorded output: from left to right starts with:
(?)11000000010000001000000011000000010000001(...)

Listen to those here

4) Possible pitches (using 50% duty as guide):

24 bit
000000000000111111111111:(low)    40.9746Hz
000000000000111111111111:(high)  163.8984Hz

12bits
000000111111000000111111:(low)    81.9492Hz
000000111111000000111111:(high)  327.7969Hz

8bits
000011110000111100001111:(low)   122.9238Hz
000011110000111100001111:(high)  491.6953Hz

6bits
000111000111000111000111:(low)   163.8984Hz
000111000111000111000111:(high)  655.5938Hz

4bits
001100110011001100110011:(low)   245.8477Hz
001100110011001100110011:(high)  983.3906Hz

2bits
010101010101010101010101:(low)   491.6953Hz
010101010101010101010101:(high) 1966.7813Hz

That's all well and good, but what about 24/8=3 bits?
yes that would make another pitch frequency available, 
but could only play 011 and 001 (1/3 and 2/3 duty)

3bits
011011011011011011011011:(low)   327.7969Hz
011011011011011011011011:(high) 1311.1875Hz New freq!!!!


in pitch order:
000000000000111111111111:(low)     40.9746Hz  MIDI:28( E2):  41.20344543
000000111111000000111111:(low)     81.9492Hz  MIDI:40( E3):  82.40689087
000011110000111100001111:(low)    122.9238Hz  MIDI:47( B3): 123.4708252
000000000000111111111111:(high)   163.8984Hz  MIDI:52( E4): 164.8137817
000111000111000111000111:(low)    163.8984Hz  MIDI:52( E4): 164.8137817
001100110011001100110011:(low)    245.8477Hz  MIDI:59( B4): 246.9416504
011011011011011011011011:(low)    327.7969Hz  MIDI:64( E5): 329.6275635
000000111111000000111111:(high)   327.7969Hz  MIDI:64( E5): 329.6275635
010101010101010101010101:(low)    491.6953Hz  MIDI:71( B5): 493.8833008
000011110000111100001111:(high)   491.6953Hz  MIDI:71( B5): 493.8833008
000111000111000111000111:(high)   655.5938Hz  MIDI:76( E6): 659.2551270
001100110011001100110011:(high)   983.3906Hz  MIDI:83( B6): 987.7666016
011011011011011011011011:(high)  1311.1875Hz  MIDI:88( E7): 1318.510254
010101010101010101010101:(high)  1966.7813Hz  MIDI:95( B7): 1975.533203

So there are 10 UNIQUE 50/50 pitches, plus one 2/3 pitch, but LOTS more different _timbres_ using other patterns. The BIOS engineers only included the 10 "different" (to the ear) 50/50 ones...

At least they found a right divider/pattern length to generate a mostly tuned E5 Scale
( -9.6417 to -7.6867 cents off Equal Temperament in NTSC)
(-21.7044 to -19.7494 cents off Equal Temperament in PAL)

Just enough for a PO-LING :)
Back to possible Timbres Lets fill some timbre void shall we?
A pitch is perceived by the repetition of a pattern:

2^24= 16777216 possible timbres for 40.9746Hz and 163.898560Hz
2^12= 4096 possible timbres for 81.951134Hz and 327.796722Hz
2^8 = 256 possible timbres for 122.919807Hz and 491.694153Hz
2^6 = 64 possible timbres for 163.898621Hz and 655.593628Hz
2^4 = 16 possible timbres for 245.850220Hz and 983.390808Hz
2^3 = 8 possible timbres for 327.7969Hz and 1311.1875Hz
2^2 = 4 possible timbres for 491.696228Hz and 1966.781128Hz

case 2^2 can only really do 50/50 since 01 and 10 sounds the same
... in a monophonic console. 00 is silence; 11 is a DC offset click

case 2^4 following the previous logic can only do 25% 50% and 75% duty...

We did not map them all in chipsounds, but this could be added in the future in a more specific oscillator ...

VIC-20 MIDI Interface and Synth Cartridge Prototype

The VIC-20 was my first computer. You can imagine how close and personal I am with the thing. I do feel that its been unjustly historically overshadowed by the computer that followed it, especially in the audio/music scene.

Viznut and PwP's Robotic Liberation was a real blast and it probably revitalized the scene a bit.

But what we need is a musician friendly way to tackle the beast!
Three years or so ago I requested the help of François Leveillé (aka eslapion) on the Denial forum, a VERY nice electronics guru to help me construct a VIC MIDI Interface like the one HERE . So that I could concentrate on making the 6502 assembly code to read the input MIDI then drive the VIC-I chip. I got the prototype from eslapion, had the core MIDI read code done, but got side tracked by the VIC-I emu in chipsounds and figured I would pursue the project a bit later... that was two years ago.

Early this year Leif Bloomquist wanted to do a similar project, so I just lend him Francois's proto and my preliminary MIDI reading code and hes done VERY WELL with it See and hear it HERE

This is really a prototype, but I believe it is going to transform itself into something that any 8bit musician will not want to miss!

Congrats to Leif for pulling it off! I want serial #00001 ok?

New screenshots on official site

Its getting VERY VERY close to shipping now.
I just build release candidate 1 with the first bunch of presets.

New screen shots and a new "preset-show-off" excuse for a track from myself on

the official chipsounds page

Kudos to my testers

Hi

We are quite lucky to have some of you testing this thing.
You know who you are and you will be credited :)

Thanks again!