Andy Honeybone has a tape dump. But we forgive him.
Avoiding all bad taste jokes about dumping (and they are legion) Andy Honeybone plays with his newly acquired Yamaha QX7 sequencer and writes a Beeb Micro program for saving his sequences on tape.
IT'S BEEN a cassette month for me. First, the review of the 'Music Machine' required the loan of a ZX Spectrum (thanks Mary) and then considerable time spent rummaging for adaptors to hook the headphone socket of a once hi-fi JVC deck into the computer's input socket. Not only that, but I had to fit croc clips to the video input of the uhf modulator within the Spectrum to be able to drive my monitor.
The second tangle with the tape storage medium arose from the purchase of a QX7 sequencer at a rather attractive price. Having amazed myself by creating a totally faked three-voice Bach fugue (a step-time special) I soon wanted to dump the sequence to tape. Alas, the tape wouldn't verify. As a temporary measure, I 'played' the QX into my homegrown sequencer and saved my efforts indirectly. As a more permanent solution, I wrote the Acornsoft FORTH sequence dump program for my trusty Beeb-and-Making-Music-MIDI-interface presented here.
So what's the difference between a voice dump and a sequence dump? Basically, length. A voice dump will always be of fixed length whereas sequence data will be an unknown quantity.
The ideal solution to the problem would require real-time write to disc which is out of the question, not least because the Beeb's disc and the MIDI interface both use the non-maskable interrupt. Instead we have to make do with a 20k buffer and write the buffer to disc after the data has been dumped from the QX. I have yet to find this to be a limitation and, in any case, sequences can be saved piecemeal (always a good idea anyway) and then later uploaded and chained as necessary.
The Yamaha format 10 dump has a six byte preamble containing the System Exclusive status and identification, the local device number, the format number and the high and low byte counts. Then follows the data with a 10 byte header. The packet is completed by a checksum. When the byte count exceeds 4096, the data is split into separate 4096 byte blocks, each with the byte count and header and trailing checksum. The last byte transmitted is, of course, the end of system exclusive (EOX) status byte and this provides a useful signal for the dump program to terminate.
The program has its origins in the DX21 voice dump featured previously. Four function keys are programmed for get, put, load and save. When a choice is made, the corresponding line on the menu begins to flash.
Depending on the function chosen, the program either prompts for a disc filename or the QX is sent a dump request or the bulk data. When a bulk dump is received from the QX, the number of bytes are displayed along with a value representing the percentage of buffer occupied. The checksum is calculated to ensure that a reliable transfer has taken place and then the track number and time signature are extracted from the dump and written to the screen. These last two pieces of information are also shown when a dump is recalled from disc. It is particularly useful to know the destination of the dump before it is sent to the QX.
Getting more detailed now, the interrupt routine is the hub of the program. It gets the MIDI data, filters clock and active sensing bytes, stores the data incrementally in the buffer, checks that the buffer isn't fillip and signals the end of dump back to the filLbuf definition. You may notice that in the code definition of xmit, the original accumulator contents are not preserved. FORTH lets you get away with this as it only uses the X register for its own internal workings.
Arrays don't exist as data types within FORTH unless you care to define them. There are three arrays in this program, each defined by CREATE and allocated memory by ALLOT. The 'array' attr comprises four bytes which are the teletext control codes for each line of the menu. The definition disp adds an offset to the address of the first member of the array, fetches the byte and sends it to the VDU driver.
The bevy of VDU commands in the definition of banner act to turn off the cursor. This works for the 1.0 and latter operating systems.
The hardest bit to code was the checksum routine. The length of each segment is present at known offsets within the dump. Given an address, the definition calc_len turns seven bit count bytes into a conventional number. The second auxiliary definition csum_add takes all the values between two supplied addresses and adds them. Because the address range includes the checksum byte, the seven bit total should be zero. If this is not the case, a message is issued and the routine quits. The chksum definition proper steps through the dump in 4099 byte chunks, calculating addresses and calling csum_add. The loop terminates when the block length is less than 4096 and the check sum is calculated on the remainder.
The QX track (0 and 1) from which the data was read is encoded within the dump as its ASCII representation. Subtraction of 47 leaves the numbers 1 or 2 which are a touch easier to understand. Similarly, further devious delving decodes the time signatures in the definition time_sig.
In case you're puzzled by the number 64 in the definition of get_qx, remember that the hexadecimal number base was selected right at the top of the listing. In decimal, the number is 100 and is used to calculate the percentage buffer filled. The FORTH word */ multiplies two numbers and divides the 32 bit result by a third supplied value. Floating point — who needs it?
The disc filing routines are hardly elegant but work reliably and are potentially more portable than OSFILE calls. The scheme is to build up *SAVE and *LOAD strings and then pass them to the operating system. Should you feel that your life is incomplete without a more detailed explanation, refer to this column in issue 3.
Remember to connect MIDI in as well as MIDI out to the sequencer or the program won't be able to request the bulk dump. This program should work for all QXs that support the format 10 dump — perhaps you'd let me know?
Feature by Andy Honeybone
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!