:>I'm trying to develop a asynchone (or synchrone?) method to transfer data
:>between 2 MSX-computers (i.e. for games), using JoyNet. Advantages of this
:>compared to a fixed Baud-rate-protocol are that it runs on every kind of
:>MSX-computer, unlike its speed and available timers. Also, you won't have
to
:>recalibrate each time after sending 10-20 bits. Both computers use the
same
:>speed as the slowest MSX, and the slowest MSX _will run on its top speed_.
:>The main idea is that bith computers flipflop bit 3.
:
:Don't forget to mention that your game uses only 2 MSXes.
Ummm... see above.
:Other JoyNet
:programs will work on larger numbers of MSXes. The bidirectional transfer
:you propose is only possible if you connect just 2 MSXes.
I am aware of that. But only 2 computers also means a very fast rate!
:>Every transfer is a send + a recieve, both containing 2 bits (and 1
:>flipflop).
:
:Note that your scheme is not delay insensitive. If the clock (which you
:call flipflop) arrives earlier than the 2 data bits, the old data can be
:read instead of the new data, resulting in a transmission error. You do
:have error detection, but retransmission is not as nice as avoiding errors.
:Unfortunately, I don't think that a delay insensitive code exists that
:encodes 2 data bits in a 3 bit signal.
Why should a delay-error occur? First, the chance on it is very low for the
MSX is very slow,
second, _if_ it occurs, there is a reasonable chance that my CRC detects it
(when too much CRC-errors occur, an error is given and transmission is
interrupted). And third, that delay-error can, to my opinion, only occur if
you use very different kinds of wire in the cable. For instance, a 1.5mm
wire for pin 8-3 and a 0.2mm wire for pins 1-6 and 2-7...
:In the case of one computer sending, you could also make the other computer
:send garbage of equal length as the real data. That might make your
:routines simpler.
It even doesn't send garbage. It just ignores it.
:>If you really want to make some
:>network-programs, which will all have to be able to 'understand'
eachothers
:>transfers, then you might develop some standard PROTOCOL (which is not
:>specified in the JoyNet standard.
:
:Such a use would require a TSR, because even if one computer is currently
:not engaged in a network transfer, it will have to forward messages from
:other computers. That TSR could best be made as part of a driver.
:But even then, it might be easier to standardize the driver interface and
:still leave to protocol to the implementer of the driver. As long as all
:MSXes on the network use the same driver, there is no problem.
:And standardizing the driver interface allows other network hardware as
:JoyNet as well. For example, the EPP cartridge Greg was working on.
There should be made some utility calles Putrough.com or so which non-stop
reads and sends the data from and to the joystick-port again (this can be
interrupted by pressing ESC or so). If you have, for instance, a 3-computer
ring then you can let two of them run the 2-player game and the other one
run this program. The profit of doing this is that you don't have to de- and
reconnect the cables in your network.
:>Ah, my homepage... almost forgot.
:>The Official JoyNet homepage:
:>http://datax.cjb.net/
:
:Hey! Where did you get the "Official" qualification?
Ummm... well, since my homepage contains the most detailed information about
it etc...
Anyway, I posted something about this once on the mailinglist and there was
no objection. Anyway, I think it is good to have a 'official page'. Just to
have all resources on one place, easy-to-find.
~Grauw
****
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/)
****
