Let's Design and Build a (mostly) Digital Theremin!

I put a spreadsheet with the file name "delta_sigma_dacs.xls" at the repository:

http://www.mediafire.com/?m8iwgugdd68i13f

It's kind of fascinating to plug various input values into the first and second order modulators and see what the output looks like.  I did one of these using analog components in grad school, with the output driving an LED and a speaker.  First order gives all kinds of tones, second order is much more stochastic.  I'm looking into adding dither to the second order so as to reduce spurs.

"Do you remember bit-slice archetecture?"

After looking into it a bit :) it seems to be a way for the designer to build data paths of varying widths with a single family of products, and a way for manufacturers to deal with the very limited pin counts of earlier IC packages (when you work with FPGAs you find out very quickly that pin management is something of a job in itself).

I'm always on the lookout for simple processors, because often much of the hardware in an FPGA design is underutilized due to low clock speed.  If latency isn't an issue, then why not multiplex the hardware with a processor construct?  But I'd like it to be really simple (stateless would be the ideal), not consume much in the way of logic (LUTs, block RAMs, multipliers), have compact op codes (internal block RAM isn't cheap), have high utilization of the ALU (the whole point), and probably most important: be easy to program at the machine code level so I don't need an assembler.

Ever since my first HP calculator I've been fascinated with stack machines.  With no explicit operands, a data stack, a return stack, and almost no internal state, one can have incredibly compact op codes - often 5 bits will do.  They can be very interruptable, and code factoring with subroutines is more natural due to the stacked registers.  I've studied many of these, and have coded my own and had them running on a demo board.  They are easy to implement but surprisingly rather cumbersome to program - one has to stick loop indices under the operands on the stack or in memory somewhere, and there are a lot of operations and time wasted on simple stack manipulation.  The tiny non-standard op code lengths produce a natural instruction caching mechanism, but multiple op codes per word is awkward when you want to manually change the code in any way.

If you are interested in processors and you've never looked at the Xilinx picoblaze, you should - it is a marvel of tiny engineering.  Kind of an overgrown register based state machine.  But the op codes are not powers of 2 in length, and addressing the registers bloats them out.

I'm coming to the conclusion that any serious processor has to have multiple registers with operand addresses in the op code - this allows for a move along with an ALU operation in a single cycle.  Self-evident to many I suppose, I'm so slow when it comes to the fundamental stuff.  After looking at the J processor I had a thought - why not do a 2 operand machine (source & source/destination address in the op code) with 4 generic registers, and have stacks under those registers with bits to enable/disable them in the op code?  A 16 bit machine with 4 bits for operand selection, 4 bits for stack enable, 8 bits for the operation itself.  Large literals would be in-line, small ones could be in the op code field. 

Anyway, it's this kind of massive side diversion that is (I hope not pointlessly) extending the design of my (mostly) digital Theremin, but I'm hoping to parlay much of the foundation established here into other designs.  And it's nice to revisit things I've spent enormous amounts of time pondering and tinkering with, but with little to show for it all at the end.  Though it does feel a bit scarily like answer C of that humorous Engineer Identification Test, where:

You walk into a room and notice that a picture is hanging crooked. You...

A. Straighten it.
B. Ignore it.
C. Buy a CAD system and spend the next six months designing a solar-powered, self-adjusting picture frame while often stating aloud your belief that the inventor of the nail was a total moron.

"Ever since my first HP calculator I've been fascinated with stack machines."

http://obswww.unige.ch/~bartho/stakflow/index.htm

"when you work with FPGAs you find out very quickly that pin management is something of a job in itself" - Dewster

Yeah - I can believe that! The PSoC (1) was advertised with pin reconfigurability as a selling point - whilst this is generally true, as soon as you get to doing anything complex with the part, you quickly find that its not so true.. I spent more time trying to connect pins to UM's to actually use the resources in the chip, than I spent on other configuration / coding issues.

I understand (and from examining the data, it looks to be true) that the new PSoC 3 + 5 pins are almost absolutely definable.

For what I do with them, the processor has only a minor role - mostly, I configure the chips to be "hard wired" as circuit blocks (analogue and digital) which operate without reference to the processor - the only time the processor acts is to reconfigure these 'blocks' when a change is initiated by the user - for example when the register (as in octaves are raised or lowered) is changed.. The processor is continuously scanning the inputs (doing debouncing , reading the A/Ds, determining wrong-side-of-null etc) and when action is required, initiates the required action/reconfiguration - this takes a few microseconds. Nothing related to the audio is ever 'produced' by the processor.

I have looked at the PSoC 3 + 5 thinking that I may (with their much faster processors) be able to do some 'signals' stuff with these  - in particular, doing some DSP in combination with the analogue filters I can construct in these chips, to implement controllable vocal formants.

But, certainly for now, if I do get back into business, I will stay with analogue and mixed signal.

The main "wall" I face is maths - DSP is too maths intensive, and whilst I can get enough of it to understand whats going on, I cannot do anything clever.. The TM showed me just how far I am from even being a DSP hobbyist, let alone an engineer!

What is really needed (IMO) is a team of engineers (and competent thereminists as consultants), sharing ideas and competence, and developing a 21st century theremin which uses the best of technology.. Alas though, I do not see this happening - we are all stubborn gits at heart - with our own particular preferences and irrationalities.. More time would probably be spent discussing (arguing!) than achieving anything - And "the inventor of the nail" would get the brunt of our scorn!

Fred.

Gordon,

Opening:

http://obswww.unige.ch/~bartho/stakflow/index.htm

The first image I saw (before I read the title) looked like some weird theremin design - Two "antenna" symbols sticking out the top of some 3d interconnected sub-circuits.

Really took me back, your article! All that stuff I used to work with daily, but have almost completely forgotten -

Now, when I look at a flowchart, my brain first assumes its a schematic ! LOL!

Fred.

"Ever since my first HP calculator I've been fascinated with stack machines."

http://obswww.unige.ch/~bartho/stakflow/index.htm

Ha!  I do have several Forth books, and have read a lot of stuff on Chuck Moore's web pages.  Being a procedural rather than a symbolic language, I find it very difficult to read.  I know it has to be 100% postfix to work, but this puts the branching words (if, then, etc.) in places where they don't necessarily make sense from a linguistic point of view.  Also, having simple stack manipulation consume the same real time (in a hardware stack machine) as an arithmetic operation strikes me as inefficient.  Finally, the stack gymnastics necessary to produce compact code often tend to obscure the algorithm being implemented.

I'm all for what they are trying to accomplish (simplify the lowest level, bring cheap computing to the masses, stick it to the man, etc.) I just wish I could appreciate it more for what it is.

Fred. Hahaha. Yes. (Although I thought it looked more like a trumpet.)

Also, not surprising that they look like schematics - Forth is one of the few (if not only) languages devised by an engineer rather than a computer scientist.

Dewster. Yes, it is an inscrutable language. It's assembly language for a stack machine, so really ought to be compared to register machine assembly languages for legibility purposes. (Although these days C is probably the closest most programmers can get to the hardware and that's not exactly the most legible language in the world either. Well, it baffles the heck out of me, anyway.)

It is possible to optimise Forth to remove stack shuffling inefficiencies - certainly Forth Inc. Forths do that - just as it is possible to optimise much of that inefficient shunting data in and out of registers in a register based machine - but I appreciate the simple and direct one to one correspondence between the written code and what the computer does. And that it acknowledges that the programmer is the smart one in the relationship, not the computer. Pretty much the same things that I appreciate in the theremin! (The downside is that the burden of responsibility is on the programmer/thereminist is greater - no lovely hand-holding here.)

"The downside is that the burden of responsibility is on the programmer/thereminist is greater - no lovely hand-holding here." - Gordon

Hand-holding, when it comes to programming, is, IMO, a pain in the but. My main programming language is C, combined with assembler - "plain" C is about as close to machine level as one can get, and (IMO) is ideal for coding MCUs..

But it is C++ (particularly microsoft variants - but also any OS centred variants [apart from unix, which C was written for]) which I dislike - One is not developing code with these, one is patching preconstructed objects together.. its (to me) a bit like painting by numbers, fine if you like the picture and the colors provided.

To me, C++ is just overwhelming and unreadable, but C is almost like a legible form of assembler - I quite often plan my project code in C, then use this as a "plan" commenting out the C lines and substituting more efficient assembler code to do the function.

I only briefly played with Forth, and really liked it - It was well suited to the TMS9900 I was using at the time, as this operated with multiple stacks and had specific opcodes to allow rapid context switching (it was a lovely processor IMO) - But this was back decades ago (I used a teletype as my I/O back then - for developing code, and we tended to write our own interpreters and compilers - or just code in octal!)

And yes - Euclid's trumpet does look like one of your flowcharts - or is that one of your flowcharts which looks like a trumpet?

Incomprehensible!

Fred.

"But, certainly for now, if I do get back into business, I will stay with analogue and mixed signal.

The main "wall" I face is maths - DSP is too maths intensive, and whilst I can get enough of it to understand whats going on, I cannot do anything clever.. The TM showed me just how far I am from even being a DSP hobbyist, let alone an engineer!" - FredM

Fred, have you read "Musical Applications of Microprocessors" by Hal Chamberlin?  Rather dated now, but a total classic.  He shows how to implement a digital state variable filter among other things (I have a spreadsheet of this in my digital Theremin archive).  Written from the hardware designer perspective.

Another big DSP influence on me was a paper by Ensoniq & Lexicon designer Jon Dattorro:

https://ccrma.stanford.edu/~dattorro/HiFi.pdf

He has some papers describing effects design that look interesting:

https://ccrma.stanford.edu/~dattorro/EffectDesignPart1.pdf

https://ccrma.stanford.edu/~dattorro/EffectDesignPart2.pdf

https://ccrma.stanford.edu/~dattorro/EffectDesignPart3.pdf

"It's assembly language for a stack machine, so really ought to be compared to register machine assembly languages for legibility purposes." - GordonC

True that.  Though it occurs to me that register names in assembly are a first step towards the symbolic representation of variables.

What do you think about a machine with 4 generic stacks?  Perhaps using stack 0 to push the interrupt return PC, but otherwise completely interchangeable.  Opcode looks like this:

 [15:8] [7:4] [3:2] [1:0]

 opcode s-bits dest src

Where the s-bits, when set, make the source and destination stacks behave like simple registers, otherwise the behavior is pop for source & push for destination (push/pop for destinations which are used also as a source for two input operand operations).

Mr. Moore's F21 processor design uses a single register as a pointer (among other things) and I've often thought that this should perhaps be a third stack.  4 stacks might remove the need for all those nasty "pick, roll, over, etc." stack commands.  Even on an HP, when I find myself needing to doing a roll I generally get completely confused and have to start over.