You have a Yamaha FB01? Do you know what it's doing? Andy Honeybone logs on with a BBC micro program to drop out the effbeeoh's configuration data.

BINGLEY land of antique shops and building societies. A paradise (if you squint) of all that is right save for the filling station giving away Stanley knives with every four litres of oil. And it was to this place that I journeyed far in search of an elusive FB-01 tone generator. Did I find one — yep, at trusty Making Music stockist JSG.

The program this month is therefore to disgorge the current configuration data from the FB-01 and display it on screen or printer in the layout illustrated in the manual.

The advantage that this gives over the stand-alone unit is that it presents, at a glance, the information that could otherwise only be obtained after some 120 key strokes.

From a programming point of view, the code represents a foray into the BBC's mode 3 screen displays and much decoding of bald digital data into information that we can understand. The interrogation and data acquisition routines should seem like old friends to regular readers and so I'll concentrate on the disassembly.

The FB-01 manual gives the 8 byte sequence for the current configuration buffer dump request. Reader Brian Thompstone of Macclesfield wrote in to ask where I get all my "inside knowledge" from. You may be able to deduce from my visit to Bingley that Yamaha and I haven't exactly established a hot-line. All the facts and info are supplied with the kit, Brian, although I have to admit that without a memory display utility (*MZAP) to resolve the many ambiguities, I'd be jiggered.

The format of the configuration data is given on page 51 of the manual which refuses to lay flat. The locations 0 to &9F do not represent offsets from the start of the dump as one might expect. The data is in fact offset by 9 bytes which is the dump identification header revealed on page 55. It's no big deal anyway to figure what's going on — eventually.

Initially, the old brain told me that I could use the display scheme featured in the DX21 random voicer program of a few months back. For that gem, the row and column legends were displayed first and then the cursor was driven around the appropriate slots like the moving finger. Unfortunately, this technique isn't suitable for output to a printer as the data appears as a heap below the chart as if it has fallen off.

The method finally selected was to decode the data line by line and print it straight across the screen/page. The hub of the code is the definition get_params which when given the necessary offset, rips through the buffer pulling out the 8 associated parameters, adds a predetermined value to the data byte and shuffles the stack so that instrument 1 data comes off first. The rest is "just" encoding the 8 values left on the stack after the call.

The use of offsetting the data at its collection is demonstrated in the definition midi_channel. We all have been taught to expect MIDI channels to be in the range 1 to 16. Computers, as we know, store this same information as 0-15. By simply adding 1 in get_params, the data is ready on the stack in the right form — nothing fancy but dead useful and widely applicable. The feature is also utilised in transpose which adds -2 to the values so that the stored range 0 to 4 is translated into -2 octaves through +2 octaves.

Conversion of the MIDI key numbers into the more understandable note and octave values requires the initialisation of a "look-up table". The array scale contains the ASCII representations of a chromatic scale starting on "C". Scale points which are not sharpened are preceded by a space to keep tabulation easy. The definition conv_key takes a note number from the stack and after duplicating the value for later reference, calculates the remainder after division by the number of notes in the chromatic scale (12). This modulus is then multiplied by 2 to give the index into the scale array to determine the note name. The octave number is given by the integer remaining after division of the original note number by 12. As key value 0 corresponds to C-2 (C minus 2), the octave number has two subtracted from it to complete the translation.

Where numeric values require conversion to text output, a rather brute force method was adopted. It may well have been more elegant to use the CASE construction shown in the Acornsoft FORTH manual and to have offset all the values correspondingly. The method used here however has the virtue of a closer relationship to the original data and it does work. Each of the expected values is tested in turn against the input data. When a match is found, the associated string is printed out.

Having defined a word to deconvolute each configuration parameter, the entire page is assembled in the routine legend. The banner definition prints the title and extracts the configuration name. It also sends commands to the printer to select an expanded type face for the heading and additionally turns off the cursor to make things look a little more "pro".

The first two red function keys are programmed to request the configuration dump. The first gives a display on the screen and the second activates a print out. The program is a little short on the "user friendlies" but it was a real struggle to get the full configuration dump into the two page limit that publishing considerations impose.

But now back to the manual. There's a rumour that you can even connect a keyboard to this FB-01.

(Click image for higher resolution version)

(Click image for higher resolution version)