Powertran BBC-MIDI Interface (Part 1)
Software writer Jim Grant and hardware designer Tim Orr begin our two-part coverage of a new interface that can connect an MCS1 to a BBC Micro using non-MIDI codes
A build-it-yourself MIDI interface for Powertran's MCS1 sampler and the BBC Micro has now been made available. In the first of a two-part feature, we look at how the hardware is put together and the design thinking that lies behind it.
If you've been following previous articles on the design and construction of the Powertran MCS1 MIDI Controlled Sampler (and if you've read through every episode, congratulations), it will no doubt have sprung to your attention that in amongst the machine's plethora of switches lies one labelled 'BBC'. However, the value of this switch will not become apparent until you make appropriate use of the similarly-labelled socket at the rear of the MCS1, since without some sort of valid connection, pressing the button will have precisely no effect at all on anything. True, there's software within the MCS1 that makes digital communication over a serial data bus a realistic possibility, but first of all, you need a suitable interface.
As luck would have it, the device in the accompanying photograph is just such an interface. It has three functions: to receive MIDI data, to send MIDI data, and to communicate with the MCS1 using non-MIDI codes.
Figures 1 and 2 should give you some idea of how the interface can be used either as standard MIDI-to-computer link or as a device capable also of non-MIDI conversation with the MCS1, which is itself MIDI-controllable, of course.
The first example shows the interface as a stand-alone link between the BBC Micro and the Wonderful World of MIDI. Figure 1(a) shows how the unit can be connected to the hardware on the outside world if circumstances (and finances) allow, while Figure 1(b) shows how the interface is configured internally for this particular application.
In contrast, Figures 2(a) and 2(b) show the external and internal connections necessary for using the interface in conjunction with the MCS1. This arrangement facilitates not only the generating of MIDI codes within the BBC and their subsequent transfer to compatible instruments, but also the saving and loading of sounds (using Powertran's own custom-developed software) between Beeb and MCS1, this data being transferred in a non-MIDI format.
Luckily, the BBC Micro's design makes interfacing fairly easy. There are three pages (each of 256 bytes) called FRED, JIM and SHEILA, in which memory-mapped inputs and outputs can be placed. And the process of decoding memory locations within these pages is simplified by Acorn having provided a Page Select signal for each of them.
Figure 3 shows the circuit diagram for the interface, and a quick glance at it should tell you that the design can be divided into three main sections: the memory decoding, the ACIA that actually generates and receives serial data and the MIDI buffering.
Memory decoding is handled by IC502, and makes use of a signal labelled NPGFD: this is the Page Select for FRED, which lies from FD00 to FDFF in the BBC's memory. Link 5 is provided to map the interface into either JIM or FRED (FRED is preferable). Using NPGFD and address lines A4 to A7, IC502 slices FRED into eight memory location blocks, from which Link 4 selects one: again, the choice is yours, but in the normal course of events it should be in position Yo. If Link 5 is at position B-A (FRED) and Link 4 at position Yo, the ACIA is mapped in the memory of the BBC at two locations. In addition, the RW and RS (Register Select) pins on the ACIA take the number of on-chip registers to four.
Link 2 is an option that lets you use an external clock to synchronise data transfer at high transmission rates. This may well prove useful, but the usual connection is B-C. Finally, Links 1 and 3 determine whether or not MCS1 communication is intended in addition to data transfer along MIDI. If you want to power your interface direct from an MCS1, you should set Link 1 to A-B, while using the interface in stand-alone MIDI configuration will necessitate an external 9V power supply, power being regulated by IC505: Link 1 should be connected B-C.
But you've got to select the data receive line as well as the power routing. Link 3 set at B-A allows the interface to listen to an MCS1, while a B-C connection hooks in the optoisolator circuit for MIDI reception. You'd be right in thinking that all that adds up to an awful lot of connections for such a small circuit, so Table 1 provides a summary of available options.
Construction should begin, as always, with the insertion of the links, closely followed by the fitting of the passive components, namely resistors and capacitors: take care checking the polarity of electrolytic capacitors. Bend the legs of the 5V regulator, IC505, and insert it into the PCB so that the fixing hole aligns with the hole in the board. Slide the heatsink under the regulator and bolt both to the PCB before soldering the IC legs: this should ensure a stress-free joint. Check the orientation of both diodes and transistors before insertion, and fit the connectors and remaining large items last of all.
There are a few more points to be made about putting the hardware together, and the first couple concern the interface unit's casing. In addition to referring to Figure 4, you should also bear in mind that the case itself is asymmetric, and that the PCB and panels will only fit properly if they're positioned the right way round. A simple point, perhaps, but worth making all the same.
Secondly, we come to the problem of the external power supply. Not everyone will need one of these, of course, but if you're one of those that does, reference to Figures 5(a) and 5(b) should help you out when it comes to wiring.
Finally on the construction front, Figure 6 gives the lowdown on how to assemble the CN505 34-way connecting cable.
Since the interface unit does nothing whatsoever in isolation, it defies most conventional test methods. However, if the unit has been correctly assembled there's actually little scope for things to go wrong, and a few simple tests should shed light on any faults that might exist.
If you're using the interface in conjunction with an MCS1, plug the unit into the MCS using a five-pin DIN cable: this will also power the interface. Check to see that + 5V is present on all ICs (see power pin box, Figure 2). Alternatively, if you're powering the unit from an external mains adaptor, check that +9V is available on the input to IC505 and that +5V is generated at its output. The Power LED will illuminate if power is present.
The next step is to connect the interface to the Beeb's 1MHz bus. If the system is operating correctly during a DSAVE (part of the software operating procedure), data will be seen on connections DO to D7 of the ACIA (IC500). In addition, FRED should go low when reading or writing from the ACIA.
If you're unlucky and a fault condition occurs, the first thing to do is to look for open circuits or shorts between adjacent tracks on the PCB. Short circuits on the PCB often manifest themselves as illegal logic levels (eg. between 0.5V and 2.5V) during testing.
Plugging in a scope should bring a couple of square waves from different pins on IC503, viz a 1MHz square wave at pin 3 and a 500kHz one at pin 2.
Note also that the interface's MIDI Out signal is normally high, going low when active. This can be seen at pin 11 of IC501, and can be tested by playing the f1 to f8 keys on the BBC's keyboard in the context of the software's MIDI Test page. MIDI In, on the other hand, can be tested by injecting a MIDI signal source or digital input: if all is working as it should do, the output of the optoisolator will be an echo of this signal with a delay of a few microseconds. As a quick visual indication that all is well, the built-in Data LED lights up when data from either the MCS1 or the MIDI In connector is being received by the interface.
Let's sort out a couple of bits of theory. The transfer of both MCS1 and MIDI data requires conversion from serial to parallel format and back again in order to take place at all. This has to be done at constant 31,25Kbit/sec rate, with stop and start bits to synchronise transfer: this is the ACIA's function in life, and communication between it and the BBC Micro is via the latter's 1MHz bus. Special timing requirements also have to be met, and these are catered for by IC501 and 503.
Mind you, before the ACIA can either receive or transmit data, it has to be initialised by the BBC sending two bytes to its Control register. The bytes in question are ?&FD00 = 03 and ?&FD00 = &55. The first resets the ACIA and clears the flags in the Status register, while the second performs a number of functions including setting the clock divide to 1/32 and choosing one start bit, one stop bit and eight bits of data.
The Interrupt flag is disabled, but can be enabled simply by sending the second byte as ?&FD00=&95. This causes the IRQ line to be pulled low on receipt of serial data, upon which the BBC whizzes off into an interrupt routine in search of the device that caused that interrupt. It'll ignore the ACIA unless you make specific use of the user interrupt vector at &206 and &207 to patch code that'll service the interrupt request.
With all that safely out of the way, the interface is now in a position to deal with either MIDI or MCS1 data, depending on how its links have been arranged.
Basically, there are two kinds of bytes - Status and Data. Instruments can distinguish between the two by examining the Most Significant Bit, which is set for Status and clear for Data bytes. The easiest way to view the situation is to see Status bytes as commands that tell the instrument what to do with (very often) the help of additional Data bytes. Examples of this sort of operation are MIDI Note On and Note Off commands.
The interface's reception of MIDI data is performed by checking bit 1 of the Status register (reading location &FD00), and if this is set, reading the received serial data at &FD01. This process can only be achieved successfully by an assembler program, as BASIC is too slow to keep pace with MIDI data transmission rates.
Well, just in case you've been on safari in the Gobi Desert for the past couple of years, the above acronym stands for Musical Instrument Digital Interface, and is rapidly becoming the interfacing standard in the world of electronic musical instruments. Physically, it's five wires terminating at each end in a five-pin DIN plug that connects two or more MIDI devices together. Electronically, it's a communication medium that allows machines of varying origins to pass on to each other common information such as pressed keyboard notes, pitch-bend and other parameters. MIDI instruments from the same manufacturer can also communicate more specialised information to each other using what's known as System Exclusive data.
The information itself is sent serially along the connecting cable, with special signalling bits that mark the beginning and end of individual segments of information called bytes. The standard bit format is shown in Figure 7.
Each byte sent has a specific meaning to the receiving machine, which decodes it and then acts accordingly.
Let's take the Note On and Note Off commands mentioned earlier as examples of this process at work. Both commands involve the sending of three bytes, the second of which represents the keyboard key number and is represented as a number between 0 and 127 in both cases: 60 is Middle C. Note On's first byte is Status byte 90 hex where as Note Off's first is 80 hex, and the third byte, similar to the second in that it's also a value of between 0 and 127, represents key-down velocity in the case of the Note On command and key-up velocity in the case of Note Off.
In either case, the first byte sent is a command that tells the receiving MIDI instrument what to expect along the MIDI lines in the (very) near future and what to do about it when it comes. It's worth noting that the Most Significant Bit of this byte is always a 1, whereas all the other bytes have their MSB clear. It's this distinguishing feature that enables the receiving machine to sort out exactly which bytes are commands (or Status bytes) and which are merely supplied data for commands, such as which specific note to play or release.
Incidentally, you'd be right in thinking that some MIDI synths are incapable of producing keyboard dynamics from MIDI velocity information, but this is still sent in any case as part of the standard MIDI protocol.
One point that's crucial to bear in mind is that although we've so far viewed MIDI as a single two-way stream of data, it does in fact consist of 16 separate channels of information transfer. Any MIDI-compatible synth is capable of sending MIDI commands on any of these 16 channels simply by varying the number held by the four Least Significant Bits of the Status byte. So for instance, while Status byte 90 hex is a Note On command transmitted over MIDI channel 1, 93 hex is the same command sent over MIDI channel 3.
The process of receiving bytes is a little bit more involved, because MIDI machines vary in the way(s) in which they can receive MIDI data. There are in fact three standardised receive modes in general use. The first is Omni mode, in which the synth in question ignores channel information entirely and executes commands whenever they arrive. The second is Poly mode, in which a synth only acts upon MIDI commands if their channel number matches its own. And the third is Mono mode, in which the instrument's voices can be controlled individually due to their having been assigned different MIDI channel numbers.
Unfortunately, hardware manufacturers have been decidedly slow on the uptake when it comes to implementing Mono mode, and to date, only a handful of models (among them most of the polysynths in the SCI range and, apparently, the Casio CZ101 and CZ1000, though Casio themselves don't seem to be aware of the fact) feature this 'multi-timbral' facility...
Since MCS1 data is unquestionably a non-MIDI format, it requires its own brief explanation. Its transfer rate and stop/start bits are in fact identical to those of MIDI, but it differs in one respect important enough to earn it its own separate transmission bus. Each sound on the MCS1 occupies 64Kbytes of RAM which, if transferred to a BBC Micro down a 31.25Kbit/sec data bus, would take around 21 seconds to make the journey.
MIDI, remember, only allows data to be sent with the MSB clear, thus reducing the amount of information that can be sent in a single byte. Synth manufacturers overcome this by splitting each data byte into two four-bit nibbles and transmitting them as two separate bytes, but this is clearly not satisfactory for MCS1 data since it would double what's already a fairly lengthy sound dump time.
So that, in a nutshell, is why MCSI data is transferred along its own communications bus (thus maintaining the eight-bit byte size) rather than down the MIDI bus under a System Exclusive command.
Next month, we'll look at the first piece of commercially-written software for the BBC-MCS1 combination, which allows MCS1 sounds to be dumped onto and retrieved from BBC disk, among other things. So stay tuned.
Further information on both the MCSI and the BBC-MIDI Interface can be had from Power-tran Cybernetics, (Contact Details).
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!