The first prototype of the tokenbus is documented here: https://github.com/autotel/TokenBusHomogeneousNetwork
Testing the speed of the prototyped network
The integrated prototype is developed in the branch COM_common_bus on the js-virtualModular git repository. It is based on the previous work, with some modifications
the messages for the bus will be defined as follows: (each byte is separated by a comma)
msg mode | length , origin | destination [, payload]
the name of each byte is:
header byte, routing byte, payload …
In any given module, the first two bytes will define whether this message must be ignored or taken. It is also possible that the first byte indicates whether the message should be ignored.
the header is shifted a nibble, and or’ed with the length (0-16). The length is inclusive of header and routing bytes. The message length format has not been defined, it can be:
Also, there is the option of using the F length as undefined length, in which case some number should be defined as terminator bytes, most likely an ASCII CR character. In such case, an escaping protocol should be deviced.
Routing byte is only used for payload messages, since the com messages will have a different syntax. This byte results from (emitter_id)<<4 | (destination_id). Emitter id is the emitting module’s id within the current network. The destination and source bytes define whether to ignore the incoming payload, according to the indicated mode of message.
it is possible that in the future, with access to more complete micro-controllers or development tools, the connections between modules become physical (using mechanical connectors between modules) instead of virtual (where modules chose their targeted messages according to id’s in a bus). It is also possible that these modules may form more than one bus, to allow faster communications in a network that has many modules. There are reasons, however untested, that may lead to think that this protocol can be applied to such cases.
[The Complete MIDI 1.0 Detailed Specification]