[sdiy] Top Octave Generator (was Chinese MG-1s??!?)

[Veronica Merryfield]

>
> The division ratios vary a bit depending on the master clock  
> frequency, but here's a set for a 2MHz clock.
>
> C low	÷478
> C#		÷451
> D		÷426
> D#		÷402
> E		÷379
> F		÷358
> F#		÷338
> G		÷319
> G#		÷301
> A		÷284
> A#		÷268
> B		÷253
> C high	÷239
>
> 2 MHz divided by 478 results in a frequency of 4184 Hz which is a C5  
> note
> 2 MHz divided by 239 results in a frequency of 8368 Hz which is a C6  
> note (the highest one on the organ usually).
>
> Obviously if you double the master clock frequency, you can also  
> double the division ratios and keep the note outputs the same. Since  
> you can then adjust not-quite-right ratios to odd numbers in- 
> between, higher master clocks will give you better accuracy.
>
> The Old Crow code produces the tones of an octave, but shifts it  
> down a few octaves, which makes life much easier since it gives you  
> more time to calculate the outputs. I don't know the detail on other  
> processors (and maybe AVRs would be better for this job?) but the  
> basic PICs will only run to 20MHz, with a 5MHz instruction cycle. If  
> we ran the chip at 16MHz to give us a convenient 4MHz instruction  
> cycle, we'd still need to get data out every other cycle.
> I'm loathed to say it can't be done, since PIC hackers often just  
> take that as a challenge and then prove you wrong, but if anyone can  
> pull that off, it'd be an impressive effort.
>
> If you were willing to accept some variation in duty-cycle between  
> outputs, that might make life easier. Given the heavy filtering in  
> most electronic organs, I doubt it'd be a huge issue.
>
> It's definitely a tricky one, or someone would have managed already!

The way to make this work is not to have 12 dividers but to use a  
rolling scheduler.

You have a table of structures, the first entry is the number of  
'ticks' you need to wait before generating the event and the second  
entry is the event specifier (probably a number indicting a port pin).  
The tick could be a timer. When the tick happens, the event is  
produced and it expires. The software inserts the next event of this  
type into the queue using the division ratio to place it then  
calculating the count from the previous entry as it's count and  
updating the next entry to subtract that amount out of it's count. I  
would use 24 events in all, one of each edge of each output. A little  
intelligence will be needed to handle events that come close together.  
If you can use a micro that has a single timer with interrupt then it  
is a sequence of single shot timer events. If not, then you need some  
way to count processor cycles and carefully crafted code.

I'm not going to volunteer to write it as I have too much else on, but  
I have done very similar things in small processors with a lot more  
work to do between events and setting events - it's how ECUs work.

Veronica