A perceptive reader enquires of the Beeb Micro if it can A to D. Andy Honeybone Pens to Paper.
How beeps the Beeb? Andy Honeybone answers questions about the BBC Micro as an Analogue to Digital converter, and then shoehorns in a few points about Forth.
I'VE BEEN contacted by none other than the President of the Jeff Berlin fan club. Kevin Clark of Fife. My acquaintance with the bass playing activities of Mr Berlin comes from an early Bruford album whereas my knowledge of Mr Clark is solely from a letter in which he expounds his desire to use his Beeb for realtime audio signal processing.
As Kevin has appreciated, the integrating analogue to digital converter within the Beeb works far too slowly for this particular application. My Advanced User Guide tells me that the faster eight-bit conversion takes typically 4 milliseconds. What does this mean in terms of sampling rate? As the reciprocal of the period gives frequency we arrive at the grand figure of 250Hz. Remembering that the sampling rate has to be at least twice the highest frequency of the input, the actual response is going to be limited to about 100Hz. Fine for a joystick but definitely not for audio.
An external A/D converter is required and eight-bit Ferranti successive approximation devices will convert in 10 microseconds. This allows a maximum sampling rate of 100kHz which is much more like it. Of course, a corresponding D/A converter is required, and these add-ons will have to be interfaced via the 1 MegaHertz bus.
For anyone interested in pursuing this idea with its associated machine code headaches, I can recommend no better source of information than the January, February and March '86 copies of "The Micro User". In these volumes, suitable interfaces are described and software is presented for echo, pre-echo, frequency shifting and sampling.
Another reader, Steven House of Clapham, has a JHS SynDrum and access to a very up-market printer. Currently, for writing percussion tracks, he uses the drum editor page of his Pro-16 sequencer or plays in real-time from a keyboard. I have to agree with him that it's not the same as hitting things. Hence the SynDrum...
Would it be possible, he asks, to build a box to convert the analogue "blurt" into dynamic MIDI information? Would a microprocessor be needed? Should he start saving for a Roland PAD-8 Octapad?
A drum controller has been on my list of possible topics for some time but this letter has stirred the grey matter again. I'm sure that you could design such a thing in discrete logic as a single pad but if you were even remotely contemplating a multi-head setup then I would think a micro would be mandatory.
Some interface like an analogue sample and hold would store the intensity of the thump until it was polled by an analogue to digital converter. The micro would send a MIDI note-on sequence when the A/D gave a value greater than some pre-determined threshold. The velocity value would be a scaled thump amplitude and after a small delay, a corresponding note-off sequence could be transmitted. With the MIDI string completed, the micro would clear the analogue memory and await the next thump.
Now for a quick sum. What sort of bandwith are we looking at for the A/D conversion? Considering a single pad, the resolution should be no worse than the MIDI 24 clocks per quarter note standard. Assuming a fast track at a tempo of 200 beats per minute, the conversion time would be within 60/(200*24) = 12.5 milliseconds. This is a near worst case figure and we shouldn't forget that the six byte MIDI sequence will take something like 2 milliseconds to send.
Although maths never was my strong point, it does rather look as if the slow old A/D converter in the Beeb could be used to run a couple of pads. I'll certainly look into it. I'm not sure that SynDrum ownership is very much of an advantage. I was thinking along the lines of cheap microphones inside sandwich boxes — the "Blue Peter" influence.
My use of the FORTH language seems to have caused problems for one or two of you who insist on using BASIC. I suppose it would be unfair to expect you to buy the FORTH manual just so you could perform the translation. Without wanting to appear to be condoning your actions, here are a few explanations of some of the more obscure bits.
FORTH uses Reverse Polish Notation where the operator (+, -, *, /, etc) follows the arguments. For example, 3 + 4 is expressed 3 4 + in RPN. This philosophy is extended to the assembler mnemonics in which the normal sequence LDA#1 is written 1#LDA. The assembler does not directly support the branch instructions but uses IF.. THEN etc constructs to enforce structure. For example 0< is true if the negative flag is set; if the zero flag is set then 0= evaluates as true.
Rather than tying up memory with many variables, FORTH uses a stack to pass parameters between its subprograms (words). The assembler needs to be able to access the stack and it does so by the symbol BOT which refers to the bottom of the stack which contains the most recently deposited piece of data.
There are other routines which allow a re-entry into FORTH from assembler. One pushes the accumulator onto the stack (PUSH0A) and another causes the stack item referenced by BOT to be dropped (POP).
Poking into memory is by the symbol ! pronounced "store". C! is an eight bit poke whereas ! is a two byte poke. The store commands expect the data and address to be on the stack in that order.
Hardly a tutorial, I appreciate, but if you were totally stuck it might just get you moving. It's a lot easier in FORTH though, none of this arcane P%, square braces and OPT value nonsense.
And for those of you that would rather I wrote code for other machines — here's a sobering thought. If everyone that picked up a copy of "Making Music" donated one penny there'd be enough to buy me a posh Atari system. Then I could program in "C" and upset even more people.
Feedback by Andy Honeybone
Previous article in this issue:
Next article in this issue:
mu:zines is the result of thousands of hours of effort, and will require many thousands more going forward to reach our goals of getting all this content online.
If you value this resource, you can support this project - it really helps!