[sdiy] Prom generating TOS like MK50240 bits..

Sat Apr 21 21:24:19 CEST 2012

FYI, it should just fit in an Altera 5M40Z - it has 24 10bit logic blocks so it will be tight and will need an external clock. $0.96 at DigiKey. I don't have the Altera tools so haven't tried it out. 

On 2012-04-20, at 1:15 PM, Harry Bissell wrote:

> doesn't this just scream "FPGA" ?   :^)
> 
> H^) harry
> 
> ----- Original Message -----
> From: nvawter at media.mit.edu
> To: synth-diy at dropmix.xs4all.nl
> Sent: Fri, 20 Apr 2012 15:22:34 -0400 (EDT)
> Subject: Re: [sdiy] Prom generating TOS like MK50240 bits..
> 
> Quoting Tom Wiltshire <tom at electricdruid.net>:
> 
>> 
>> On 19 Apr 2012, at 18:15, nvawter at media.mit.edu wrote:
>> 
>>> Quoting Tom Wiltshire <tom at electricdruid.net>:
>>> 
>>>> Thinking about it more, though, it's the least common *multiple*  
>>>> which is crucial, not the factors.
>>>> Multiply all these, Least Common Multiple = 1.4163158499841E+22
>>>> 
>>>> Still very big, but we're under a yottabyte this time!
>>> 
>>> 
>>> Ah yes!  Glad you reminded me it's least common multiple...  that
>>> reduces my implementation to:
>>> 32*27*25*7*17*19*23 = 1123264800
>>> l(.)/l(2)
>>> 30.06505092474673512219, e.g. 2^30.065
>>> 
>>> So, that's just a little over 1 Gig addresses!
>>> 
>>> Shockingly enough, you can by 1Gb flash mems for ~$6 now.
>>> Since you'd need 11-12 of them (one for each note), that's about $66....
>>> or, just use a single 16Gb flash chip for $11.73!!!
>>> 
>>> If you were to clock it at e.g. 14080 kHz, the /32 output would  
>>> result in A440 and the chip would only repeat every 19 hours!
>>> 
>>> 
>>> With some interesting features... for instance, you could scramble,  
>>> randomize, wow, flutter, and otherwise perturb the outrageously  
>>> long word inside the memory to get variations and reduce  
>>> phase-locking...
>>> 
>> 
>> One thing I don't understand; are you using more than one bit for  
>> each output? if so, why? The point is that if we had a 16-bit  
>> memory, we could store the next state for all 13 outputs and have 3  
>> bits left over. In which case we need only one large 16-bit memory,  
>> not 12.
> 
> oops yeah I could have been clearer about that.  for now, I'm only  
> considering one-bit output per note... so when I said 1Gb chips for a  
> single voice, I meant literally 1 Gb of storage, which in practical  
> reality means 128Mb of addr and 8b of data, so you'd have to have a  
> demux in there to get the full 1G of data for the single voice.   
> That's obnoxious :)  So 1G of addr by 16b of data chip would be much  
> smarter.   And yeah I'm saying that the output would only require 12  
> (11) of those 16 bits.  The other 4-5 would be wasted, or alternates...
> 
> 
>> However, since the problem gets worse the more outputs you try and  
>> combine onto a single chip, perhaps it's worth looking at the  
>> problem in pieces.
> 
> oh mi god!  you just burst the problem space wide open again, just  
> when it was getting tractable :)  Seriously, not a bad idea to group  
> the outputs into more manageable sizes.  I'm not smart enough to  
> partition that without going through all possible combinations.
> 
> I think, using my product of 7 factors approach (32*27*25*7*17*19*23),  
> it would be possible to loop through all 128(64) combinations of  
> putting each factor into one or the other chip, and choose the  
> combination that results in the lowest common multiple.  e.g.
> 
> 32*27*25*7*17*19 in one chip,   23 in the other
> 32*27*25*7*17     in one chip, 19*23 in the other
> 32*27*25*7*17*23  in one chip,  19 in the other
> 32*27*25*7*19*23  in one chip, 17 in the other
> 
> ok I'm silly, I just wrote the program that does it (see source and  
> output at  
> https://docs.google.com/document/d/1qLgSr9A_BqfQit-rcODdxahpwE4Qw0nuAJLp2-n10VU/edit).  The optimal way seems to be a combination  
> of:
> 52003 in one chip and 21600 in the other chip.  Note that these are  
> below 64k!!!
> 
> 32*27*25 = 21600
> 7*17*19*23 = 52003
> 
> 
> although -- it's note quite valid for the problem b/c those values  
> aren't the actual values needed to make sounds...   I would shift it  
> around and stuff those "ugly" (prime) dividers together on the same  
> chip.  That would fit on an 8k chip and a 256k chip :)
> 
> 17*19*23 = 7429
> 32*27*25*7 = 151200
> 
> 
>> Say we broke it into 4. Which outputs would you put on each chip to  
>> get the smallest possible memory size? (e.g. which ratios combine to  
>> give the smallest least common multiple?).
>> This would reduce the problem enormously, although it would require  
>> 4 sets of address counters. For example 478x358x239 = 40,898,636 -  
>> only 27 bits required for the address!
>> 
>> To be honest, I still don't think this is a viable way to go. I've  
>> thought quite a lot about this problem on and off over the last few  
>> years. It's a classic "can it be done on a $1 PIC?" problem, which  
>> is why it appeals to me - I don't actually need or really see the  
>> point of a top octave generator chip.
> 
> I agree that as a final, shipping, production solution TOGs are  
> probably not sensible.  However, for exploring and experimenting, it's  
> very convenient to have simultaneous access to all 12 outputs.  I'm a  
> programmer so I see things different from the rest of the crew I work  
> with...  they like things at the chip-level, having come from the  
> circuit-bending direction, so they're fond of making tangible  
> connections.  I think it's got something to do with constructive anger  
> which doesn't translate well into virtual activities :)
> 
> One other consideration when comparing e.g. CPLDs to uControllers  
> would be the maximum clocking frequency.  a CPLD might be able to  
> reach 200MHz or so, while a uController might be hard-pressed to work  
> function at 1 MHz, unless code was 100% optimized.  So, part of the  
> decision depends on how fast your source frequency is.
> 
> And I guess the other part is complexity/number of chips/board space.   
> The whole reason I decided to use a CPLD in the first place is because  
> when I tried it with discrete logic, it was too big to fit on a PCB of  
> the eval version of Eagle :)
> 
> BTW, w/r/t to reducing phase locking, it might be possible to  
> introduce noise into the clock.  For example, in my CPLD "Divider  
> Party," every divider is clocked by one input...  but why not use  
> separate clocks into the chip and physically interfere with them?    I  
> like your idea of using the thermally-influenced internal oscillators  
> even better :)
> 
> 
>> Anyway, my best guess for a solution would be to use 12 super-small,  
>> super-simple chips to simply output the states for *one* note. This  
>> requires a maximum of 478 different outputs, and perhaps twice that  
>> for ROM if it takes you two instructions to output a literal to a  
>> pin. So you'd take 12 of these:
>> 
>> http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en019863
>> 
>> (6-pin, SOT-23, costs $0.30 - total under $4)
>> These all have their own internal 4MHz RC clock, so you won't get  
>> phase locking, and you will get some temp drift - hey, it's almost  
>> an *analog* solution! Alternatively, find a similar chip that  
>> accepts an external clock and clock all 12 uPs from one master  
>> clock, locking the phases and making it sound like a cheap Italian  
>> organ from the 70s.
>> Currently, that's the best way I can see - but I don't use  
>> CPLD/FPGAs, which probably offer another route.
> 
> 
> yeah, that's actually a really good an interesting solution, too!
> 
> 
> 
>> Regards,
>> Tom
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
> 
> -- 
> Harry Bissell & Nora Abdullah 4eva
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
> 