Alex Wulms wrote:
> I have an even better idea. In stead of using port1 and port2 for
> communication, we can also use port1 for the joystick and port2, with a
> device like the Ninja Tap, for communication with the neighbouring
> computers.
>
> Like in the following picture:
>
> +----------+ +---------+ +---------+ +---------+
> | comp1 p2----+ mux p2a------------p2b mux +-----p2 comp2 |
> | p1-+ | p2b--+ +---p2a | +-p1 |
> +----------+ | +---------+ | | +---------+ | +---------+
> joy-stick | | joy-stick
> +-+ +-+
> | |
> p p
> +-2-2-+
> | a b |
> | mux |
> +--+--+
> | +---------+
> +---p2 comp3 |
> +--p1 |
> | +---------+
> joy-stick
>
> To keep the communication driver as simple as possible, we can define one
> port on the multiplexer (mux) as in-only (for example p2a) and the other as
> out-only (for example p2b). In this case, we have to implement a token-ring
> network. A bus simply can't do because in a bus we need bi-directional
> communication for the two systems on the end.
>
> This schema can be implemented in very cheap hardware. Ofcourse, it will be
> a
> little bit more complicated then only making a cable, but I think it still
> is
> not too complicated. Or is it?
>
> Kind regards,
> Alex
Hi all,
This is what I've been waiting for. This seems (at least to me) the
smartest solution. In this way the token bus could be expanded
'without end' and you wouldn't need expensive hardware.
If I'm not mistaken, then the only thing you need are wires and
connectors. As I have understood this discussion, the MSX has (per
joystick port) 3 outputs and (for simplicity) 3 inputs (does it
already ring a bell :-) ).
This means that you could make a connection as follows (keep in mind
that I'm only a simple programmer and don't understand data
communications):
+--------------------data---------------------+
|+-------------------clock-------------------+|
|| ||
|| +---data----+ +---data----+ +---data----+ ||
|| |+--clock--+| |+--clock--+| |+--clock--+| ||
|| || || || || || || ||
|| || || || || || || ||
+-ii-oo-+ +-ii-oo-+ +-ii-oo-+ +-ii-oo-+
| MSX A | | MSX B | | MSX C | | MSX X |
+-o---i-+ +-o---i-+ +-o---i-+ +-o---i-+
| | | | | | | |
| | | | | | | |
| +--ready--+ +--ready--+ +--ready--+ |
| |
+--------------------ready--------------------+
In simple language this would mean that MSX N signals MSX N-1 it is
ready to receive data. MSX N-1 'sees' this and sends it's data (in a
sort of I2C way with a data and a clock signal) to MSX N.
MSX N removes the message from the ring if it has the token, else it
relays the message to MSX N+1.
If MSX N has the token, it sends the next message (if any) or
transfers the token to MSX N+1.
Let me clarify the 'I2C way' of communicating:
If MSX N signals it is ready to receive data (ready line), MSX N-1
sets the first bit on the data line and after that alters the clock
line. MSX N reacts on the alternating of the clock by IMMEDIATELY
reading the signal on the data line. After Xms (depends on the
implementation), MSX N-1 sets the next bit on the data line and alters
the clock line. MSX N reacts on the alternating of ......
After reading the above again, I realize that the wait of Xms could be
replaced by toggling the ready line, but this sort of detail could be
worked out if the idea seems feasible.
I don't know if all of this is feasible, but it seems to me that this
is THE most low budget token ring bus possible for MSX. This would
also mean that any MSX could be replaced by a PC (which could do the
same thing via the parallel port). This would also mean an easy to use
and implement driver. It would however mean that every MSX in the ring
becomes slower if the bus activity increases.
Hope this adds something to the discussion,
Jeroen Smael
FutureDisk
Homepage: http://www.futuredisk.msxnet.org
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
