| ***********************************************************************
B U M P V1.0 is now available for DECcie use only.
This is Steph Bailey's new Bulkdump program for the ST and is in the form of a
desk accessory. It is not Public Domain.
Steph would love to here from you about this, your comments, suggestions, bugs,
what new equipment you own, your new children, etc.
From my card in cardfiler:
--------------------------------------------------
Steph Bailey
Author of BulkDump for the Atari ST
No longer at DEC
email: NM%DECWRL::"[email protected]"
--------------------------------------------------
Bump is located on NORGE::B$:[ATARI.BULKDUMP.BUMP_V10]
It may be available elsewhere too.
Chad
------------------------------------------------------------------------------
Here is BUMP.TXT, the release notes:
Bump V1.00
Copyright, 1988 Stephen Bailey, Simple Minded Software
1.0 What is Bump
Bump is a generic MIDI system exclusive bulk dumper and loader desk-accessory
for archiving MIDI devices' configuration data on an Atari ST.
As a desk-accessory, Bump uses about 36K of the ST's memory, plus a
variable amount which depends upon the size of the user configuration file
(see Bump.Cnf, below) The sample configuration file requires approximately
1.5K more.
Bump provides support for handshaking and host (Atari) initiated transfers
through a user configuration file. (See Bump.Cnf, below) The Bump
interface is GEM windows/buttons/dialogs.
2.0 Using Bump
Using Bump requires the following files be in the ``system boot''
directory:
Bump.Acc Atari desk accessory program file
Bump.Cnf User created configuration file
When the system boots, Bump attempts to read the configuration file.
If it is un-successful (perhaps because of a syntax error in the
file), Bump will display an alert box, and will disable itself from
any further action. The ``Bump'' menu entry will still appear in
the GEM ``Desk'' menu, but selecting it will have no effect.
To invoke Bump, assuming that Bump's boot-time initialization was successful,
simply select the ``Bump'' entry from the GEM ``Desk'' menu.
1.1 The ``Bump Control'' Window
The ``Bump Control'' window, which is always displayed when the accessory is
opened, if initialization was successful, contains four buttons (Send,
Receive, Abort, and About), and three running status fields (Bytes Received,
Bytes Sent, Transfer Rate).
The functions of the buttons are as follows:
1) Send -- Active only in the idle state (see States, below). This
function prompts the user for the name of a file to send
to the Atari's MIDI OUT port. If the file fits in memory,
and begins with a SYSEX byte and ends with an ENDEX byte,
the transfer state is entered (see States, below) and the
file is transmitted. Handshaking is performed as required by
the configuration file (see Bump.Cnf, below)
2) Receive -- Active only in the idle state (see States, below). This
function prompts the user for the name of a file to receive
from the Atari's MIDI IN port. The transfer state
is entered and the receive begins. Handshaking is
performed as required by the configuration file (see
Bump.Cnf, below)
3) Abort -- Active only in the transfer state (see States, below).
This function aborts any transfer currently in process. If
a file was being overwritten by a Receive, this file is
restored. The idle state is entered. Note that since
the mouse is scanned less frequently in the Transfer State,
mouse button may have to be held for a period of time before
the Abort function is engaged.
4) About -- Active only in the idle state. This function displays
a dialog with information about Bump.
The status displays are as follows:
1) Bytes Received
A count of bytes recieved by the program.
2) Bytes Sent
A count of bytes sent by the program.
3) Transfer Rate
The number of bytes transfered in the ``primary'' direction
(as specified by pushing the Send or Receive button, or
transfer direction field of the command being executed)
divided by the transfer time.
If Bump is in the idle state, the status reflects the values for the last
transfer. If BulkDump is in the transfer state, the status reflects the
current values, and is updated every two (2) seconds.
1.2 The Bump Command Window.
The Bump Command window will only appear if there are one or more commands
found in the configuration file (see Bump.Cnf, below).
The Bump Command window contains a line for each command found in the
configuration file, in the order in which they are read from the file. Each
line contains the command type (``X'', ``R'' or ``I'') followed by a space,
followed by the command name. The vertical scroll bar in this window may be
used to expose lines associated with commands which are not currently visible
in the window.
A command is activated by clicking on its line in the BulkDump Command window.
The program will then:
1) Prompt for variable values with a dialog box, if the command contains
any.
2) Prompt for a file name, if the command type is ``X'' or ``R''.
3) transmit the command on the MIDI OUT port.
4) Either return to the idle state, if the type is ``I'', enter the
transfer state and receive, if the type is ``R'', or enter the transfer
state and transmit, if the type is ``X''.
A command may only be activated in the idle state.
The values provided to the variable prompt dialogue are hexadecimal numbers.
Any attempt to give a variable a non-hexadecimal value will result in ``0''
being transmitted for that particular variable. The variable prompt dialogue
is not case-sensitive.
1.3 States
As described above, Bump has two states which correspond to whether a
transfer is occurring--the transfer state--or not--the idle state.
The idle state is characterized by all functions being active, except
ABORT. The text in the Abort button is ``shady'' (disabled) in the transfer
state, and the texts for all other controls (the buttons and commands) are
solid. No items are selected. The idle state is exited when a command or
the Send or Receive button is clicked.
The transfer state is characterized by no functions or commands being active,
except ABORT. In the transfer state, the function which was used to enter the
state (Send, Receive or an``X'' or ``R'' command) remains selected until the
transfer state is exited. The transfer state is exited when the transfer
completes or fails, or the Abort button is clicked.
2.0 Bump.Cnf
The configuration file, Bump.Cnf, is the way for the user to customize
Bump so that will work with his or her MIDI modules. The file allows the
user to specify handshaking protocols for modules which require this type of
interaction, and commands which may be used to trigger, or manipulate in some
other way, the user's MIDI modules. The user may create and modify the
configuration file with an ordinary text editor. If no configuration data is
needed, an empty Bump.Cnf file may be used, but the file must exist, even
if it contains no data.
The configuration file language is comprised of two types of records which may
be freely intermixed; handshaking records, and command records.
Fields within records and the records themselves are separated by the backslash
(``\'') character. Where white-space is allowed or required, any amount may be
used. White-space is defined to be any character with an ASCII value less than
or equal to that of a SPACE character.
The configuration file language is only case sensitive for fields which are to
be displayed for the user (e.g. command and variable names).
2.1 Handshaking Records.
2.1.1 Handshaking Record Syntax.
Each handshaking record begins with the character ``S'', is followed by
white-space, follwed by a hex ``pattern'' string, followed by a separator,
followed by a hex ``response'' string followed by a separator.
A hex string is a sequence of hex numbers less than or equal to 10F each
separated by white-space. Numbers in a hex string between 100 and 10F are
called ``variables'' and have special significance, depending upon their
context.
s f0 41 100 \ f0 41 100 32 F7 \
s 41 100 100 100 \ 01 01
01 01 01\
Are examples of two syntactically valid handshaking records
2.1.2 Handshake Record Operation.
In operation, when a block of SYSEX data is either transmitted or recieved the
first few bytes in the block are compared with the patterns of the handshaking
records until the first match is found. The exact number of bytes compared is
equal to the length of the pattern string being tried.
If a match is found, then the response associated with that handshaking record
is either transmitted, or expected after an ENDEX byte is seen. Receive
operations cause a response to be transmitted, and transmits cause a response
to be expected.
Variables in the pattern portion of a handshaking record match any character in
the data block. If the same variable appears twice in the pattern string, it
must match the same value each time it appears. Non-variables must match
their precise values in the data block.
Variables which appear in the response string are substituted by the values
which they assumed in matching the pattern string. Any variables which appear
in the response, but don't appear in the pattern will cause a ``0'' byte to be
transmitted in their stead. Non-variables are transmitted as MIDI data bytes
of their own value.
2.2 Command Records.
Command records are used, generally, to define MIDI messages which will trigger
MIDI modules to return bulk dump data.
2.2.1 Command Record Syntax.
Each Command record begins with the character ``C'', followed white-space,
followed by a command type character (``X'', ``R'', or ``I'' in either case),
followed by a separator, followed by a command name word, followed by a
separator, followed by a hex ``command'' string, followed by a separator,
followed by a variable value prompt word followed by a separator for each
unique variable found in the command string.
A hex string is as defined in the Handshaking Record Syntax section.
A word is between 1 and 20 non-white-space characters.
c r \ K5_One_Single \ f0 40 106 00 00 02 00 100 f7 \
Program_Number \
Midi_Channel \
c
i \ Miracle_DoDad \
01 02 03 04
100 100 100 \ Fun$Param \
c X \ Rhubarb^2 \ 01 00 00 01 00 00 01 \
Are three examples of syntactically valid command records.
2.2.2 Operation
The command type field in a command record is used to determine the mode of the
program after the command is transmitted:
X -- Xmit. Bump will transmit the user-specified file after the
command string has been transmitted.
R -- Receive. Bump will receive the user-specified file after the
command string has been transmitted.
I -- Idle. Bump will stay in the idle state after the command
string has been transmitted.
Each variable prompt word will appear next to an editable field in the variable
value prompt dialogue. The first variable value word is used for the lowest
numbered variable in the command string, the next is used for the next highest
numbered variable, etc.. In the ``Kawai_One_Single'' example above, the value
for variable 100 is prompted with the ``Program_Number'' word, and the value
for the variable 106 is prompted with the ``Midi_Channel'' word.
The values obtained from the dialogue are substituted in for their respective
variables before the command string is transmitted.
3.0 Implementation Notes
There are some items of which to be aware when using Bump.
3.1 Receive mode behavior.
When the program is receiving a file, it will wait until it receives a SYSEX
byte, and then the receive will be considered complete if a ``significant''
data byte has not been received in over two (2) seconds. A significant data
byte is a SYSEX, ENDEX or a MIDI data byte received after a SYSEX but before an
ENDEX byte.
3.2 Handshake behavior.
The transmission process will time out if a handshake message is not received
within two (2) seconds of the reception of the ENDEX byte for a data block
which requires handshaking.
When a handshake is received by the program, it is not compared against the
expected handshake. Any block of data which is a SYSEX followed by data bytes
followed by an ENDEX will be accepted as a handshake. This behavior is correct
on all the MIDI modules which I have seen, but I could be persuaded to change
it if it isn't good enough for some cases.
3.3 Drop-downs and Other DAs
Dropping down the desk menu or using DAs may halt the transmission process the
target MIDI module to, possibly, time-out. Reception should continue through
anything short of a system crash or another application doing something really
nasty.
In general, it is best to avoid doing anything else while a transfer is
occuring, because this may cause unpredictable side-effects to either Bump or
one of the other applications (DAs, or the ``main''application).
3.4 Robustness in the Face of Sneaky Applications.
Bump tries very hard to ensure that it will get control of the MIDI
data stream while a transfer is occuring and return control of this
data stream to whatever had it before Bump took control after a transfer
is complete. It is not always successful.
Particularly, Bump is known not to work with Passport MidiSoft Studio
(and probably other Passport sequencers), but since I poured Coke on my
key disk, I have not had a chance to fix the problem. If you
encounter problems with other products, please let me know, and I might
or might not be able to do something about it.
4.0 Support
This program is not in the public domain, so about the only person from whom
you can get support is me or another user. I will try to respond to all
questions, and I am especially eager to hear any feedback (positive and
negative) about the program. This is my only fee for use of the program,
so please send me something.
Bump may be freely distributed to employees of DEC (Digital Equipment
Corporation). Bump may only be distributed to non-DEC employees with
my express consent.
Stephen W. Bailey ([email protected]) 26-Oct-1988
|