Re: JoyNet serial transfer routines
At 07:00 PM 10/12/98 +, you wrote: I think you are both mistaken here. In synchronous communications, the exact point in time at which the data signal(s) is sampled, is determined by an 'extra' signal, an other signal, and with that, the data stream is SYNCHRONISED with that other signal. What you call an 'extra' signal, is just as much part of the signal as the data signals are. Dependant on the encoding, it may not even be possible to say "these bits are data and these bits are timing". Take for example the encoding I proposed on this list a while ago: There are 2 signal bits: D0 and D1. Flipping of D0 means "a 0 is transmitted". Flipping of D1 means "a 1 is transmitted". Since the timing information is part of the communicated message, the sender and receiver need not be synchronized. If such an other signal is not used, or not present, the data stream can NOT be SYNCHRONISED with that other signal, and thus becomes an ASYNCHRONE communication method. In this case, it is usallly a fixed timing scheme that determines when bits are to be sampled. Such a fixed timing scheme is usually referred to/derived from/related to as "baudrate". This is the common way used for RS-232 communications, and the same goes for MIDI-connections (also Asynchronous). Because the signal itself doesn't include any timing information, you do need external synchronization. I'm not sure the reasoning I used above is the one used for the name-giving. But I have had a couple of courses at the university about asynchronous computing and communication, so I know what's asynchronous and what isn't. Besides: if JoyNet only standardises the cable, than that leaves the programmer free to choose for a synchronous or an asynchronous communication method. It does. I just strongly recommend an delay-insensitive asynchronous communication protocol, because that will give far less trouble. For example, it is insensitive to cable lengths and it will run at any clock speed. If the number of connection lines in the cable is such, that no extra lines besides the data lines are available, then that would automaticly force asynchronous communication to be used. If not, both methods could be used. There are two bits available for sending, which is enough. -For networkgames, SPEED is crucial, and error-checking not that important, or not at all There are two speed factors that are important: 1. the delay before actual data is sent 2. the time it takes to send the data Point 1 is caused by the fact that the processors of both the sender and the receiver need to actively participate in the transfer handshaking. The sender has to wait until the receiver is ready to start the transfer. If the amount data you have to send is small, point 1 is far more important for the performance of your game than point 2 is. Transmission errors in games are *not* funny random effects. They can ruin the game in progress. -For data-transfer, speed is not THAT important, and error-checking might greatly improve reliability. I too think reliability is important. But you suggested 32 bit CRC without any proper argument why what error detection would be the right one. Besides, error detection depends on message size as well. One 32 bit CRC per kilobyte offers far better error detection that one 32 bit CRC per megabyte. Bye, Maarten 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/)
Re: JoyNet serial transfer routines
: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/)
Re: JoyNet serial transfer routines
Hi,
It's about the exact time(s) of sampling the bit values of the main
(RxD/TxD) signal. In asynchronous communications, this is based upon
a fixed time for a single bit, determined by the baudrate.
Ehrm... I don't wanna spoil the fun, but for JoyNet, we're talking
about asynchronous communication. What you describe here
("...based upon a fixed time...baudrate") is synchronous comm.
[Which trashes the whole supersampling idea]
For instance a 32-bit CRC (Cyclic Redundancy Check), not something
like "adding all bytes, modulo 2^16" for a 16-bit checksum.
Say _what_? Are you planning to transfer Gigabytes?
And if it's for transferring data (for instance MSX - PC), some
extra overhead is really a don't care, if you got 50 MB's to
transfer, who cares whether that takes 20, or 22 hours or so?
Get real. If you've got 50 MB to transfer, JoyNet is definitely
not the way to get it done. You'd better take a RS232 or similar
type of communication...
[Transmission errors]
(for games, this might even introduce a nice 'random' element!).
Yeah, right. Then I can't shoot my enemies because they jump around
all the time, due to the transmission errors, instead of staying
nicely where they are :-)
Eric
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/)
Re: JoyNet serial transfer routines
:And you can include all of these things in a set of standard-routines :that go with any JoyNet application, and might be updated any time. :An application programmer could just take this standard set of :routines, and build his/her application around it, not worrying about :the internals of these standard routines. Like with drivers for :equipment, you could have updates of these drivers later on, and :application software would be easily modified (maybe not even) to :include these newer versions, whenever these become available. Hey, hey, I'm working on it... (not too hard, but whatever). But I fully agree to this. :And hey, you'll have to put together some of these standard-routines :at some time, how are you gonna call this a standard otherwise? The cable is the standard, not the software (although it has got some restrictions). Any program (i.e. a game) can use its own protocol, for it won't have to communicate with other programs than the same on another computer. Which uses the same protocol. 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. It could be called i.e. JoyCom...). But network-programs are not very useful for this. JoyNet is just a cheap, simple-to-make cable which is meant to be used in games or maybe to transfer some files from one computer to another. And a bonus is that it also supports a network, for more than 2-player games. But if one really wants to make a network, then you should just use SCSI or so... it is developed for it, is much faster and a lot easier to use. By the way, I think your (Alwin Henseler) mail is a pretty good 'article'... Do you mind if I put it on my homepage, in some kind of 'tips' or 'ideas'-section??? Ah, my homepage... almost forgot. The Official JoyNet homepage: http://datax.cjb.net/ ~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/)
Re: JoyNet serial transfer routines
I wrote earlier:
It's about the exact time(s) of sampling the bit values of the main
(RxD/TxD) signal. In asynchronous communications, this is based upon
a fixed time for a single bit, determined by the baudrate.
Maarten ter Huurne [EMAIL PROTECTED] replied:
That's synchronous communication. In asynchronous communication,
there is no baudrate.
[EMAIL PROTECTED]replied:
Van: [EMAIL PROTECTED]
Ehrm... I don't wanna spoil the fun, but for JoyNet, we're talking
about asynchronous communication. What you describe here ("...based
upon a fixed time...baudrate") is synchronous comm.
[Which trashes the whole supersampling idea]
I think you are both mistaken here. In synchronous communications,
the exact point in time at which the data signal(s) is sampled, is
determined by an 'extra' signal, an other signal, and with that, the
data stream is SYNCHRONISED with that other signal.
If such an other signal is not used, or not present, the data stream
can NOT be SYNCHRONISED with that other signal, and thus becomes an
ASYNCHRONE communication method. In this case, it is usallly a fixed
timing scheme that determines when bits are to be sampled. Such a
fixed timing scheme is usually referred to/derived from/related to as
"baudrate". This is the common way used for RS-232 communications,
and the same goes for MIDI-connections (also Asynchronous).
Note that for both ways of communicating there IS a baudrate, only
for asynchronous it is determined externally (and needs to be the
same for transmitter and receiver to have it working), for
synchronous this is determined by these 'extra' signals (call it
'bit-clock' or such). Bit-rate and baud-rate are not the same thing
technically, I wouldn't know the exact difference between these
though.
I do not know exactly what method is used with JoyNet, if it uses a
fixed bit-timing, that would make it asynchronous. If it uses an
extra signal, besides the data-carrying signal, that would make it a
synchronous communication (you figure that out).
Besides: if JoyNet only standardises the cable, than that leaves the
programmer free to choose for a synchronous or an asynchronous
communication method. If the number of connection lines in the cable
is such, that no extra lines besides the data lines are available,
then that would automaticly force asynchronous communication to be
used. If not, both methods could be used.
Anyway, my suggestions were just that. Whether you think it's needed
to implement these in your applications, is up to you. Generally, I
think:
-For networkgames, SPEED is crucial, and error-checking not that
important, or not at all
-For data-transfer, speed is not THAT important, and error-checking
might greatly improve reliability. If not needed (with good, short
cables, and/or low speeds) it won't matter, IF needed (under worse
conditions), a proper error-detection mechanism can well be the
difference between something working lousy, and something working
normal, but just a bit (!) slower. That's all. And you should know
that less-than-optimum conditions are more common than optimimum
conditions.
Greetings,
Alwin Henseler([EMAIL PROTECTED])
http://huizen.dds.nl/~alwinh/msx (MSX Tech Doc page)
http://www.twente.nl/~cce/index.htm(Computerclub Enschede)
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/)
Re: JoyNet serial transfer routines
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. And because you'll have to flipflop bit 3 after a read, why not write at the same time? Thus making bidirectional transfer possible. It uses 6 transfers for one byte, and this includes an 1-bit checksum (a copy of the P/V-flag on the Z80, if I'm correct). Every transfer is a send + a recieve, both containing 2 bits (and 1 flipflop). The first transfer transfers an ID-byte, indicating any send-requests plus the checksum. If both computers don't want to send, the transfer stops, if both computer wants to send, bidirectional transfer is used and if only one computer wants to send, the other computer does only read (and send flipflops). The 2nd, 3rd, 4th and 5th are the byte devided in 2-bit parts, and the last transfer (the 6th) confirms if the checksum is correct. Behold, I'm working on this and this is only to let you know about it and to let you critizise (?english?) my idea. So not to use it yourself in your program (although you won't hear a word of me if you do, but in that case let me know). ~Grauw "Yes, I indeed think it's a very good idea." 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/)
